To Fork or Not To Fork
Lessons From Ubuntu and Debian
Benjamin
Mako
Hill
Canonical Limited
The Debian GNU/Linux Project
Software in the Public Interest, Inc.
Benjamin Mako Hill is an intellectual property
researcher and activist and a professional Free/Open Source
Software (FOSS) advocate and developer. He is active
participant in the Debian Project in both technical and
non-technical roles. He is the author of the Free Software
Project Management HOWTO and many published works on Free
and Open Source Software. He currently is working full time
for Canonical Ltd. on Ubuntu, a new Debian-based
distribution.
2005
Benjamin Mako Hill
Introduction
The explosive growth of free and open source software over
the last decade has been mirrored by an equally explosive growth
in the ambitiousness of free software projects in choosing and
tackling problems. The free software movement approaches these
large problems with more code and with more expansive
communities than was even thinkable a decade ago. Example of
these massive projects include desktop environments — like
GNOME and KDE — and distributions like Debian.
These projects are leveraging the work of thousands of
programmers — both volunteer and paid — and are
producing millions of lines of code. Their software is being
used by millions of users with a diverse set of needs. This
paper focuses on two major effects of this situation:
The communities that free software projects — and
in particular large projects — serve are increasingly
diverse. It is becoming increasingly difficult for a single
large project to release any single product that can cater
to all of its potential users.
It's becoming increasingly difficult to reproduce these
large projects. While reproducing entire project is
impossible for small groups of hackers, it is often not
substantially easier for small groups to even track and
maintain a fork of a large project over time.
Taken together, these facts imply an increasingly realized
free software community in which programmers frequently derive
but where traditional forking is often untenable. "Forks," as
they are traditionally defined, must be improved upon.
Communities around large free software projects must be smarter
about the process of derivation than they have been in the
past.
We are already seeing this with GNU/Linux distributions. New
distributions are rarely built from scratch today. Instead, they
adapted from and built on top of the work of existing projects.
As projects and user-bases grow, these derived distributions are
increasingly common. Most of what I describe in this essay are
tools and experiences of derived distributions.
Software makers must pursue the idea of an
ecosystem of free software projects and
products that have forked but that maintain a close relationship
as they develop parallelly and symbiotically. To do this,
developers should:
Break down the process of derivation into a set of
different types of customization and derivation and
prioritize methods of derivation.
Create and foster social solutions to the social aspects
of the derivation problem.
Build and use new tools specifically designed to
coordinate development of software in the context of an
ecosystem of projects.
Distribute and utilize distributed version control tools
with an emphasis on maintaining differences over
time.
This paper is an early analysis of this set of problems. As
such, it is highly focused on the experience of the Ubuntu
project and it's existence as a derived Debian distribution. It
also pulls from my experience with Debian-NP and the Custom
Debian Distribution (CDD) community. Since I participate in both
the Ubuntu and CDD projects, these are areas that I can discuss
with some degree of knowledge and experience.
"Fork" Is A Four Letter Word
The act of taking the code for a free software project and
bifurcating it to create a new project is called "forking."
There have been a number of famous forks in free software
history. One of the most famous was the schism that led to the
parallel development of two versions of the Emacs text editor:
GNU Emacs and XEmacs. This schism persists to this day.
Some forks, like Emacs and XEmacs, are permanent. Others are
relatively short lived. An example of this is the GCC project
which saw two forks — EGCS and PGCC — that both eventually
merged back into GCC. Forking can happen for any number of
reasons. Often developers on a project develop political or
personal differences that keep them from continuing to work
together. In some cases, maintainers become unresponsive and
other developers on the project fork the project to keep the
project alive.
Ultimately though, most forks occur because people do not
agree on the features, the mechanisms, or the technology at the
core of a project. People have different goals, different
problems, and want different tools. Often, these goals, problems
and tools are similar up until a certain point before the need
to part ways becomes essential.
A fork occurs on the level of code but a fork is not merely
— or even primarily — technical. Many projects create
"branches." Branches are alternative version of a piece of
software used to experiment with intrusive or unstable features
and fixes. Forks are distinguished from branches both in
that they are often more significant departures from a technical
perspective (i.e., more lines of code have been changed and/or
the changes are more invasive or represent a more fundamental
rethinking of the problem) and in that they are bifurcations
defined in social and political terms. Branches involve a
single developer or community of developers
— even if it does boil down to distinct subgroups within a
community — whereas forks are separate projects.
Forking has historically been viewed as a bad thing in free
software communities: they are seen to stem from people's
inability to work together and have ended in reproduction of
work. When I published the first version of the Free Software Project
Management HOWTO more than four years ago, I included
a small subsection on forking which described forking to
prospective free software project leaders with this text:
The short version of the fork section is, don't do them.
Forks force developers to choose one project to work with,
cause nasty political divisions, and redundancy of
work.
In the best situations, a fork means
that two groups of people need to go on developing features and
doing work they would ordinarily do in addition
to tracking the forked project and having to
hand-select and apply features and fixes to their own code-base.
This level of monitoring and constant comparison can be
extremely difficult and time-consuming. The situation is not
helped substantially by traditional source control tools like
diff, patch, CVS and Subversion which are not optimized for this
task. The worse (and much more common) situation occurs when two
groups go about their work ignorant or partially ignorant of the
work done on the other side of the fork. Important features and
fixes are implemented twice — differently and
incompatibly.
The most substantial bright side to these drawbacks is that
the problems associated with forking are so severe and notorious
that, in most cases, the threat of a fork is enough to force
maintainers to work out solutions that keep the fork from
happening in the first place.
Finally, it is worth pointing out that fork is something of
a contested term. Because definitions of forks involve, to one
degree or another, statements about the political, organization,
and technical distinctions between projects, bifurcations that
many people call branches or parallel trees are described as
others as forks. Recently, fueled by the advent of distributed
version control systems, the definition of what is and is not a
fork has become increasingly unclear. In part due to the same
systems, the benefits and drawbacks of what is increasingly
problematically called forking is equally debatable.
Case Study
In my introduction, I described how the growing scope of
free software projects and the rapidly increasingly size and
diversity of project's user communities is spearheading the need
for new type of derivation that avoids, as best as possible, the
drawbacks of forking. Nowhere is this more evident than in the
largest projects with the broadest scope: a small group of
projects that includes operating system distributions.
The Debian Project
The Debian project is my counts the largest, in terms of both code
and volunteers, free software distribution. It is the also,
arguably, the largest free software project in terms of the
number of volunteers. Debian includes more than 15,000
packages and the work of well over 1,000 official volunteers
and many more contributors without official membership.
Projects without Debian's massive volunteer base cannot
replicate what Debian has accomplished; they can rarely hope
to even maintain what Debian currently has.
At the time that this paper was written, Distrowatch lists
129 distributions based on Debian
Information is listed on the distrowatch homepage
here: http://distrowatch.com/dwres.php?resource=independence
— most of them currently active to varying
degrees. Each distribution represents at least one person —
and in most cases a community of people — who disagreed with
Debian's vision or direction strongly enough to want to create
a new distribution and who had the
technical capacity to follow through with this goal. Despite
Debian's long-standing slogan — "the universal operating
system" — the fact that the Debian project has become the
fastest growing operating system while spawning so many
derivatives is testament to the fact that, as far as software
is concerned, one size can not fit
all.
Netcraft posts yearly updates on the speed at which
Linux distributions are growing. The one in question can
be found at: http://news.netcraft.com/archives/2004/01/28/debian_fastest_growing_linux_distribution.html
Organizationally, Debian derivers are located both inside
and outside of the Debian project. A group of derivers working
within the Debian project has labeled themselves "Custom
Debian Distributions" and has created nearly a dozen projects
customizing and deriving from Debian for specific groups of
users including non-profit organization, the medical
community, lawyers, children and many others.
I spearheaded and help build a now mostly defuct
derivation of Debian called Debian-Nonprofit (Debian-NP)
geared for non-profit organizations by working within the
Debian project.
These projects build on the core Debian distribution and
the canonical archive from within the
organizational and political limits of the Debian project and
constantly seek to minimize the delta by focusing on less
invasive changes and by advancing creative ways of building
the ability to make changes in the core
Debian code base through established and policy compliant
procedures.
A second group of Debian customizers includes those
working outside of the Debian project organizationally.
Notable among this list are (in alphabetical order) Knoppix,
Libranet, Linspire (formerly Lindows), Progeny, MEPIS, Ubuntu,
Userlinux, and Xandros. With its strong technological base,
excellent package management, wide selection of packages to
choose from, and strong commitment to software freedom which
ensures derivability, Debian provides an ideal point from
which to create a GNU/Linux distribution.
Ubuntu
The Ubuntu project was started by Mark Shuttleworth in
April 2004 and the first version was built almost entirely
by a small group of a Debian developers employed by Shuttleworth's
company Canonical Limited.
Information Ubuntu can be found on the Ubuntu homepage.
Information Canonical Limited can be found at Canonical's
homepage.
It was released to the world in the fall of 2004.
The second version was released six months later in April
2005. The goals of Ubuntu are to provide a distribution based
on a subset of Debian with:
Regular and predictable releases — every six months
with support for eighteen months.
An emphasis on free software that will maintain the
derivability of the distribution.
An emphasis on usability and a consistent desktop
vision. As an example, this has translated into less
questions in the installer and a default selection and
configuration of packages that is usable for most desktop
users "out of the box."
The Ubuntu project provides an interesting example of a
project that aims to derive from Debian to an extensive
degree. Ubuntu made code-level changes to nearly 1300 packages
in Debian at the time that this paper was written and the
speed of changes will not decelerate with time; the total
number of changes and the total size of the delta will
grow.
Scott James Remnant maintains a list of these patches
online here: http://people.ubuntu.com/~scott/patches/
The changes that Ubuntu makes are primarily of the
most intrusive kind — changes to the code itself.
That said, the Ubuntu project is explicit about the fact
that it could not exist with the work done by the Debian
project before Ubuntu was created.
You can see that explicit statement on Ubuntu's
website here: http://www.ubuntulinux.org/ubuntu/relationship/
More importantly, Ubutnu explains that it cannot
continue to provide the complete set of packages that its
users depend on without the ongoing work by the Debian
project. Even though Ubuntu has made changes to the nearly
1300 packages, this is less than ten percent of the total
packages shipped in Ubuntu and pulled from Debian.
Scott James Remnant, a prominent Debian developer and a
hacker on Ubuntu who works for Canonical Ltd., described the
situation this way on his web log to introduce the Ubuntu
development methodology in the week after first public
announcement of Canonical and Ubuntu:
The entire post can be read here: http://www.netsplit.com/blog/work/canonical/ubuntu_and_debian.html
I don't think Ubuntu is a "fork" of Debian, at least not
in the traditional sense. A fork suggests that at some
point we go our separate way from Debian and then
occasionally merge in changes as we carry on down our own
path.
Our model is quite different; every six months we take a
snapshot of Debian's unstable distribution, apply any
outstanding patches from our last release to it and spend a
couple of months testing and bug-fixing it.
One thing that should be obvious from this is our job is
a lot easier if Debian take all of our changes, the model
actually encourages us to give back to Debian.
That's why from the very first day we started fixing
bugs we began sending the
patches back to Debian through the BTS. Not only
will it make our job so much easier when we come to freeze
for "hoary", our next release, but it's exactly what every
derivative should do in the first place.
There is some debate on the degree to which Ubuntu
developers have succeeded in accomplishing the goals laid out
by Remnant. Ubuntu has filed hundreds of patches in the bug
tracking system but it has also run into problems in deciding
what constitutes something that should be
fed back to Debian. Many changes are simply not relevant to
Debian developers. For example, they may include changes to a
package in response to another change made in another package
in Ubuntu that will not or has not been taken by Debian. In
many other cases, the best action in regards to a particular
change, a particular package, and a particular upstream Debian
developer is simply unclear.
The Ubuntu project's track record in working
constructively with Debian is, at the moment, a mixed one.
While an increasingly large number of Debian developers are
maintaining their packages actively within both projects, many
in both Debian and Ubuntu feel that Ubuntu has work left to do
in living up to its own goal of a completely smooth productive
relationship with Debian.
That said, the importance of the goals described by
Remnant in the context of of the Ubuntu development model
cannot be overstated. Ever line of delta between Debian and
Ubuntu has a cost for Ubuntu developers. Technology, social
practices, and wise choices may reduce the cost but it cannot
eliminate it. The resources that Ubuntu can bring to bear upon
the problem of building a distribution are limited — far
more limited than Debian's. As a result, there is a limit to
how far Ubuntu can diverge; it is always in Ubuntu's advantage
to minimize the delta where possible.
Applicability
Ubuntu and Debian are distributions and — as such —
operate on a different scale than the vast majority of free
software projects. Using a very simple metric, they include
more code and more people. As a result, there are questions as
to whether the experiences and lessons learned from these
projects are particularly applicable to the experience of
smaller free software projects.
Clearly, because of the difficulties associated with
forking massive amount of code and the problems associated
with duplicating the work of large volunteer bases,
distributions are forced into finding a way to balance the
benefits and drawbacks of forking. However, while the need is
stronger and more immediate in larger projects, the benefits
of their solutions will often be fully transferable.
Clearly, modifiability of free software to better fit the
needs of its users lies at the heart of the free software
movement's success. However, while modification usually comes
in the form of collaboration on a single code-base, this is
function of limitations in software development methodologies
and tools rather than the best response to the needs or
desires of users or developers.
I believe that the fundamental advantage of free software
in the next decade will be in the growing ability of any
single free software project to be multiple things to multiple
users simultaneously. This will translate into the fact that,
in the next ten years, technology and social processes will
evolve so that forking is increasingly less of a bad thing.
Free software development methodology will become less
dependent on a single project and begin to emphasize parallel
development within an ecosystem of software development
working on related projects. The result is that free software
projects will gain a competitive advantage over propriety
software projects through their ability to better serve the
increasingly diverse needs of increasingly large and
increasingly diverse user-bases. Although it sounds
paradoxical today, more projects will derive and less
redundant code will be written.
Projects more limited in code and scope may use the tools
and methods described in the remainder of this paper in
different combinations, in different ways, and to different
degrees than the examples around distributions introduced
here. Different projects with different needs will find that
certain solutions work better than others. Because communities
of the size of Debian are difficult to fork in a way that is
beneficial to any party, it is in these communities that the
technology and development methodologies are first
emerging. With time, these strategies and tools will find
themselves employed productively in a wide variety of projects
with a broad spectrum of sizes, needs, scopes and
descriptions.
Balancing Forking With Collaboration
Derivation and Problem Analysis
The easiest step in creating a productive derivative
software project is to break down the problems of deriviations
into a series of different classes of modification. Certain
types of modification are more easily done and are
intrinsically more maintainable.
In the context of distributions, the problem of derivation
can be broken down into the following types of changes (sorted
roughly according to the intrusiveness inherent in solving the
problem and the severity of the long-term maintainability
problems that they introduce):
Selection of individual pieces of software;
Changes to the way that packages are installed or run
(e.g., in a Live CD type environment or using a different
installer);
Configuration of different pieces of software;
Changes made to the actual software package (made on
the level of changes to the packages code);
By breaking down the problem in this way. Debian derivers
have been able to approach deriviation in ways that focus
energy on the less intrusive problems first.
The first area that Ubuntu focused on was selecting a
subset of packages that Ubuntu would support. Ubuntu selected
and supports approximate 2,000 packages. These became the
main component in Ubuntu. Other packages in
Debian were included in a separate section of the Ubuntu
archive called universe but were not
guaranteed to be supported with bug or security fixes. By
focusing on a small subset of packages, the Ubuntu team was
able to select a maintainable subsection of the Debian archive
that they could maintain over time.
The most simple derived distributions — often
working within the Debian project as CDDs but also including
projects like Userlinux — are merely lists of packages
and do nothing outside of package selection. The installation
of lists of packages and the maintenance of those lists over
time can be aided through the creation of what are called
metapackages: empty packages with long
lists of "dependencies" that are maintained over time.
The second item, configuration changes, are also
relatively low-impact. Focusing on moving as many changes as
possible into the realm of configuration changes is a
relatively low-impact strategy that derivers working within
the Debian project intent on a single code-base have pursued
actively. Their idea is that rather than forking a piece of
code due to disagreement in how the program should work, they
can leave the code intact but add the
ability to work in a different way to the
software. This alternate functionality is made toggleable
through a configuration change in the same manner that
applications are configured through questions asked at install
time. Since the Debian project has a unified package
configuration framework called Debconf, derivers are able to
configure an entire system in a highly centralized
manner. More information on Debconf can be
found online at: http://www.kitenet.net/programs/debconf/
This is not unlike RedHat's Kickstart although the
emphasis is on maintenance of those configuration changes over
the life and evolution of the package; Kickstart is focused
merely on installation of the package.
A third type of configuration is limited to changes in the
environment through which a system is run or installed. One is
example is Progeny's Anaconda-based Debian installer which
provides an alternate installer but results in an identical
system. Another example is the Knoppix project which is famous
for its "Live CD" environments. While, Knoppix makes a wide
range of invasive changes that span all items in my list
above, other Live CD projects, including Ubuntu's "Casper"
project, are much closer to alternative environments through
which the same code is run.
Because these three methods are relatively non-invasive,
they are reasonable strategies for small teams and individuals
working on creating a derived distribution. However, many
desirable changes — and in the case of some derived
distributions, most desirable changes — require more
invasive changes. The final and most invasive type of change
— changes to code — is the most difficult but also
the most promising and powerful if it can be done sustainably.
Changes of this type involve bifurcations of the code-base and
will be the topic of the remainder of this paper.
Distributed Source Control
One promising method of maintaining changes in forked or
branched problems lies in distributed version control systems
(VCS). Traditional VCS systems work in a highly centralized
fashion. CVS, the archetypal free software VCS and the basis
for many others, is based around the model of a single
centralized server. Anyone who wishes to commit to a project
must commit to the centralized repository. While CVS allows
users to create branches, anyone with commit rights has access
to the entire repository. The tools for branching and merging
over time are not particularly good.
The branching model is primarily geared toward a system
where development is bifurcated and then the branch is merged
completely back into the main tree. Normal use of a branch
might include creating a development branch, making a series
of development releases while maintaining and fixing important
bugs in the stable primary branch, and then ultimately
replacing the stable release with the development release. The
CVS model is not geared toward a system
where an arbitrary delta, or sets of deltas, are maintained
over time.
Distributed version control aims to solve a number of
problems introduced by CVS and alluded to above by:
Allowing people to work disconnected from each other
and to sync with each other, in whole or in part, in an
arbitrary and ad-hoc fashion.
Allowing deltas to be maintained over time.
Ultimately, this requires tools that are better at merging
changes and in not merging certain
changes when that is the desired behavior. It also leads to tools capable
of history-sensitive merging.
The most famous switch to a distributed VCS model from a
centralized VCS model was the move by the Linux kernel
development community to the proprietary distributed version
control system BitKeeper. In his recent announcement of the
decision to part ways with BitKeeper, Linus Torvalds
said:
In fact, one impact BK has had is to very fundamentally
make us (and me in particular) change how we do things. That
ranges from the fine-grained changeset tracking to just how
I ended up trusting sub-maintainers with much bigger things,
and not having to work on a patch-by-patch basis any
more. The full message can be read online
at: http://kerneltrap.org/mailarchive/1/message/48393/thread
At the time of the switch, free distributed version
control tools were less advanced than they are today. At the
moment, an incomplete list of free software VCS tools includes
GNU Arch, Bazaar, Bazaar-NG, Darcs, Monotone, SVK (based on
Subversion), GIT (a system developed by Linus Torvlards as a
temporary replacement for BitKeeper) and others.
Each of these tools, at least after they reach a certain
level of maturity, allow or will allow users to develop
software in a distributed fashion and to, over time, compare
their software and pull changes from others significantly more
easily than they could otherwise. The idea of parallel
development lies at the heart of the model, the tools for
merging and resolving conflicts over time, and the ability to
"cherry pick" certain patches or changes from a parallel
developer each make this type of development significantly
more useful than it has been in the past.
VCSs work entirely on the level of code. Due to the nature
of the types of changes that Ubuntu project is making to
Debian's code, Ubuntu has focused primarily on this model and
Canonical currently funds two major distributed control
products — the Bazaar and Bazaar-NG projects.
In many ways, employing distributed version control
effectively is a much easier problem to solve for small, more
traditional, free software development projects than it is for
GNU/Linux distributions. Because the problems with maintaining
parallel development of a single piece of software in a set of
related distributed repositories is primary use case for
distributed version control system, distributed VCS alone can
be a technical solution for certain types of parallel
development. As the tools and social processes for distributed
VCS evolve, they will become increasingly important tools in
the way that free software is developed.
Because the problems of scale associated with buildling an
entire derivative distribution are more complicated than those
associated with working with a single project, distributed
version control has not yet been widely deployed in the Ubuntu
project. Instead, the project is focusing on integrating these
into problem specific tools built on top of distributed
version control.
Problem Specific Tools
Another technique that Canonical Ltd. is experimenting
with is the creation of high level tools built on top of
distributed version control tools specifically designed for
maintaining difference between packages. Because packages are
usually distributed as a source file with a collection of one
or more patches, this introduces the unique possibility of
creating a high-level VCS system based on this fact.
In the case of Ubuntu and Debian, the ideal tool creates
one branch per patch or feature and using heuristics to
analyze patch files and create these branches
intelligently. The package build system section of the total
patch can also be kept as a separate branch. Canonical's tool,
called the Hypothetical Changeset Tool (HCT) (although no
longer hypothetical), is one experimental way of creating a
very simple, very streamlined interface for dealing with a
particular type of source that is created and distributed in a
particular type of way with a particular type of
change.
While HCT promises to be very useful for people making
derived distributions based on Debian, its application outside
distribution makers will, in all likelihood, be limited. That
said, it provides an example of the way that problem and
context specific tools may play an essential role in the
maintenance of derived code more generally.
Social Solutions
It has been said that it is a common folly of a
technophile to attempt to employ technical solutions toward
solving social problems. The problem of deriving software is
both a technical and a social problem and
adequately addressing the larger problems requires approaches that
take into consideration both types of solution.
Scott James Remnant compares the relationship between
distributions and derived distributions as not unlike the
relationship between distributions and upstream
maintainers:
I don't think this is much different from how Debian
maintainers interact with their upstreams. As Debian
maintainers we take and package upstream software and then
act as a gateway for bugs and problems. Quite often we fix
bugs ourselves and apply the patch to the package and send
it upstream. Sometimes the upstream don't incorporate that
patch and we have to make sure we don't accidentally drop it
each subsequent release, we much prefer it if they take
them, but we don't get angry if they don't.
This is how I see the relationship between Ubuntu and
Debian, we're no more a fork of Debian than a Debian package
is a fork of its upstream.
Scott alludes the fact that, at least in the world of
distributions, parallel development is already one way to view
the modus operandi of existing GNU/Linux
distributions. The relationship between a deriver and derivee
on the distribution level mirrors the relationship between the
distribution and the "upstream" authors of the packages that
make up the distribution. These relationships are rarely based
around technological tools but are entirely in the realm of
social solutions.
Ubuntu has pursued a number of different initiatives along
these lines. The first of these has been to regularly file
bugs in the Debian bug tracking system when bugs are fixed
that exist in Debian are fixed in Ubuntu. While this can be
partially automated, the choice to automate this is a purely
social one.
However, as I alluded to above, Ubuntu is still left with
questions in regards to changes that are made to packages that
do not necessarily fix bugs or that fix bugs that do not exist
in Debian but may in the future. Some Debian developers want
to hear about the full extent of changes made to their
software in Ubuntu while others do not want to be
bothered. Ubuntu should continue to work with Debian to find
ways to allow developers to stay in sync.
There is are also several initiatives by developers in
Debian, to create a stronger relationship between the Debian
project and its ecosystem of derivers and between Ubuntu and
Debian in particular. While the form that this will ultimately
take is unclear, projects existing within an ecosystem should
explore the realm of appropriate social relationships that
will ensure that they can work together and be informed of
each others' work without resorting to "spamming" each other
with irrelevant or unnecessary information.
Another issue that has recently played an important role
in the Debian/Ubuntu relationship is the importance of both
giving adequate credit to the authors or upstream maintainers
of software without implying a closer relationship than is the
case. Derivers must walk a file line where they credit others'
work on a project without implying that the others work for,
support, or are connected to the derivers project which, for
any number of reasons, the original author might not want to
be associated with.
In the case of Debian and Ubuntu, this has resulted in an
emphasis on keeping or importing changelog entries when
changes are imported and in noting the pedigree of changes
more generally. It has recently also been discussed in terms
of the "maintainer" field in each package in Ubuntu. Ubuntu
wants to avoid making changes to every unmodified source
package (and introducing an unnecessary delta) but does not
want to give the impression that the maintainer of the package
is someone unassociated with Ubuntu. While no solution has
been decided at the time of writing, one idea involved marking
the maintainer of the package explicitly as a Debian
maintainer at the time that the binary packages are built on
the Ubuntu build machines.
The emphasis on social solutions is also essential when
using distributed VCS technology. As Linus Torvalds alluded to
in the quote above, the importance of technological changes to
distributed VCS technology is only felt when people begin to
work in a different way — when they begin to employ differnet
social models of developer interaction.
While Ubuntu's experience can provide a good model for
tackling some of these source control issues, it can only
serve as a model and not as a fixed answer. Social solutions
must be appropriate for a given social relationship. Even in
situations where a package is branched because of social
incompatibility, a certain level of collaboration on a social
level will be essential to the long term viability of the
derivation.
Conclusions
As the techniques described in this paper evolve, the role
that they play in free software development becomes increasingly
prominent and increasingly important. Joining them will be other
techniques and models that I have not seen and cannot predict.
Because of the size and usefulness of their code and the size of
their development communities, large projects like Debian and
Ubuntu have been forced into confronting and attempting to
mediate the problems inherent in forking and deriving. However,
as these problems are negotiated and tools and processes are
advanced toward solutions, free software projects of all sizes
will be able to offer users exactly what they want with minimal
redundancy and little duplication of work. In doing this, free
software will harness a power that proprietary models cannot
compete with. They will increase their capacity to produce
better products and better processes. Ulimately, it will help
free software capture more users, bring in more developers, and
produce more free software of a higher quality.