Underproduction: An Approach for Measuring Risk in Open Source Software(arxiv.org)
arxiv.org
Underproduction: An Approach for Measuring Risk in Open Source Software
https://arxiv.org/abs/2103.00352
6 comments
I enjoyed this abstract. Very clear, no unnecessary academic language.
> 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.
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.
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.
No, it's a perfectly descriptive name that's appropriate to the context.
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.
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.
> It is quite ridiculous and offensive to name it "underproduction".
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[0], 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.
[0] https://opensym.org/ws2011/_media/proceedings%253Ap205-gorba...
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[0], 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.
[0] https://opensym.org/ws2011/_media/proceedings%253Ap205-gorba...
Section III definitely connects the choice to use this term to economics ("In an economic market, supply and demand are said to be aligned through a price mechanism. Alignment is reached because lower demand decreases prices, which disincentivizes production and returns a market to equilibrium.") Not 100% sure about the context of this conference, but my understanding is that it's a norm in these kinds of papers to refer to relatively basic concepts like supply, demand, and price signals without a citation (esp. given that page limits often limit your cites!). Totally get that some may disagree with this choice though.
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.
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.
I don't think that connection is really very strong. Supply and demand is taught in a 101 course -- but maddeningly, discussion of externalities, public goods, information etc tend to get a fairly cursory glance.
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.
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.
I don’t think it’s meant as a value judgement. But perhaps it would read better as ‘over demand’?
You make perfectly reasonable points in your second and third paragraph but the name doesn't seem like something to take quite so personally. From a scan of the paper it makes sense as a name and only seems like it would be offensive if one were actively seeking to be offended.
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.
This was put together by my cohort mate and desk neighbor, so glad to finally see it in a shareable form!
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)
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
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
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.
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).
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.
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.
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.
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.
Yes, there is code of conduct. It is called consulting and gimme money! Most big projects have that :)
Really interesting study, I will give it some thought.
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.
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.