> SQLite is maintained by... 3 guys. ... And they don't accept public patches or fixes.
> "SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution."
This doesn't feel like a great example; it seems like if those 3 guys got hit by 3 buses, the source being available means that someone could fork it. (Assuming the license allows it.) At worst, folks could compile it for their own use.
I once gave the "cross train so you don't have a bus number of one" speech to a bunch of managers.
Got some push back from one middle manager who said the complex driving their business line was understood by someone had been there by 20 years and was getting rebuilt in a year or two and there's no point in wasting anyone's time meanwhile.
I saw them a few months later where I got a free lunch as an apology. The only man who understood the complex code died of a heart attack while trying to prepare the next release. No one had a clue where to start making the required changes.
And you know what? That's not my only story of someone dying and no one being able to figure out the code that only they understood.
Agreed. The TZ example is a lot stronger. That said, the overall point -- that the stance of these mega corps that rely on these projects do very little to ensure their longevity -- is well made.
If you follow the tz mailing list you will see their are many willing volunteers that would step up if needed. So I don't think even this is a good example..
> What happens when that person gets bored with the project... or decides to do something malicious (as in the case with a recent backdoor in the XZ compression tool)...
The maintainer of the xz compression tool didn't do anything malicious. This statement is incorrect and damaging.
sqlite already had an active community fork started by Turso called libsql. They are fixing longstanding API gaps the upstream team isn’t interested in supporting. For example, they added a native write-ahead log API, so you can plug directly into the WAL for streaming replication. This is possible-ish with upstream sqlite + LiteFs but litefs has to implement a whole FUSE file system and can’t run on Mac for that reason.
It’s more risky to run libsql because new features mean new bugs, but it seems worth it to me.
A detailed analysis of what would happen if Linus Torvalds got hit by a bus was conducted[1] as far back as in 2000. Unsurprisingly the result showed this would most likely have had a devastating impact on the development of Linux.
But it's also the beauty that a few people can create so much value.
And how many of these projects couldn't be picked up and urgently patched if the proverbial bus does come along? Like it wouldn't be pretty, but would it be possible?
They really assume entangling hobbyists into corporate/academic politics/bureaucracy would improve anything? Because these inevitably follow the money. Be careful of what you wish for.
A solo maintainer getting hit by a bus can be mitigated by forking the repo by other interested contributors. A more malicious scenario raised by OP is a solo maintainer with little to no funding getting enticed by a nation state actor to add a backdoor, a supply chain attack proven to be very feasible by the recent XZ library incidence.
> "SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution."
This doesn't feel like a great example; it seems like if those 3 guys got hit by 3 buses, the source being available means that someone could fork it. (Assuming the license allows it.) At worst, folks could compile it for their own use.