The dividing line between supporting code and forking it

February 28, 2010

Suppose that you want to provide support for a bunch of open source code but are not the primary author or maintainer. Inevitably you will have to patch bugs and add features on your own in some way (and perhaps fix the code to port it to your environment or whatever). This leads to a question: where is the dividing line between merely supporting the code and actually forking your own version of the code?

To me, the dividing line is whether you can get your changes accepted upstream and applied to the main codebase (assuming that you even try). If you can't get changes accepted upstream, you have to maintain your own version of the code, forward-porting all of your fixes and changes to new versions of the main code that you chose to adopt (or perhaps porting changes from the main code into your version). Ergo, forking.

If you can get changes accepted upstream you have less divergence, especially over the long term. Instead of carrying changes that have to live forever and be perpetually forward-ported, you are instead simply developing and maintaining changes until they can be merged, which is part of normal development for many projects. (Of course, ideally you merge changes upstream as fast as possible; the faster you merge, the less work each of your changes is for you.)

The direct corollary is that your ability to merely support code instead of forking it depends on how willing the upstream is to accept your changes. A closed or mostly closed upstream forces you to effectively fork, whether you like it or not. And of course this presumes that you can find an upstream and that the upstream is alive.

(In real life many people doing 'support' for open source projects carry a mix of changes that are in the process of going upstream and changes that the upstream will never accept for various reasons. Note that a lot of people do this sort of support in the open source world, as this issue applies to lots of people who packages programs for particular operating systems.)

Written on 28 February 2010.
« An 'email marketing' wish
Why XML is terrible for configuration files »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Feb 28 00:16:16 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.