Earlier quoted context omitted.
It prevents the No from ever materializing because almost no one wants to use your code to build on top of.
How am I supposed to practice saying "No" in low-stakes situations then? :|
Burnout is real for open source maintainers
21–30 of 75 posts
Re: Burnout is real for open source maintainers
#22Earlier quoted context omitted.
I am happy with the network solution AGPL provides on top of GPL. I think a new AGPL version needs to come out that addresses rewriting codebases with AI and claiming new original work.
How would you enforce that? I'm genuinely curious. It's nearly impossible to conclusively prove someone rewrote your codebase with AI.
Re: Burnout is real for open source maintainers
#23If you have a hobby project like writing a blog, crocheting, or almost any other creative hobby, you can dip in and out however it suits you. If you deal with major life events, sicknesses, etc., you can leave the hobby and come back. Nobody is paying you for it, so nobody can complain (maybe the friends who miss you, but it's not actively impacting the real world). Open source is one of those weird things where your…
When I was a kid, we always had New Year's (read: Christmas) decorations (the maximum that wouldn't be out of place in a mostly Muslim country) on a small park in my neighborhood. One year they never appeared, and people were enraged . The guy the city hired every year had a mob in front of his door. People's letters to the authorities got no answer, so suddenly he apparently became their contact person. I was buying…
Re: Burnout is real for open source maintainers
#24Earlier quoted context omitted.
When I was a kid, we always had New Year's (read: Christmas) decorations (the maximum that wouldn't be out of place in a mostly Muslim country) on a small park in my neighborhood. One year they never appeared, and people were enraged . The guy the city hired every year had a mob in front of his door. People's letters to the authorities got no answer, so suddenly he apparently became their contact person. I was buying…
What country was this?
Plus code for the park: 326F+73J Beşiktaş, İstanbul, Türkiye
Re: Burnout is real for open source maintainers
#25> This conversation was initially just a phone call, but was so powerful that we decided to turn it into a blog and share the audio via YouTube i can tell - it looks like the blog post doesn't really add anything over a direct transcript of the call itself. it's just a bland summary of the really interesting story Dalton told
Re: Burnout is real for open source maintainers
#26Earlier quoted context omitted.
How would you enforce that? I'm genuinely curious. It's nearly impossible to conclusively prove someone rewrote your codebase with AI.
I don't think you can, which is also why Open Source is effectively dead thanks to AI.
Re: Burnout is real for open source maintainers
#27Instead of talking about concrete misbehavior by concrete individuals or institutions, "oh that poor guy is suffering from foss burnout" is thrown in, and instantly, any thought or action that might change anything about the situation is stopped and discarded.
It depersonalizes a problem that is _very_ personal. Diffusing responsibility to no one, while at the same time reframing valid logical callouts as emotionally driven nonsense that can be ignored.
__
In essence, "FOSS Burnout" is this hybrid between victim blaming and blaming the universe, while in reality it's a real person at that very moment doing something unethical to another human being.
We need to stop talking about useless higher-level concepts and start talking about concrete bad behavior that could be instantly stopped.
__
If you've read "it diffuses responsibility to no one" and thought "oh, hey! corporate! Asscovering!", then yes. You got it. That's why this trope keeps coming up.
It's no grassroots thing. It's engineered to keep the meat grinder running. Nothing else.
And the worst part is that it shows up even without corporate involvement, because it seeped into the defaults people apply without thinking.
Re: Burnout is real for open source maintainers
#28Earlier quoted context omitted.
and nobody is willing to pay for it.
The value created vs value captured equation of OSS must be one of the most lopsided things ever. If you’re at Google and invent Kubernetes you might still capture 0.000001% (probably less) of the economic value created by Kubernetes, but you probably enjoy very generous comp. OSS doesn’t have any of that, besides being extremely in demand as a consultant or whatever.
Not necessarily. AI has significantly reduced the marketability of that angle, when people can just ask AI about your OSS project.
That is to say, it's only getting more lopsided.
Re: Burnout is real for open source maintainers
#29If you have a hobby project like writing a blog, crocheting, or almost any other creative hobby, you can dip in and out however it suits you. If you deal with major life events, sicknesses, etc., you can leave the hobby and come back. Nobody is paying you for it, so nobody can complain (maybe the friends who miss you, but it's not actively impacting the real world). Open source is one of those weird things where your…
and nobody is willing to pay for it.
We definitely do not pay enough for the utility we get from OSS. But on the other hand do we want do copyright in code? Also when you pay for something you can hold liable the vendor if things go south (security holes etc). Do we want the devs of OSS to be in such position?
Re: Burnout is real for open source maintainers
#30Earlier quoted context omitted.
How would you enforce that? I'm genuinely curious. It's nearly impossible to conclusively prove someone rewrote your codebase with AI.
I don't think you can, which is also why Open Source is effectively dead thanks to AI.
Honestly I think we're going to see a lot less AI-written code in the future, and more AI-assistance (PR reviews, documentation, security scans, scaffolding, brainstorming, test suites, etc). Example: to ship one feature for my open source project with a collaborator, we went back and forth for a month to agree on the change, test it, approve it, merge it. The code was pretty tiny. We could get more contributions faster if AI can help us tighten up that lifecycle.