A couple more examples I can think of:
- jq: https://stedolan.github.io/jq/
- pass: https://www.passwordstore.org/
- tokyo/kyoto cabinet: embedded key value database
- awk: text processing tool / programming language
- (almost per-se) any game that shipped on physical media
Besides X11, there's the Web for stability, or at least a subset of it. That's a subset of the subset that includes everything that has been standardized, implemented, and widely available since let's say 2000, 2005 or so. It's perhaps one of the most stable pieces of technological infrastructure that we have examples of. But in the face of this, we have people advocating that we throw away this stability in favor of another approach (Gemini) that is supposed to deliver on some vague promises of fulfilling its purpose better than HTTP does. In reality, it looks like another example of NIH and the flakiness of hobbiest programmers' fleeting interests and will probably be deader 10 years from now than Flash. Whatever the case ends up being, Gemini is needlessly incompatible with existing Web infrastructure, given its advocates' ostensible priorities of stability (and it goes beyond mere irony, considering the places where they are similar--but just not similar enough to be compatible).
In fact, they're both classic examples of the opposite approach to what my article argues for: they did not start saying "no" to ideas. They never constrained their scope to focus on stability and longevity. A website which works today could easily be broken tomorrow, which has only become true in recent memory. These are excellent examples of the consequences of not holding true to the ethos I describe.
But that's not what's going on. As of today, what's written above about Gemini is true. Gemini is NIH, and it's definitely not a picture of stability. Despite the entire "ethos" of the project, it manages to project a worse sense of its own dependability, right from the beginning, than the Web does. Given all the bad stuff that can be said about the Web, that's saying a lot. Here's what you can't say about the Web or Gemini: that it's "Becoming a tool which 'just works' and can be depended on without a second thought". But the reason you can't say that about the Web? Because that's what the Web already is. There is no "becoming" involved. This is unlike Gemini, for which there is also no "becoming", but that's because that would imply there's a possibility that Gemini will ever get there, of being anything more than the computational equivalent of a fidget spinner that it is. Here's the best you can say about Gemini, even if you're predisposed to look at it with unmerited optimism:
Hey, folks. Step up and build your world around the opinions and whims of a bunch of people who showed up yesterday and decided to make something new because it felt like a good way experience self-fulfilment at the time. It's not the Web, because, you know--because of bloat. And it's important to say "no". Ah, yeah, that makes sense. Sounds good, too. So we're gonna go with that. And it's not Gopher, either, because... well, just because. But pay no attention to that! Gemini is the product of brilliant programmers who think the right way and are totally committed to dependability.
But once you start to consider forms and interactive content, the possibilities for expanding interactivity are near endless: raster or vector maps, the spam bot / capcha arms-race, custom form widgets (ie. better dropdowns, file upload dropzones, datatables, drag/drop items), different connection types or wire protocols (XML/JSON vs. binary formats, Websockets, WebRTC, QUIC, more UDP-based stuff in the future), rich API's like payments, hardware security dongles, and social networks (webmentions/activity-pub/etc).
Kind of like Excel, these are each must-have's for some industry or app. Each one requires a different 10% of core features to work. So, we need them all if the web is going to be an application delivery platform. And for better or worse, it is the current de-facto standard cross-platform apps.
But I think this shows an interesting effect: platforms are very unlikely to ever be feature complete. Whereas distinct pieces of software are. PDF is another example of this kind of scope creep.