Afterwards, a number of people came up to talk about it further, with generally positive feedback.

Christopher Curtis, for example, emailed to say that the idea of economic clustering in the motor car industry goes far further than the location of car dealerships. He writes:

Firstly, every car maker releases their new models at about the same time. Each car maker has similar products - economy, sedan, light truck. They copy each other prolifically. Eventually, they all adopt a certain baseline - seatbelts, bumpers, airbags, anti-lock brakes. Yet they compete fiercely (OnStar from GM; Microsoft Sync from Ford) and people remain brand loyal. This isn’t going to change in the Linux world. Even better, relations like Debian->Ubuntu match car maker relations like Toyota->Lexus.

I agree with him wholeheartedly. Linux distributions and car manufacturers are very similar: we’re selling products that reach the same basic audience (there are niche specialists in real-time or embedded or regional markets) with a similar range (desktop, workstation, server, mobile), and we use many of the same components just as the motor industry uses common suppliers. That commonality and coordination benefits the motor industry, and yet individual brands and products retain their identity.

Let’s do a small thought experiment. Can you name, for the last major enterprise release of your favourite distribution, the specific major versions of kernel, gcc, X, GNOME, KDE, OpenOffice.org or Mozilla that were shipped? And can you say whether those major versions were the same or different to any of the enterprise releases of Ubuntu, SLES, Debian, or RHEL which shipped at roughly the same time? I’m willing to bet that any particular customer would say that they can’t remember either which versions were involved, or how those stacked up against the competition, and don’t care either. So looking backwards, differences in versions weren’t a customer-differentiating item.  We can do the same thought experiment looking forwards. WHAT IF you knew that the next long-term supported releases of Ubuntu, Debian, Red Hat and Novell Linux would all have the same major versions of kernel, GCC, X, GNOME, KDE, OO.o and Mozilla. Would that make a major difference for you? I’m willing to bet not - that from a customer view, folks who prefer X will still prefer X. A person who prefers Red Hat will stick with Red Hat. But from a developer view, would that make it easier to collaborate? Dramatically so.

Another member of the audience came up to talk about the fashion industry. That’s also converged on a highly coordinated model - fabrics and technologies “release” first, then designers introduce their work simultaneously at fashion shows around the world. “Spring 2009″ sees new collections from all the major houses, many re-using similar ideas or components. That hasn’t hurt their industry, rather it helps to build awareness amongst the potential audience.

The ultimate laboratory, nature, has also adopted release coordination. Anil Somayaji, who was in the audience for the keynote, subsequently emailed this:

Basically, trees of a given species will synchronize their seed releases in time and in amount, potentially to overwhelm predators and to coordinate with environmental conditions. In effect, synchronized seed releases is a strategy for competitors to work together to ensure that they all have the best chance of succeeding. In a similar fashion, if free software were to “release its seeds” in a synchronized fashion (with similar types of software or distributions having coordinated schedules, but software in different niches having different schedules), it might maximize the chances of all of their survival and prosperity.

There’s no doubt in my mind that the stronger the “pulse” we are able to create, by coordinating the freezes and releases of major pieces of the free software stack, the stronger our impact on the global software market will be, and the better for all companies - from MySQL to Alfresco, from Zimbra to OBM, from Red Hat to Ubuntu.

I had a lecturer who was very opposed to the use of the term “bugs”. He said that the term “bug” was a cute-sification for “nasty biting insect”, and similarly, software defects have potentially serious consequences, so we shouldn’t treat them lightly. Bug work is serious work, and it’s one of the most important forms of contribution to the digital commons that Ubuntu can make, so I’d like to salute the extraordinary efforts of the Ubuntu Quality Assurance Team and Bug Squad. Initiatives like five-a-day are already making a huge difference to our users. As Henrik Omma says, effective bug reporting requires a diligent and professional approach, and I’ve noticed a real improvement in our community. Hopefully, we can bring the benefits of that competence to the broader free software ecosystem.

Ubuntu gets as many bugs reported against it as OpenOffice, Mozilla, Gnome, and KDE combined.The vast majority of those bugs are issues that exist in upstream tarball releases, or in Debian. Our primary goals should be to ensure that fixes we produce, and information we generate in the QA process, make their way upstream where they will benefit the broadest cross-section of the community. Separately, we want to ensure that each Ubuntu release ships without major issues, regardless of where those issues originated. We are responsible for the user experience of every line of code, even though we don’t produce every line of code.

In the month of April 2008, I found the following bug counts for large FLOSS projects:

With hindsight, April was possibly a bad choice, because it was an Ubuntu release month so there’s usually a small spike in the number of bugs filed. It would be interesting to see the stats for other distributions, and projects, over a full year. But the general picture is clear - within our family of distributions, Ubuntu carries the brunt of the load w.r.t. bug tracking, triage and patch management - not only for our users, but for a broad cross-section of the open source stack.

