If 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 hobby project can become an essential piece of infrastructure.

It's like if you loved crocheting, but somehow if you stopped crocheting everyone in your city would no longer have clothes and need to walk around naked.

and nobody is willing to pay for it.

Who would pay, though? Companies bundle a hundred dependencies and none of them individually seem worth a line item. Would a mandatory "maintenance tax" per download actually get funded, or would everyone just wait for someone else to pay first?

I feel this is way too fear mongering heavy against developing in Open Source.

I published nearly everything I code on my free time, that's ~100 git repositories. Out of these, ~15 are documented and made generic enough to be used by other people, and out of these ~5 actually have some users, 2 being packaged in mainstream Linux distributions and one even has a CVE.

In total, I have received one AI slop PR. one.

Your mileage may vary, and you may be blessed/cursed with the new redis or xz. But in all likelihood, things will stay more than manageable in terms of critical infrastructure piece.

If everyone needs it, everyone can pay for it.

Don’t take shit just because you release software under a permissive license.

I wrote recently about bringing back my open source project back from the dead. It's more than a decade old. Many life events occured during that time. It's tough. It's nothing like Lodash but honestly these things ebb and flow. It operates in cycles just as life does. Wish him all the best. Sounds like he had many tough years personally and I can relate.

https://go-micro.dev/blog/27

There’s only so many sprints you can do back to back to back… you are correct, things ebb and flow and they’ll relax and life will happen and they’ll come back and either pick it up or start a new. It’s OK. It’s all OK.

I had an open source project (https://github.com/dheera/rosboard) that I burned out and didn't really do a good job continue maintaining.

* I was burned out from work politics at the same time, and had to prioritize fighting those work politics since that's what was paying me. By the end of each day at that company, I didn't feel like staring at a screen any more

* I would get a flurry of poorly-tested pull requests that would break it for some users

* I got lots of suggestions of <feature to implement> which weren't well thought out for how to generalize

* No actually good engineer stepped up to say "I want to help with this"

* There was a commercial alternative that had gotten funding and they were better at marketing

> When people talk about burnout in open source, the conversation often centers on workload, too many issues, too many requests, too much responsibility.

Why not simply ignore all this stuff by the maxim "my software - my vision":

- If some request does not serve your vision for the software: close it.

- If you cannot handle the workload: work less on the program.

- If issues exist which you cannot fix very fast: take your time to fix it. Nobody is willing to pay you big money for fixing the issue, so a fix does not seem to be very urgent for the users.

- Too much responsibility: if the software was indeed such an important piece of infrastructure, people would pay you big money for you to maintain it.

Instead of going open source, consider selling licenses with Supported Source (https://supso.org/). I made this for the maintainer problem: it's easy to burnout when companies are constantly asking for new features or fixes, while not paying you anything. Why should you work for free so these companies can make more profits? When they start paying you, you're a lot happier about it.

This is unironically why the AGPL3 is the best license. No need to worry about "virality" or derivative works or any of that, just set it and forget it. On top of that, corporations will avoid you like the plague, ensuring that your audience is other AGPL3 users.

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.

I've used MIT almost exclusively for anything I've published, under multiple identities, and seems to work fine too. What benefit would AGPL3 give me over MIT, in terms of avoiding burnout? So far, saying "No" or not working for free for companies, been working fine as an approach so far, but always open to hearing even better approaches.

We bumped into this at one point looking to switch our Rust GUI framework and found the best alternatives also suffered a core issue because they both (and almost all Rust GUI frameworks) depended on the same `winit` crate. The `winit` maintainer seemed massively under water.

We wrote about it: https://tritium.legal/blog/desktop

Honestly, I don't know if open source works outside of a few massive projects any more.

> 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

It's also likely an AI generated blogpost over the original content.

I remember the creator of Lodash being quite abrasive in the early days, when the library was surfacing as an alternative fork of underscore.js. Life does you a number.

Working on open source is truly exhausting; when I couldn't balance my work and personal life, I gave it up. Just a side note: I am an Apache PMC member.

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.

So does this mean no Lodash 5?

I find the term "burnout" in context of FOSS quite infuriating, as it is usually being used to invalidate a real problem.

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

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 initially was a weekend project but spiraled out of control when it made its way through Europe and people called me for setups or features for other actions. My burnout was the result of trying to help grass root organizations while also being politically active myself and having a full time job. The solution was basically what the article says:

* invited more maintainers by dumbing down the implementation so that one does not need a black belt in perl to hack on it

* created minimal docs

* I found hoster in the scene who was competent and willing to do pro bono hosting in exchange for me being available in case of problems (he never called me).

Small nitpick: WHO's ICD-11 only classifies burnout as an "occupational phenomenon," not a medical diagnosis, so it's not even the clinical label people assume it is. That said, your point stands, the term still gets used to dodge naming who's actually responsible.

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

Makes sense for small tool like ls, and doesn't for things that are actually complex like the python language or sqlite.

It is a common misconception that permutation is progress, and popularity is justification for poor design-pattern choices.

Spiraling complexity often eventually implodes out-of-band ecosystems sooner or later. =3

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

Disagree - "write it correct the first time" isn't second-system, it's just good scoping. Second-system failure is scope creep from overconfidence, not planning. Plenty of tight, simple v1s exist that never needed a rewrite because nobody added the fax-export feature.

Second-system effect assumes there was a "first system" that worked. Half the stuff I patch at 3am was broken from day one, just nobody noticed till it scaled.

Foundation writes blog post about burnout instead of, you know, paying maintainers.