Earlier quoted context omitted.
Closely related, I wish we had a better way of saying a library or product is now feature-complete. We use recent commit activity as a proxy of viability, but all of that churn could just as easily be an indication of immaturity. It's okay for tools to achieve their objectives and just live on as stable code with maintenance releases as needed. To my mind, Jekyll is feature-complete. The only changes I've needed to m…
I get what you're saying, and for single-purposes libraries or other simple infrastructure, that totally makes sense. But Jekyll lives in a wider world of vital tools from Gatsby to Eleventy to Hugo to (fill in the blank of your favorite SSG), and if it can no longer serve its main audience relative to compelling alternatives, it's not feature-complete, it's obsolete.
I think there's probably two levels of discussion going on here. In very broad terms and with a generous scope of "we", we largely treat anything written in the last 15 years differently than anything that came before it. I don't know if it's because GitHub makes it so easy to see source or because recent languages have public repositories or something entirely different. But, no one looks at `bzip2` or `dig` and dismisses them as being obsolete because they don't have a hockey stick shape on the commit graph or because they don't serve multiple possible functions. To qrush's point, there has been a recent push to create "modern" implementations of system utilities and so we now have `ripgrep` and `bat` and maybe those new tools will reign supreme. But, I don't think that means `grep` or `cat` are dead and it's fantastic that they've worked reliably and consistently for so long (minus GNU vs BSD differences).
So my lament, if you will, is software being declared dead just because activity on it has slowed down (or essentially ceased). I think another way to interpret that data is it's mature and stable. I think it's great that Jekyll is a reasonably stable utility that I can rely upon. I can even install it via `apt` now and not have to deal with the mess of maintaining a Ruby environment. I can push a commit to GitHub and have a high degree of certainty that my site will generate the way I expect and that can match what I see on my own local system.
That level of maturity is something I'd like to see more software approach. In my experience, constantly chasing use cases often transforms a tool or library that was great at one thing into a tool that is okay at best at several things. Breaking compatibility is a good way to start annoying your supporters.
Maybe Jekyll won't be adopted for greenfield projects and that'll lead to its obsolescence. I just think that's a premature proclamation. It has a massive installation base via GitHub Pages, so stability is likely the better lever to pull.