When I delved into the data to see how we do with pushing bugs upstream, I found a somewhat mixed picture. In many cases, we do very well indeed. We have a very good relationship with GNOME, for example, with a very high percentage of bugs appropriately forwarded to the relevant upstream bug tracker. In other projects, it’s harder to make a definitive statement. The percentage varies based on whether the Ubuntu team members have good relationships upstream, or whether there’s a person acting as an ambassador from Ubuntu to upstream (this is a great way to make a difference if you care about a specific application in Ubuntu!) or whether upstream themselves have taken an interest.

We need to improve the tools that support these kinds of cross-project conversations. Launchpad does currently allow us to track the status of a bug in many different bug trackers, and there are quite a few distributions and upstreams that are now either using Launchpad directly or exchanging data efficiently. We’ll keep working to improve the quality of exchange across the whole ecosystem, including those projects that don’t use Launchpad themselves

1) Hi Mark, thank you for your availability. Some simple questions to introduce you to our readers to start. What’s your role at Ubuntu/Canonical and what do you do in your spare time? What are your hobbies?
My favourite sport is snowboarding, and I enjoy travel to tropical spots. But ultimately I’m happiest when I’m being a geek, reading, playing games or relaxing with friends.

2) You’re the founder of Canonical, the company behind Ubuntu. Why do you decided to invest a lot of dollars (10$ million) to start up the company? In which fields does it work to make its business? How do you make the company sustainable?
The vision of Ubuntu and Canonical is a symbiotic one. We believe that Linux has grown to the point where it is possible to build the platform at a low enough cost to make it sustainable purely though services around it, rather than through licensing the platform. In other words, we think that support, training, online services, and professional engineering for people who want to adapt Ubuntu commercially will earn enough money to pay for Ubuntu itself.

That means that we can fundamentally change the business model of the OS industry. Of course, it till take time to prove that we can achieve this, but we have a superb team and now that Ubuntu is well established we see increasing demand for services from Canonical, which is positive.

3) Ok, let’s talk about the latest Ubuntu 8.04. In an interview you said that “Hardy Heron is your most significant release ever”. Well, can you talk about the main improvements of this release?
First, this is an LTS (“Long Term Support”) release that was delivered on a very precise schedule. Six months ago we committed to shipping 8.04 LTS on April 24th, and we did exactly that. As far as I know, nobody has ever shipped an “enterprise class” OS release on a schedule that precise. And not only did we do that, but we have now committed to ship the next LTS in April 2010, it will be 10.04 LTS, and we’ll set the exact date six months in advance like we did with this one. It is thanks to Debian and the free software community that it is possible for us to do this. So 8.04 LTS has proven our ability to deliver not just 18-month-supported releases on time, but also LTS releases on time. We very much hope that other distributions will follow our lead on the LTS cycle with their enterprise releases, because that will make it easier for us all to collaborate, and make all the major Linux distributions better.

Second, there are very significant new developments for Ubuntu itself. On the server, we worked with HP on their Proliant range, and with Dell on their PowerEdge range, to ensure that 8.04 LTS will be compatible with their popular x86 servers. We’re not yet certified, but we are sure that it will “Just Work”. Sun Microsystems has gone further, and has actually certified 8.04 LTS on a range of their x86 servers. This is a major step forward for Ubuntu on the server. We see an amazing amount of usage now for Ubuntu on the server – it’s the most popular server platform for several ISV’s. So it’s important that we work with server vendors, and server solution vendors. We’ve also put a lot of work into the use of KVM and VMWare virtualisation, because we see people building hundreds of virtual appliances on Ubuntu.

On the desktop, we have focused on making it easier to install Ubuntu, especially on a machine which already has Windows, where you can now install Ubuntu into a file on the Windows partition instead of having to resize your Windows partition to make a new partition for Ubuntu. That makes it much easier for people to test out Ubuntu, and hence to get a taste of free software. We have also worked on many of the common things that people want to do with their PC, such as work with photos and music, and started to improve the user experience there.

4) There are still some hardware issues (especially with some wireless devices) in Ubuntu. How do you think to solve these kind of problems and improve hardware support in the next releases?
We are increasingly able to work directly with the hardware manufacturers, to try and convince them to develop free software drivers for their hardware. Our relationships with different PC companies mean that we can lobby strongly for people to embrace Linux, properly.

We also work very hard to tie together all the ugly pieces of string that are needed to make the user experience of Linux on your hardware a pleasant one. Unfortunately, for example, there are multiple different wireless stacks, for example, with different capabilities. And Ubuntu spends a lot of time integrating and debugging them to try and create a harmonious, standardised experience for end-users.

5) What kind of improvements Ubuntu 8.04 bring to server and virtualization solutions?
Ubuntu Server Edition brings all the wonderful characteristics of Debian to the front – it’s modular, efficient, has a huge package selection, and is easy to install and manage. In addition, we’ve done a lot of work with server manufacturers to ensure compatibility with their popular hardware, and have started certifying with some of them.

