Written May, 2006, updated May, 2007 in preparation for Debconf 7
Update 2: The slideshow and my thoughts on the subsequent discussion are available here.

Ubuntu is a very exciting distro, gaining critical mass, and demonstrating the possibilities for a powerful and simple Linux desktop. I can’t help spending time handicapping the top Linux distros; it is more fun than the Windows, Mac & OS/2 wars of the past, especially as we are participants rather than merely spectators.

I don’t think that there need be just one distro or family of distros which will own the market, and Linux needn’t become a monoculture to succeed on the desktop. I run Gnome, but can run KDE apps as well, so while we can make this situation better, we don’t need to. Today there are 20 million Linux computers and lots of different distros and I don’t know why there can’t be 1 billion Linux computers with lots of different distros. I’m sure Novell would be ecstatic with only 50 million Linux customers.

For those living inside the Debian or Ubuntu worlds, the issue of their relationship is an old topic, but it it will continue to evolve as they learn from their experience. Ubuntu already exists and is a great distro, and I support the friendly competition and energy that it brings. However, a goal should be to figure out how to best harness each’s efforts. I strongly believe that Debian needs to stay the center of gravity; when a feature is done first in Ubuntu, the center of gravity shifts away. Given the fact that Ubuntu has no “list of features” they’d like Debian to implement, you can say they are on course to become the center of gravity.

As background, I believe that Ubuntu’s existence is an exploitation of a loophole in the GPL: you are allowed to take someone’s code, and do anything you want with it, but the presumption is that you should work together on one codebase. As you make improvements, you should immediately put them back into the standard codebase, and take ownership of any issues with that improvement. When someone makes a fix to the Linux kernel, they don’t use that improvement to make a competing Linux kernel!

While Ubuntu forking Debian goes against the spirit of cooperation embodied in the GPL, there are also practical reasons why it is a bad idea.

Ubuntu’s challenges
While Ubuntu has 2 million (now 8 million) customers, it has lots of challenges as well. The biggest is that the maintainers cannot keep up with the incoming bugs. In fact, if the most popular Linux distro has the smallest engineering team and is the least stable, it threatens the perception of the desktop distro market as a whole. Meanwhile, if Debian had so many new customers and 10,000 (now 30,000) new bugs, I’ll bet they could pick up the pace for the increased workload, especially if it came with a few New Maintainer applications. That mild shock to their system might even be healthy. Excitement brings in new people and makes existing people work harder. Ubuntu is sapping excitement, which is killing Debian.

I think there are 3 main reasons why Ubuntu is buried in bugs:

• Ubuntu is finding bugs which exist in Debian but that Debian hasn’t fixed or doesn’t even know about. This is very worrisome because Ubuntu has 10,000 (now 30,000) active bugs, with 5,000 (now 15,000 ) still unconfirmed. Not only is it a problem that Ubuntu is shipping with so many bugs, Debian is shipping stable releases with potential “release critical” bugs that it does not know about. It therefore questions the merits of Debian even making stable releases.
• Ubuntu is making deep core changes but it doesn’t have the resources to deal with the issues across all the hardware and software because Debian’s expertise is not being fully utilized.
• Ubuntu snapshots bits from Debian-unstable which gives them the latest and greatest Debian code, but it is code which hasn’t been debugged yet.

Here’s a question: of the first 75 bugs in Ubuntu, how many exist and are filed in Debian?

Efficiency by doing work directly in Debian
When Ubuntu did modular X, the packages were provided for Debian but it still needed to be adapted and re-debugged and in the end turned out to be only a “starting point,” according to the Debian engineer who did this work. In other words, even though Debian had Ubuntu’s patches, it was still months of work–not that much better than if they didn’t have the changes at all! It sounds helpful to throw code over the wall, or publish patches on a website, but it takes time to ramp up expertise to understand them. If you have to ramp up expertise in 2 organizations, the global community’s time is not being spent efficiently. Hiring Debian developers, even to work full-time on Ubuntu, does not much help, and actually weakens, Debian.

