Home » Debian » Ubuntu 2.0 (Twobuntu?!)

Ubuntu 2.0 (Twobuntu?!)

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.


9 Comments

  1. I have Debian on my server and Ubuntu on my laptop: therefore having a SPM done inside Debian makes obvious sense to me because I could issue the same command from either distro and have things work. SPM for Ubuntu doesn’t necessarily mean the particular program is available for Debian. It does from the other side, however: that is, from Debian to Ubuntu.

    Good topic. We need more of these!

  2. I too have ubuntu on two boxes at home and in the office, having replaced debian in the first. however, i am perfectly fine having ubuntu even a little bit on the experimental side. Imagine having to wait for so many months between ubuntu releases just like debian.

    I’d rather see canonical helping debian in moving to new platforms (64-bit, embedded etc)

    ikd

  3. ## For IKD

    Debian’s next version(etch) will ship with 64 bit(officially) support… but debian’s current version runs fine on 64 bit and you can download the 64 bit version from http://www.debian.org. And from your comment “I’d rather see canonical helping debian in moving to new platforms (64-bit, embedded etc)” … debian supports the most architectures out of any distribution…it supports i386, AMD64, PowerPC, 68k, SPARC, DEC Alpha, ARM, MIPS, HPPA, S390, IA64 … So I doubt debian needs to move towards new platforms… Ubuntu forked for this reason particularly(among many), that is doesn’t have to support all of the architectures that debian does. Ubuntu only supports 3 architectures… i386 powerpc and amd64.

    ## For Montana
    “SPM for Ubuntu doesn’t necessarily mean the particular program is available for Debian. It does from the other side, however: that is, from Debian to Ubuntu.”
    This depends on which version of Ubuntu and Debian you are speaking about. And generally this statement is false. Ubuntu only gives _official_ support to a small amount of packages. You have to manually edit sources to add other packages.(which aren’t support[if you pay for support?]) Debian has over 15,000 packages in main…which can be accessed by default. And if you are running Debian testing(which a lot of people run on their desktops) you could easily have programs in debian etch that aren’t in Ubuntu and vise versa. So while most programs that are in debian are also in Ubuntu…not all of them are.

    And both these comments so far seem to miss the point of the article. The author seems to suggest that Ubuntu should remerge with Debian…this way efforts would be more combined.(many of the Debian developers are ubuntu developers..and vise versa)

    Mark Shuttleworth is a debian developer. This is how he started…and he wanted faster release cycles essentially. And debian does not want to go that fast. So mark forked. And created Ubuntu. Mark Shuttleworth could have shaked up the project and made things go faster…but he didn’t want to disturb/ruin the project as most debian developers are volunteers and they program debian in their spare time. Where mark hired 20ish full time developers to work on Ubuntu full time. ubuntu is based off of debian. Without debian ubuntu would have a hard time surviving/existing at all. So Ubuntu team not only needs to manage their own project. They need to make sure debian is moving in a certain direction…so they can guarantee Ubuntu’s sucess in the future also. This is difficult to do…as debian has stipulation in their contracts about corporations(Ubuntu/Canonical Inc.) not being able to control/mess with their project too much.(This is good as it doesn’t allow microsoft to destroy them, heh) I believe Mark’s move to fork debian was not a good idea. I think he should have taken a risk and tried to shake up the project. As things the way they don’t seem to be the optimal productivity that they could be. I think it would be possible for him to remerge with debian…and would be more likely now..as he has proven himself and his worth. And proven the project(Ubuntu). I do not think he will do this though. And that is ok…things can be forked…that is the whole point of GNU/Linux … and both projects are doing very well and are very sucessfull.

    I think there needs to be more structure in the way Ubuntu and Debian are tied to each other…and the developers need to not think of each other as competitors…but as collaborators. But again both projects are doing very well…and not much needs to change. They are obviously moving in the right direction. It just takes time.(and now money?)

  4. I really like some of these ideas. However I would not base Edgy Eft on Debian Stable because edgy is supposed to be about new technologies.

    For Dapper (and other releases that will be supported for a long time) this is a very good idea.

  5. > I believe Mark’s move to fork debian was not a good idea

    Actually he hasn’t forked Debian, he’s created a branch. There’s a big difference. A fork has a life of it’s own and over time will diverge (e.g. Mandrake is a Red Hat fork that is now quite different from Red Hat). A branch is like a fork, except that it periodically gets remerged. In Ubuntu’s case, each release is a snapshot of Debian unstable that’s been stabilized for a time. The next release resynchronizes with Debian. This allows Ubuntu to have packages that are almost as fresh as Debian unstable without having to worry about things breaking every once and a while (the whole purpose of unstable is to precisely be able to test out new changes and break things if needed).

    Building Ubuntu off of Debian stable misses the point of Ubuntu (always use the latest and greatest). Building it off of Debian Testing wouldn’t work unless the Debian Testing conformed to Ubuntu’s model (i.e. Debian Testing is a 6 month snapshot of Debian Unstable and Debian Testing started getting security patches).

    Personally, I think it would be a *great* idea if Debian changed this way (it would make having regular Debian stable releases *a lot* easier). However, it’s not Ubuntu’s place to push Debian around. Debian is a big meta distribution that’s been around for over a decade and has a social structure that dwarfs Ubuntu’s. Ubuntu may get all the glory but Debian is the silent workhorse that makes it all possible. If Debian sees the benefits of making Debian Testing a 6 month snapshot, there’s little reason why Ubuntu would choose to create a Debian Unstable snapshot branch. Ubuntu would likely continue to create a snapshot of GNOME or KDE (since it’s unlikely that Debian will synchronize it’s Testing snapshot with GNOME), but the size of the branch would be a lot smaller and would be usable by any other Debian Testing distro.

  6. […] Ubuntu 2.0 (Twobuntu?!) Filed under: Links — rakhesh @ … 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 2 million new customers and 10,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. § […]

  7. I have had no direct contact with the Debian community (other then running the OS). Several of my friends go to the meetings, and when they tell me about the meetings they sound miserable.

    The decision making process in the Debian process is not fast enough and can be held up by a few crappy and difficult people. Ubuntu fixes that, and does not try to support 15k packages.

    Ubuntu is agile and can try more new things to see what works. Ubuntu can show millions of Open Source buyers to hardware and software makers, while hiding our few malcontents. It could be a beautiful OS ecosystem if both distros play nice — so that the fruit of the Ubuntu tree can fertilize the soil of Debian.

    Ð Ubuntu syncs a lot from Debian, and needs to try to give back more without sinking into the dysfunctional culture of the project.

    Ð Debian, on the other hand, needs to take the major changes from Ubuntu that are working (like Upstart?).

Comments are closed.