Our virtualisation offering is based around KVM and VMWare. Out of the box, Ubuntu should give you the best possible experience with both of them. It is optimised and rigorously tested, and Ubuntu is certified on VMWare’s ESX Server platform. KVM, the free software virtualisation option we prefer, is built in to our standard server kernel, so you can get started with virtualisation immediately. There is also a Xen kernel for folks who prefer Xen.

We have done a lot of work around the integration of Ubuntu servers and Windows networks, particularly in the field of Active Directory and SMB file sharing servers. We worked with a company called Likewise to make sure that there is a smooth process to join an Active Directory network, and can even manage Linux machines through AD using Likewise’ professional tools. All the capabilities to do the basic stuff are free software and built in to Ubuntu.

6) A dirty question from our readers: Ubuntu is really a giant now, are you trying to kill the Debian project?
Absolutely not. I’m a Debian Developer myself, and very proud of what Debian has achieved, and also proud of everything that Ubuntu contributes to the broader Debian project. We consider Ubuntu to be a member of the Debian family, that’s just purely focused on the specific use cases and platforms that our customers want.

Much of what we do in Ubuntu contributes directly to Debian. We lead the packaging of many important pieces of the desktop, and server, and toolchain, and contribute that work directly to Debian. As a result, Debian is updated much faster these days than it used to be without Ubuntu. We have lead many key transitions and always try to collaborate with the relevant people upstream AND in Debian to ensure that the work flows smoothly into those projects. Most DD’s are very happy to collaborate, but some view Ubuntu as a threat, and refuse to collaborate, or make unreasonable demands on Ubuntu because they think “you have money” when in fact most of Ubuntu is volunteer driven.

My vision is that Debian and Ubuntu both grow stronger through good collaboration. I’m trying to have a keynote accepted at DebConf to help make that vision a reality, but so far have had no luck in getting approval. Hopefully, the leadership of Debian will start to come around tot he idea that Ubuntu’s success is very good for Debian.

7) You’re working with embedded devices and electronics company. In which way? What is you work in the tight partnership with Intel?
Linux is increasingly used by embedded solution providers, and many of them want to use Ubuntu. So we are working with Intel to make sure that Ubuntu fully supports their low-power hardware (cpu’s, chipsets, graphics and so on).

Ubuntu surely is the most used and appreciated GNU/Linux distribution in the world. But, do you think that Ubuntu Linux will reach – one day – the success of other operating systems like OS X and Windows? In which way do you think to accomplish a similar goal?
I do believe that free software will come to be widely recognised, trusted and used by everyday computer users, as opposed to being limited to specialists as it is today. Hopefully Ubuntu will play a part in that, but I don’t think one platform will dominate that free software era like Windows dominated the proprietary software era. Ubuntu is focused on specific needs, and there are other versions of Linux or BSD that meet others.

In order to break out from the pack, we need to deliver a desktop experience that is exciting, that is easy to use, and which people are confident will be compatible with their future needs and with those of their colleagues.

9) Everybody talk about GNU/Linux but seems that not so many peoples trust Linux for now (some statistics talk about 0.xx% of the Linux world usage). What is the problem? Nevertheless Ubuntu is really a great operating system. Do you think it’s just a matter of marketing or because the lack of game packages?
I think it takes time to change the habits of hundreds of millions of people! I also think we need to deliver an experience that is simply better than the alternatives. Projects like Firefox don’t define their goal as being “a good browser”, they say “we want to be the best browser on any platform, period”, and as a result they are very popular even on Windows. We need that winning attitude everywhere.

10) Canonical was the first GNU/Linux company to make a deal with a computer vendor, Dell. How is going your business now? The curious thing is that on IdeaStorm a lot of users asked for Linux Computers but after some months seems that the sales aren’t so good, or at least not as expected. Why? Maybe GNU/Linux is not ready for the consumer market yet?
I agree that the more people actually buy systems with Linux pre-installed, the faster things like hardware support will be addressed. Fortunately, we see millions of units being shipped with Linux already, just not at the high-end of the PC business. The low-end, especially in countries like Brazil and China, is very active. Slowly, Linux is becoming a volume player.

11) Are you working with other computer vendor to sell other Ubuntu-based desktops and laptops? We’re Italians and the Ubuntu-Dell computers never arrived in our country. Why Dell, and other vendor, is so shy to sell GNU/Linux computers world wide?
That’s a simple matter of demand and the cost to meet it. Any PC manufacturer will take a firm view of the economics of an opportunity, and it’s healthy that they do. Until folks in Italy are really willing to buy computers with Linux pre-installed, there will not be a real market for them. I’m sure there are local providers who build good computers who will pre-install Ubuntu for you. You need to help them become big enough that the Dell’s and HP’s and Lenovo’s of the world are confident there is an opportunity that is worthwhile for them.

12) What is your point of view about the the Novell-Microsoft controversial deal?
There are some good intentions, and there are some bad intentions, and unfortunately they are all mixed up in that deal. On the positive side, it’s good to see Microsoft acknowledge the need for both Linux and Windows, and the need for interoperability. On the negative side, the deal only works financially because Novell and Microsoft have the same business model – licensing software for a certain price per seat.

