1 <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>To Fork or Not To Fork</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article"><div class="titlepage"><div><div><h2 class="title"><a name="paper-11194"></a>To Fork or Not To Fork</h2></div><div><h3 class="subtitle"><i>Lessons From Ubuntu and Debian</i></h3></div><div><div class="author"><h3 class="author"><span class="firstname">Benjamin</span> <span class="othername">Mako</span> <span class="surname">Hill</span></h3><div class="affiliation"><span class="orgname">Canonical Limited<br></span></div><div class="affiliation"><span class="orgname">The Debian GNU/Linux Project<br></span></div><div class="affiliation"><span class="orgname">Software in the Public Interest, Inc.<br></span></div></div></div><div><p class="copyright">Copyright © 2005 Benjamin Mako Hill</p></div><div><div class="legalnotice"><a name="idp27154528"></a><p>This material is licensed under the <a class="ulink" href="http://creativecommons.org/licenses/by-sa/2.0/" target="_top">Creative
2 Commons Attribution-Sharealike 2.0 License</a>.</p><p>The canonical location for the most recent version of this
3 document is <a class="ulink" href="http://mako.cc/" target="_top">at the author's
4 website</a>.</p></div></div><div><div class="revhistory"><table style="border-style:solid; width:100%;" summary="Revision History"><tr><th align="left" valign="top" colspan="2"><b>Revision History</b></th></tr><tr><td align="left">Revision 0.2</td><td align="left">August 7, 2005</td></tr><tr><td align="left" colspan="2">Correction and improvements.</td></tr><tr><td align="left">Revision 0.1</td><td align="left">May 15, 2005</td></tr><tr><td align="left" colspan="2">
5 <p>The first version of this paper was written to an
6 accepted talk given at Linuxtag 2005 given in Karlsruhe,
8 </td></tr></table></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="#idp27161152">Introduction</a></span></dt><dt><span class="section"><a href="#idp27077936">"Fork" Is A Four Letter Word</a></span></dt><dt><span class="section"><a href="#idp27089792">Case Study</a></span></dt><dd><dl><dt><span class="section"><a href="#idp26985776">The Debian Project</a></span></dt><dt><span class="section"><a href="#idp26996864">Ubuntu</a></span></dt><dt><span class="section"><a href="#idp32030512">Applicability</a></span></dt></dl></dd><dt><span class="section"><a href="#idp26879744">Balancing Forking With Collaboration</a></span></dt><dd><dl><dt><span class="section"><a href="#idp26880432">Derivation and Problem Analysis</a></span></dt><dt><span class="section"><a href="#idp32061728">Distributed Source Control</a></span></dt><dt><span class="section"><a href="#idp32075664">Problem Specific Tools</a></span></dt><dt><span class="section"><a href="#idp32079568">Social Solutions</a></span></dt></dl></dd><dt><span class="section"><a href="#idp32092080">Conclusions</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp27161152"></a>Introduction</h2></div></div></div><p>The explosive growth of free and open source software over
9 the last decade has been mirrored by an equally explosive growth
10 in the ambitiousness of free software projects in choosing and
11 tackling problems. The free software movement approaches these
12 large problems with more code and with more expansive
13 communities than was thinkable a decade ago. Example of these
14 massive projects include desktop environments — like GNOME
15 and KDE — and distributions like Debian, RedHat, and
16 Gentoo.</p><p>These projects are leveraging the work of thousands of
17 programmers — both volunteer and paid — and are
18 producing millions of lines of code. Their software is being
19 used by millions of users with diverse sets of needs. This
20 paper focuses on two major effects of this situation:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The communities that free software projects — and
21 in particular large projects — serve are increasingly
22 diverse. It is becoming increasingly difficult for a single
23 large project to release any single product that can cater
24 to all of its potential users.</p></li><li class="listitem"><p>It's becoming increasingly difficult to reproduce these
25 large projects. While reproducing entire project is
26 impossible for small groups of hackers, it is often not even
27 possible for small groups to even track and maintain a fork
28 of a large project over time.</p></li></ul></div><p>Taken together, these facts imply an increasingly realized
29 free software community in which programmers frequently derive
30 but where traditional forking is often untenable. "Forks," as
31 they are traditionally defined, must be improved upon.
32 Communities around large free software projects must be smarter
33 about the process of derivation than they have been in the
34 past.</p><p>We are already seeing this with GNU/Linux distributions. New
35 distributions are rarely built from scratch today. Instead, they
36 adapted from and built on top of the work of existing projects.
37 As projects and user-bases grow, these derived distributions are
38 increasingly common. Most of what I describe in this essay are
39 tools and experiences of derived distributions.</p><p>Software makers must pursue the idea of an
40 <span class="emphasis"><em>ecosystem</em></span> of free software projects and
41 products that have forked but that maintain a close relationship
42 as they develop parallelly and symbiotically. To do this,
43 developers should:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>Break down the process of derivation into a set of
44 different types of customization and derivation and
45 prioritize methods of derivation.</p></li><li class="listitem"><p>Create and foster social solutions to the social aspects
46 of the derivation problem.</p></li><li class="listitem"><p>Build and use new tools specifically designed to
47 coordinate development of software in the context of an
48 ecosystem of projects.</p></li><li class="listitem"><p>Distribute and utilize distributed version control tools
49 with an emphasis on maintaining differences over
50 time.</p></li></ul></div><p>This paper is an early analysis of this set of problems. As
51 such, it is highly focused on the experience of the Ubuntu
52 project and its existence as a derived Debian distribution. It
53 also pulls from my experience with Debian-NP and the Custom
54 Debian Distribution (CDD) community. Since I participate in both
55 the Ubuntu and CDD projects, these are areas that I can discuss
56 with some degree of knowledge and experience.</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp27077936"></a>"Fork" Is A Four Letter Word</h2></div></div></div><p>The act of taking the code for a free software project and
57 bifurcating it to create a new project is called "forking."
58 There have been a number of famous forks in free software
59 history. One of the most famous was the schism that led to the
60 parallel development of two versions of the Emacs text editor:
61 GNU Emacs and XEmacs. This schism persists to this day.</p><p>Some forks, like Emacs and XEmacs, are permanent. Others are
62 relatively short lived. An example of this is the GCC project
63 which saw two forks — EGCS and PGCC — that both
64 eventually merged back into GCC. Forking can happen for any
65 number of reasons. Often developers on a project develop
66 political or personal differences that keep them from continuing
67 to work together. In some cases, maintainers become unresponsive
68 and other developers fork to keep the software alive.</p><p>Ultimately though, most forks occur because people do not
69 agree on the features, the mechanisms, or the technology at the
70 core of a project. People have different goals, different
71 problems, and want different tools. Often, these goals, problems
72 and tools are similar up until a certain point before the need
73 to part ways becomes essential.</p><p>A fork occurs on the level of code but a fork is not merely
74 — or even primarily — technical. Many projects create
75 "branches." Branches are alternative versions of a piece of
76 software used to experiment with intrusive or unstable features
77 and fixes. Forks are distinguished from branches both in
78 that they are often more significant departures from a technical
79 perspective (i.e., more lines of code have been changed and/or
80 the changes are more invasive or represent a more fundamental
81 rethinking of the problem) and in that they are bifurcations
82 defined in social and political terms. Branches involve a
83 <span class="emphasis"><em>single</em></span> developer or community of developers
84 — even if it does boil down to distinct subgroups within a
85 community — whereas forks are separate projects.</p><p>Forking has historically been viewed as a bad thing in free
86 software communities: they are seen to stem from people's
87 inability to work together and have ended in reproduction of
88 work. When I published the first version of the <a class="ulink" href="http://mako.cc/projects/howto/" target="_top">Free Software Project
89 Management HOWTO</a> more than four years ago, I included
90 a small subsection on forking which described the concept to
91 future free software project leaders with this text:</p><div class="blockquote"><blockquote class="blockquote"><p>The short version of the fork section is, don't do them.
92 Forks force developers to choose one project to work with,
93 cause nasty political divisions, and redundancy of
94 work.</p></blockquote></div><p>In the <span class="emphasis"><em>best</em></span> situations, a fork means
95 that two groups of people need to go on developing features and
96 doing work they would ordinarily do <span class="emphasis"><em>in addition
97 to</em></span> tracking the forked project and having to
98 hand-select and apply features and fixes to their own code-base.
99 This level of monitoring and constant comparison can be
100 extremely difficult and time-consuming. The situation is not
101 helped substantially by traditional source control tools like
102 diff, patch, CVS and Subversion which are not optimized for this
103 task. The worse (and much more common) situation occurs when two
104 groups go about their work ignorant or partially ignorant of the
105 code being cut on the other side of the fork. Important features
106 and fixes are implemented twice — differently and
107 incompatibly.</p><p>The most substantial bright side to these drawbacks is that
108 the problems associated with forking are so severe and notorious
109 that, in most cases, the threat of a fork is enough to force
110 maintainers to work out solutions that keep the fork from
111 happening in the first place.</p><p>Finally, it is worth pointing out that fork is something of
112 a contested term. Because definitions of forks involve, to one
113 degree or another, statements about the political, organization,
114 and technical distinctions between projects, bifurcations that
115 many people call branches or parallel trees are described by
116 others as forks. Recently, fueled by the advent of distributed
117 version control systems, the definition of what is and is not a
118 fork has become increasingly unclear. In part due to the same
119 systems, the benefits and drawbacks of what is increasingly
120 problematically called forking is equally debatable.</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp27089792"></a>Case Study</h2></div></div></div><p>In my introduction, I described how the growing scope of
121 free software projects and the rapidly increasingly size and
122 diversity of user communities is spearheading the need for new
123 type of derivation that avoids, as best as possible, the
124 drawbacks of forking. Nowhere is this more evident than in the
125 largest projects with the broadest scope: a small group of
126 projects that includes operating system distributions.</p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp26985776"></a>The Debian Project</h3></div></div></div><p>The Debian project is by many counts the largest free
127 software distribution in terms of code. It is the also,
128 arguably, the largest free software project in terms of the
129 number of volunteers. Debian includes more than 15,000
130 packages and the work of well over 1,000 official volunteers
131 and many more contributors without official membership.
132 Projects without Debian's massive volunteer base cannot
133 replicate what Debian has accomplished; they can rarely hope
134 to even maintain what Debian has produced.</p><p>At the time that this paper was written, Distrowatch lists
135 129 distributions based on Debian<a href="#ftn.idp26988128" class="footnote" name="idp26988128"><sup class="footnote">[1]</sup></a> — most of them
136 are currently active to varying degrees. Each distribution
137 represents at least one person — and in most cases a
138 community of people — who disagreed with Debian's vision
139 or direction strongly enough to want to create a new
140 distribution <span class="emphasis"><em>and</em></span> who had the technical
141 capacity to follow through with this goal. Despite Debian's
142 long-standing slogan — "the universal operating system"
144 that the Debian project has become the fastest growing
145 operating system while spawning so many derivatives is
146 testament to the fact that, as far as software is concerned,
147 one size <span class="emphasis"><em>can not</em></span> fit all.<a href="#ftn.idp26990736" class="footnote" name="idp26990736"><sup class="footnote">[2]</sup></a>
148 </p><p>Organizationally, Debian derivers are located both inside
149 and outside of the Debian project. A group of derivers working
150 within the Debian project has labeled themselves "Custom
151 Debian Distributions" and has created nearly a dozen projects
152 customizing and deriving from Debian for specific groups of
153 users including non-profit organization, the medical
154 community, lawyers, children and many others.<a href="#ftn.idp26993168" class="footnote" name="idp26993168"><sup class="footnote">[3]</sup></a> These projects build on the core Debian distribution and
155 the canonical archive from <span class="emphasis"><em>within</em></span> the
156 organizational and political limits of the Debian project and
157 constantly seek to minimize the delta by focusing on less
158 invasive changes and by advancing creative ways of building
159 the <span class="emphasis"><em>ability</em></span> to alter the core
160 Debian code base through established and policy compliant
161 procedures.</p><p>A second group of Debian customizers includes those
162 working outside of the Debian project organizationally.
163 Notable among this list are (in alphabetical order) Knoppix,
164 Libranet, Linspire (formerly Lindows), Progeny, MEPIS, Ubuntu,
165 Userlinux, and Xandros. With its strong technological base,
166 excellent package management, wide selection of packages to
167 choose from, and strong commitment to software freedom which
168 ensures derivability, Debian provides an ideal point from
169 which to create a GNU/Linux distribution.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp26996864"></a>Ubuntu</h3></div></div></div><p>The Ubuntu project was started by Mark Shuttleworth in
170 April 2004 and the first version was built almost entirely
171 by a small group of a Debian developers employed by Shuttleworth's
172 company Canonical Limited.<a href="#ftn.idp26998016" class="footnote" name="idp26998016"><sup class="footnote">[4]</sup></a> It was released to the world in late 2004.
173 The second version was released six months later in April
174 2005. The goals of Ubuntu are to provide a distribution based
175 on a subset of Debian with:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>Regular and predictable releases — every six months
176 with support for eighteen months.</p></li><li class="listitem"><p>An emphasis on free software that will maintain the
177 derivability of the distribution.</p></li><li class="listitem"><p>An emphasis on usability and a consistent desktop
178 vision. As an example, this has translated into less
179 questions in the installer and a default selection and
180 configuration of packages that is usable for most desktop
181 users "out of the box."</p></li></ul></div><p>The Ubuntu project provides an interesting example of a
182 project that aims to derive from Debian to an extensive
183 degree. Ubuntu made code-level changes to nearly 1300 packages
184 in Debian at the time that this paper was written and the
185 speed of changes will not decelerate with time; the total
186 number of changes and the total size of the delta will
187 grow.<a href="#ftn.idp27004416" class="footnote" name="idp27004416"><sup class="footnote">[5]</sup></a> The changes that Ubuntu makes are primarily of the
188 most intrusive kind — changes to the code itself.</p><p>That said, the Ubuntu project is explicit about the fact
189 that it could not exist without the work done by the Debian
190 project.<a href="#ftn.idp27006336" class="footnote" name="idp27006336"><sup class="footnote">[6]</sup></a> More importantly, Ubuntu explains that it cannot
191 continue to provide the complete set of packages that its
192 users depend on without the ongoing work by the Debian
193 project. Even though Ubuntu has made changes to the nearly
194 1300 packages, this is less than ten percent of the total
195 packages shipped in Ubuntu and pulled from Debian.</p><p>Scott James Remnant, a prominent Debian developer and a
196 hacker on Ubuntu who works for Canonical Ltd., described the
197 situation this way on his web log to introduce the Ubuntu
198 development methodology in the week after the first public
199 announcement of Canonical and Ubuntu:<a href="#ftn.idp27008624" class="footnote" name="idp27008624"><sup class="footnote">[7]</sup></a>
200 </p><div class="blockquote"><blockquote class="blockquote"><p>I don't think Ubuntu is a "fork" of Debian, at least not
201 in the traditional sense. A fork suggests that at some
202 point we go our separate way from Debian and then
203 occasionally merge in changes as we carry on down our own
204 path.</p><p>Our model is quite different; every six months we take a
205 snapshot of Debian's unstable distribution, apply any
206 outstanding patches from our last release to it and spend a
207 couple of months testing and bug-fixing it.</p><p>
208 <span class="inlinemediaobject"><img src="tfontf-picture-01.png"></span>
209 </p><p>One thing that should be obvious from this is that our
210 job is a lot easier if Debian takes all of our changes. The
211 model actually encourages us to give back to
212 Debian.</p><p>That's why from the very first day we started fixing
213 bugs we began sending <a class="ulink" href="http://www.no-name-yet.com/patches/" target="_top">the
214 patches</a> back to Debian through the BTS. Not only
215 will it make our job so much easier when we come to freeze
216 for "hoary", our next release, but it's exactly what every
217 derivative should do in the first place.</p></blockquote></div><p>There is some debate on the degree to which Ubuntu
218 developers have succeeded in accomplishing the goals laid out
219 by Remnant. Ubuntu has filed hundreds of patches in the bug
220 tracking system but it has also run into problems in deciding
221 <span class="emphasis"><em>what</em></span> constitutes something that should be
222 fed back to Debian. Many changes are simply not relevant to
223 Debian developers. For example, they may include changes to a
224 package in response to another change made in another package
225 in Ubuntu that will not or has not been taken by Debian. In
226 many other cases, the best action in regards to a particular
227 change, a particular package, and a particular upstream Debian
228 developer is simply unclear.</p><p>The Ubuntu project's track record in working
229 constructively with Debian is, at the moment, a mixed one.
230 While an increasingly large number of Debian developers are
231 maintaining their packages actively within both projects, many
232 in both Debian and Ubuntu feel that Ubuntu has work left to do
233 in living up to its own goal of a completely smooth productive
234 relationship with Debian.</p><p>That said, the importance of the goals described by
235 Remnant in the context of of the Ubuntu development model
236 cannot be overstated. Every line of delta between Debian and
237 Ubuntu has a cost for Ubuntu developers. Technology, social
238 practices, and wise choices may reduce that cost but it cannot
239 eliminate it. The resources that Ubuntu can bring to bear upon
240 the problem of building a distribution are limited — far
241 more limited than Debian's. As a result, there is a limit to
242 how far Ubuntu can diverge; it is always in Ubuntu's advantage
243 to minimize the delta where possible.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp32030512"></a>Applicability</h3></div></div></div><p>Ubuntu and Debian are distributions and — as such
244 — operate on a different scale than the vast majority of
245 free software projects. They include more code and more
246 people. As a result, there are questions as to whether the
247 experiences and lessons learned from these projects are
248 particularly applicable to the experience of smaller free
249 software projects.</p><p>Clearly, because of the difficulties associated with
250 forking massive amount of code and the problems associated
251 with duplicating the work of large volunteer bases,
252 distributions are forced into finding a way to balance the
253 benefits and drawbacks of forking. However, while the need is
254 stronger and more immediate in larger projects, the benefits
255 of their solutions will often be fully transferable.</p><p>Clearly, modifiability of free software to better fit the
256 needs of its users lies at the heart of the free software
257 movement's success. However, while modification usually comes
258 in the form of collaboration on a single code-base, this is
259 a function of limitations in software development methodologies
260 and tools rather than the best response to the needs or
261 desires of users or developers.</p><p>I believe that the fundamental advantage of free software
262 in the next decade will be in the growing ability of any
263 single free software project to be multiple things to multiple
264 users simultaneously. This will translate into the fact that,
265 in the next ten years, technology and social processes will
266 evolve, so that forking is increasingly less of a bad thing.
267 Free software development methodology will become less
268 dependent on a single project and begin to emphasize parallel
269 development within an ecosystem of related projects. The
270 result is that free software projects will gain a competitive
271 advantage over propriety software projects through their
272 ability to better serve the increasingly diverse needs of
273 increasingly large and increasingly diverse user-bases.
274 Although it sounds paradoxical today, more projects will
275 derive and less redundant code will be written.</p><p>Projects more limited in code and scope may use the tools
276 and methods described in the remainder of this paper in
277 different combinations, in different ways, and to different
278 degrees than the examples around distributions introduced
279 here. Different projects with different needs will find that
280 certain solutions work better than others. Because communities
281 of the size of Debian are difficult to fork in a way that is
282 beneficial to any party, it is in these communities that the
283 technology and development methodologies are first
284 emerging. With time, these strategies and tools will find
285 themselves employed productively in a wide variety of projects
286 with a broad spectrum of sizes, needs, scopes and
287 descriptions.</p></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp26879744"></a>Balancing Forking With Collaboration</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp26880432"></a>Derivation and Problem Analysis</h3></div></div></div><p>The easiest step in creating a productive derivative
288 software project is to break down the problems of derivations
289 into a series of different classes of modification. Certain
290 types of modification are more easily done and are
291 intrinsically more maintainable.</p><p>In the context of distributions, the problem of derivation
292 can be broken down into the following types of changes (sorted
293 roughly according to the intrusiveness inherent in solving the
294 problem and the severity of the long-term maintainability
295 problems that they introduce):</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Selection of individual pieces of software;</p></li><li class="listitem"><p>Changes to the way that packages are installed or run
296 (e.g., in a Live CD type environment or using a different
297 installer);</p></li><li class="listitem"><p>Configuration of different pieces of software;</p></li><li class="listitem"><p>Changes made to the actual software package (made on
298 the level of changes to the packages code);</p></li></ol></div><p>By breaking down the problem in this way, Debian derivers
299 have been able to approach derivation in ways that focus
300 energy on the less intrusive problems first.</p><p>The first area that Ubuntu focused on was selecting a
301 subset of packages that Ubuntu would support. Ubuntu selected
302 and supports approximate 2,000 packages. These became the
303 <span class="command"><strong>main</strong></span> component in Ubuntu. Other packages in
304 Debian were included in a separate section of the Ubuntu
305 archive called <span class="command"><strong>universe</strong></span> but were not
306 guaranteed to be supported with bug or security fixes. By
307 focusing on a small subset of packages, the Ubuntu team was
308 able to select a maintainable subsection of the Debian archive
309 that they could maintain over time.</p><p>The most simple derived distributions — often
310 working within the Debian project as CDDs but also including
311 projects like Userlinux — are merely lists of packages
312 and do nothing outside of package selection. The installation
313 of lists of packages and the maintenance of those lists over
314 time can be aided through the creation of what are called
315 <span class="emphasis"><em>metapackages</em></span>: empty packages with long
316 lists of "dependencies."</p><p>The second item, configuration changes, is also
317 relatively low-impact. Focusing on moving as many changes as
318 possible into the realm of configuration changes is a
319 sustainable strategy that derivers working within the Debian
320 project intent on a single code-base have pursued actively.
321 Their idea is that rather than forking a piece of code due to
322 disagreement in how the program should work, they can leave
323 the code intact but add the <span class="emphasis"><em>ability</em></span> to
324 work in a different way to the software. This alternate
325 functionality is made toggleable through a configuration
326 change in the same manner that applications are configured
327 through questions asked at install time. Since the Debian
328 project has a unified package configuration framework called
329 Debconf, derivers are able to configure an entire system in a
330 highly centralized manner.<a href="#ftn.idp32057520" class="footnote" name="idp32057520"><sup class="footnote">[8]</sup></a> This is not unlike RedHat's Kickstart although the
331 emphasis is on maintenance of those configuration changes over
332 the life and evolution of the package; Kickstart is focused
333 merely on installation of the package.</p><p>A third type of configuration is limited to changes in the
334 environment through which a system is run or installed. One is
335 example is Progeny's Anaconda-based Debian installer which
336 provides an alternate installer but results in an identical
337 system. Another example is the Knoppix project which is famous
338 for its "Live CD" environments. While, Knoppix makes a wide
339 range of invasive changes that span all items in my list
340 above, other Live CD projects, including Ubuntu's "Casper"
341 project, are much closer to an alternate shell through which
342 the same code is run.</p><p>Because these three methods are relatively non-invasive,
343 they are reasonable strategies for small teams and individuals
344 working on creating a derived distribution. However, many
345 desirable changes — and in the case of some derived
346 distributions, <span class="emphasis"><em>most</em></span> desirable changes
347 — require more invasive techniques. The final and most
348 invasive type of change — changes to code — is the
349 most difficult but also the most promising and powerful if it
350 can be done sustainably. Changes of this type involve
351 bifurcations of the code-base and will be the topic of the
352 remainder of this paper.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp32061728"></a>Distributed Source Control</h3></div></div></div><p>One promising method of maintaining deltas in forked or
353 branched projects lies in distributed version control systems
354 (VCS). Traditional VCS systems work in a highly centralized
355 fashion. CVS, the archetypal free software VCS and the basis
356 for many others, is based around the model of a single
357 centralized server. Anyone who wishes to commit to a project
358 must commit to the centralized repository. While CVS allows
359 users to create branches, anyone with commit rights has access
360 to the entire repository. The tools for branching and merging
361 over time are not particularly good.</p><p>The branching model is primarily geared toward a system
362 where development is bifurcated and then the branch is merged
363 completely back into the main tree. Normal use of a branch
364 might include creating a development branch, making a series
365 of development releases while maintaining and fixing important
366 bugs in the stable primary branch, and then ultimately
367 replacing the stable release with the development release. The
368 CVS model is <span class="emphasis"><em>not</em></span> geared toward a system
369 where an arbitrary delta, or sets of deltas, are maintained
370 over time.</p><p>Distributed version control aims to solve a number of
371 problems introduced by CVS and alluded to above by:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>Allowing people to work disconnected from each other
372 and to sync with each other, in whole or in part, in an
373 arbitrary and ad-hoc fashion.</p></li><li class="listitem"><p>Allowing deltas to be maintained over time.</p></li></ul></div><p>Ultimately, this requires tools that are better at merging
374 changes and in <span class="emphasis"><em>not</em></span> merging certain
375 changes when that is the desired behavior. It also leads to tools capable
376 of history-sensitive merging.</p><p>The most famous switch to a distributed VCS model from a
377 centralized VCS model was the move by the Linux kernel
378 development community to the proprietary distributed version
379 control system BitKeeper. In his recent announcement of the
380 decision to part ways with BitKeeper, Linus Torvalds
381 said:</p><div class="blockquote"><blockquote class="blockquote"><p>In fact, one impact BK has had is to very fundamentally
382 make us (and me in particular) change how we do things. That
383 ranges from the fine-grained changeset tracking to just how
384 I ended up trusting sub-maintainers with much bigger things,
385 and not having to work on a patch-by-patch basis any
386 more.<a href="#ftn.idp32069728" class="footnote" name="idp32069728"><sup class="footnote">[9]</sup></a>
387 </p></blockquote></div><p>At the time of the switch, free distributed version
388 control tools were less advanced than they are today. At the
389 moment, an incomplete list of free software VCS tools includes
390 GNU Arch, Bazaar, Bazaar-NG, Darcs, Monotone, SVK (based on
391 Subversion), GIT (a system developed by Linus Torvalds as a
392 replacement for BitKeeper) and others.</p><p>Each of these tools, at least after they reach a certain
393 level of maturity, allow or will allow users to develop
394 software in a distributed fashion and to, over time, compare
395 their software and pull changes from others significantly more
396 easily than they could otherwise. The idea of parallel
397 development lies at the heart of the model. The tools for
398 merging and resolving conflicts over time, and the ability to
399 "cherry pick" certain patches or changes from a parallel
400 developer each make this type of development significantly
401 more useful than it has been in the past.</p><p>VCSs work entirely on the level of code. Due to the nature
402 of the types of changes that Ubuntu project is making to
403 Debian's code, Ubuntu has focused primarily on this model and
404 Canonical currently funds two major distributed control
405 products — the Bazaar and Bazaar-NG projects.</p><p>In many ways, employing distributed version control
406 effectively is a much easier problem to solve for small, more
407 traditional, free software development projects than it is for
408 GNU/Linux distributions. Because the problems associated with
409 maintaining parallel development of a single piece of software
410 in a set of related distributed repositories is the primary
411 use case for distributed version control systems, distributed
412 VCS alone can be a technical solution for certain types of
413 parallel development. As the tools and social processes for
414 distributed VCS evolve, they will become increasingly
415 important tools in the way that free software is
416 developed.</p><p>Because the problems of scale associated with building an
417 entire derivative distribution are more complicated than those
418 associated with working with a single "upstream" project,
419 distributed version control is only now being actively
420 deployed in the Ubuntu project. In doing so, the project is
421 focusing on integrating these into problem specific tools
422 built on top of distributed version control.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp32075664"></a>Problem Specific Tools</h3></div></div></div><p>Another technique that Canonical Ltd. is experimenting
423 with is the creation of high level tools built on top of
424 distributed version control tools specifically designed for
425 maintaining difference between packages. Because packages are
426 usually distributed as a source file with a collection of one
427 or more patches, this introduces the unique possibility of
428 creating a high-level VCS system based around this fact.</p><p>In the case of Ubuntu and Debian, the ideal tool creates
429 one branch per patch or feature and uses heuristics to
430 analyze patch files and create these branches
431 intelligently. The package build system section of the total
432 patch can also be kept as a separate branch. Canonical's tool,
433 called the Hypothetical Changeset Tool (HCT) (although no
434 longer hypothetical), is one experimental way of creating a
435 very simple, very streamlined interface for dealing with a
436 particular type of source that is created and distributed in a
437 particular type of way with a particular type of
438 change.</p><p>While HCT promises to be very useful for people making
439 derived distributions based on Debian, its application outside
440 distribution makers will, in all likelihood, be limited. That
441 said, it provides an example of the way that problem and
442 context specific tools may play an essential role in the
443 maintenance of derived code more generally.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idp32079568"></a>Social Solutions</h3></div></div></div><p>It has been said that it is a common folly of a
444 technophile to attempt to employ technical solutions toward
445 solving social problems. The problem of deriving software is
446 both a technical <span class="emphasis"><em>and</em></span> social problem and
447 adequately addressing the larger problems requires approaches that
448 take into consideration both types of solution.</p><p>Scott James Remnant compares the relationship between
449 distributions and derived distributions as similar to the
450 relationship between distributions and upstream
451 maintainers:</p><div class="blockquote"><blockquote class="blockquote"><p>I don't think this is much different from how Debian
452 maintainers interact with their upstreams. As Debian
453 maintainers we take and package upstream software and then
454 act as a gateway for bugs and problems. Quite often we fix
455 bugs ourselves and apply the patch to the package and send
456 it upstream. Sometimes the upstream don't incorporate that
457 patch and we have to make sure we don't accidentally drop it
458 each subsequent release, we much prefer it if they take
459 them, but we don't get angry if they don't.</p><p>This is how I see the relationship between Ubuntu and
460 Debian, we're no more a fork of Debian than a Debian package
461 is a fork of its upstream.</p></blockquote></div><p>Scott alludes the fact that, at least in the world of
462 distributions, parallel development is already one way to view
463 the <span class="emphasis"><em>modus operandi</em></span> of existing GNU/Linux
464 distributions. The relationship between a deriver and derivee
465 on the distribution level mirrors the relationship between the
466 distribution and the "upstream" authors of the packages that
467 make up the distribution. These relationships are rarely based
468 around technological tools but are entirely in the realm of
469 social solutions.</p><p>Ubuntu has pursued a number of different initiatives along
470 these lines. The first of these has been to regularly file
471 bugs in the Debian bug tracking system when bugs that exist in
472 Debian are fixed in Ubuntu. While this can be partially
473 automated, the choice to automate this and the manner in which
474 it it is set up is a purely social one.</p><p>However, as I alluded to above, Ubuntu is still left with
475 questions in regards to changes that are made to packages that
476 do not necessarily fix bugs or that fix bugs that do not exist
477 in Debian but may in the future. Some Debian developers want
478 to hear about the full extent of changes made to their
479 software in Ubuntu while others do not want to be
480 bothered. Ubuntu should continue to work with Debian to find
481 ways to allow developers to stay in sync.</p><p>There are also several initiatives by developers in
482 Debian, Ubuntu, and in other derivations to create a
483 stronger relationship between the Debian project and its
484 ecosystem of derivers and between Ubuntu and Debian in
485 particular. While the form that this will ultimately take is
486 unclear, projects existing within an ecosystem should explore
487 the realm of appropriate social relationships that will ensure
488 that they can work together and be informed of each others'
489 work without resorting to "spamming" each other with
490 irrelevant or unnecessary information.</p><p>Another issue that has recently played an important role
491 in the Debian/Ubuntu relationship is the importance of both
492 giving adequate credit to the authors or upstream maintainers
493 of software without implying a closer relationship than is the
494 case. Derivers must walk a file line where they credit others'
495 work on a project without implying that the others work for,
496 support, or are connected to the derivers project to which, for
497 any number of reasons, the "upstream" author might not want to
498 be associated.</p><p>In the case of Debian and Ubuntu, this has resulted in an
499 emphasis on keeping or importing changelog entries when
500 changes are imported and in noting the pedigree of changes
501 more generally. It has recently also been discussed in terms
502 of the "maintainer" field in each package in Ubuntu. Ubuntu
503 wants to avoid making changes to every unmodified source
504 package (and introducing an unnecessary delta) but does not
505 want to give the impression that the maintainer of the package
506 is someone unassociated with Ubuntu. While no solution has
507 been decided at the time of writing, one idea involved marking
508 the maintainer of the package explicitly as a Debian
509 maintainer at the time that the binary packages are built on
510 the Ubuntu build machines.</p><p>The emphasis on social solutions is also essential when
511 using distributed VCS technology. As Linus Torvalds alluded to
512 in the quote above, the importance of technological changes to
513 distributed VCS technology is only felt when people begin to
514 work in a different way — when they begin to employ
515 different social models of developer interaction.</p><p>While Ubuntu's experience can provide a good model for
516 tackling some of these source control issues, it can only
517 serve as a model and not as a fixed answer. Social solutions
518 must be appropriate for a given social relationship. Even in
519 situations where a package is branched because of social
520 disagreements, a certain level of collaboration on a social
521 level will be essential to the long term viability of the
522 derivative.</p></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idp32092080"></a>Conclusions</h2></div></div></div><p>As the techniques described in this paper evolve, the role
523 that they play in free software development becomes increasingly
524 prominent and increasingly important. Joining them will be other
525 techniques and models that I have not described and cannot
526 predict. Because of the size and usefulness of their code and
527 the size of their development communities, large projects like
528 Debian and Ubuntu have been forced into confronting and
529 attempting to mediate the problems inherent in forking and
530 deriving. However, as these problems are negotiated and tools
531 and processes are advanced toward solutions, free software
532 projects of all sizes will be able to offer users exactly what
533 they want with minimal redundancy and little duplication of
534 work. In doing this, free software will harness a power that
535 proprietary models cannot compete with. They will increase their
536 capacity to produce better products and better processes.
537 Ultimately, it will help free software capture more users, bring
538 in more developers, and produce more free software of a higher
539 quality.</p></div><div class="footnotes"><br><hr style="width:100; text-align:left;margin-left: 0"><div id="ftn.idp26988128" class="footnote"><p><a href="#idp26988128" class="para"><sup class="para">[1] </sup></a>Information is listed on the distrowatch homepage
540 here: <a class="ulink" href="http://distrowatch.com/dwres.php?resource=independence" target="_top">http://distrowatch.com/dwres.php?resource=independence</a></p></div><div id="ftn.idp26990736" class="footnote"><p><a href="#idp26990736" class="para"><sup class="para">[2] </sup></a>Netcraft posts yearly updates on the speed at which
541 Linux distributions are growing. The one in question can be
542 found at: <a class="ulink" href="http://news.netcraft.com/archives/2004/01/28/debian_fastest_growing_linux_distribution.html" target="_top">http://news.netcraft.com/archives/2004/01/28/debian_fastest_growing_linux_distribution.html</a></p></div><div id="ftn.idp26993168" class="footnote"><p><a href="#idp26993168" class="para"><sup class="para">[3] </sup></a>I spearheaded and help build a now mostly defunct
543 derivation of Debian called Debian-Nonprofit (Debian-NP)
544 geared for non-profit organizations by working within the
545 Debian project.</p></div><div id="ftn.idp26998016" class="footnote"><p><a href="#idp26998016" class="para"><sup class="para">[4] </sup></a>Information Ubuntu can be found on the <a class="ulink" href="http://www.ubuntu.com" target="_top">Ubuntu homepage.</a>
546 Information Canonical Limited can be found at <a class="ulink" href="http://www.canonical.com" target="_top">Canonical's
547 homepage</a>.</p></div><div id="ftn.idp27004416" class="footnote"><p><a href="#idp27004416" class="para"><sup class="para">[5] </sup></a>Scott James Remnant maintains a list of these patches
548 online here: <a class="ulink" href="http://people.ubuntu.com/~scott/patches/" target="_top">http://people.ubuntu.com/~scott/patches/</a></p></div><div id="ftn.idp27006336" class="footnote"><p><a href="#idp27006336" class="para"><sup class="para">[6] </sup></a>You can see that explicit statement on Ubuntu's
549 website here: <a class="ulink" href="http://www.ubuntulinux.org/ubuntu/relationship/" target="_top">http://www.ubuntulinux.org/ubuntu/relationship/</a></p></div><div id="ftn.idp27008624" class="footnote"><p><a href="#idp27008624" class="para"><sup class="para">[7] </sup></a>The
550 entire post can be read here: <a class="ulink" href="http://www.netsplit.com/blog/work/canonical/ubuntu_and_debian.html" target="_top">http://www.netsplit.com/blog/work/canonical/ubuntu_and_debian.html</a></p></div><div id="ftn.idp32057520" class="footnote"><p><a href="#idp32057520" class="para"><sup class="para">[8] </sup></a>More information on
552 found online at: <a class="ulink" href="http://www.kitenet.net/programs/debconf/" target="_top">http://www.kitenet.net/programs/debconf/</a></p></div><div id="ftn.idp32069728" class="footnote"><p><a href="#idp32069728" class="para"><sup class="para">[9] </sup></a>The full message can be read online
553 at: <a class="ulink" href="http://kerneltrap.org/mailarchive/1/message/48393/thread" target="_top">http://kerneltrap.org/mailarchive/1/message/48393/thread</a></p></div></div></div></body></html>
projects / to_fork_or_not / blob