This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
What's behind Subversion's dominance?
As Jeffrey Hammond, of Forrester, blogged recently, Subversion is the overwhelmingly predominant version control system today. Yet if you read the open-source blogs and discussions, you see loads of growth in the "Distributed Version Control Systems" (DVCS), such as git, Mercurial, Bazaar, and the like. What's going on here?
There's an interesting even just now in the Linux kernel that sheds some light. This week, according to Greg Kroah-Hartman, some Google-contributed, Android-related code was removed from the Linux kernel. The reason: the code in question is both incomplete on its own, and specific to the Android device. Either of these properties makes it constitute a "fork," and in this case there seemed no prospect of ever healing the fork.
Now, you might think a "fork" is something that happens to the code, and certainly that's part of it. But as Kroah-Hartman points out, code-forking happens all the time. The problem here is that "no one cared about the code, so it was removed." This doesn't mean no one cares about the code that's going into Android–certainly not! It means two other things:
- No one was taking care of the code that had been contributed into the Linux kernel tree
- No one was consuming, using, extending, or applying the code for new purposes
It had been, as the phrase is, "thrown over the wall," and left.
That–abandonment–is a big problem for open-source code, both in that it's harmful and wasteful, and also in that it's common. But it's a cultural problem, not a technical one: there's no claim that this was "bad" code, just that it was a dead end.
Open-source communities are actually pretty robust against this sort of harm. This event illustrates one such defense: if it's dead, dump it. Another commonly applied defense is simply to let projects die when no one cares: the notorious numbers of open-source projects that never got anywhere are actually signs of health: the open-source community has a powerful defense called "cheap failure," that allows ideas to start out sounding good, then peter out harmlessly. One of the cool things about DVCS is that it's very easy to start a fork, very easy to reintegrate it if you choose to–and very easy to chop it off and toss it away if it ends up a dead end, as we see here.
But if we recast this whole experience into an enterprise context, it begins to look very different indeed. The essential difference is that failure within an enterprise is never "cheap." If the Linux kernel community, including Google/Android, were an enterprise, then all the work that has been spent on this fork would have come out of corporate wallet, and the decision to toss it would be a recognition of wasted resources: salaries, equipment, time, plans, marketing, process–endless kinds of costs, sunk with no payback.
The great contrast between the low cost of open-source failure, and the high cost of enterprise failure has far-reaching effects, even down to details like tool choice.
- An open-source project can usefully tell prospective contributors "clone the tree, work up your idea, and get back to us when you have something to show," because there's no cost to the project if the idea never bears fruit. An enterprise, however, does have such costs, and at the least has little incentive to allow that sort of work style.
- An open-source project can allow parallel, semi-independent, persistent forks, such as the several Linux distributions: as long as there are enough people (whether sponsored or volunteer) interested in working the fork, as long as things stay controlled enough that work can be merged back and forth, there's no problem. But an enterprise may need to match its centralized budgeting and resource management with some centralized supervision, planning, marketing, and management: making it easy to disappear from the radar is not a good thing.
And that, I think, is at least part of why the centralized Subversion model remains so strong.