Microsoft is in an awkward position. They very much want to stop the free use of Linux, and they would like to use patents to do so, which is why they structured the deal as a notional “IP license”. But they also know that free software engineers could probably avoid any patents they raise, so they have been unwilling to state which patents they think justify such a deal.

13) In a interview (http://mybroadband.co.za/nephp/?m=show&id=6672) you declared that “you’d love to work with Microsoft”. Do you want to make another deal following the Novell one or what?
I am very happy to work with Microsoft, or any other company, to improve the state of free software and the software industry as a whole. There are many things that we can collaborate on where we have shared interests – encouraging good telecommunications policy, for example.

But I will not agree to a deal like the Novell one, because I don’t think there is any IP issue in fact, and until Microsoft actually states what patents it is concerned about there is no need for us to take any action. Unfortunately for Novell, I think they have done a deal which gives them a short-term boost, at a very high long term cost. Time will tell.

14) And what do you think about the OOXML standard and the Microsoft Open Promise?
I don’t believe that ISO’s declaration of OOXML as a standard will actually deliver any benefit to users of Microsoft Office. They will still be using a big, bloated piece of software with no competition, that is not-quite-standards-compliant. That’s a pity. Microsoft’s customers had an opportunity to ignite real innovation in the office document space, by encouraging Microsoft to support and existing, open, well-defined document standard in ODF. But they didn’t – Microsoft managed to push enough partners and resellers into the standards process that the ISO decision did not really reflect anything other than Microsoft’s commercial interests.

15) We’re getting a GNU/Linux ultramobile-lowcost-laptop everyday. What do you think about Eee PC Linux revolution?
I think they are great!

16) Acer, HP, MSI, Asus and much more want to join the Linux-powered UMPC market. Are you making some deals to port Ubuntu on some of these laptop?
Lots of people are installing Ubuntu onto their UMPC’s, so I think it’s reasonable that some manufacturers may choose to pre-install it. It’s their decision! If you think that would be popular, then it would probably be worth encouraging them to do so.

17) A lot of analysts talks about a GNU/Linux conquer on mobile market in the next few years. From smartphone to UMPC: the future is Linux. Can you talk about Ubuntu Mobile, its concept, the present and the future?
Yes! Intel is driving a project called Moblin, which aims to produce a mobile software platform for handheld devices, and we’re basing Ubuntu Mobile on that. The first versions are out already, and the roadmap looks very exciting.

Traditionally, it was very expensive to produce software for consumer electronic devices, because they were all specialised hardware with specialised operating systems and application development environments. We are aiming to change that – to make it so that you can build a simple .deb on x86 which can be installed on any piece of consumer electronics that uses this platform. That should greatly increase the amount of innovation we see in the mobile space.

18) What do you think about your competitors? Fedora/Red Hat, openSUSE and Mandriva are doing good work as well as Ubuntu. What GNU/Linux distribution do you prefer if you couldn’t use Ubuntu?
Yes, all of the distributions make contributions to the art and industry of free software. I’m very glad that lots of companies continue to invest in Linux, it makes it a much healthier and more vibrant ecosystem than it would be if just one company dominated it. So I’m very happy with the competition. If Ubuntu didn’t exist, I would use Debian.

19) And what is your feeling about the latest Sun acquisition (MySQL)? Are you working with Sun to port the OpenJDK on Ubuntu?
MySQL is a great company and a very good fit for Sun. I hope they are happy together and that the company will continue to produce a superb free software database.

Yes, OpenJDK is part of Ubuntu 8.04 (though it is not yet at the core, and not yet the default Java environment). We hope to have 8.04 LTS fully TCK-certified in due course. And most of all we are grateful to the Sun folks for letting us package OpenJDK as a proper Ubuntu package, neatly integrated with the rest of the OS. We are aiming for a result which feels “all Java, all Ubuntu”, and I would encourage your users to try it out! Make sure “universe” is enabled on your Ubuntu machine, then type “sudo apt-get install openjdk-6-jdk”.

20) What are the next Canonical plans? Are there any interesting initiatives in progress?
Of course, but this is not the right place for a press release

21) Finally, do you think that GNU/Linux is “really” ready for the desktop users? In which way could be improved?
Yes, I believe it is ready for SOME desktop users. If you really want a desktop that is web-oriented, then Linux is an excellent choice, with either Gnome or KDE (I’m really impressed with the work going on as part of KDE4, by the way). We know that there are millions of people using Linux today. And we are focused on solving the problems that prevent more and more people from adopting it.

Free software is intrinsically a better way to build software, I believe. But we should not plan to be judged on our morals, we should expect to be judged on our software. We have to deliver something that LOOKS and FEELS better, then we can expect people to embrace it fully. And once people realise they can have something that is better AND sustainable AND comes with many freedoms, the world will be a fundamentally different place. That is our goal.

