5 ms·

I think this argument massively ignores the underlying message of this blogpost: addressing that the human beings that make and use software aren't always treat

I think this argument massively ignores the underlying message of this blogpost: addressing that the human beings that make and use software aren't always treated as, well, human beings. > A maintainer goes to jail for vehicular manslaughter and a bugs needs fixing, no problem The author didn't seem to hint that open bugs in core-js or its usefulness to its community of users are / is problematic. They hinted that maintainers are people with real life problems, whether that's struggling to make a livelihood, or facing imprisonment and ignoring that social/economic context is problematic. Stating "well, let's just fork their code and off we go" basically ignores the person behind the code entirely. It reduces the value of a person to their ability to spend time and effort on maintaining code. And that's just a morally very questionable way of approaching other people. That kind of behavior just doesn't foster any mutual trust or respect which are the basic requirements for open source to thrive to begin with. > But that's all part of the deal going in, and everyone is fully aware of all the trade-offs straight from the onset. No, absolutely not. That's not how the original instigators of the Open Source movement envisioned this. Yes, open source licensing allows forking, but that's not something you'd do, for instance, because a maintainer fails to respond to your issues on GitHub. Eric S. Raymond can be quoted from his seminal essay "Homesteading the noosphere": > The three taboos we observed above make perfect sense under this analysis. One's reputation can suffer unfairly if someone else misappropriates or mangles one's work; these taboos (and related customs) attempt to prevent this from happening. (Or, to put it more pragmatically, hackers generally refrain from forking or rogue-patching others' projects in order to be able to deny legitimacy to the same behavior practiced against themselves.) > Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the fork. (This would generally be too confusing or difficult to be practical.) > Distributing rogue patches (or, much worse, rogue binaries) exposes the owners to an unfair reputation risk. Even if the official code is perfect, the owners will catch flak from bugs in the patches (but see [RP]). > Surreptitiously filing someone's name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim's gift to be presented as the thief's own. http://catb.org/~esr/writings/homesteading/homesteading/ar01s09.html http://catb.org/~esr/writings/homesteading/homesteading/ar01... Especially the last taboo is incriminating. In the past, I kept a handful of tiny open source libraries in PHP on Packagist. Someone forked one of those without notifying me and started directly competing with mine. I can't express how off putting that experience was at the time. It has made me quite apprehensive of pro-actively sharing code I write in my spare time under an open source license. Because someone falls on hard times or isn't available for a while, that doesn't justify taking their work and presenting it as your own under the guise of "having a thriving, organic, creative, productive ecosystem."

icambron 5y ago
ESR doesn't get to decide how it works; the revealed preferences of the participants do. And those revealed preferences are that everyone pretty much does what they want, and nobody owes anybody anything. And it seems to have clearly created a vibrant ecosystem. If you're in it for money or the fame, you're going to end up very unhappy. If you prioritize OSS work above addressing your real life problems, you're going to end up unhappy. If you invest your ego into the success of the project, you'll probably end up unhappy Those aren't broken properties of the system; they're the consequences of transparently poor decisions by participants. Those people would be better served by simply not doing OSS instead of trying to convince everyone else to fund their coding adventures. I am the sole maintainer of a project with almost 12k stars on GH and 2M weekly downloads from NPM. It would be a massive amount of work if I let it be. The entitlement and indifference of users would eat me alive if it were a real workplace. And the pay would be hilariously bad if I expected income from it. But none of those predicates are true. No one asked me to make it, no one pays me for it, and no one controls what I spend my time on. Those mutual obligations are properties of jobs, exactly what I don't want out my hobby work. When I don't want to work on it, I just don't. When a bunch of people want a feature I have no wish to add, I don't add it and they're free to fork. When I write or merge a bug, I lose no sleep over it. When people "threaten" to use a "competing" library, I laugh: who cares? Building it is fun for me and it's apparently useful to others. What's the problem? Since all that seems to work pretty well, the right answer is to keep doing it. Sure, you'll end up with occasional log4j RCEs, but it's not like anyone is going to look at that and say, "I guess I won't use OSS". It was always caveat emptor.
- CaptArmchair 5y ago
  You're addressing maintainers who somehow arrive at open source with expectations which set them up for failure and disappointment. I can agree with you there. In the past, I've made comments that open source isn't a business model. It's a licensing model which governs intellectual property. My comment, however, isn't addressing maintainers. It's addressing their audience and their behavior: anyone who uses and leverages open source code without consideration of the labor that goes into it, which is a big difference. ESR is absolutely right when he points out that anyone who shares creative work also shows themselves vulnerable when it comes to reputation, good name and public perception. Sure, you could use the argument that "open source doesn't make any promises regarding support". But that still doesn't excuse the entitlement and indifference. If you can happily ignore it, that's great for you. Calling it out for what it is, however, isn't any less valid a way of responding. Even when it's just a hobby project and you don't get paid. Every so often, there's a case where a small open source project with limited maintenance ends up being leveraged by entire industries with interests worth billions. When things fall apart, media outlets and pundits will report about the failings of that small project and how it affects big interests, but they won't point out the elephant in the room: how these projects are maintained by a skeleton crew working in their spare time. The Ars Technica article is an example of this: https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/ https://arstechnica.com/information-technology/2021/12/minec... At most, the lack of due diligence of these big passive players gets called out, like in this Wired article: https://www.wired.com/story/log4j-flaw-hacking-internet/ https://www.wired.com/story/log4j-flaw-hacking-internet/ Sure, none of this is going to awaken people's minds to be more apprehensive or more empathic to the challenges of maintaining a popular OSS project. The value proposition of being able to leverage free labor is simply too attractive. Meanwhile though, the log4j maintainers are now stuck being perceived as not having done enough to avoid these kinds of bugs. Whether that's trough investing "enough" time, making the "right" calls (whatever those are) or finding "appropriate sources of funding" for themselves. Thousands of engineers are scrambling to roll out fixes upstream. And millions of end users merely learn how "a software bug almost breaks the Internet and Minecraft." Ultimately, nobody gains from these disasters as a result of a lack of assuming shared responsibility for a common good.

