
Open Source Maintainers Owe You Nothing - mikemcquaid
https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/
======
bluesign
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.

~~~
Digital-Citizen
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.

~~~
bluesign
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.

~~~
eesmith
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.

------
gumby
Brian Fox had a canned email response to whiners: "Please return Bash for a
full refund."

~~~
IshKebab
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.

~~~
Flimm
I like this part of the Ubuntu code of conduct:

> Step down considerately

> 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.

~~~
cmsj
I agree, but it's also worth noting that it's often quite hard to find someone
prepared to take over maintainership.

------
skybrian
I would put it this way:

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.

~~~
smcameron
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.

~~~
jazoom
Would certainly stop me, unless you included a snippet of the exact commands
required to compile it.

~~~
imtringued
./configure

make

make install

( I have no obligation to tell you to which project these commands apply to)

------
kazinator
> _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.

------
chauhankiran
> In short, any open source software you use can delete all your production
> data and you can’t sue anyone because...

This is the killer one.

~~~
ozim
That is pretty much industry standard in any EULA. Same with companies not
owing you anything.

------
sbr464
.

~~~
craftyguy
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.