22) Our interview seems to be completed. Do you have something to add for our readers? Thank you for your time and keep up the excellent work!
Please participate! There are lots of ways to get involved with upstream projects or with Ubuntu. Help spread the word, or fix a bug, or translate something from the desktop into Italian!

There are some very cool launchers out there - AWN is a current favourite of mine - but people seem to prefer the more 2-dimensional tabbed approach, so the OEM team implemented a lightweight but still very classy launcher for this use case. The work received a detailed review in Ars Technica and has been covered in Free Software Magazine and elsewhere.

The aim was to do something very simple that could be tested easily, work with touch devices and made shippable very quickly. It also needed to be efficient on lower-power devices, and work well with Intel hardware, which seems to be the preferred platform for this generation of devices and allows us to slip a few nice effects in that would be hard without the right hardware support. Here’s a screenshot of a recent version:

The new launcher is free software - so far, everything Canonical has funded, written and published for general public use on Ubuntu has been under the GPL. Currently we use GPLv3. You can grab the relevant packages from a public PPA, just add the following entry to your /etc/apt/sources.list:

deb http://ppa.launchpad.net/netbook-remix-team/ubuntu hardy main


The PPA contains a number of packages for the launcher, some GNOME panel applets, window manager tweaks and themes. These bits and pieces are small but improve the experience of Ubuntu run with the netbook launcher on screens with lower vertical resolution. There’s also some code in there specific to the Intel netbook hardware platforms, don’t install ume-config-netbook unless you are on the right hardware! This is all code produced by Canonical and published on Launchpad under free software licenses:

https://launchpad.net/netbook-remix
https://launchpad.net/netbook-remix-launcher

I’m particularly happy with the way it gives you more screen space for web browsing, which is probably the major use case on these form factors:

There are still plenty of interesting corner cases, Ars calls out issues with the GiMP’s palettes, for example, so please do take the opportunity to test it with the apps you think you’d run on a small laptop (or as El Reg would say, laptot).  And feel free to push up and submit for inclusion a branch or two if you’re up to a bit of Clutter hackery!

For the rest, the netbook remix uses standard ubuntu packages from the standard ubuntu archive, with standard security updates. So it meets all of our usual commitments around security and compatibility. You can recreate the netbook remix just by installing 8.04, adding the PPA to your list of repositories, fetching the packages and configuring them appropriately for your system.

The netbook remix is not part of the “official Ubuntu editions”, it’s not like Kubuntu or Ubuntu or Ubuntu Server. It’s a separate remix published by the Canonical OEM team. It will probably get revved in October when Ubuntu 8.10 is released, but that’s up to the Canonical OEM team and their customers, and not the responsibility of the Ubuntu project team.

In working with manufacturers, the OEM team creates custom install images which are specific to hardware from those OEM’s. They have the free software packages I’ve described, and they may also include third-party software selected by OEM’s which Canonical cannot redistribute, so we can’t publish the custom installers that are produced under contract. Those images typically are hand-customised for a faster boot time, which means they will only work on the particular device for which they were intended, unlike standard Ubuntu which should auto-detect and configure itself for whatever hardware it is being booted on.

We specifically wanted to do this project as an Ubuntu Remix - based on standard Ubuntu 8.04 packages, with modified package selection and some additional code, but leaving the core platform packages unmodified. In terms of the trademark guidelines for an Ubuntu Remix companies cannot call their platform Ubuntu if they have modified packages (especially the kernel and desktop packages) but they can if they are just re-arranging standard Ubuntu packages. Canonical is in a privileged position as the Ubuntu trademark owner - we can certify a custom kernel if we believe it has been done in an appropriate way that won’t conflict with standard Ubuntu maintenance processes, and if we can keep the custom kernel up to date to the same standard as the normal Ubuntu kernel. So these are certified Ubuntu devices from Canonical, even though they are more customized than other people can within the Remix guidelines.

We’re also working with two companies that want more radical user interface innovation. Canonical is participating directly in the design and implementation of one of those UI’s, and we’re integrating someone else’s UI on an Ubuntu base for the second project. I haven’t seen either of those UI’s, for confidentiality reasons, but I’m told that the teams working on them think they have great ideas that will elevate, in different ways, the state of the art. All in all it will be exciting to see how the netbook era stimulates innovation in the Linux user experience, because there are a lot of companies wanting to build differentiated UI’s on a standard Linux base. And directly or indirectly Canonical will help to bring that innovation to KDE and GNOME and hence to the wider Linux ecosystem.

Robert Knight summarized the arguments I made during a keynote at aKademy last year. I’m really delighted by the recent announcement of that the main GNOME and KDE annual developer conferences (GUADEC and aKademy) will be held at the same time, and in the same place, in 2009. This is an important step towards even better collaboration. Initiatives like FreeDesktop.org have helped tremendously in recent years, and a shared conference venue will accelerate that process of bringing the best ideas to the front across both projects. Getting all of the passionate and committed developers from both of these into the same real-space will pay dividends for both projects.

