The Three F's of Open Source Development
2019/11/04 (408 words)

I write and publish open source code. I quite often get bug fixes, patches, requests and questions regarding the things I have published. Most of the feedback is respectful and helpful. However occasionally there are other requests. This page is where I plan to redirect them as a final warning before I block and ignore them.

The three F’s to open source development.

Fix it, Fork it, Fuck off.

Fix it.

If you find a bug, notice missing, incorrect or misleading documentation, or want an enhancement, your first option is to make a request to fix it. Raise the issue in the bug/request tracker of choice. Heck even a tweet at the owner might be good enough. However that is not your only option. You can choose submit a patch after you fix it yourself, or if you lack the skills, pay someone else to do so. You could also offer to pay the maintainer to resolve this for you. If there is enough value for you to raise the issue, perhaps there is enough value to pay to resolve it?

The maintainer however has all rights to reject your patch, close your bug ticket or turn down your offer of payment. It is their project. So should you get angry and start abusing them? No. You should move to the next F of open source software.

Fork it.

If the maintainer refuses to make your change, then you have the option to fork the project. If your project becomes better it will naturally gain more attention and be more inclusive. There are many successful forked projects https://en.wikipedia.org/wiki/List_of_software_forks so this is a viable strategy. Don’t have the skills? Remember you can always pay someone to maintain your fork, or to implement the changes you want into your own version.

Fuck off.

The last option is to frankly bugger off. If you are unwilling to either submit a patch, maintain a fork or put your money where you mouth is just go away. There is no need to abuse the maintainer, repeatedly post the bug, harass them over twitter. All this results in is people wanting to not contribute their time and expertise for free. It also makes you a douche-bag. Always remember you are talking to a real human being, and just because their ideas of how to implement a project are not in line with your own does not mean you have any right to abuse them.