Dumb Ways for an Open Source Project to Die

The framing assumes the ratio of "problem-and-solution" projects to "personal-brand" projects has shifted. I'd push back: I think the underlying ratio is roughly the same — what's shifted is what gets published.

The work of running an open-source project (issue triage, security disclosures, contribution guidelines, CI, release cadence, dependency maintenance) is way higher than the work of solving the original problem. People with the "here's my private workflow tool" mindset increasingly don't publish at all because they can't afford that tax. Meanwhile, anyone seeking brand-building benefits IS willing to take it on, because the brand-building is the point.

So the visible OSS landscape over-represents the brand category not because solution-sharing died, but because solution-sharing acquired a 10x maintenance overhead that most people now opt out of. I see it in my own dotfiles — full of small tools I'd happily share if "share" still meant "drop a gist." It doesn't, anymore.

Dependency bloat and dependency bitrot have made solutions less permanent, have increased the maintenance burden. My ancient projects with zero dependencies still stand. But projects I built on shifting dependencies are rotting and cracking.

Its also become lots of people demanding fixes but not many contributing them.

And there was a definite shift from sharing toward evangelism.

For example C was shared, C++ was evangelized. The difference is the effort put into convincing people to adopt your stuff.

Java for instance was mega evangelized, Sun thought it might reverse their fortunes.

Linux was initially “here you go, hope it works for you” but then it attracted many people who decided to create an ecosystem around it.

I imagine there's a similar same number of those style projects out there.

However, the amount of devs have grown exponentially, and the number of non-niche problems without a solution have dramatically decreased.

There was a time when web meant sharing your hobbies with supportive anonymous strangers, a time when crypto meant doing clever things with numbers.

In my experience you can pretty much always bet on greed, money, and psychopathy to ruin anything that reaches beyond Dunbar's number.

It's sad when your playground gets overrun by drug lords (metaphorically speaking); I don't really have an answer to that. It's my central trauma.

Occasionally though, rather than petering out, you get a rage-fork that does something good.

The io.js fork from node back in 2014 or 2015 springs to mind. IIRC there were a bunch of changes/improvements that needed to be made to move node forward and Joyent were dragging their heels (a V8 upgrade might have been one of them but it's been so long I can't remember for sure). Some of the core devs were getting fed up with how long all of this was taking.

So a group of them forked off io.js from node, did the upgrade and a bunch of other improvements, and eventually all of that was folded back into core node, and everyone was happy with the final result.

But I think we could have found ourselves in a world where we'd all be using io.js rather than node had it turned out slightly differently.

This. The core problem is that people assume that all software is necessarily unreliable.

The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole.

Not all technologies change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?

According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.

Different times. The need to patch for security updates alone is increasing rapidly.

It seems not at all surprising that the “other side” of a fork would view it somewhat negatively. The person planning the fork presumably views the mainline project maintainers somewhat negatively in that moment as well.

They can be as hostile as they want; that seems nearly irrelevant to the fork decision. If the mainline won’t take a patch or wants to go in a different direction, forking seems perfectly valid and they can keep their empire. That seems fine; they didn’t want to go east, the fork going east means that those users who also want to go east can be served.

I've invested time working with a project like that and it's kind of heartbreaking to see it lose its way and become a total mess. It's tempting to fork and try and go back to its roots, but that has its own problems e.g. needing to invest a magnitude more time.

So much this. Everyone has their own idea of that the project should do and it's hard to explain that whilst that implementation is great for their specific use case, it's pretty shit for everyone else.

AI has just made this so much worse.

Ignoring the GitHub Pages issue, What does Jekyll 4.x not-do that you want it to do?

I wish more projects would archive themselves to send a clear signal.

The missing piece there, that would be a real value-add over normal package repositories, is that functions can be small enough to simply be done. Function gets marked as such, it can no longer be updated, thus eliminating the risk of supply chain attacks and their ilk. IMO, most packages I actually use, with the exception of web frameworks, ought to fall into this category. My JSON parser should never update. My Knapsack-problem solver should never update.

These are problems that are hairy enough that I don't want to write my own solution, yet tractable enough that there ought to be a solution that never needs to be touched again. Maybe someone finds a better way of doing it, but the way they're currently doing it will never be wrong.

There are a few usecases for this in some languages, where your functions might as well be class extensions. But you need a huge standard library with non-competitive types, or you end up with deep dependency stacks.

You also run into trouble if your language has side effects (ie, almost all of them). A leftPad that launches a fiber to mine cryptocurrency or sends an http call that fires nuclear missiles can still pass tests. It's hard to guarantee hygiene via tests alone.

Your comment is easily misunderstood, my first thought was also “that’s NPM” - but the idea of providing tests and types without implementation is a pretty interesting one.

> remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions.

Like leftpad?

> Someone [...] pissed the maintainer off enough to stop working on it

FTFY, e.g nvim-treesitter:

https://github.com/nvim-treesitter/nvim-treesitter/discussio...

it says so at the end of the article

It sounds like the maintainer you're describing was underhandedly helping their users with the silent expectation that they also contribute back to the project and got bitter when it didn't happen that way.

Open source is altruistic, remember. You explicitly tell the world that you are happy for anyone to only take from the code what they want for their own needs and never contribute back. If you don't want to help users or develop your software alone, an alternative is to sell the software and support service to users and use the money to hire developers.

>The Melbourne Metro safety campaign this post is named after closes with “be safe around trains,” which is more actionable than anything I’ve got.

so, just be safe about it, i guess.

The key term is "responsible sunsetting".

Pay people