4 ms·

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 ma

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". 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 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 https://news.ycombinator.com/item?id=26625461

krageon 6y ago
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).
- austinjp 6y ago
  Agreed, although it would give the maintainer and other contributors a simpler way to say 'no'. They can point to the rules and say "that's the way things are here". This might also help them shrug off the sense of letting people down, which I think would be helpful. To predict a possible issue (not from you krageon, just in general): I doubt there would be significant risk of this being abused, like, by a lazy dev who would use "the rules" to avoid code they didn't want to fix even if it was clearly in scope. Obviously, this would always be a judgement call, and that's the way things currently are anyway.
frankfurter10 6y ago
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.
keenreed 6y ago
Yes, there is code of conduct. It is called consulting and gimme money! Most big projects have that :)
dalbasal 6y ago
This is super tangent but... 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.

krageon 6y ago

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).

austinjp 6y ago
Agreed, although it would give the maintainer and other contributors a simpler way to say 'no'. They can point to the rules and say "that's the way things are here". This might also help them shrug off the sense of letting people down, which I think would be helpful. To predict a possible issue (not from you krageon, just in general): I doubt there would be significant risk of this being abused, like, by a lazy dev who would use "the rules" to avoid code they didn't want to fix even if it was clearly in scope. Obviously, this would always be a judgement call, and that's the way things currently are anyway.

frankfurter10 6y ago

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.

keenreed 6y ago

Yes, there is code of conduct. It is called consulting and gimme money! Most big projects have that :)

dalbasal 6y ago

This is super tangent but... 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.