Done, not abandoned
When I’m checking out a new app, one of the first things I look at is the last updated date in the App Store. A recent date is a green flag. Last updated 2 years ago is a yellow one. Has the developer wandered off? Is this thing dead?
That instinct isn’t crazy. Plenty of software does just stop because the person making it loses interest or runs out of time, and a stale “last updated” line is often the first sign. But it isn’t the only reason a piece of software might go quiet. Sometimes the developer hasn’t gone anywhere. They’ve just decided the thing is done.
I want to be careful here. I’m not arguing that “done” software is better than software that keeps changing. There’s plenty of software that genuinely needs to keep changing — operating systems chasing security disclosures, browsers chasing the moving target of the web, products with real competitors that have to keep up. There are also products on growth treadmills for less edifying reasons, but even then getting off the treadmill often isn’t an option for the team running them. None of this is what I want to push back on.
What I want to push back on is the assumption that quiet equals dead. The last twenty years of software have trained us, mostly correctly, to read constant updates as a sign of vitality. The flip side of that training is that anything not getting constant updates starts to feel like it’s failing some basic test of liveness. No new release in a year? Probably abandoned. That shorthand catches a lot of true positives. It also catches things that aren’t broken at all.
The example I keep coming back to is games. There are plenty of modern games on indefinite update cycles — live-service games, online shooters, anything with a season pass — and that’s fine, it suits what they’re doing. But there are also classic games that shipped, got a handful of patches, and never got updated again, and they’re just as fun to play now as they were the year they came out. Tetris didn’t need a roadmap. The absence of patches isn’t a defect; the game just works.
Software that does a defined job can be like that too. Not all of it — but more of it than the last updated date suggests. A static-site generator that takes markdown and emits HTML isn’t going to need quarterly redesigns to remain useful. A keyboard remapper that sits between a USB device and the OS doesn’t need a roadmap. A web service that filters RSS feeds will just quietly keep working. Software that’s bounded by a finite problem can be finished in a real sense. It doesn’t mean nothing ever changes — security patches happen, browser quirks get worked around, dependencies get bumped — but it does mean the software has stopped chasing.
That’s where I’m aiming with FeedFilters. The plan is to get it feature-complete sometime this year, and then move on to other projects, checking in every now and then to make sure things still work. There are still a handful of refinements I want to make. I’m also open to ideas from people who actually use it — the core is small and I’m sure there are good suggestions I haven’t thought of. But the whole concept only goes so far. There’s a horizon to this project, and once the work is up to that horizon, the work is done.
Part of the reason I’m writing this post is to say so out loud, ahead of time. If someone finds FeedFilters in 2028 and notices that the last post on this blog was from a year ago, I’d like that to read as the state I was aiming for, not as a sign that I bailed. I’ll still be around if something breaks. Most of the time, though, nothing should need to. That’s what done is supposed to look like.