> if you let someone else carry the flame from now on
Ha!
For a lot of open source maintainers and projects, that's not an option because there isn't someone else.
A number of articles about how to run healthy open source projects talk about the importance and difficulty of getting sufficient interested volunteers to keep it going, and how most projects don't succeed at that.
It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on.
Or they're offering for the status (Github stars, résumé-driven development etc), and you can sadly tell it's bad for the project if you just hand it over. At least, you need to on-board people like this in stages, find out which ones are serious maintainers and which aren't.
It's also very common to have drive-by "this should do $X" type comments, or "someone should do $X", but nobody is willing to help in a realistic or useful way with $X, or at all.
That's why some places respond with "patches welcome!". Or "you are welcome to fix this yourself".
That's not maintainers being unwilling to step aside.
There's also an awkward problem where people are willing to help, but their help creates more work than if they weren't helping. For example low quality patches, things which add a high maintenance burden, things that add more bugs or break other features.
Or more reasonably, which just clash with the design direction of the project.
The same happens in the real world (non-computer) non-profit volunteer projects.
A large burden ends up on a small number of shoulders, and people may "armchair comment" while being full of it, out loud in public, that the people doing the work aren't "letting" others do the work or "stepping aside". When in reality, there is so much less volunteering on offer than people think from the talk, and much of what's genuinely available creates more additional work than it saves. But talk is cheap, fun for some, and it sways views, while doing actual work means you don't have the time to talk as much, but you're under pressure to talk anyway to counter prevailing armchair views if you don't.
> It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on.
Then you step down. If you’re burnt out and the project no longer gives you joy, you have no obligation to fix bugs or even keep things working.
The project will be abandoned and dead... until evolution decides that it should be revived again (if it should), by someone not you, in a fork with a new maintainer who now has the drive you once had.
It may be hard for you, but it may be best for the project, and it’s probably good for your own health too.
I’ve done it to some of my projects. I’ve taken over projects who has been abandoned by others too.
If the code is useful, someone will pick it up and make use of it. No need burning out by convincing yourself of the falsehood that the person that does all the hard work has to be you, forever.
I think you've been downvoted because your reply is too dismissive of the motivations why people do open source projects in the first place, and of the way joy depends on how other people behave.
For myself, I have worked on projects where I continued long past where I felt joy in doing the project, because the goal of the project was still worth doing, and not just for myself but for other people's benefit.
I've done many things like that which you wouldn't call projects too. If I quit at the first sign of not enjoying them, I would have abandoned a lot of people by now!
There is also reputation. For better and worse, some people's reputation is bound up in how they handle their projects, and this has become stronger since "GitHub is the new résumé" for some. To step down from a project is to potentially drop a career-building opportunity.
To apply your principle to that sort of thing, we would need an expansive definition of joy that goes beyond feeling uplifted in the short term, and go deep into a pandora's box of why people choose things, intrinsic and extrinsic motivations.
We would also need to figure out how to apply the principle when joy isn't a passive result of whether you work on the project. It's affected by how things like bug reports are handled, on talking publicly about what we want from each other, about the importance of politeness and reasonable expectations, learning how to respond to people, and other things such as this discussion. Sometimes unpleasant experiences are needed to create more joy in future.
I think it's more fruitful to just let joy be good old simple joy, and when it comes to deciding whether to "step down", instead of a simple assessment of "am I enjoying this", talk about better ways to accomplish things we think are still worth doing, even when we're not currently enjoying it.
Ha!
For a lot of open source maintainers and projects, that's not an option because there isn't someone else.
A number of articles about how to run healthy open source projects talk about the importance and difficulty of getting sufficient interested volunteers to keep it going, and how most projects don't succeed at that.
It is often difficult or untenable to "step aside" and pass along the baton because there's nobody seriously available to take it on.
Or they're offering for the status (Github stars, résumé-driven development etc), and you can sadly tell it's bad for the project if you just hand it over. At least, you need to on-board people like this in stages, find out which ones are serious maintainers and which aren't.
It's also very common to have drive-by "this should do $X" type comments, or "someone should do $X", but nobody is willing to help in a realistic or useful way with $X, or at all.
That's why some places respond with "patches welcome!". Or "you are welcome to fix this yourself".
That's not maintainers being unwilling to step aside.
There's also an awkward problem where people are willing to help, but their help creates more work than if they weren't helping. For example low quality patches, things which add a high maintenance burden, things that add more bugs or break other features.
Or more reasonably, which just clash with the design direction of the project.
The same happens in the real world (non-computer) non-profit volunteer projects.
A large burden ends up on a small number of shoulders, and people may "armchair comment" while being full of it, out loud in public, that the people doing the work aren't "letting" others do the work or "stepping aside". When in reality, there is so much less volunteering on offer than people think from the talk, and much of what's genuinely available creates more additional work than it saves. But talk is cheap, fun for some, and it sways views, while doing actual work means you don't have the time to talk as much, but you're under pressure to talk anyway to counter prevailing armchair views if you don't.