Even by that (misleading) metric, it doesn't seem to be dead. Expecting maintainers to tilt at the newest windmill instead of actually maintain is a critical part of why so many in the open source community burn out.
It would be extremely souring to me if Jekyll decided to add webpack and other javascript dependencies with a newer version. One of the things I like about Jekyll is that it's a STATIC site generator that doesn't try to do everything.
Some sites I want to be dead simple, and that's what you get with Jekyll. If I want more complexity I'd go with a more complex generator like Hugo or Gatsby.
That's my impression as well, as an outsider.
A recurring nightmare of mine as a maintainer is that I'll wake up one day and read someone's blog proclaiming the death of one of my projects, when all I've done is stopped adding new features to it. Especially so when it's someone who's made a living for themselves as a downstream user.
And I'm in the same boat as you: I've had a Jekyll-based blog, without incident, for a little bit under a decade now. It's only gotten faster and easier to use over time, which is more than I even asked for.
Changes are very rare other than occasional bug fixes or breaking ecosystem changes, but that doesn't mean the code is bad.
The code is a hammer, you don't need the newest shiniest hammer. You just need the hammer that hits nails.
If I want an SSG, I want an engine that takes a relatively simplistic text markup format, like Markdown or Org, and create a series of HTML documents from it. Why would the technology that does the gruntwork matter to me as an user?
Also, with Jekyll's plugin structure, what is an example of a functionality that cannot be achieved in Jekyll, but can in another non-Ruby SSG?
It's kind of interesting to me that the author opted not to use the Github "fork" feature to start Bridgetown, and there's no reference to Jekyll in the README (and hardly any in the git history either). This strikes me as an odd way to respond if the concerns are for the health of the upstream project; it would make sense to reach out and try to work with upstream if they aren't doing what needs to be done, then explain why a fork is needed in the README.
Jekyll itself is a project that still receives active commits and continues to do everything I ask of it (and indeed, it seemed essentially feature complete for my uses years ago).
It's literally at the top of the article.
Sounds like a "Hotel California" repo now, if you follow me. Which is unacceptable for a lot of distributors/users (are they just going to package random git HEAD snapshots whenever they feel like it, now that releases are apparently de facto banned?).
Deviations from their previous release schedule are certainly noteworthy, but release schedules also naturally length as projects mature.
And then there's the Theseus-type questions: if Jekyll changes its name because the current maintainers have lost access to the RubyGems credentials, is it really not Jekyll anymore? It occurs to me that OSS is replete with `${project}-ng` namings, the `ng` suffix typically indicating that the project serves the same purpose as its original form but has been moved to a different namespace for whatever reason. If Jekyll's current maintainers were to publish `jekyll-ng` on RubyGems, I'd be inclined to call that a continuation of the original Jekyll for all extents and purposes.
At this rate, if the release maintainer continues to ghost the project (including by refusing to make any clear public announcement), Jekyll users are going to have to fork. You can't wait forever.
> but release schedules also naturally length as projects mature.
That's why I pointed out they had been maintaining a very steady monthly release schedule for years beforehand (and just look at the total release count!). Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!"...
This is a point of confusion, since GitHub now has a few different things that could be called "releases": tags (a Git thing), tags that are labeled as "releases" (a GitHub thing), and released packages via one of GitHub's package indexes (including one that behaves like RubyGems).
Anybody who has push access to a repository should also have access to the first two, and probably has access to the third. The first is a Git-level consequence of access, and the second is just sugar on top of tags ("releases" don't behave any meaningfully different, and many projects do releases without using the release labeling). IOW, they should have sufficient permissions, as-is, to continue cutting releases. They might not have sufficient permissions to publish those releases to RubyGems, but that just means renaming the package to `jekyll-ng` or using GitHub's index instead.
> Plus, "maybe they don't need to do a release" is rather contradictory with "this project is in rude health, look at how many patches they're receiving piled up in the (unreleased) HEAD!
Yeah, these facts are in tension. Then again, looking further, a lot of the recent activity has been documentation and dependency tweaks, along with some light backporting activity (since they're also continuing to support Jekyll 3). So I think the needle I'd thread here is: "the project is receiving active attention, but is sufficiently stable to not warrant regular releases."