the lesson *I'm* choosing to take from xz, as an oss maintainer, is that anyone trying to pressure or guilt me into doing something should immediately be told no, for security reasons
I will never hand over development to whoever, I had my lesson in the past –
I wouldn’t like that someone would turn the project into something I never intended it to become
(monetization, feature bloat, etc.). At most I would archive the project and whoever is free to fork
under a new name. For now I resisted doing this, so people will have to be patient for new stable release.
What would actually help is that people help to completely investigate existing issues instead of keep
asking me to add yet more features. Turns out people willing to step in the code to investigate
and pinpoint exactly where is an issue (or that there is no issue) is incredibly rare.
That last sentence rings true of most software engineers. Everyone wants to work on a glamorous new feature that’s going to wow users or let them think about problems they want to think about. No-one wants to hunt down the difficult-to-repro bug in an old but critical section of someone else’s code.
When I stepped away from my own (mildly successful) Free software project, I had the same concerns: it’s about the reputation.
The project had earned a decent amount of trust when I was running it, and presumably people were installing new updates without going over the changes. If I handed off the project to someone new, I wasn’t just handing over the work, but that trust as well.
So rather than handing over the project to someone new, I archived it and someone else (thankfully someone not-evil) forked it. Anyone installing the fork immediately understood that the relationship was new. They’d have to decide whether to trust this new maintainer or not.
For my money, this is the way. If you’re burning out, remember that your reputation is tied to your project name, and that it has considerable value. If you don’t want to continue, the disruption of a fork is better/safer than the smooth-but-risky hand-off.
In some open source projects there is a lot of leeching and little contributions.
In 2020 the sole developer of Invidious stepped away from development because of burn out. https://omar.yt/posts/stepping-away-from-open-source
Also in 2020 developer Raymond Hill archived the uMatrix browser add-on https://news.ycombinator.com/item?id=24532973
That last sentence rings true of most software engineers. Everyone wants to work on a glamorous new feature that’s going to wow users or let them think about problems they want to think about. No-one wants to hunt down the difficult-to-repro bug in an old but critical section of someone else’s code.
For anyone wondering, here is the difference between uMatrix and uBlock Origin: https://news.ycombinator.com/item?id=24533329
When I stepped away from my own (mildly successful) Free software project, I had the same concerns: it’s about the reputation.
The project had earned a decent amount of trust when I was running it, and presumably people were installing new updates without going over the changes. If I handed off the project to someone new, I wasn’t just handing over the work, but that trust as well.
So rather than handing over the project to someone new, I archived it and someone else (thankfully someone not-evil) forked it. Anyone installing the fork immediately understood that the relationship was new. They’d have to decide whether to trust this new maintainer or not.
For my money, this is the way. If you’re burning out, remember that your reputation is tied to your project name, and that it has considerable value. If you don’t want to continue, the disruption of a fork is better/safer than the smooth-but-risky hand-off.