I don't understand why project leads straight up bury their projects instead of transferring ownership to maintainers that are interested in keeping the project alive.
I don’t understand why people have such high expectations and demands from OSS volunteers.
They are people doing this for free. They have no obligation to pass off their work in any particular way shape or form when they no longer want to do it. They don’t owe you or anyone else a smooth handover (or literally anything else).
Maybe they just burnt out so hard that even finding a replacement is too much work. Maybe they’re just not passionate about the project anymore and can’t be bothered. Maybe life is just a lot for them right now. Whatever the reason is, it’s nobody’s business but the maintainer.
If you care so much, you are free to take it over (like this post) or just fork it and continue it yourself.
>I don’t understand why people have such high expectations and demands from OSS volunteers.
Because OSS volunteers frequently push people to use their projects. Sure, I didn't pay them, but they advertised to me and encouraged me and resulted me in expending time and resources in adopting their project. I have a valid claim that they act in a manner that doesn't rug pull me.
Not neofetch because it's a useless vanity thing. (E.g. /r/unixporn is pointless because it's just screenshots of people's random linux systems.) But other projects, yes.
Oh I'm sorry how could I forget about your wants and needs as a consumer?
While you were spending your time being "advertised to, encouraged, and expending time and resources adopting their project" they did, you know, actual work to create and maintain said project.
Let's not kid ourselves here. You chose to use their project. You are free to use any other one that fulfills your needs, fork an existing one, or, hell, create one yourself. Nobody is putting a gun up to your head and saying "you must use this project or else". Strictly as a consumer, you have absolutely zero pull on what a project or its maintainers do, and you shouldn't delude yourself in thinking otherwise just because you expended a modicum of effort to use a project.
In short, get over yourself. Your time commitment is many magnitudes smaller than theirs.
As someone involved in open source, both as a user and maintainer, this is a very user hostile position to take.
For one, respect your users. If you made the decision to publish an OSS project, acknowledge that you can become a dependency in someone's workflow. While your users likely aren't supporting you financially, their usage of your projects, feedback, testing, indirect support and community building, all contribute to the success, and any status, fame, or potential employment that might come your way because of it.
Saying that you don't owe your users anything and mistreating them like you suggest is just a dickish move, and earns you no good will in the open source community. These are relationships that you should cherish, not look down upon because you get to call the shots about your project.
Everyone has difficult moments and perpetual unpaid work shouldn't be expected from anyone, but if you feel like abandoning a popular OSS project, the polite thing to do is to communicate this with your users, and find someone else willing to continue maintenance.
There is a massive gap between what would be nice (what you describe) and what should be expected (the rest of the thread) from maintainers.
While a smooth exit and transfer of ownership (and politeness in general) is nice to have, it should not be the norm out of a free product with no implicit or explicit support offered. And no, publishing a project is not an implicit offer of support, as much as some might want it to be.
If someone chooses to offer something (whether that’s updates, support or anything else), awesome, but it should not be expected or demanded out of anyone you don’t pay money for. Heaping on responsibilities to people just because they created, maintained, or contributed to a project is just a recipe for burnout and eventual deterioration of a project.
Sometimes, the user is wrong. If the user is demanding and expecting things out of a free project created and maintained by volunteers doing it in their own spare time, then they are a shitty user. You may choose to interact with them out of the kindness of your heart, but it should not be the norm or expectation from every maintainer out there.
I agree that expecting, or worse―demanding―, a specific behavior from a maintainer is out of place.
But at the same time, categorically refusing to meet a user request or expectation just because they're not paying you implies that you prioritize paying users, which corrupts how the software is built. It means that you consider people who use your software for free (gratis) to not have any voice in how the software is developed, but paying users do. This is a very reductionist point of view of OSS to provide only the barebone essential freedoms of the license you chose, without taking into account the people using the software, and the community that can develop around it.
If money is the main issue, there are ways to monetize OSS projects so that paying users effectively subsidize support and requests of non-paying users. But regardless if that system is in place or not, all users deserve a fair treatment, and maintainers should put in _some_ effort to do the right thing.
In the context of Neofetch, a popular OSS project, the right thing would've been to not ghost the community, announce your eventual departure, and start the discussion of finding a new maintainer. These are not unreasonable expectations, and require minimal effort from the maintainer. This person decided to abandon software development altogether, and that's fine, but this way of handling things would ensure that users would think twice about using any of their software in the future.
Forcing someone to do work they don’t want to do just because they are a maintainer is extremely unreasonable.
> and require minimal effort from the maintainer.
I don’t think you understand the time and effort that finding a new maintainer takes. It is far from “minimal” and this mindset that it is somehow expected and/or required to leave a project is exactly my point.
> I agree that expecting, or worse―demanding―, a specific behavior from a maintainer is out of place.
> In the context of Neofetch, a popular OSS project, the right thing would've been to not ghost the community, announce your eventual departure, and start the discussion of finding a new maintainer.
You literally just placed expectations and demands onto someone. Neofetch being a popular or well used project does not somehow make this ok.
If someone doesn’t want to continue giving their time contributing or maintaining a project, then that is entirely their decision to make in whatever method they deem right. It’s not your or anyone else’s place to tell another person how they should leave a project they no longer want to be a part of. Nothing in being a user of said project gives you that right or privilege and making it sound like “the right thing to do” is just putting lipstick on an obvious demand.
> and that's fine
The rest of your comment makes it pretty clear that you do not actually think it is fine.
> I don’t think you understand the time and effort that finding a new maintainer takes. It is far from “minimal” and this mindset that it is somehow expected and/or required to leave a project is exactly my point.
If a community of users exists, it takes no effort to communicate your desire to depart the project.
If there are active contributors besides the lead maintainer (Neofetch had 206, most of them, granted, with minor contributions), starting a discussion to consider one or several people who could take over takes _minimal_ effort. Many projects do this all the time. It also takes minimal effort to mention the project in one of several maintainers-wanted lists/sites.
The difficult thing, as pointed out by a comment in an adjacent thread, is to handover the trust in the project that existing users had to someone you presumably don't trust. As the xz situation showed, this can easily be exploited.
Ultimately, if no suitable replacement can be found, then sure, shut the project down. My point is that it's not unreasonable to expect some effort before making this decision.
> You literally just placed expectations and demands onto someone.
I'm sleepy and sedated, so might not be fully congruent. :S I probably should've prefaced that first line with "unreasonable expectations".
But to save us both some time, all I'm saying is that project maintenance involves more than just releasing code as open source. It's fine for a user, paying or not, to have some basic expectations of how the project is maintained, beyond the freedoms they have from the software license. I consider communication as one of those basic expectations, and in my opinion, the author of Neofetch failed to meet them. I am allowed to judge them for it, and you are allowed to disagree.
If you transfer your project, you have to find somebody that you trust enough to transfer over the personal trust that a huge group of people have put on you, to them. That is an unbelievably high barrier.
The existing mechanism is for people to fork the project and move on. This is much better, because it doesn’t require the previous maintainer to endorse anything.
Your suggestion puts probably the hardest social task this sort of project could have, on somebody who is in the process of giving up on it. A succession strategy could be designed while the project is going along well and healthy, but at the end, this is a recipe for disaster.
