This chapter is from the book
This chapter is from the book
This chapter is from the book
What Is Ubuntu?
The Warthogs’ goal and Canonical’s flagship project is Ubuntu. If you’ve gotten this far, you already have some idea of what that means. That said, this section tries to offer a little bit of background that is helpful in understanding exactly what Ubuntu is and what its goals are.
What Is a Distribution?
It’s clear to most people that Ubuntu is an OS. The full story is a little more complex. Ubuntu is what is called a distribution of GNU/Linux—a distro for short. Understanding exactly what that means requires, once again, a little bit of history. In the early days of GNU and Linux, users needed a great deal of technical knowledge. Only geeks needed to apply. There were no Linux operating systems in the sense that we usually use the term—there was no single CD or set of disks that one could use to install. Instead, the software was dozens and even hundreds of individual programs, each built differently by a different individual, and each distributed separately. Installing each of the necessary applications would be incredibly time consuming at best. In many cases, incompatibilities and the technical trickery necessary to install software made getting a GNU/Linux system on a hard disk prohibitively difficult. A great deal of knowledge of configuration and programming was necessary just to get a system up and running. As a result, very few people who were not programmers used these early GNU/Linux systems.
Early distributions were projects that collected all of the necessary pieces of software from all of the different places and put them together in an easier-to-install form with the most basic configuration already done. These distributions aimed to make using GNU/Linux more convenient and to bring it to larger groups of users. Today, almost nobody uses GNU/Linux without using a distribution. As a result, distribution names are well known. Ubuntu is such a project. Other popular distros include Red Hat and Fedora, Novell’s SUSE, Gentoo, and of course Debian.
Most distributions contain a similar collection of software. For example, they all contain most of the core pieces of GNU and a Linux kernel. Almost all contain the X Window System and a set of applications on top of it that may include a Web browser, a desktop environment, and an office suite. While distributions started out distributing only the core pieces of the OS, they have grown to include an increasingly wide array of applications as well. A modern distribution includes all of the software that “comes with an OS,” that is, several CDs or DVDs containing anything that most users might want and that the distribution is legally allowed to distribute.
Ubuntu, like other contemporary distros, offers a custom installer, a framework including software and servers to install new software once the system has been installed, a standard configuration method through which many programs can be configured, a standard method through which users can report bugs in their software, and much more. Frequently, distributions also contain large repositories of software on servers accessible through the Internet. To get a sense of scale, Ubuntu includes on the order of 20,000 pieces of software on its central servers—each piece of software is customized slightly and tested to work well with all of the other software on the system. That number grows daily.
What’s important to realize is that the creators of distributions do not, for the most part, write or create the applications you use. The Ubuntu team did not write Linux, and it did not write GNU—although individuals on the team have contributed to both projects. Instead, the Ubuntu team takes GNU, Linux, and many thousands of other applications and then tests and integrates them to be accessible under a single installer. Ubuntu is the glue that lets you take a single CD, install hundreds of separate pieces of software, and have them work together as a single, integrated desktop system. If you were to pick up a CD of another distribution such as Debian, Red Hat, or Novell, the software installed would be nearly identical to the software in Ubuntu. The difference would be in the way the software is installed, serviced, upgraded, and presented and the way it integrates with other pieces of software on the system.
An Ecosystem of Distributions
Many hundreds of GNU/Linux distributions are in active use today. A quick look at Distrowatch’s database (distrowatch.com) demonstrates the staggering number and growth of distributions. One of the first GNU/Linux distributions was called Softlanding Linux System, or SLS. For a number of reasons, a programmer named Patrick Volkerding thought he could improve on SLS. Because SLS was free software, Volkerding had the freedom to make a derivative version of SLS and distribute it. Volkerding did just this when he took SLS’s code and used it as the framework or model upon which to create his own variant called Slackware. Subsequently, Slackware became the first widely successful GNU/Linux distribution and is maintained to this day.
With time, the landscape of GNU/Linux distribution has changed. However, the important role of derivation that made Slackware possible has remained fully intact and is still shaping this landscape. Today, the hundreds of GNU/Linux distributions serve a multitude of users for a myriad of purposes: There are distributions specially designed for children, for dentists, and for speakers of many of the world’s languages. There are distributions for science, for business, for servers, for PDAs, for nonprofit organizations, for musicians, and for countless other groups.
Despite this diversity, the vast majority of derivatives can be traced back to one of two parent distributions: Red Hat and Debian. While it is not necessary to understand the details of how these projects differ, it’s useful to know that Red Hat and Debian offer two compelling, but frequently different, platforms. Each project has strengths and weaknesses. For almost every group making a Linux-based OS, one of these projects acts as square one (with a few notable exceptions, such as the Gentoo project).
However, while the process of deriving distributions has allowed for a proliferation of OS platforms serving a vast multiplicity of needs, the derivative process has, historically, been largely a one-way process. New distributions based on Red Hat—Mandriva and Novell’s SUSE, for example—begin with Red Hat or a subset of Red Hat technology and then customize and diverge. Very few of these changes ever make it back into Red Hat and, with time, distributions tend to diverge to the point of irreconcilable incompatibility. While the software that each system includes remains largely consistent across all distributions, the way that it is packaged, presented, installed, and configured becomes increasingly differentiated. During this process, interdistribution sharing and collaboration grow in difficulty.
This growing divergence indicates a more general problem faced by distribution teams in getting changes upstream. Frequently, the users of GNU/ Linux distributions find and report problems in their software. Frequently, distribution teams fix the bugs in question. While sometimes these bugs are in changes introduced by the distribution, they often exist in the upstream version of the software and the fix applies to every distribution. What is not uncommon, but is unfortunately much less frequent, is for these bug fixes to be pushed upstream so that all distributions and users get to use them. This lack of collaboration is rarely due to malice, incompetence, or any tactical or strategic decision made by developers or their employers. Instead, tracking and monitoring changes across distributions and in relation to upstream developers is complicated and difficult. It’s a fact of life that sometimes changes fall on the floor. These failures are simply the product of distribution-building processes, policies, and tools that approach distributions as products in and of themselves—not processes within an ecosystem.
Like many other distributions, Ubuntu is a derivative of Debian. Unlike the creators of many derivatives, the Ubuntu community has made it one of its primary goals to explore the possibility of a better derivation process with Debian, with Debian and Ubuntu’s common upstreams (e.g., projects such as Linux or GNU), and with Ubuntu’s own derivatives. A more in-depth discussion of Debian can help explain how Ubuntu positions itself within the free software world.
The Debian Project and the Free Software Universe
Debian is a distribution backed by a volunteer project of over 1,000 official members and many more volunteers and contributors. It has expanded to encompass around 20,000 packages of free and open source applications and documentation. Debian’s history and structure make it very good at certain things. For example, Debian has a well-deserved reputation for integrated package management and access to a large list of free software applications. However, as a voluntary and largely nonhierarchical organization, there are also several things that Debian has trouble providing. Frequent and reliable releases, corporate support and liability, and a top-down consistency on the desktop have proven to be difficult for Debian to offer.
Each new distribution exists for a reason. Creating a new distribution, even a derivative, is far from easy. In large part, Ubuntu exists to build off of the many successes of the Debian project while solving some of the problems it struggles with. The goal is to create a synthetic whole that appeals to users who had previously been unable or unwilling to use Debian.
In building off the great work of the Debian project, as well as GNU, Linux, and other projects that Debian is built on, the Ubuntu team wanted to explore a new style of derivation that focused on a tighter interproject relationship within an ecosystem of different developers. While Ubuntu tries to improve and build on Debian’s success, the project is in no way trying to replace Debian. On the contrary, Ubuntu couldn’t exist without the Debian project and its large volunteer and software base, as well as the high degree of quality that Debian consistently provides. This symbiotic relationship between Ubuntu and Debian is mirrored in the way that both Ubuntu and Debian depend heavily on projects such as GNU and Linux to produce great software, which they can each package and distribute. The Ubuntu project sets out explicitly to build a symbiotic relationship with both Debian and their common “upstream.”
The relationship between Ubuntu and Debian has not been simple, straightforward, or painless and has involved patience and learning on both sides. While the relationship has yet to be perfected, with time it has improved consistently, and both groups have found ways to work together that seem to offer major benefits over the traditional derive-and-forget model. It is through a complex series of technological, social, and even political processes—many of which is described in the rest of this chapter—that Ubuntu tries to create a better way to build a free software distribution.
The Ubuntu Community
By now you may have noticed a theme that permeates the Ubuntu project on several levels. The history of free software and open source is one of a profoundly effective community. Similarly, in building a GNU/Linux distribution, the Ubuntu community has tried to focus on an ecosystem model—an organization of organizations—in other words, a community. Even the definition of ubuntu is one that revolves around people interacting in a community.
It comes as no surprise then that an “internal” community plays heavily into the way that the Ubuntu distribution is created. While the Ubuntu 4.10 version (Warty Warthog) was primarily built by a small number of people, Ubuntu achieved widespread success only through contributions by a much larger group that included programmers, documentation writers, volunteer support staff, and users. While Canonical employs a core group of several dozen active contributors to Ubuntu, the distribution has, from day one, encouraged and incorporated contributions from anyone in the community, and rewards and recognizes contributions by all. Rather than taking center stage, paid contributors are not employed by the Ubuntu project—instead they are employed by Canonical, Ltd. These employees are treated simply as another set of community members. They must apply for membership in the Ubuntu community and have their contributions recognized in the same way as anyone else. All nonbusiness-related communication about the Ubuntu project occurs in public and in the community. Volunteer community members occupy a majority of the seats on the two most important governing boards of the Ubuntu project: the Technical Board, which oversees all technical matters, and the Community Council, which approves new Ubuntu members and resolves disputes. Seats on both boards are approved by the relevant community groups, developers for the Technical Board and Ubuntu members for the Community Council.
In order to harness and encourage the contributions of its community, Ubuntu strives to balance the important role that Canonical plays with the value of empowering individuals in the community. The Ubuntu project is based on a fundamental belief that great software is built, supported, and maintained only in a strong relationship with the individuals who use the software. In this way, by fostering and supporting a vibrant community, Ubuntu can achieve much more than it could through paid development alone. The people on the project believe that while the contributions of Canonical and Mark Shuttleworth have provided an important catalyst for the processes that have built Ubuntu, it is the community that brought the distribution its success to date. The project members believe that it is only through increasing reliance on the community that the project’s success will continue to grow. We won’t outspend the proprietary software industry. As a community, though, we are very much more than Microsoft and its allies can afford.
The nature of the Ubuntu community is described in depth in Chapter 7, which is wholly devoted to the subject. Finally, it is worth noting that, while this book is official, none of the authors are Canonical employees except Jono Bacon (and he wasn’t hired as the Community Leader until the first edition of the book was already on the shelves). This book, like much of the rest of Ubuntu, is purely a product of the project’s community.