poole-response.html [plain text]
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css"> /* <![CDATA[ */
@import "branding/css/tigris.css";
@import "branding/css/inst.css";
/* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
href="branding/css/print.css"/>
<script type="text/javascript" src="branding/scripts/tigris.js"></script>
<title>Why Damon Poole is Wrong about Subversion and Open Source</title>
</head>
<body>
<div class="app">
<h1 style="text-align: center;"
>Why Damon Poole is Wrong about Subversion and Open Source</h1>
<p style="font-size: 70%; text-align: center;">[First published: 10 Jan 2006,
canonical URL:
<a href="http://svn.collab.net/repos/svn/trunk/www/poole-response.html"
>http://svn.collab.net/repos/svn/trunk/www/poole-response.html</a>]</p>
<p>In an <a
href="http://www.sdtimes.com/link/29026">
opinion piece</a> 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.</p>
<p>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 (<a
href="http://www.sdtimes.com/article/opinion-20051215-02.html"
>http://www.sdtimes.com/article/opinion-20051215-02.html</a>).
Indented red text in italics is quoted from the original, the regular
text is our commentary:</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<p>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.</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<p><a href="http://www.collab.net/">CollabNet</a>, 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 (<a
href="http://www.redhat.com/">Red Hat</a> also sponsored some of
its early development). Other open source SCM systems also receive
corporate sponsorship, for example, <a
href="http://www.canonical.com/">Canonical</a> sponsors <a
href="http://bazaar-ng.org/">Bazaar-NG</a>, <a
href="http://bestpractical.com/">Best Practical</a> supports <a
href="http://svk.elixus.org/">SVK</a> development, etc.</p>
<p>Regarding innovation: let's remember that it was an open source
product (<a href="http://www.nongnu.org/cvs/">CVS</a>) 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.</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<p>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.</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<blockquote>
<p style="color: red;"><i>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).</i></p>
</blockquote>
<p>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 (<a
href="http://subversion.tigris.org/">http://subversion.tigris.org/</a>).</p>
<p>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.</p>
<p>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.</p>
<p>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 <a
href="http://www.edgewall.com/trac/">Trac</a>, 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.</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<p>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.</p>
<p>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.</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<p>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.</p>
<p>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.</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<p>The statistics Poole gives above do not support his case; they may
support the opposite.</p>
<p>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 <i>not</i> to see at least this much
growth, even if the sector were merely holding steady.</p>
<p>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 <a
href="http://subversion.tigris.org/svn-dav-securityspace-survey.html"
>this one</a>, showing Subversion's extremely rapid growth since even
before its 1.0 release, might be useful for comparison.</p>
<blockquote>
<p style="color: red;"><i>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.</i></p>
</blockquote>
<p>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.</p>
</div>
</body>
</html>