Aaron Seigo of KDE Plasma has taken a strong position against synchronized release cycles, and his three recent posts on the subject make interesting reading.

Aaron raises concerns about features being “punted” out of a release in order to stick to the release cycle. It’s absolutely true that discipline about “what gets in” is essential in order to maintain a commitment on the release front. It’s unfortunate that features don’t always happen on the schedule we hope they might. But it’s worth thinking a little bit about the importance of a specific feature versus the whole release. When a release happens on time, it builds confidence in the project, and injects a round of fresh testing, publicity, enthusiasm and of course bug reports. Code that is new gets a real kicking, and improves as a result. Free software projects are not like proprietary projects - they don’t have to ship new releases in order to get the money from new licenses and upgrades.  We can choose to slip a particular feature in order to get a new round of testing and feedback on all the code which did make it.

Some developers are passionate about specific features, others are passionate about the project as a whole. There are two specific technologies, or rather methodologies, that have hugely helped to separate those two and empower them both. They are very-good-branching VCS, and test-driven development (TDD).

We have found that the developers who are really focused on a specific feature tend to work on that feature in a branch (or collaborative set of branches), improving it “until it is done” regardless of the project release cycle. They then land the feature as a whole, usually after some review. This of course depends on having a VCS that supports branching and merging very well. You need to be able to merge from trunk continuously, so that your feature branch is always mergeable *back* to trunk. And you need to be able to merge between a number of developers all working on the same features. Of course, my oft-stated preference in VCS is Bazaar, because the developers have thought very carefully about how to support collaborative teams across platforms and projects and different workflows, but any VCS, even a centralised one, that supports good branches will do.

A comprehensive test suite, on the other hand, lets you be more open to big landings on trunk, because you know that the tests protect the functionality that people had *before* the landing. A test suite is like a force-field, protecting the integrity of code that was known to behave in a particular way yesterday, in the face of constant change. Most of the projects I’m funding now have adopted a tests-before-landings approach, where landings are trunk are handled by a robot who refuses to commit the landing unless all tests passed. You can’t argue with the robot! The beauty of this is that your trunk is “always releasable”. That’s not *entirely* true, you always want to do a little more QA before you push bits out the door, but you have the wonderful assurance that the test suite is always passing. Always.

So, branch-friendly VCS’s and test-driven development make all the difference.  Work on your feature till it’s done, then land it on the trunk during the open window. For folks who care about the release, the freeze window can be much narrower if you have great tests.

There’s a lot of discussion about the exact length of cycle that is “optimal”, with some commentary about the windows of development, freeze, QA and so on.  I think that’s a bit of a red herring, when you factor in good branching, because feature development absolutely does not stop when the trunk is frozen in preparation for a release. Those who prefer to keep committing to their branches do so, they scratch the itch that matters most to them.

I do think that cycle lengths matter, though. Aaron speculates that a 4-month cycle might be good for a web site. I agree, and we’ve converged on a 4-month planning cycle for Launchpad after a few variations on the theme. The key difference for me with a web site is that one has only one deployment point of the code in question, so you don’t have to worry as much about update and cross-version compatibility. The Launchpad team has a very cool system, where they roll out fresh code from trunk every day to a set of app servers (called “edge.launchpad.net”), and the beta testers of LP use those servers by default. Once a month, they roll out a fresh drop from tip to all the app servers, which is also when they rev the database and can introduce substantial new features. It’s tight, but it does give the project a lot of rhythm. And we plan in “sets of 4 months”, at least, we are for the next cycle. The last planning cycle was 9 months, which was just way too long.

I think the cycles-within-cycles idea is neat. Aaron talks about how 6 months is too long for quick releases, and too short to avoid having to bump features from one cycle to the next. I’ve already said that a willingness to bump a feature that is not ready is a strength and not a weakness. It would be interesting to see if the Plasma team adopted a shorter “internal” cycle, like 2 months or 3 months, and fit that into a 6 month “external” cycle, whether Aaron’s concerns were addressed.

For large projects, the fact that a year comes around every, well, year, turns out to be quite significant. You really want a cycle that divides neatly into a year, because a lot of external events are going to happen on that basis. And you want some cohesion between the parts. We used to run the Canonical sprints on a 4-month cycle (3 times a year) and the Ubuntu releases on a six month cycle (twice a year) and it was excessively complex. As soon as we all knew each other well enough not to need to meet up every 4 months, we aligned the two and it’s been much smoother ever since.

Some folks feel that distributions aren’t an important factor in choosing an upstream release cycle. And to a certain extent that’s true. There will always be a “next” release of whatever distribution you care about, and hopefully, an upstream release that misses “this” release will make it into the next one. But I think that misses the benefit of getting your work to a wider audience as fast as possible. There’s a great project management methodology called “lean”, which we’ve been working with. And it says that any time that the product of your work sits waiting for someone else to do something, is “waste”. You could have done that work later, and done something else before that generated results sooner. This is based on the amazing results seen in real-world production lines, like cars and electronics.

