www/poole-response.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4 <head>
   5 <style type="text/css"> /* <![CDATA[ */
   6  @import "branding/css/tigris.css";
   7  @import "branding/css/inst.css";
   8  /* ]]> */</style>
   9 <link rel="stylesheet" type="text/css" media="print"
  10  href="branding/css/print.css"/>
  11 <script type="text/javascript" src="branding/scripts/tigris.js"></script>
  12 <title>Why Damon Poole is Wrong about Subversion and Open Source</title>
  13 </head>
  14
  15 <body>
  16 <div class="app">
  17
  18 <h1 style="text-align: center;"
  19 >Why Damon Poole is Wrong about Subversion and Open Source</h1>
  20
  21 <p style="font-size: 70%; text-align: center;">[First published: 10 Jan 2006,
  22 canonical URL:
  23 <a href="http://svn.collab.net/repos/svn/trunk/www/poole-response.html"
  24         >http://svn.collab.net/repos/svn/trunk/www/poole-response.html</a>]</p>
  25
  26 <p>In an <a
  27 href="http://www.sdtimes.com/article/opinion-20051215-02.html">
  28 opinion piece</a> in the Dec. 15th issue of the Software Development
  29 Times, AccuRev CTO Damon Poole makes various false or misleading
  30 claims about Subversion and about open source SCM systems in general.
  31 Beyond that, he uses not-very-subtly biased language to imply that
  32 only proprietary SCM systems are worth taking seriously.  Since his
  33 company competes directly against open source systems, it's
  34 understandable that he'd want his readers to think this, but it is a
  35 disservice to people seeking solutions to their change management
  36 problems.</p>
  37
  38 <p>Poole's article does make some valid points, and we agree that
  39 commercial investment is good for software, both proprietary and open
  40 source.  However, we think he misanalyzes the amount, nature, and
  41 effect of commercial backing in open source software.  The purpose of
  42 this response is to correct his mistakes and point out his biases.
  43 Therefore we address only those issues below, and urge you to read his
  44 original piece for the rest (<a
  45 href="http://www.sdtimes.com/article/opinion-20051215-02.html"
  46 >http://www.sdtimes.com/article/opinion-20051215-02.html</a>).
  47 Indented red text in italics is quoted from the original, the regular
  48 text is our commentary:</p>
  49
  50 <blockquote>
  51 <p style="color: red;"><i>According to the analyst firm Ovum, most
  52 professional developers are still using homegrown SCM tools. Homegrown
  53 tools are either built entirely from scratch or more commonly built
  54 atop one of the free version-control tools such as CVS or
  55 Subversion.</i></p>
  56 </blockquote>
  57
  58 <p>By saying "still", Poole tries to imply some clear industry trend
  59 toward proprietary solutions, when there is no such trend.  Numbers
  60 are hard to come by, because open source licenses cannot be tracked
  61 like proprietary ones, but anyone working in professional software
  62 development today knows that adoption of open source SCM is strong; on
  63 the Subversion mailing lists, we often see posts from people seeking
  64 to switch from proprietary tools to Subversion.  And the degree to
  65 which an SCM solution is "homegrown" is largely independent of whether
  66 it is based on open source or proprietary technology, as we discuss in
  67 more detail below.</p>
  68
  69 <blockquote>
  70 <p style="color: red;"><i>Unlike major open-source projects such as
  71 Linux, which receives corporate support in the form of salaried
  72 engineers from such companies as IBM and Red Hat, open-source SCM
  73 projects receive very little corporate sponsorship. As a result,
  74 features and innovation in the open-source SCM tools lag far behind
  75 the commercial SCM tools.</i></p>
  76 </blockquote>
  77
  78 <p><a href="http://www.collab.net/">CollabNet</a>, which started the
  79 Subversion project, has sponsored it consistently for six years as of
  80 this writing, employing several full-time developers and paying all
  81 the hosting and infrastructure costs (<a
  82 href="http://www.redhat.com/">Red&nbsp;Hat</a> also sponsored some of
  83 its early development).  Other open source SCM systems also receive
  84 corporate sponsorship, for example, <a
  85 href="http://www.canonical.com/">Canonical</a> sponsors <a
  86 href="http://bazaar-ng.org/">Bazaar-NG</a>, <a
  87 href="http://bestpractical.com/">Best&nbsp;Practical</a> supports <a
  88 href="http://svk.elixus.org/">SVK</a> development, etc.</p>
  89
  90 <p>Regarding innovation: let's remember that it was an open source
  91 product (<a href="http://www.nongnu.org/cvs/">CVS</a>) that made
  92 WAN-accessible version control repositories an industry standard, a
  93 feature some proprietary products are still scrambling to catch up
  94 with, now that globally distributed development is becoming the norm.
  95 Poole is naive to assume that only proprietary models are capable of
  96 real innovation; it's never been that simple.  But even granting that
  97 wrong assumption, open source development receives more, and steadier,
  98 funding than he acknowledges.</p>
  99
 100 <blockquote>
 101 <p style="color: red;"><i>Some of the major features that are
 102 available only in the commercial tools are refactoring (rename
 103 operations that preserve history and merge operations), issue-based
 104 change packages, tight integration with issue tracking, stream-based
 105 development, caching, replication, full support for mixed Unix and
 106 Windows environments, and process workflow. In addition to these
 107 examples, there are literally hundreds of smaller features that are
 108 available only in the commercial tools.</i></p>
 109 </blockquote>
 110
 111 <p>Many of these features are available in open source tools; anyone
 112 familiar with the field would be able to think of counterexamples
 113 right away.  Perhaps Poole has highly idiosyncratic definitions of
 114 these features, carefully constructed so as to make his statement true
 115 in some formal sense, but if that's the case, he should state those
 116 definitions clearly.  His statements as given are misleading, at least
 117 as most readers would be likely to interpret them.  We also wonder if
 118 he has actually enumerated those "hundreds" of features that are
 119 "available only in the commercial tools"&nbsp;&mdash;&nbsp;and if he
 120 has tried the same exercise in the other direction.</p>
 121
 122 <blockquote>
 123 <p style="color: red;"><i>CVS, introduced in 1986 and now the most
 124 popular open-source SCM tool, is missing not only the features above,
 125 but also some of the more basic features, such as atomic transactions,
 126 fast branching, rename tracking and merge tracking.</i></p>
 127 </blockquote>
 128
 129 <blockquote>
 130 <p style="color: red;"><i>In 2000, a group of open-source developers
 131 (with the help of a commercial sponsor, CollabNet), set out to address
 132 this deficit by creating a tool from scratch, called Subversion. Their
 133 goals and road map do not include the more advanced capabilities
 134 listed earlier. In the five years since inception, they have
 135 accomplished only the first two of their four goals, atomic
 136 transactions and fast branching. It comes as no surprise that rename
 137 tracking and merge tracking are still missing from Subversion, as
 138 those are both difficult SCM problems that are typically either part
 139 of the original architecture or never implemented (as is the case with
 140 CVS).</i></p>
 141 </blockquote>
 142
 143 <p>This isn't just bias or misstatement: it's factually incorrect.
 144 And inexcusable, given that everything about the Subversion project
 145 and its history is publicly accessible at the project's home page (<a
 146 href="http://subversion.tigris.org/">http://subversion.tigris.org/</a>).</p>
 147
 148 <p>Looking at the original version of the Subversion home page, as it
 149 appeared when the project was started, we count twelve goals (not
 150 four), many with subgoals.  Almost all of these were accomplished; a
 151 few were deferred and replaced with different
 152 goals&nbsp;&mdash;&nbsp;reprioritizations that resulted from listening
 153 closely to our user community, a responsiveness which is one of open
 154 source's great strengths.</p>
 155
 156 <p>Furthermore, Subversion's road map (which extends far beyond the
 157 1.0 goals we reached in 2004) has long included many of the features
 158 Damon Poole claims the project is ignoring.  There are even issues
 159 filed in our public issue tracker about some of these features,
 160 with links to design discussions and patches.</p>
 161
 162 <p>But there's a deeper sense in which he is mistaken.  Subversion by
 163 itself may be a standalone version control system, but thanks to its
 164 rich and well-documented APIs, it has been integrated into fuller
 165 change management systems, that include features like tight
 166 integration with issue tracking (see <a
 167 href="http://www.edgewall.com/trac/">Trac</a>, for example).  Such
 168 third-party repackaging is the norm in open source software, and means
 169 that end users can enjoy the benefits of tool integration without
 170 needing to become integration experts themselves.  Thus Poole should
 171 either compare just the version control component of a proprietary
 172 suite against Subversion, or compare a full proprietary suite against
 173 a full open source suite.  Comparing standalone Subversion with an
 174 entire proprietary tool suite is weighing apples against oranges.</p>
 175
 176 <blockquote>
 177 <p style="color: red;"><i>Open-source SCM tools are written by
 178 open-source developers primarily to meet their own needs. This leaves
 179 out key constituencies such as release engineers, QA and
 180 management. The commercial SCM tools need to appeal to all
 181 constituencies and thus offer a more balanced set of features and
 182 benefits for the whole organization.</i></p>
 183 </blockquote>
 184
 185 <p>There is a kernel of truth to this description of open source, but
 186 the Subversion project (with institutional support from CollabNet) has
 187 worked hard to overcome this problem by deliberately seeking out
 188 enterprise-level users and studying their requirements, to help us
 189 design and prioritize features.</p>
 190
 191 <p>It is certainly not true that proprietary SCM tools need to appeal
 192 to more constituencies than open source tools.  Any tool that wants to
 193 be successful will appeal to as many constituencies as it can while
 194 remaining coherent and comprehensible.  That's exactly what we're
 195 trying to do with Subversion, and we believe we're succeeding.</p>
 196
 197 <blockquote>
 198 <p style="color: red;"><i>Homegrown tools tend to be built to satisfy
 199 current business requirements, and thus, they lack the flexibility to
 200 adapt quickly to changing business needs. Reconfiguring usually means
 201 partial rewrites or adding new functionality. The need for SCM vendors
 202 to meet the requirements of many organizations requires them to design
 203 SCM tools that easily adapt to a wide range of business requirements
 204 via customization. When it comes time to change your process, it is
 205 far easier to change customizations in a commercial SCM tool than it
 206 is to rewrite or add new functionality to a homegrown SCM
 207 tool.</i></p>
 208 </blockquote>
 209
 210 <p>This doesn't ring true, even if one accepts the premise that a
 211 proprietary tool will need less customization than an open source one
 212 (which is not always the case).  Why would a
 213 closed source tool be inherently more flexible than an open source
 214 one, when open source tools come with source code, a wealth of
 215 third-party add-ons in some cases, and a vastly better record of
 216 standards-compliance and interoperability?  Our experience has been
 217 the opposite: open source tools are more flexible than proprietary
 218 ones.  Flexibility may or may not be a good thing, depending on how
 219 much customization one desires, but that is a different question.</p>
 220
 221 <p>This might also be the place to point out that Poole likes to say
 222 "homegrown" when he's talking about open source, but "customization"
 223 when talking about proprietary solutions.  We don't see the
 224 difference.  Those who run open source SCM systems customize them in
 225 the same way they would a proprietary system: via the published APIs
 226 and administrative interfaces.  Open source solutions are not
 227 necessarily more nor less "homegrown" than proprietary ones.  The
 228 amount of customization required depends on how well a tool natively
 229 fits one's needs, regardless of whether that tool is proprietary or
 230 open source.  Poole's use of "homegrown" is merely pejorative.</p>
 231
 232 <blockquote>
 233 <p style="color: red;"><i>Commercial SCM tools are rapidly gaining in
 234 popularity. In 1994, according to IDC, just US$173 million was spent
 235 on commercial SCM tools. In 2004, $1,062 million was spent, with
 236 double-digit growth in both 2003 and 2004. Looking forward, IDC
 237 expects this growth to continue.</i></p>
 238 </blockquote>
 239
 240 <p>The statistics Poole gives above do not support his case; they may
 241 support the opposite.</p>
 242
 243 <p>Between 1994 and 2004, the software industry in general grew
 244 hugely&nbsp;&mdash;&nbsp;the sheer number of people writing code for a
 245 living has been increasing for a long time.  To see a roughly tenfold
 246 growth in dollars spent on commercial SCM licenses is only to be
 247 expected (and he doesn't say whether the numbers have been adjusted
 248 for inflation, nor whether they control for real changes in license
 249 prices).  It would be surprising <i>not</i> to see at least this much
 250 growth, even if the sector were merely holding steady.</p>
 251
 252 <p>But anyway, counting license dollars is conveniently incommensurate
 253 with open source growth, since open source software don't have license
 254 fees.  What Poole should be interested in is relative growth in user
 255 base between proprietary and open source SCM systems, in which case a
 256 chart like <a
 257 href="http://subversion.tigris.org/svn-dav-securityspace-survey.html"
 258 >this one</a>, showing Subversion's extremely rapid growth since even
 259 before its 1.0 release, might be useful for comparison.</p>
 260
 261 <blockquote>
 262 <p style="color: red;"><i>With this growth has come an increase in
 263 innovation, both from the established vendors and from new entrants in
 264 the market. In short, this is a great time to consider stepping up to
 265 a commercial SCM tool.</i></p>
 266 </blockquote>
 267
 268 <p>The SCM field in general is seeing a lot of innovation lately, but
 269 this phenomenon is just as true in the open source systems as in the
 270 proprietary ones&nbsp;&mdash;&nbsp;as the users and authors of
 271 Subversion, SVK, Codeville, Mercurial, Vesta, Darcs, monotone,
 272 Bazaar-NG, CVSNT, Arch/tla, Aegis, GIT, and many others could testify.
 273 We'd like to amend Poole's sentiment: this is a great time to consider
 274 stepping up to the SCM tool that best fits your needs, without
 275 distraction from baseless prejudices about proprietary versus open
 276 source software.</p>
 277
 278 </div>
 279 </body>
 280 </html>