This and other recent threads here about OS development make me wonder, how many OS projects set deliberate and specific rules to safeguard the sanity of the maintainer and prevent burnout and distress?
I'm sure I've seen at least one solo dev GitHub project where the maintainer has said something along the lines of "I maintain this in my spare time and predominantly for my own purposes, so I'll definitely fix bugs that affect me directly, but I'll do this at my own pace and you may need to be patient, and other bugs will require contributions from other developers, but I can't test those so I can't guarantee those fixes".
Obviously, this applies only to a certain class of project. Probably single maintainer, and going through a growth in popularity, and an issue list that has started to grow and diversify.
Larger, highly popular projects set clear boundaries, and will reject issues simply saying "platform not supported" or similar (for better or worse).
I guess I'm wondering if there could be a collective push-back against the burnout and stress that OS maintenance can induce. Is there a well defined 'code of conduct' statement somewhere that puts the health of the maintainer first, maybe with some nice badges and boilerplate text to pop into the readme.md and wiki and issue templates?
I appreciate that popularity and GitHub stars have become career currency, that smashing out thousands of LoC over the weekend is a badge of honour, and that people can get abusive if their issues aren't fixed ASAP. But this is well recognised as a toxic situation, and requires recognition and pushing back.
I'm not aware of a maintainer friendly CoC, I agree it would be needed.
CoCs currently all follow the same pattern: A group composed of a mix of corporate and entryist developers want more power and write a pamphlet that promises the respective project to the masses.
It encourages rudeness and demands to the core developers who actually do the work. The worker developers are expected to remain silent, smile and burn themselves out for the collective.
The winners are new "contributors", the nomenklatura and their corporations.
A code of conduct doesn't teach people to say no, which is what is required when you write OSS. You will get demands (ranging from slightly to breathtakingly rude) on every channel that can even remotely be traced back to you. The more popular your software is, the worse it gets. That's leaving aside the toxic fellow devs (who will yell at you for presumably different but generally entirely inscrutable reasons).
I think that if we could talk to some of the originals from the 70s, how big a deal "maintenance" in software. Code doesn't rust, but it kind of does. That really dictates a lot of the dynamics in ways they would have never predicted.
> the ongoing maintenance of many widely used software components relies on the collaborative effort of volunteers who set their own priorities and choose their own tasks. We argue that this has created a new form of risk that we call 'underproduction' which occurs when the supply of software engineering labor becomes out of alignment with the demand of people who rely on the software produced.
Someone in the know please correct me if I'm wrong, but isn't this risk precisely the reason that large companies such as Google et al assign some of their experienced developers to work on open source projects full time?
Don't get me wrong, this risk of "underproduction" no doubt applies across many FOSS projects and is thus a good measure to take into account - but I wonder whether the impact of said risk is somewhat more contained than we'd be led to believe.
It is quite ridiculous and offensive to name it "underproduction".
If I am making something for free, or for minimum amount of money, or based on unstable funding - then I am doing because I want to do it, and because I produce something that I like or want to exist.
Obviously, I am not going to code features useful for oversized corporation that are neither useful nor interesting for me. If they want this features - they will need to hire people, and it is not my problem.
I think most big companies tend to assign devs when they get some bizz value out of it. Sure that can be a hedge against abandonware, but i think most of the time they're looking for a more direct benefit.
I've noticed this in the Rust embedded community, especially with STM32 HALs. Each MCU family is run by its own maintainers, and despite the overlap in the hardware, there's fragmentation among features and code style among between the HALs.
The part about priorities is especially relevant - A user of the library may care mostly about features, and correct implementation on a hardware layer, while the repo owners (who don't have much time available) stall bug fix and feature PRs over code style disagreements, long-term maintainability concerns, or not (no longer?) having the time available.
The code style issues can turn what looks to a use to be a clean kill (fixing a bug, adding a peripheral), into an extended back-and-forth, where one party loses interest.
[+] [-] austinjp|5 years ago|reply
I'm sure I've seen at least one solo dev GitHub project where the maintainer has said something along the lines of "I maintain this in my spare time and predominantly for my own purposes, so I'll definitely fix bugs that affect me directly, but I'll do this at my own pace and you may need to be patient, and other bugs will require contributions from other developers, but I can't test those so I can't guarantee those fixes".
I can't find examples right now, but I'm sure I've seen it happen. (Edit: see thread here https://news.ycombinator.com/item?id=26625461)
Obviously, this applies only to a certain class of project. Probably single maintainer, and going through a growth in popularity, and an issue list that has started to grow and diversify.
Larger, highly popular projects set clear boundaries, and will reject issues simply saying "platform not supported" or similar (for better or worse).
I guess I'm wondering if there could be a collective push-back against the burnout and stress that OS maintenance can induce. Is there a well defined 'code of conduct' statement somewhere that puts the health of the maintainer first, maybe with some nice badges and boilerplate text to pop into the readme.md and wiki and issue templates?
I appreciate that popularity and GitHub stars have become career currency, that smashing out thousands of LoC over the weekend is a badge of honour, and that people can get abusive if their issues aren't fixed ASAP. But this is well recognised as a toxic situation, and requires recognition and pushing back.
Edit: As if by magic, yet another thread has appeared relating to the pressures of maintaining software, bug etiquette etc: https://news.ycombinator.com/item?id=26625461
[+] [-] frankfurter10|5 years ago|reply
CoCs currently all follow the same pattern: A group composed of a mix of corporate and entryist developers want more power and write a pamphlet that promises the respective project to the masses.
It encourages rudeness and demands to the core developers who actually do the work. The worker developers are expected to remain silent, smile and burn themselves out for the collective.
The winners are new "contributors", the nomenklatura and their corporations.
[+] [-] krageon|5 years ago|reply
[+] [-] dalbasal|5 years ago|reply
I think that if we could talk to some of the originals from the 70s, how big a deal "maintenance" in software. Code doesn't rust, but it kind of does. That really dictates a lot of the dynamics in ways they would have never predicted.
[+] [-] keenreed|5 years ago|reply
[+] [-] herodoturtle|5 years ago|reply
Someone in the know please correct me if I'm wrong, but isn't this risk precisely the reason that large companies such as Google et al assign some of their experienced developers to work on open source projects full time?
Don't get me wrong, this risk of "underproduction" no doubt applies across many FOSS projects and is thus a good measure to take into account - but I wonder whether the impact of said risk is somewhat more contained than we'd be led to believe.
[+] [-] matkoniecz|5 years ago|reply
If I am making something for free, or for minimum amount of money, or based on unstable funding - then I am doing because I want to do it, and because I produce something that I like or want to exist.
Obviously, I am not going to code features useful for oversized corporation that are neither useful nor interesting for me. If they want this features - they will need to hire people, and it is not my problem.
[+] [-] bawolff|5 years ago|reply
[+] [-] altsalt|5 years ago|reply
[+] [-] the__alchemist|5 years ago|reply
The part about priorities is especially relevant - A user of the library may care mostly about features, and correct implementation on a hardware layer, while the repo owners (who don't have much time available) stall bug fix and feature PRs over code style disagreements, long-term maintainability concerns, or not (no longer?) having the time available.
The code style issues can turn what looks to a use to be a clean kill (fixing a bug, adding a peripheral), into an extended back-and-forth, where one party loses interest.
[+] [-] medstrom|5 years ago|reply
[+] [-] unixhero|5 years ago|reply