Login | Register
My pages Projects Community openCollabNet

Why Damon Poole is Wrong about Subversion and Open Source

[First published: 10 Jan 2006, canonical URL: http://svn.collab.net/repos/svn/trunk/www/poole-response.html]

In an opinion piece in the Dec. 15th issue of the Software Development Times, AccuRev CTO Damon Poole makes various false or misleading claims about Subversion and about open source SCM systems in general. Beyond that, he uses not-very-subtly biased language to imply that only proprietary SCM systems are worth taking seriously. Since his company competes directly against open source systems, it's understandable that he'd want his readers to think this, but it is a disservice to people seeking solutions to their change management problems.

Poole's article does make some valid points, and we agree that commercial investment is good for software, both proprietary and open source. However, we think he misanalyzes the amount, nature, and effect of commercial backing in open source software. The purpose of this response is to correct his mistakes and point out his biases. Therefore we address only those issues below, and urge you to read his original piece for the rest (http://www.sdtimes.com/article/opinion-20051215-02.html). Indented red text in italics is quoted from the original, the regular text is our commentary:

According to the analyst firm Ovum, most professional developers are still using homegrown SCM tools. Homegrown tools are either built entirely from scratch or more commonly built atop one of the free version-control tools such as CVS or Subversion.

By saying "still", Poole tries to imply some clear industry trend toward proprietary solutions, when there is no such trend. Numbers are hard to come by, because open source licenses cannot be tracked like proprietary ones, but anyone working in professional software development today knows that adoption of open source SCM is strong; on the Subversion mailing lists, we often see posts from people seeking to switch from proprietary tools to Subversion. And the degree to which an SCM solution is "homegrown" is largely independent of whether it is based on open source or proprietary technology, as we discuss in more detail below.

Unlike major open-source projects such as Linux, which receives corporate support in the form of salaried engineers from such companies as IBM and Red Hat, open-source SCM projects receive very little corporate sponsorship. As a result, features and innovation in the open-source SCM tools lag far behind the commercial SCM tools.

CollabNet, which started the Subversion project, has sponsored it consistently for six years as of this writing, employing several full-time developers and paying all the hosting and infrastructure costs (Red Hat also sponsored some of its early development). Other open source SCM systems also receive corporate sponsorship, for example, Canonical sponsors Bazaar-NG, Best Practical supports SVK development, etc.

Regarding innovation: let's remember that it was an open source product (CVS) that made WAN-accessible version control repositories an industry standard, a feature some proprietary products are still scrambling to catch up with, now that globally distributed development is becoming the norm. Poole is naive to assume that only proprietary models are capable of real innovation; it's never been that simple. But even granting that wrong assumption, open source development receives more, and steadier, funding than he acknowledges.

Some of the major features that are available only in the commercial tools are refactoring (rename operations that preserve history and merge operations), issue-based change packages, tight integration with issue tracking, stream-based development, caching, replication, full support for mixed Unix and Windows environments, and process workflow. In addition to these examples, there are literally hundreds of smaller features that are available only in the commercial tools.

Many of these features are available in open source tools; anyone familiar with the field would be able to think of counterexamples right away. Perhaps Poole has highly idiosyncratic definitions of these features, carefully constructed so as to make his statement true in some formal sense, but if that's the case, he should state those definitions clearly. His statements as given are misleading, at least as most readers would be likely to interpret them. We also wonder if he has actually enumerated those "hundreds" of features that are "available only in the commercial tools" — and if he has tried the same exercise in the other direction.

CVS, introduced in 1986 and now the most popular open-source SCM tool, is missing not only the features above, but also some of the more basic features, such as atomic transactions, fast branching, rename tracking and merge tracking.

In 2000, a group of open-source developers (with the help of a commercial sponsor, CollabNet), set out to address this deficit by creating a tool from scratch, called Subversion. Their goals and road map do not include the more advanced capabilities listed earlier. In the five years since inception, they have accomplished only the first two of their four goals, atomic transactions and fast branching. It comes as no surprise that rename tracking and merge tracking are still missing from Subversion, as those are both difficult SCM problems that are typically either part of the original architecture or never implemented (as is the case with CVS).

This isn't just bias or misstatement: it's factually incorrect. And inexcusable, given that everything about the Subversion project and its history is publicly accessible at the project's home page (http://subversion.tigris.org/).

Looking at the original version of the Subversion home page, as it appeared when the project was started, we count twelve goals (not four), many with subgoals. Almost all of these were accomplished; a few were deferred and replaced with different goals — reprioritizations that resulted from listening closely to our user community, a responsiveness which is one of open source's great strengths.

Furthermore, Subversion's road map (which extends far beyond the 1.0 goals we reached in 2004) has long included many of the features Damon Poole claims the project is ignoring. There are even issues filed in our public issue tracker about some of these features, with links to design discussions and patches.

But there's a deeper sense in which he is mistaken. Subversion by itself may be a standalone version control system, but thanks to its rich and well-documented APIs, it has been integrated into fuller change management systems, that include features like tight integration with issue tracking (see Trac, for example). Such third-party repackaging is the norm in open source software, and means that end users can enjoy the benefits of tool integration without needing to become integration experts themselves. Thus Poole should either compare just the version control component of a proprietary suite against Subversion, or compare a full proprietary suite against a full open source suite. Comparing standalone Subversion with an entire proprietary tool suite is weighing apples against oranges.

Open-source SCM tools are written by open-source developers primarily to meet their own needs. This leaves out key constituencies such as release engineers, QA and management. The commercial SCM tools need to appeal to all constituencies and thus offer a more balanced set of features and benefits for the whole organization.

There is a kernel of truth to this description of open source, but the Subversion project (with institutional support from CollabNet) has worked hard to overcome this problem by deliberately seeking out enterprise-level users and studying their requirements, to help us design and prioritize features.

It is certainly not true that proprietary SCM tools need to appeal to more constituencies than open source tools. Any tool that wants to be successful will appeal to as many constituencies as it can while remaining coherent and comprehensible. That's exactly what we're trying to do with Subversion, and we believe we're succeeding.

Homegrown tools tend to be built to satisfy current business requirements, and thus, they lack the flexibility to adapt quickly to changing business needs. Reconfiguring usually means partial rewrites or adding new functionality. The need for SCM vendors to meet the requirements of many organizations requires them to design SCM tools that easily adapt to a wide range of business requirements via customization. When it comes time to change your process, it is far easier to change customizations in a commercial SCM tool than it is to rewrite or add new functionality to a homegrown SCM tool.

This doesn't ring true, even if one accepts the premise that a proprietary tool will need less customization than an open source one (which is not always the case). Why would a closed source tool be inherently more flexible than an open source one, when open source tools come with source code, a wealth of third-party add-ons in some cases, and a vastly better record of standards-compliance and interoperability? Our experience has been the opposite: open source tools are more flexible than proprietary ones. Flexibility may or may not be a good thing, depending on how much customization one desires, but that is a different question.

This might also be the place to point out that Poole likes to say "homegrown" when he's talking about open source, but "customization" when talking about proprietary solutions. We don't see the difference. Those who run open source SCM systems customize them in the same way they would a proprietary system: via the published APIs and administrative interfaces. Open source solutions are not necessarily more nor less "homegrown" than proprietary ones. The amount of customization required depends on how well a tool natively fits one's needs, regardless of whether that tool is proprietary or open source. Poole's use of "homegrown" is merely pejorative.

Commercial SCM tools are rapidly gaining in popularity. In 1994, according to IDC, just US$173 million was spent on commercial SCM tools. In 2004, $1,062 million was spent, with double-digit growth in both 2003 and 2004. Looking forward, IDC expects this growth to continue.

The statistics Poole gives above do not support his case; they may support the opposite.

Between 1994 and 2004, the software industry in general grew hugely — the sheer number of people writing code for a living has been increasing for a long time. To see a roughly tenfold growth in dollars spent on commercial SCM licenses is only to be expected (and he doesn't say whether the numbers have been adjusted for inflation, nor whether they control for real changes in license prices). It would be surprising not to see at least this much growth, even if the sector were merely holding steady.

But anyway, counting license dollars is conveniently incommensurate with open source growth, since open source software don't have license fees. What Poole should be interested in is relative growth in user base between proprietary and open source SCM systems, in which case a chart like this one, showing Subversion's extremely rapid growth since even before its 1.0 release, might be useful for comparison.

With this growth has come an increase in innovation, both from the established vendors and from new entrants in the market. In short, this is a great time to consider stepping up to a commercial SCM tool.

The SCM field in general is seeing a lot of innovation lately, but this phenomenon is just as true in the open source systems as in the proprietary ones — as the users and authors of Subversion, SVK, Codeville, Mercurial, Vesta, Darcs, monotone, Bazaar-NG, CVSNT, Arch/tla, Aegis, GIT, and many others could testify. We'd like to amend Poole's sentiment: this is a great time to consider stepping up to the SCM tool that best fits your needs, without distraction from baseless prejudices about proprietary versus open source software.