On Being a Free Software Maintainer

Friendly heads-up that 'irregardless' is not a real word, rather a mashup between 'irrespective' and 'regardless', either of which alone will do. It's particularly one to avoid because it's probably in the top five of "words that irritate sticklers", who will judge you for it.

FOSS, in my experience, will not make you money, will not get you a job, and will gradually suck up more and more of your free time until you have none left.

In can also be tedious and frustrating, especially dealing with users.

Usually if any money is made off of your labor, it's made by other people, and they never contribute any of it back.

Spend your time on something you can monetize.

It seems most people who have responded seem to think I defend the kind of guy who joins an open source project, get some importance and then starts to act like a jerk (or in other words, starts challenging the power status of the main maintainer which is a natural thing once an individual invests a certain amount of time in a project).

No wonder so many people react against this kind of guy. There is resentment on both sides. Now let me tell you about another kind of "maintainer", the casual one. He just goes by, fixes a bug or broadens the interface of a function and he's gone. You'll most likely never have resentment against this kind of maintainer even though he might, because you're not engaged in a power struggle against him. Why ? Because you have already won it. You just can ignore/forget about his PR he won't harass you about it anyway. For what he knows you might be dead and have carried that holy merging power with you in the afterlife. He has invested work in this, because working for the benefit of community brings him joy, only to have his work briefly considered and discarded. And most of the time when this happens, the real reason behind this is never explicitly told "This is my project and I am in power – firmly kicks the ground" but this is paraphrased with words like "this does not fit the community needs". There are also maintainers who truely are dedicated to the community and if in power only for this greater good with no personal gains. They are sincere. If so why not let the community express itself, for instance through voting, instead of making decisions in its name ?

Now let's consider some points for an alternative take on what "code" and it's management could be.

- A library is not just a pack of implementations for a given solution (a categoria) it's also the public place on top of which such implementations can be enunciated (an agora). Version tags hint at this reality (code is a Becoming) but we prefer to play it down and hide it in a Changelog because the listed changes are seen as mere incidents on a road that leads to an idealized, objective and optimal state of code in front of which personal preference have almost nothing to say.

- To generalize what versions are variants are introduced. A code variant can be defined at any granularity level, small or large and there is ways to state a certain variant must be used, from global to more local scales.

- Each user can push variants in its own namespace (e.g: the-lib.public.the-user).

- A team of maintainers only curates such variants and its goal is to provide a comprehensive default perspective on the implementation space of the library. A library can have competing team of maintainers.

- There is no fork. Either your library is totally different and there is no point in starting it as a fork, or only parts of the library change and this is the wrong variant granularity. Plus a fork is a way to push unwanted changes "out of sight, out of mind", both for the irritated chief maintainer and for the library users that may be interested in what the fork has to offer.

- There is no ideal community to please, only a standard/reference set of implementations and multiple variants at multiple scales. Each variant has its own community, i.e. users/projects that use such variants.

- Variants are not just code fragments but are places where they can be proposed, discussed, versioned, tested, measured, etc. Want to collect data on the way a function is used in order to bootstrap some machine learning model ? It's the place where this data is stored and can be reached.

Sometimes, especially at "political moments" (like elections in a project I was involved in recently - and I wasn't even a candidate), it can feel like being overwhelmed by a tidal wave.

If I only have 1 spare hour per day for a project, there is neither time nor emotional energy to handle emails that are so full of demanding questions that it would take 3 hours to process carefully and reply carefully. And if you don't reply carefully, they send you more, writing longer and getting more obsessive (and sometimes personal) as if they sense you'll engage them in a long conversation, so being careful in the first place is a net win.

Even if it only took 1 hour, that's still used up all the time I was going to use on other productive things, the "real work".

I am in awe of maintainers who seem to reply to an onslaught of demanding questioners, and somehow satisfy them.

For me, these are relevant:

"Assholes are Killing Your Project" (Donnie Berkholz) https://www.slideshare.net/dberkholz/assholes-are-killing-yo... https://www.youtube.com/watch?v=-ZSli7QW4rg