So while it’s certainly true that you could put out a release that misses the “wave” of distribution releases, but catches the next wave in six months time, you’re missing out on all the bug reports and patches and other opportunities for learning and improvement that would have come if you’d been on the first wave. Nothing morally wrong with that, and there may be other things that are more important for sure, but it’s worth considering, nonetheless.

Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true. I think it’s a much more productive approach for the whole free software ecosystem, and will help us compete with the proprietary world. That’s good for everyone. And it’s not just Ubuntu that does regular 6-month releases, Fedora has adopted the same cycle, which is great because it improves the opportunities to collaborate across both distributions - we’re more likely to have the same versions of key components at any given time.

Aaron says:

Let’s assume project A depends on B, and B releases at the same time as A. That means that A is either going to be one cycle behind B in using what B provides, or will have to track B’s bleeding edge for the latter part of their cycle allowing some usage. What you really want is a staggered approach where B releases right about when A starts to work on things.

This goes completely counter to the “everyone on the same month, every 6 months” doctrine Mark preaches, of course.

I have never suggested that *everyone* should release at the same time. In fact, at Ubuntu we have converged around the idea of releasing about one month *after* our biggest predictable upstream, which happens to be GNOME. And similarly, the fact that the kernel has their own relatively predictable cycle is very useful. We don’t release Ubuntu on the same day as a kernel release that we will ship, of course, but we are able to plan and communicate meaningfully with the folks at kernel.org as to which version makes sense for us to collaborate around.

Rather than try and release the entire stack all at the same time, it makes sense to me to offset the releases based on a rough sense of dependencies.

Just to be clear, I’m not asking the projects I’ll mention below to change anything, I’m painting a picture or a scenario for the purposes of the discussion. Each project should find their own pace and scratch their itch in whatever way makes them happiest. I think there are strong itch-scratching benefits to syncronicity, however, so I’ll sketch out a scenario.

Imagine we aimed to have three waves of releases, about a month apart.

In the first wave, we’d have the kernel, toolchain, languages and system libraries, and possibly components which are performance- and security-critical. Linux, GCC, Python, Java, Apache, Tomcat… these are items which likely need the most stabilisation and testing before they ship to the innocent, and they are also pieces which need to be relatively static so that other pieces can settle down themselves. I might also include things like Gtk in there.

In the second wave, we’d have applications, the desktop environments and other utilities. AbiWord and KOffice, Gnumeric and possibly even Firefox (though some would say Firefox is a kernel and window manager so… ;-)).

And in the third wave, we’d have the distributions - Ubuntu, Fedora, Gentoo, possibly Debian, OpenSolaris. The aim would be to encourage as much collaboration and discussion around component versions in the distributions, so that they can effectively exchange information and patches and bug reports.

I’ll continue to feel strongly that there is value to projects in getting their code to a wider audience than those who will check it out of VCS-du-jour, keep it up to date and build it. And the distributions are the best way to get your code… distributed! So the fact that both Fedora and Ubuntu have converged on a rhythm bodes very well for upstreams who can take advantage of that to get wider testing, more often, earlier after their releases. I know every project will do what suits it, and I hope that projects will feel it suits them to get their code onto servers and desktops faster so that the bug fixes can come faster, too.

Stepping back from the six month view, it’s clear that there’s a slower rhythm of “enterprise”, “LTS” or “major” releases. These are the ones that people end up supporting for years and years. They are also the ones that hardware vendors want to write drivers for, more often than not. And a big problem for them is still “which version of X, kernel, libC, GCC” etc should we support? If the distributions can articulate, both to upstreams and to the rest of the ecosystem, some clear guidance in that regard then I have every reason to believe people would respond to it appropriates. I’ve talked with kernel developers who have said they would LOVE to know which kernel version is going to turn into RHEL or an Ubuntu LTS release, and ideally, they would LOVE it if those were the same versions, because it would enable them to plan their own work accordingly. So let’s do it!

Finally, in the comments on Russell Coker’s thoughtful commentary there’s a suggestion that I really like - that it’s coordinated freeze dates more than coordinated release dates that would make all the difference. Different distributions do take different views on how they integrate, test and deploy new code, and fixing the release dates suggests a reduction in the flexibility that they would have to position themselves differently. I think this is a great point. I’m primarily focused on creating a pulse in the free software community, and encouraging more collaboration. If an Ubuntu LTS release, and a Debian release, and a RHEL release, used the same major kernel version, GCC version and X version, we would be able to improve greatly ALL of their support for today’s hardware. They still wouldn’t ship on the same date, but they would all be better off than they would be going it alone. And the broader ecosystem would feel that an investment in code targeting those key versions would be justified much more easily.

As a result, we can commit that the next LTS release of Ubuntu will be 10.04 LTS, in April 2010.