icambron 5y ago

ESR doesn't get to decide how it works; the revealed preferences of the participants do. And those revealed preferences are that everyone pretty much does what they want, and nobody owes anybody anything. And it seems to have clearly created a vibrant ecosystem. If you're in it for money or the fame, you're going to end up very unhappy. If you prioritize OSS work above addressing your real life problems, you're going to end up unhappy. If you invest your ego into the success of the project, you'll probably end up unhappy Those aren't broken properties of the system; they're the consequences of transparently poor decisions by participants. Those people would be better served by simply not doing OSS instead of trying to convince everyone else to fund their coding adventures. I am the sole maintainer of a project with almost 12k stars on GH and 2M weekly downloads from NPM. It would be a massive amount of work if I let it be. The entitlement and indifference of users would eat me alive if it were a real workplace. And the pay would be hilariously bad if I expected income from it. But none of those predicates are true. No one asked me to make it, no one pays me for it, and no one controls what I spend my time on. Those mutual obligations are properties of jobs, exactly what I don't want out my hobby work. When I don't want to work on it, I just don't. When a bunch of people want a feature I have no wish to add, I don't add it and they're free to fork. When I write or merge a bug, I lose no sleep over it. When people "threaten" to use a "competing" library, I laugh: who cares? Building it is fun for me and it's apparently useful to others. What's the problem? Since all that seems to work pretty well, the right answer is to keep doing it. Sure, you'll end up with occasional log4j RCEs, but it's not like anyone is going to look at that and say, "I guess I won't use OSS". It was always caveat emptor.

CaptArmchair 5y ago
You're addressing maintainers who somehow arrive at open source with expectations which set them up for failure and disappointment. I can agree with you there. In the past, I've made comments that open source isn't a business model. It's a licensing model which governs intellectual property. My comment, however, isn't addressing maintainers. It's addressing their audience and their behavior: anyone who uses and leverages open source code without consideration of the labor that goes into it, which is a big difference. ESR is absolutely right when he points out that anyone who shares creative work also shows themselves vulnerable when it comes to reputation, good name and public perception. Sure, you could use the argument that "open source doesn't make any promises regarding support". But that still doesn't excuse the entitlement and indifference. If you can happily ignore it, that's great for you. Calling it out for what it is, however, isn't any less valid a way of responding. Even when it's just a hobby project and you don't get paid. Every so often, there's a case where a small open source project with limited maintenance ends up being leveraged by entire industries with interests worth billions. When things fall apart, media outlets and pundits will report about the failings of that small project and how it affects big interests, but they won't point out the elephant in the room: how these projects are maintained by a skeleton crew working in their spare time. The Ars Technica article is an example of this: https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/ https://arstechnica.com/information-technology/2021/12/minec... At most, the lack of due diligence of these big passive players gets called out, like in this Wired article: https://www.wired.com/story/log4j-flaw-hacking-internet/ https://www.wired.com/story/log4j-flaw-hacking-internet/ Sure, none of this is going to awaken people's minds to be more apprehensive or more empathic to the challenges of maintaining a popular OSS project. The value proposition of being able to leverage free labor is simply too attractive. Meanwhile though, the log4j maintainers are now stuck being perceived as not having done enough to avoid these kinds of bugs. Whether that's trough investing "enough" time, making the "right" calls (whatever those are) or finding "appropriate sources of funding" for themselves. Thousands of engineers are scrambling to roll out fixes upstream. And millions of end users merely learn how "a software bug almost breaks the Internet and Minecraft." Ultimately, nobody gains from these disasters as a result of a lack of assuming shared responsibility for a common good.