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

Benjamin Mako Hill || Want to submit a patch?