This represents one of the most extraordinary, and to me somewhat unexpected, benefits of free software to those who deploy it. Most people would assume that precise release management would depend on having total control of all the moving parts - and hence only be possible in a proprietary setting. Microsoft writes (almost) every line of code in Windows, so you would think they would be able to set, and hit, a precise target date for delivery. But in fact the reverse is true -  free software distributions or OSV’s can provide much better assurances with regard to delivery dates than proprietary OSV’s, because we can focus on the critical role of component selection, integration, testing, patch management and distribution rather than the pieces which upstream projects are better able to handle - core component feature development. This is in my mind a very compelling reason for distributions to focus on distribution - that’s the one thing they do which the upstreams don’t, so they need to invest heavily in that in order to serve as the most efficient conduit of upstream’s work.

We also committed, for the first time, to a regular set of point releases for 8.04 LTS. These will start three months after the LTS, and be repeated every six months until the next LTS is out. These point releases will include support for new hardware as well as rolling up all the updates published in that series to date. So a fresh install of a point release will work on newer hardware and will also not require a big download of additional updates.

Gerry Carr at Canonical put together this diagram which describes the release management plan very nicely:

The Ubuntu team does an amazing job of ensuring that one can update from release to release, and from LTS release to LTS release directly, too. I’m very proud to be part of this community! With the addition of some capability to support newer hardware in LTS releases, I think we are doing our part in the free software community - helping to deliver the excellent work of thousands of other teams, from kernel.org to GNOME and KDE, safely to a huge audience.

There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that. I think the benefits of this sort of alignment to users, upstreams and the distributions themselves would be enormous. I’ll write more about this idea in due course, for now let’s just call it my dream of true free software syncronicity.

I’m very conscious of the fact that Ubuntu is the pointy edge of a very large wedge - we are the conduit, but we exist only because of the extraordinary dedication and effort of thousands of other communities and projects. We all owe a great deal to the team who make Debian’s “unstable” repository possible, and of course to the upstream projects from GNOME and KDE through to the Linux kernel. We hope you will be proud of the condition in which we have carried your excellent work through to the users of Ubuntu.

So, well done everybody! I hope that friends, family, colleagues and others will have the opportunity to try it out and understand why we have all devoted so much to this project. Our work is deeply important - we are helping to bring free software to a new level of acceptance and adoption in the wider world.  Ubuntu’s success adds to the success of free software. So as much as it is fun, challenging, the opportunity of a lifetime, a profession for some and a passion for others, it’s also changing the world. I don’t exactly want to shout “Save the Cheerleader, Save the World” but to me you are all Heroes.

Mark

Firefox, for example, is an inspiring free software success story, and I’m certain that a key driver of that success is their excellent support for the Windows environment. It’s a quick download and an easy install that Just Works, after which people can actually FEEL that free software delivers an innovative and powerful browsing experience that is plainly better than the proprietary alternatives. I’ve noticed that many of the best free software projects have a good Windows story. MySQL and PostgreSQL both do. Bazaar works well too. And users love it - users that may then be willing to take a step closer to living in the GNU world entirely.

So, I was absolutely delighted with the way Agostino Russo and Evan Dandrea steered the Windows-native installer for Ubuntu into 8.04 LTS. What I think is really classy about it is the way it uses the Windows Boot Manager sensibly to offer you the Ubuntu option. If I was a Windows user who was intrigued but nervous about Linux, this would be a really great way to get a taste of it, at low risk. Being able to install and uninstall a Linux OS as if it were a Windows app is a brilliant innovation. Kudos to Agostino and Evan, and of course also to the guys who pioneered this sort of thinking (it’s been done in a number of different ways). It looks crisp, clean and very professional:

I’m a little daunted at something as new as WUBI being the very first experience that people have of Linux, free software and Ubuntu, but initial reports are positive.  I did have a question from the media that started with “it didn’t work for me but…” which makes me a wee bit nervous.

So - yesterday I suggested folks hammer on the Heron for servers, today, here’s a call for folks who have a Windows machine and would like to see WUBI in action to test it out and let the developers know if there are any last-minute gotchas. Happy hunting!

The coolest part of the firewall upgrade is the fact that Michael has made the release upgrade tool independent of the GUI, so you can use it for server upgrades too.

So, now would be a great time to test the upgrade! File bugs if you run into any issues with your particular configuration. Apparently, this is upported on both Ubuntu 6.06 LTS (Dapper) and Ubuntu 7.10 (Gutsy), so feedback on either upgrade path would be most welcome.

sudo aptitude install update-manager-core

That should make sure you have the release upgrade tool installed. Now you can trigger the upgrade process to the current beta:

sudo do-release-upgrade --devel-release

This should fetch the latest version of the update tool, which knows about various transitions in library versions etc so that it can attempt to update your machine smoothly without leaving large amounts of dangling packages. You can say “no” if you don’t like the proposed package install and removal plan (in which case, your feedback would be very valuable!).

For fresh installs, 8.04 LTS should be good to go on any high-volume server platform available in the market today - let the server team know if you run into any problems at all. They are hoping to meet the desktop team’s “Just Works” standard, so the bar is set pretty high. From my perspective, the upgrade was smooth - full marks and my thanks to everyone involved.