Live data from Hacker News

Burnout is real for open source maintainers

openjsf.org

61–70 of 75 posts

Re: Burnout is real for open source maintainers

#62
post #42
post #36

Earlier quoted context omitted.

I think you are doing the post injustice by hijacking it. FOSS maintainers can get a burnout even without toxic users - hard deadlines and the understanding that people really rely on your project can do that to you. e.g.: About 25 years I had developed some blogging software in the style of usemod (single executable, data stored in ./data) for coordination of and reporting about protests on throwaway VMs. This initi…

I think not. I believe that post is bullshit written _by_ the oppressor (if you allow me to use that lingo which you won't but I don't care). Hence this is on-topic. But interesting, isn't it? The moment someone questions the root narrative, someone instantly tries to shut it down with "ackschually unrelated!!11 You're hijacking by not having the desired response" + lots of text I didn't read. As I said. It seeped in…

> I think not.

> [...] if you allow me to use that lingo which you won't but I don't care

> [...] + lots of text I didn't read

Understood.

Re: Burnout is real for open source maintainers

#63
Step 1: I'm gonna work for free!

Step 2: Oh no! These people are taking advantage of me!

Who would have guessed? Honest people want to pay others for their work, so if you explicitly want to work for free, you will attract all types of sleaze balls who are looking for somebody to take advantage of.

Step out of the FOSS swamp and step into human dignity.

Re: Burnout is real for open source maintainers

#64

Corollary: if software requires constant revisions it didn't actually cover the initial problem scope, and degenerated into a high-latency service state-machine powered by coders. =3 https://en.wikipedia.org/wiki/Second-system_effect

The very idea of "let's just write it correct the first time" is itself very much a second system fallacy.

Re: Burnout is real for open source maintainers

#65

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

It's enforcement through deterrent. Without a change, there is no case to be held. With AI refactor clause, companies become subject to subpoenas, witnesses subject to perjury, reputations subject to scrutiny. Just as the same as any license affords protections than without them.

Re: Burnout is real for open source maintainers

#66

Earlier quoted context omitted.

The society is built on informal expectations like that. People assume that things will go on as before, and they will start relying on it. They assume that for every thing they rely on, there is a bureaucrat somewhere responsible for making it happen. But unless you are that bureaucrat yourself, you probably don't need to be aware of the specifics. Many things in the society depend on volunteer work. Open source sof…

As a non Christian, I feel that Christianity and similar religions did much to counter such harmful innate human tendencies (promoting charity, forgiveness, humility, etc) and the reason why Western societies have been so successful. The trend toward secularism could also explain their recent decline.

[deleted]

Re: Burnout is real for open source maintainers

#69

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

It's enforcement through deterrent. Without a change, there is no case to be held. With AI refactor clause, companies become subject to subpoenas, witnesses subject to perjury, reputations subject to scrutiny. Just as the same as any license affords protections than without them.

[deleted]

Re: Burnout is real for open source maintainers

#70

Corollary: if software requires constant revisions it didn't actually cover the initial problem scope, and degenerated into a high-latency service state-machine powered by coders. =3 https://en.wikipedia.org/wiki/Second-system_effect

The very idea of "let's just write it correct the first time" is itself very much a second system fallacy.

Standard project release cycles build to a design specification, clearly defining phases of what is acceptable and when.

https://en.wikipedia.org/wiki/Technology_readiness_level

One way to enforce implementation convergence is to define core unit tests before coding even begins. If people just ignored communication, the results are rather predictable.

https://en.wikipedia.org/wiki/Conway's_law

Building something that doesn't need patched every week is impossible for some. =3

Post reply on HN