The Cost of Going it Alone

When working with community software, which costs more, working a private branch, based off a stable version, or developing the features upstream? Many companies choose to take stable software and adapt it to their needs, rather than building their projects near the tip of the upstream projects.

In the first case, you are taking on board the maintenance cost of your code, plus the cost of periodically merging code from the upstream project back into your branch, with all of the integration issues that brings. In the second, you lose time with community processes, rewriting code to the satisfaction of the community, and you risk maintaining features for months on personal branches before they finally meet the approval of the project maintainers, if they ever do.

The answer will be obvious to most people – but depending on who you are, the “obvious” answer might change.

People who are accustomed to working with community projects, who have perhaps gone through painful merges in the past, will recognise the value of getting changes upstream. Others, who have seem many hours wasted waiting for patch review, or facing Yet Another Patch Rejection, may point to the obvious advantage of self determination that a private branch gives.

By looking at the past, we hope to give a clear quantitative answer to the question: Does maintaining code out-of-tree cost more than getting it upstream, in the long run? Are there situations when maintaining a feature out of tree makes more sense?