“Critical” projects and volunteer maintainers
lwn.net
lwn.net
I've seen this happen much more often than I've seen volunteers gracefully leave a project with a smooth transition to a replacement person or persons.
If you are using volunteer-maintained software in a "critical" part of your business, you should be prepared for this.
You can hold elections, people can have fancy titles, but frequently there's still only one person if you're lucky who will "run" for office. And so they can't be fired, and if/when they burn out and quit, the organization may crumble.
When I think of the sort of person who is unreasonably demanding of an open source maintainer, I think of the sort of person who is on LinkedIn and has padded their resume/profile with various wholesome volunteer gigs.
But this is a contradiction - because if the latter is true, they should be intuitively aware of the dynamic.
Also, another expectation I would have is that anyone with more than a year or two of corporate experience would know that even when people are being paid little attention is given to preparing for transitions, people quitting, people retiring, and so on.
Clearly there are some significant false premises buried somewhere.
I was looking at some contract jobs that seemed to be examples of a manager outsourcing the problem of finding a replacement that will somehow take responsibility while probably no longer having any access to the skills to interview them.. So in corporations there's a kind of eventual consistency if the replacement is actually essential.
I think that in these cases you don't actually have an organization, you have an elaborate ritual to convince a single person to facilitate the activity that you wish to happen.
This can be true in local chapters of fairly sizable and well known national organizations.
Meetings had good cookies, so in my opinion it was worth it though.
-- https://unsongbook.com/chapter-5-never-seek-to-tell-thy-love...
It was still really tough to find people to be officers and do what needed to be done to keep the org running.
There were those 10-20% who stepped up and took roles (president, chairs of committees). Some had different ideas on how to do things, but I was absolutely grateful they stepped up, even if I might have done things differently myself.
This is a truism in running volunteer orgs well: you get to pick from the people who show up, not the people you wish had shown up.
And often "willing to donate time at all" is a higher priority skill than any subject matter expertise.
We also see what seems like rather balkanized approaches (npm, pypi, cargo, ...). It would be great if broader consensus arose on what the ideal standard should be for package management and distribution that then those projects could adhere to. Similar about commit access to repos and what the requirements there should be.
It's also peculiar how much stronger the guarantees you get from your operating system vendor are w.r.t. signatures on packages vs what the underlying projects themselves have. OSs have had this pretty well handled for decades, but no common best practices like 2fa, signatures, etc seem to have emerged.
Seems like something like this, but which employed/funded the maintainers might be ideal.
If you want guarantees, you need to put them in place yourself, or pay the maintainer to give it to you. There really isn't anything else to this debate. Stuff like `cargo vet` is just trying to circumvent the issue by making it easier for users of the free labour of others to associate and vet updates, still avoiding paying anyone else but themselves - which may work in some cases, even when it seems to de-value the actual authors of such work as being in need of the veto of somebody else, but we'll see.
You really need actual programmers contributing. Ideally large enterprises would give time dedicated to this and help maintain more projects.
But everywhere I've worked (FAANG included) has had more managers than engineers so I can't see it becoming commonplace.
Seems way too many people (or organisations) have forgotten that.
The thing I liked about doing open source in my spare time is that there was absolutely no pressure and I could take as long as I wanted to ponder the technical details and there was a kind of purity to it. Now it feels like there's a sense of expectation that I need to fulfil.
If the community decides that your software is 'critical', it is the community's responsibility to maintain it.
We, as maintainers, of course should try to help. But if I'm on vacation, or just simply don't feel like programming, that has to be acceptable. If somebody needs professional support and guaranteed availability, they should pay people to do so. I think this is the central tenet of spare-time OSS maintainership.
Perhaps we'd need a sponsorship model: A button on Github where a customer can negotiate a price with a maintainer for a particular feature or bugfix.
Yep.
I think the PyPI team needs to get a lot of responses along the lines of “Let me know if you’d like to fork this ‘critical’ code, or if the obligations imply you’re prepared to pay reasonable professional consulting rates? I’m happy to remove my code from your index if required.”
Apparently you need to encode some dead man switch in your code if you want to stop supporting it.
Like blowing up X years after the last release or deliberately not working on some future version of Python/Ruby/whatever. But OTOH these automatisms are more code and code that might go off when they shouldn't. They make code more brittle.
Then somebody would need to actively step in and change the code to make it work again.
If the maintainer abandoned it and it's working to your satisfaction in production, why not leave it alone?
If it breaks you debug it yourself ... But if anything is sufficiently important, you'd probably still debug it yourself even if it were maintained.
Exactly! There is nothing better than a library that's truly done. That's rare, sure, but it's the ideal state. All bugs are fixed, it does exactly what it set out to do and it is stable since it never needs to change again.
If only all my dependencies could forever be libraries that are done!
It can be hard to work out when it’s the right time to commit a “done” version of a dependancy into your own repo, but the risks of not doing so are real and have bitten many people.
Every piece of software lives in an ecosystem. Libraries even more so. Unless the ecosystem is dead, there are always small changes over time until the code is outdated and should be replaced or redone.
This has happened with lockfile. It has been superseded and shouldn't be used anymore.
You say if it ain't broken don't fix it. That's only reasonable if you can say with 100% certainty that it won't break ever in the future. Otherwise you're building software debt.
The point of free software is to be free. If you do not wish people to be allowed to use and maintain it, and if you wish to have the possibility to "unpublish" or make old version non-free, you should use a non-free licence to begin with.
It would give security and formal-methods people something to do
There's also the risk implicit in a stack with no single authority, which is a difference between a combined OS and runtime like the BSDs and the Linux distros. RH and Canonical do the lords work keeping up, but its never really going to be the same as the BSD people and their tight coupling.
This probably makes me sound like a BSD bigot, which is not my intent, but it does seem to me that there is a cost to all this flexibility that Linux pays a high price for.
Perhaps the Linux Foundation would sponsor something like this? A package that hasn't been updated since 2015 should be considered frozen, not a long term risk. End of life open source projects should be safe to use, not undetonated warheads.
https://news.ycombinator.com/item?id=32026624 "Atomicwrites' old versions have been purged from PyPI"
https://news.ycombinator.com/item?id=32037562 "Congratulations: We now have opinions on your open source contributions"
https://news.ycombinator.com/item?id=32061428 "Yes, I have opinions on your open source contributions"
https://news.ycombinator.com/item?id=32058053 "PyPI is rolling out 2FA for critical projects, giving away 4k security keys"
On the other hand, some large companies make tones of money from offerings based on open source projects. Despite they deem those open source projects as critical, they still don't want to spend a cent on them. I remember there were cases some companies demanded some authors to fix bugs for free quite a few times so that they could fix issues in their production environments.
Maybe it's time for the maintainers to throw the towels and take a break. It looks like those so called critical open source projects are not so critical after all.
"This software is distributed as-is with absolutely no warranty.
Really people relying on open source packages should actually fund those packages.