Published 2025-10-16
(A few edits for clarity 2025-10-17)
tag(s): #yell-at-cloud #programming
I am not a user of RSS feeds. I only added one to my site after a couple people asked, via email.[1] But...lately I follow enough blogs that checking for new posts in my bookmarks has been a bit of a chore. In particular for rarely-updated blogs.
If I had to use a reader, I would go for either Newsticker (built in Emacs reader) or Elfeed (by far the most popular Emacs reader).
The problem is...I read blogs in my personal laptop and my phone. Sometimes at work too. So I need a way to "share the state" between Emacs instances, plus a solution to sync with an iOS reader. What to do?
Well, I could use a third party service! And then all devices would share the same
"state". But since I now have a
VPS, I could instead host my own RSS aggregator! Looking at lists of self-hosted software,
there's a ton of them. Which one to choose?
I want something minimal, that "just works". I don't care if it has extensions, or it is super
configurable. And ideally built with Python...
I was checking out a blog post that compared a few of these self-hosted readers, and the guy
did an OK job.
Except that every single review started with the GitHub stars count and
date of last commit. And points were deducted from the review if the commit date was "not
recent enough".
Since I can only be a curmudgeon once per night, I am picking on "date of last commit" for today's rant.
I was guilty of those crimes too[2], until I read a few years ago the
excellent, and still relevant,
"A road to Common
Lisp" by Steve Losh. In particular the sections "Escaping the Hamster Wheel of Backwards
Incompatibility" and "Practicality Begets Purity".
Sure, Common Lisp is blessed with being particularly immune to bit rot, because of the curse
of its specification being untouched since 1990.
And it gets away with it because the language (and ecosystem) has the ability to add new
features without touching said spec, in ways that no other can.
But there's a deeper lesson there, one that I was thinking about when, some time after reading that post, I was evaluating libraries for some work thingy[3].
My advice is this: as you learn Common Lisp and look for libraries, try to suppress the voice in the back of your head that says "This project was last updated six years ago? That's probably abandoned and broken." The stability of Common Lisp means that sometimes libraries can just be done, not abandoned, so don't dismiss them out of hand
What if one of these libraries is done?.
And I will be honest, I had been programming for a long time by then, and either this thought
never occurred to me...or I had forgotten the possibility, caught in the whirlwind of constant
updates for everything.
This is not unlike a mini-revelation that I had around 2011/2012, that I didn't "need" to be
on top of every language/framework/major library release.
Eventually I would work with them, and then I can get caught up, or the update would never be
relevant to me.
This sounds silly, but it was a huge relief. It helped me slow down a lot.
Maybe even helped me "go deeper" into some stuff, as a developer? Mmmm I know I gave myself
permission to exaggerate a bit in the post, but that sounds like too much. Anyway.
I am not saying "date of last commit" isn't important. I am saying that you can't only look at it as a measure of a project's health, unless you also consider...
If a repository has a library that's been built since 1999, then I would expect it to be stable enough that it doesn't need to have recent commits to be useful. But you also have to consider...
When a project's scope is big enough, it is going to be perpetually fixing bugs.
But if a repository hosts a small GUI application, that has a single window with two file
pickers and a button, maybe it is done? Done-done? But you also have to consider...
In the same post quoted above, Steve says: My current day job is in Scala, and if a
library's last activity is more than 2 or 3 years old on GitHub I just assume it won't work
without a significant amount of screwing around on my part.
.
So yes, if a Python repository hasn't been updated since 2011, I would look closely to make
sure it is actually Python 3 and not Python 2. 🙃
But maybe a project's last commit is in 2016. It depends on Requests and the built-in CSV
module, and some smaller PyPI projects that are also stable...then, it is fine?
I still don't know which one I will pick. Or if I will take the opportunity to build something
on my own,
very basic. Like, not even a proper aggregator: just a SQLite database, and regularly update
a list of feed entries. Which I then manually mark as read in a very plain-looking front end.
Sounds good?
No, it doesn't, to be honest.
But, as far as evaluating the different projects: since I am interested in something as small as possible in scope, and the more conservative in library and platform choices, the better...I wouldn't look as "date of last commit" as a very good metric.
Feature creep everywhere.