Hacker News Reader

Comment by bluesign | Hacker News Reader

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.

View on HN

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.

Maintainer bottleneck is the origin of forking-as-a-feature; previously forking had been considered a disaster: https://gcc.gnu.org/news/announcement.html (1997)

The most notable fork before then was likely Lucid Emacs and the Emacs Schism of 1993. https://www.emacswiki.org/emacs/EmacsSchism :

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

Reply on news.ycombinator.com