Note that this inefficiency issue doesn’t happen as much going the other way. Ubuntu doesn’t have Apache maintainers, so they just take the code as-is, and probably file any bugs upstream. In the areas where they both have maintainers: the kernel, X, Gnome, KDE, FireFox, OpenOffice, you will find a ton of duplicative efforts and expertise.

Code is infinitely malleable
Ubuntu wanted modular X, and so they forked Debian and added this feature. However, no one has said why this feature couldn’t have been added directly to Debian. Whether Canonical believes that Debian is missing features or shipping too slowly, it can simply hire Debian engineers to directly fix these problems, without needing to create a separate codebase. The codebase they started with was 100% Debian, so clearly it was possible to add their features to the Debian codebase.

Reasons for a divergent fork no longer apply
Debian and Ubuntu have converged a lot in the last year. Ubuntu’s initial changes were big, however, Debian has caught up with Ubuntu and both want to add Xen and Xgl to Etch/Feisty Fawn. Now that the architectural differences are smaller, the reasons to add features outside Debian become smaller. It only makes sense to add features directly to Debian that Debian wants, but from looking at Ubuntu’s spec list, I’ll bet that Debian wants at least 90% and potentially all, of Ubuntu’s improvements. If there are no features that Ubuntu is adding that Debian doesn’t want, what does that say about the wisdom of separate codebases? Even worse, some significant features that Ubuntu has, Debian is no longer even motivated to add: any user of Debian that has wanted better power management for his laptop is now using Ubuntu, and so Debian 4.0’s power management is several releases behind Ubuntu’s and probably not as well tested.

Ubuntu shouldn’t be doing the big stuff first
Some of Ubuntu’s architectural bets: modular X, 2.6 kernel, new GCC, etc. were safe bets to make. However, core decisions are better left for Debian to decide and whatever decision Debian makes will typically be fine with Ubuntu. Just imagine what a mess would be created if Ubuntu adopts Upstart and Debian something else. Lots of arbitrary differences could cause unnecessary divergence over time.

Building on top of Debian Unstable
Another significant decision Ubuntu made is to ship the Unstable branch. This is an interesting idea that made sense during the Sarge era because Sarge had lots of new code in unstable, but the stable code was ancient. While this suggests that even an unstable branch is a pretty solid base, I’m not sure if Ubuntu can ever be confident in the quality of an LTS release if it has known, and untested and therefore unknown, bugs. Either Debian has ‘release critical’ bugs or it does not.

What is Twobuntu, other than a silly name?

I’m suggesting a few changes to the way Ubuntu develops software:

• When Ubuntu decides to add a feature, the question needs to be asked if it is a core feature that Debian wants. If so, the Ubuntu developer should either do the work directly inside Debian, or takes ownership for it in Debian after implementing it in Ubuntu.
• If Ubuntu adds features in Debian first, it won’t ship with Ubuntu till it hits Debian stable (or unstable) but it will not take much more time to do something in Debian.
• If Ubuntu doesn’t make big changes outside of Debian, it could more easily triage: for example, all X and power management bugs would flow directly upstream. By having all the bugs in one place, it makes it easier to hand them out amongst a unified team of developers, and to analyze the state of a component.

I realize that whether to do a feature inside or outside Debian is a hard question. An exercise for the reader: if Ubuntu decides to adopt a Smart Package Manager, should this be done inside Debian or not?

Because code is infinitely malleable, separate codebases create arbitrary boundaries between ideas and people. There are various ways to work better together, and the goals should be to make development maximally efficient, allow Debian to better feel Ubuntu’s investments, help Ubuntu with its pitched battle against bugs, ensure that bugs and code flow freely, and that Ubuntu and Debian’s architecture, user and developer communities be well connected.

Update: this old proposal is somewhat complicated, but it would allow Ubuntu to exist as a separate entity if they believe that there are enough features they want that Debian doesn’t care about. If it turns out that Debian wants all Ubuntu’s features except for the orange, then it makes sense to think big. I would prefer merging, because I don’t like the idea of disparate communities. In general, the goal should be for Ubuntu and Debian to share a source tree, bug list and community, like Wikipedia and the Linux kernel do. Whether they have Technical Committees, or Community Councils, codes of conduct, etc. doesn’t matter nearly as much.