Volunteers abandon projects when the dam breaks. They work, and adapt, and take on more and more, and then one day one small new thing (that an outsider would see as totally reasonable) breaks the dam, all their motivation is washed away, and they quit.
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.
I'd argue this is true for paid positions as well - particularly ones where work keeps getting dumped on one or two individuals to keep up the whole artifice while others move on. Eventually one or both of them have had enough, and then there's no one left who remembers why the spangle is always switched to the left on a daily basis...
I witnessed this situation firsthand, a critical support person quit, and their notice period was basically them trying to teach the PM their job. I remember them laughing as they walked out "he isn't going to remember half of what I do." And low and behold, noone could pickup where he left off.
Those who belong to a small volunteer-based, mostly offline organization, know how hard it is to keep people who will do essential administrative work for free.
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.
> even when people are being paid little attention is given to preparing for transitions, people quitting, people retiring, and so on.
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.
> 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.
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.
Hmm, my 20 people youth organisation had like 5 positions that you had to fill (by law). Elections were generally of the ‘does anyone else wish to run for this office?’ and then ‘does anyone have a problem with this person retaining their position?’ kind.
Meetings had good cookies, so in my opinion it was worth it though.
““You’re late,” Erica told her. There was no malice in her voice, only confusion that someone might risk missing her cooking. She’d poured blood and sweat and tears into building our little community, but the secret ingredient had turned out to be soup. She was a really good cook, and what her magazine and occasional impassioned speeches couldn’t do, an invitation to one of her dinner parties might. It was weird, the way little things like that turned the wheels of destiny. I’ve always wondered if history is missing some story like how the Founding Fathers only declared independence because Martha Washington served amazing stew every time there was a Continental Congress.”
I remember being a part of a volunteer organization. We actually had some assets and so some rental income. Not a ton, but enough to be able to make some grants and do some good.
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.
It is interesting seeing the evolution of open source maintenance in the light of new (or increasing) supply chain attacks and acts of political protest. There always has been a "what is your obligation to quickly respond to a security issue?" expectation around the code and now similar obligatory expectation questions arise on the maintenance process itself.
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.
but then you get self-appointed guys, it seems near finance centers, auto-vacuuming up huge sets of OSS and re-selling it with security assurances. MSFT sells a copy of The Github itself to those with enough money and connections, as I understand, likely via the 60+ countries with MSFT datacenters now
Reselling free services is a time-honored business model (hundreds of years old, probably). It seems a bit “dodgy,” but lots of people are willing to pay for it.
Yep, it really isn't hard to understand. But people don't want to understand, they want to have critical infrastructure code for free, and also with guarantees even though every open source license in existence includes zero guarantees.
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.
I got an email a few days ago saying that a couple of my Python projects were 'critical', and I'm not sure what to make of it all. On the one hand I like working on the software and listening to users and improving it and it's good that a lot of people find it useful. On the other hand I find myself feeling a bit exposed, and feeling a bit of pressure, and that makes it feel like 'work but without getting paid'.
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.
It took me a long time to realize that Open Source does not imply any responsibility unless you want it to.
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.
> If the community decides that your software is 'critical', it is the community's responsibility to maintain it.
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.”
> Paul Moore noted that marking it as deprecated did not work, nor did ceasing releases in 2015; "I'm not at all sure 'tell people not to use it' is a viable strategy for getting marked as 'not critical'."
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.
> I don't get this cult of newness thing. To me there's no shame in a library being "done".
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!
I agree, but in my opinion you shouldn’t be downloading it from PyPI every time you use it in that case, or one day you’ll end up leftpad.js-ed or node-ipc-ed.
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.
It's not about newness thing. It's about software bit rot.
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.
Even a dead man switch is not enough. jwz added a "WARNING: This version is very old! Please upgrade!" time bomb message to xscreensaver's about dialog and Debian removed the warning code instead of upgrading to the fixed version of xscreensaver. Google "I would like Debian to stop shipping XScreenSaver" for details.
Debian is taking care of security maintenance of the software they ship. Now: maybe they will do a poor job of it, but that's another issue than intent; some users misdirect support requests to the upstream, but unless Debian version is misleading them, that's a problem with the users.
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.
I would argue that removing the warning triggers the "you touched it last" clause of FOSS development. I've done this exact thing multiple times, and the complaints always go away.
Maybe we should have security-interested folks develop their own versions of popular open-source software which can then be “critical”, with formal methods. It’s hard to audit or verify an existing codebase, it would likely be a lot easier to just start from scratch.
It would give security and formal-methods people something to do
Im not an OpenBSD insider, but this feels very much like what that team have reluctantly and yet repeatedly concluded that they need to do. LibreSSL and OpenNTPD and pf, for example.
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.
Current approach of commercial and non-commercial organizations to make "critical" FOSS projects fit their (or public) security, code quality, etc standards is doomed to fail. They focus on sheer force or, sometimes, incentives to developers. What part is often overlooked - is the tools, software and legal, to make such moves easier and practical. Recent GitHub and GitLab developments helped to setup static code analysis for many, also security advisories management. Another good example is the OSSFuzz software/program, it helped many developers to understand what fuzzing is, how to use it for eliminating easy bugs, and ease of setup for your project. This is a step in a right direction but still somewhat patchy experience hinders these developments. They should focus more on making it as easy for FOSS maintainers as possible, in uniform way across the ecosystem of languages, frameworks, infrastructures. In commercial world we have mandatory certification and audits, enforced standards, etc. That would never work in FOSS world, since often the "user perspective" of jumping through hoops to get the desired compliance status is absolutely horrendous. Organizations like OpenSSF should focus on making their standards and such void of legalese and compliance-speak, make them as easy as possible to understand for every developer: from JS to C++, from Web frontend to the embedded, from console tools to huge distributed computation softwares. From what I see, this is not what is happening.
With the growing army of opensource developers (and also for benefit of commercial ones) we should coin the new term - MX (Maintainer experience, analogous to developer experience), who would devote all their time to make daily life of sole developers and maintainers easier.
I see no problem with mandating 2FA for all PyPi users, potentially offering free security keys to maintainers of Critical projects as an incentive to adopt even more secure practices.
There ought to be an organization willing to offer these maintainers the option to transfer control to a committee or organization set up to be stewards. Not quite locked and frozen, but say, resistant to change. Security fixes only.
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.
Companies that want to build a business on open source software should fork it and then read it before deploying it to customers (or hire the author). Or hire someone to do that. Programmers gotta eat too.
For most of the us, we'll have to take home some bread for the family and thus no one should assume any commitment on most of the open source contributors as they virtually not even get a dime for all the hard work.
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.
GitHub should standardise a SUPPORT.md or similar file where maintainers could indicate what level of support to expect and how to pay for support. The default would be "unsupported" of course.
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.