3

One thing in OSS I have now run into a few times are project owners or maintainers who are very aggressive. Sentences are taken out of context, asking about a design decision is seen as an attack and a demand for free work, and the most mild of statements are labelled as abusive.

I have tried engaging, but the fever pitch of their reaction started to look like they were going to involve a lawyer over a versioning option. This latest one I think I just need to stop all communication. But is there a better way?

5

In the end, an open source project is just a bunch of humans, and where there are humans there isn't always harmony. This is a social problem, it is not specific to open source, and there is nothing particular about open source that would help avoid this.

However, open source has an escape hatch: any open source license allows you to fork the project. You can do your own thing, without having to engage with the current maintainers. The two projects can still use each other's patches as long as they stay under compatible licenses.

If you do a better job at maintainership than the current maintainers (and good maintainership involves social aspects such as the tone used to respond to bug reports), then the community may eventually migrate over to your fork. Or may not. Part of the beauty of open source is that the code and the community cannot be shackled to a particular maintainer or vendor.

Such forks (either a fork of the code that won over the community, or the community moving to a similar but separate project) have happened multiple times over the history of open source. An older example might be the XFree86 server that was developed by a Core Team. After some drama most developers eventually moved to the X.org fork that is nowadays used by most Linux distros. A more recent example is the Node.js → io.js fork in 2014 over a disagreement in project governance. However, a few months later the two projects reunited under the governance of a neutral foundation.

Unfortunately, maintainership requires a ton of effort.

If you really want to go that route, you should check a couple of things first:

  • Is the project really under an open source license? OSI-approved licenses should be fine.
  • Is the project name encumbered by trademarks? For example, you cannot distribute your own version of “Java” or “Firefox” without changing the name and branding.
  • Does the license include a requirement to change the name? The Artistic License and the Open Font License come to mind.
  • As a practical consideration: is the original maintainer particularly litigious? Just because you have a right to fork the code doesn't mean they will accept this. They could e.g. hit a GitHub repo with a DMCA notice which will force it to be taken down at least temporarily.

Maintaining a good fork isn't just a lot of effort, it will also be perceived as as quite hostile move. This will likely sever your relationship to the original maintainers beyond repair. But if you don't have a workable relationship to begin with, nothing is lost.

  • And in some cases you can have hard to work with maintainers/owners and can't really fork due to how ingrained it has become in mainstream distros (aka, the systemd issue) – ivanivan Mar 15 at 23:45
  • 1
    @ivanivan you can fork and use your fork, but you can't expect the community to move to your fork as well unless it is clearly and consistently superior, technically and socially. Systemd is not without problems, but so far no one seems to have stepped up to maintain a better variant. And I can understand why, given how much effort that would be. That particular project is also not quite as b0rked as e.g. XFree86 around its fork. – amon Mar 16 at 0:12
  • I think this is a good response, but part of me thinks there isn't an actual solution to this problem. – Josh Mar 16 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.