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
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.
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.
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.
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.
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.
Note they totally about it being a thing that happens partly because devs are volunteers. There are things that are more important than they are interesting.
This is not a "how devs should behave" paper, it's an economics paper.
Underproduction is a meaningful term in economics, where it refers to the way collective action problems cause a gap between a socially-desirable outcome and the actual outcome.
However, from skimming the paper, this does not seem to be the direct source of the term. The authors appear to adopt it from Gorbatai, who is apparently using the economic term without defining it or referring to literature about underproduction generally. That means the authors of this paper may be unaware of the depth of economic literature in this field.
Sorry if this comes across as defensive -- I know the authors, so am very certain that they are aware of the rich literature on collective action problems and public goods.
It's the latter which have been the most important developments in the past 70 or 80 years (starting with, say, Coase), because they so radically modify and constrain the applicability of pure theories of supply and demand. "Underproduction" belongs to these later developments.
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.