Open-source, when (not) to go on a crusade for a feature?

Question

I've submitted a patch to an open source library that was ignored by the maintainers. Some time after the submittal one of the maintainers implemented a different patch for the same problem.

The implementation has been present for a few versions, but hardly anyone uses it, even the examples in the library still resort to alternate approaches that may be perceived as hacks.

It turns out that my proposal wasn't the only one, in the past others have tried to solve the same problem, and submitted more or less the same solution. However, I'm the only one still going at it.

This manifests itself as linking my proposal to various issues that i believe would be easy to solve with the API. I collect examples of improper use of the existing API (which i believe to be flawed) and demonstrated that it is not seeing adoption because users still resort to the "old ways".

I went further and filed a couple of bugs, but they were deemed as features.

In this process it feels like i have alienated myself from the community and that other devs simply ignore my comments.

I want to know what to do in this situation. What is considered good etiquette, what should be the drive behind making an aggressive or less aggressive push of a feature/patch? Is there some magic number of "well i've tried" before one should give up. Should one be concerned how one is perceived when doing this kind of a push, or should it not even be a factor in the matter? I see the value of any opinion being expressed for anyone who potentially might be interested in the matter.

In my last attempt I refactored some of the code and halved the number of lines in some files. I can see this swing many ways, good and bad. "Here it works"/"Here you've no idea what you're doing". On the dev front, maybe i didn't want to do the refactor, I just wanted to do the feature, is there a trade off here between "trust me" and putting your code to the test?

Are there ways to go through this process more efficiently? I tend to write lengthy posts with a lot of (pseudo)code, i've seen people write much conciser posts etc.

Answer 1

An open source project is more than a bunch of source code that anyone can download. It also includes an active community that works together to help make the project better for everyone that uses it. If the owners of a project don't encourage and nurture the community that goes with a project, then they end up being replaced or just cast aside.

The smaller your customisations, the easier it is for you to maintain your own "flavour" of a project that has small alterations to your liking. You can merge the parent projects changes into yours for as long as you want, even if the original project isn't interested in accepting your changes into their project.

One option you have is to fork the project and develop it and the community around it so that your fork becomes the preferred place to go. You can still merge changes made by the original project into yours as well as adding your own changes and changes offered to you by others. An example of this might be OpenSSL, which was forked into LibreSSL. Sometimes this happens as the main goal of the new project does not match original goals, this is where we get NetBSD, OpenBSD, DragonflyBSD - all of these projects work together and share code with common goals but have different overall goals that set them apart. Some other examples are OpenSSH and OpenSMTP. There is nothing wrong with forking a project to follow your own goals, it is part of what empowers open source projects.

Anoter option is to start a new project from scratch that has no affiliation with the existing project. You can put the linux kernel into this category.

Answer 2

Yes, open source has a way to address exactly the issue you're having.

It's called "forking". It means you create your own version of the software. In Github, it can happen by just pressing one button once, and your fork will also be listed in the list of forks.

Forking is not discouraged; it's very much encouraged. In fact, with Git the preferred development happens by having many forks.

If they refuse to merge your fork, then you can start contacting the other people wanting the same feature you want and telling them about your fork.

Who knows, perhaps your fork could overtake in popularity the original project!