[azangru]

> do you maintain open source projects that actually have users depending on it? I’m asking because when people say that OSS devs of popular projects suffer from burnout, that’s not an opinion, but a matter of fact.

Not the author of the parent comment and not a maintainer of a popular open-source project, but could you explain the process of how devs get into this trap of burning out? I mean, there are quite a few projects that have been abandoned by people who lost interest or have too much on their plate, so their authors are by no means forced to stay on the project if they no longer want or are able to. These projects can be forked or taken up by other maintainers.

[kakwa_]

As the creator and maintainer of a project, it's really hard to let go of said project.

It's really hard to completely abandon a project you know people are relying on. You do feel responsible for it in the end.

Also, nearly every time someone opens a ticket, it points a deficiency in your project, and it's somewhat hard to accept that your project is not "perfect" (spoiler alert, it never is). Consequently you, as a maintainer, always want to fix issues or implement obviously missing features.

Also publicly admitting that your project is abandoned (by an header in the README for example) is quite hard, it feels like a failure and at least, you are publicly admitting something with a negative connotation.

"Maintained" forks that take over the initial project are extremely rare. In most cases, a fork will be tiny modifications done to fit one user's specific need. Nobody really wants to factorize these modifications into a common solution and maintain it. Well maintained forks do happen, but only for highly projects.

I'm speaking out of experience, I maintain a bunch of projects, not highly popular ones (a few dozen stars on github), but definitely used by other people. And in these projects I've a few that I definitely have nor the motivation nor the means to really maintain well. Typically I created a puppet samba module that is quite successful, but I've not used Puppet in 3 years, so I'm not a consumer of my own software anymore and I've not followed the evolution of Puppet in years, yet, I've not set my mind on publicly stating that this project is not maintained anymore.

Lastly if I do get PR for these projects, these are generally not really complete quite complete, documentation and unit tests are always missing, and the code quality is rarely on par, specially if the PR is quite complex. For every PR I accept I generally have a few commits to complete it/fix it.

[Ayesh]

You can easily fix the low quality PR issue with a CI setup.

Setup a Travis job to fail often (build, lint, test, coverage, etc), so you pressure them PR author to complete it. This will make the entry barrier massive, but helps you focus your attention.

In addition, take an hour setting up issue and PR templates and guidelines in GitHub. A good readme with an FAQ section helps too.

See Symfony/Symfony for a good example.

[bad_user]

It's easy to get into that trap.

We love to code and the projects you work on become like your babies. Have you ever heard of this expression from people doing what they love, or from people starting their own companies? "Like your baby"?

Well the trap is that you end up putting a lot of work in it, at first it's for fun, but then it's because what you're doing is popular and you hope of leaving something valuable behind. And unfortunately these things happen:

1. the project is never done, there's always some feature that people want or some bug waiting to be fixed, or some dependency waiting to be upgraded (these are the worst) and if nobody does it, then users will end up abandoning the project

2. people willing to contribute are very rare and people capable of great contributions and of sharing the maintenance burden are like unicorns

So the answer is: if you don't keep doing it, the project dies. In which case all of your effort was for nothing.

[jhbadger]

Projects have a lifespan. They don't have to be monuments for eternity, and if they get abandoned because the maintainer gets bored/burned out, it often is because the problem it was trying to solve doesn't really make sense in the current landscape anymore. The development time wasn't "wasted" if the project served its purpose in its era.

[AstralStorm]

There is also part 3, someone picks up an unmaintained project, cleans it up and makes it workable. Or patches in the feature.

This is what cannot happen in most shareware or freeware apps. It depends on the source code repository being easy to find, so centralized big ones win. (SourceForge, Github, Gitlab, etc.)

The sad part is companies not delegating a person to maintain or develop critical dependencies even though they could.

[azangru]

> In which case all of your effort was for nothing.

I thought people maintain open-source projects if they use them themselves. In which case, all your effort was for solving particular use cases that you had.

When developers have no further use for a project (e.g. when they've moved on to a different technology), then the project will likely die. I haven't seen many people keep maintaining a project after they've stopped using it.

[rleigh]

You can stop using the tool yourself, but still have a large active userbase depending upon it. As a result, you can still end up with an unwritten obligation to support that userbase.

[rleigh]

You end up having unwritten obligations to your users.

You can start from the position that you can write your software, make it public, and you have no obligation to do more. Some people do just this. But once you have to (or feel that you have to) answer support questions, fix bugs, add features, make releases and do so on an ongoing basis, you can end up in a situation where you effectively have a second full-time job.

I'm not saying that this is desirable, or even necessary. But it's a reality for many open source project maintainers and contributors. You get sucked into it. End users have expectations, and it's only human to try to meet them. I've personally been very badly burned by this, and I've get to contribute at anything but a minimal level for the last six years as a result.

One of the things which I don't like are that people can have very unreasonable attitude towards what they can expect from a person who does this in their spare time who helps them for free, sacrificing their spare time for someone else's benefit. The longer I've been doing this, the more I appreciate that it's not as sustainable as we might like to believe, and that being fairly compensated for work is no bad thing. We should be more willing to say that we would be happy to fix that bug, or add that new feature, so long as we are paid for it. But in many projects this isn't politically or practically possible.