This attitude is forcing to ‘fork it’ approach, which is causing a lot of duplicated effort in practise, instead if you feeling like ‘not worth to maintain (can be by any reason, personal, lack of time, burnout), stepping down as maintainer and giving flag to someone else to carry is much more productive. But usually we witness, burned-out maintainers still sticking to their projects.
Your duplicated effort is my production bug fixed for me right now. Fork, fix the bug, deploy the forked fix, submit the fix, work with the maintainers to eventually merge the fix into mainline, redeploy mainline once mainline includes the fix. This inevitably results in multiple people in parallel privately developing and deploying their individual fix to the bug, and that's OK, because having the freedom to solve your problem quickly is more important than some absolute minimization of effort expended in the overall ecosystem.
If the maintainers are assholes and really won't fix the bugs in their product, you can either maintain your fix, maintain your fork (including new feature development and merging in changes from upstream), or switch to commercially-supported software.
I don't think I understand that response. If a project is forked that could very well be someone deciding to base their work on another's work without regard to the parent code editor's attitude. I could make my own GNU Emacs fork, for instance, just because I wanted to. I don't have to wait for someone to "step down as maintainer" nor do I have to wait for a project to appear to be unmaintained. I can compete against GNU Emacs by building my variant on the same code. Anyone can choose from the published forks and there is no need for the one maintainer per project approach your comment suggests (nor does one maintainer per project exist).
I don't share that objection to forks; I don't find forks to be a problem. One can't do anything to change in the free software world, nor would I want it to change because changing that would mean losing the software freedom I value.
You should consider the scenarios with multiple contributors and single maintainer, where the maintainer is bottle neck.
I am not against the forks, but we also have examples like openwrt/lede split.
My perspective on this is only against splitting contributor base because of maintainer mismanagement.
Edit: in your emacs example, it is much more beneficial your changes (and a lot of others) pushed back to main project vs multiple emacs forks with minor improvements.
This is not directly relevant to the thread, which is about maintainer burnout.
I've used lemacs (Lucid emacs) and xemacs, and now I use Aquamacs.
As I recall, Lucid forked emacs because they, a commercial company with an emacs-based IDE, wanted to push changes faster than the FSF, a small non-profit dependent on volunteer labor, could accept them.
This turned into xemacs. My feeling was that xemacs was much better then emacs-for-x.
I think Aquamacs has better Mac integration than stock GNU emacs.
> LucidEmacs forked quite publicly from the FreeSoftwareFoundation’s implementation of Emacs in 1993. This was one of the more notorious code forks in the history of free software, probably because it was early and public.
I'm not sure it was seen as a "disaster", but it was certainly controversial, and negatively by many, so close enough.
I do think for Lucid it was seen as a feature, that is, they could fork and ship to customers.
Yeah which is bullshit. He may not have been paid to make Bash but you can definitely make the argument that there is an ethical responsibility not to foist shit software on the world.
I mean you can't totally avoid Bash today, and that has a cost to society (because it's so shit) which he at least has some responsibility for.
Of course if he doesn't want to work on it and fix things that is fine. But I don't think he is responsibility-free.
Look at it another way - if I build a dangerous bridge over a river, and someone dies crossing it can I say "well you were free to walk around the river"? Of course I can, but that ignores the fact that I made the bridge available to other people, expecting them to use it and importantly it put other people off making a safe bridge. I am in some way responsible even though I only provided something for free that nobody had to use.
It's precisely this kind of entitled rhetoric that pushes people away from contributing at all. Please try to consider that on the other end of a conversation there is a human being, who doesn't owe you anything and does what he does (in this case) out of pure charity.
Builders of bridge for general public use have a legal obligation for safety. That's not comparable.
Moreoever, I have made bridges across streams, using stones and logs, which were not safe. And left them there as-is, because there isn't an obligation that these sorts of throw-it-together hiking bridges actually be safe for others. The risk is entirely on the crosser. If you try to cross it, slip, knock your head on a rock, and drown, there is no blame on me. (Plus, it might have been safe when I made it, but the water conditions changed, or if overnight it iced over, etc.)
Look at it another way. If I post a poem on my web site, for people to read for free, and you think it's crap, I don't have an obligation to edit the poem to your liking or even read your criticism.
Do I have an ethical obligation to not post shitty poetry on the world? No! I don't even have the obligation to not be snide to criticism I don't like.
And I believe you are saying that it's unethical for all of those college students in introductory CS classes to host their software - almost all of which are 'shit software' - on a public system like github.
> When somebody leaves or disengages from the project, we ask that they do so in a way that minimises disruption to the project. They should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off.
I don't think a maintainer owes anybody free labour, but I do think a good maintainer will hand over the keys to someone else when the needs of the community require it.
As soon as software engineering is a profession that requires professional certification, and as soon as Bash is something that's commissioned by some kind of entity that requires it to adhere to certain safety/quality standards, your bridge example will apply here. Until then, it is 100% irrelevant.
For maintainers: if you don't want people to act like you promised them anything, don't put up a fancy website showing how wonderful it is and what its best features are.
Instead, do what you can to discourage people from using your software. Tell people how crappy it is, that you could abandon it at any time, and so on.
Making it version 0.15 alpha might not be enough to counteract a marketing message that makes it sound like the greatest thing since mobile phones.
I have a website showing all the nice features, but I make users compile it themselves, and it only works on linux. Seems to stop pretty much everyone.
> In practise, however, when there are issues, maintainers often work quickly to resolve them and apologise in the same way as a company does. This is one of the biggest causes of burnout.
Nonsense. This is what FOSS maintainers crave: someone cares about their project and has a real problem: call to action!
It's the cure for burnout.
> For maintainers: if you’re not enjoying most of your work on a project, don’t do it anymore.
If your regular day job is software developer, and you're not even enjoying your side project, then you're basically burned out from development, which is a bigger problem.
If the FOSS project is in fact a piece of crap that you hate (because, say, you're now 10X the developer compared to when you made important (mis-)decisions in that project that are difficult to undo now), then ... just stop. What's the big deal.
No, an author/maintainer is free to do as they see fit. If they don't want to merge your PR, that is their choice.
If you don't agree with that choice, you are free to clone/fork the project and merge the PR there. No one -- even the author/maintainer -- is stopping you and they have, in fact, granted you the permission to do exactly that (via their choice of an OSS license).
How do you 'automatically merge' a comment where a user voices a popular concern? What about a merge request that needs to be rebased? What about a merge request that requires deep knowledge of the project to understand if it would break something critical, or introduce security flaws?
A nation state could submit a merge request to the Linux kernel that is a blatant backdoor and override maintainers by just shear numbers of 'supporters'? This is a very bad, no, terrible idea.
Code merges should not be an open democracy with no opportunity for oversight.
