Quantal, raring, saucy…

Friday, October 18th, 2013

Before I launch into the tongue-twisting topic of t-series terminology I would like to say a few thank-you’s.

Saucy, now officially known as Ubuntu 13.10, is a wonderful achievement by a very large and diverse collection of teams and individuals. Each of us is motivated by something different – in fact, we might have very different visions of what the ideal desktop looks like or what the default set of applications should be. But we manage, in the spirit of ubuntu, to work together to make something wonderful like 13.10, which serves the needs and goals of a very large number of people and communities.

This release had plenty to put it under pressure. It’s the preview-LTS, in a sense, which means we need to get a lot of the “big rocks” in. That means a willingness to lead change, and doing so in such a complex inter-dependent environment is very challenging. I would like to thank all the teams who have done their part to shape that change into something that worked for them. To the KDE, XFCE and GNOME-focused communities in Ubuntu, thank you for bringing your perspective and I’m delighted that you are all making such great releases now as well.

13.10 is a very special release for me because I think we are leading the GNU/Linux world into a very important arena, which is mobile personal computing. Canonical has its fair share of competitors and detractors who love to undermine the work it does, but I think that wiser heads appreciate the magnitude of the effort required to break this ice, and the extent to which it has taken courage and grace under fire for this team to deliver such a sharp 1.0 of the mobile experience for Ubuntu. It is a reflection of the widespread interest and enthusiasm for that work that we had such diverse participation in the core applications that make up this 1.0 of Ubuntu-for-phones. Multiple teams formed spontaneously to explore new territory: a new mobile design paradigm, new SDK, new visual language. And wow, you guys pulled it off beautifully.  So many contributions from a fresh free software community is testament to the work and style of guys like Michael Hall, who epitomise collaborative development and friendly exchanges of views, motivating guys like me and a hundred others to make sure we deliver something great.

Designers, shell engineers, browser engineers, app engineers, people who built app review and publication mechanisms, security experts… I could not be more proud of what these teams have achieved together.

For the technologists there are some very significant milestones, what Rick Spencer calls “the big rocks”, that made it into 13.10.

Image based updates is really important work. For the first time we can guarantee the integrity of a device running Ubuntu, knowing exactly what version of the OS is installed. I can’t wait to get that on my laptop. Yes, it will be a big change, but I can already see how it’s going to make things easier for me. And I’ll still have the full power of raw Ubuntu inside for all my cloud development needs. Well done to the guys who conceived and delivered the mechanism and the machinery that make it possible. Image 100 is, as they say, the cake.

Mir is really important work. When lots of competitors attack a project on purely political grounds, you have to wonder what THEIR agenda is. At least we know now who belongs to the Open Source Tea Party ;) And to put all the hue and cry into context: Mir is relevant for approximately 1% of all developers, just those who think about shell development. Every app developer will consume Mir through their toolkit. By contrast, those same outraged individuals have NIH’d just about every important piece of the stack they can get their hands on… most notably SystemD, which is hugely invasive and hardly justified. Watch closely to see how competitors to Canonical torture the English language in their efforts to justify how those toolkits should support Windows but not Mir. But we’ll get it done, and it will be amazing.

I can tell you what the agenda of the Mir team is: speed, quality, reliability, efficiency. That’s it. From what I’ve seen on the smartphone, Mir is going to be a huge leap forward for gaming performance, battery life and next-generation display capabilities. So thank you for the many contributions we had to Mir, and to everyone who is testing it in more challenging environments than the smartphone. I’m enjoying it on my laptop and loving the gaming benchmarks for native Mir. So to that team, and the broader community who are helping test and refine Mir, thank you.

App containers and the associated mechanisms for application update are hugely important too. We now have a much better way for app developers to deliver an app to Ubuntu users, giving them much more control of the libraries and dependencies and updates that will affect them. We also make it much easier for developers to deliver newer versions of their app on older versions of the OS. I know that’s a top ask for many of our users, and we’ve done it for the smartphone. It will be available for the desktop as soon as we converge the two. I love seeing those app updates flow onto the phone, and I’m told the developer review and publication process is really sweet. Well done.

So yes, I am very proud to be, as the Register puts it, the Ubuntu Daddy. My affection for this community in its broadest sense – from Mint to our cloud developer audience, and all the teams at Canonical and in each of our derivatives, is very tangible today. It’s had its ups and downs this cycle :) but I feel we’ve pulled together. What the Register misses in that description is that so many of you are in fact the progenitors of Ubuntu’s goodness. Its a privilege to provide the conduit, but the generosity of all of you in making something wonderful to share through that conduit is what’s most touching.

So – saucy is in the can, and it’s time to turn our tactical talk to 14.04, which will of course be an LTS.

As such, our focus is going to be on performance, refinement, maintainability, technical debt. It would be entirely appropriate for us to make conservative choices in this upcoming vUDS, so please join us in those discussions as we shape 14.04 as a platform for long-term deployments on the PC and the cloud and the server. In particular, we will be providing OpenStack I, J and K on 14.04 for LTS deployments, so we need to make sure we meet the needs of that community for a solid core. On the desktop, 13.10 has benefited greatly from the fact that it has a team just focused on improving quality. We’ll do the same again and more for 14.04. On the mobile front, we’re going to keep racing forward, the platform is too new for an LTS and we’re excited to complete the journey of full convergence. We won’t get there in one cycle but given the pace of improvement of the phone and tablet in the last month I think it’s going to be a fantastic cycle there.

vUDS is where those core decisions are made. We’ve broken new ground on public consultation and discussion: anyone can participate by voice or video, discussions are fast and open-minded, results are communicated in the same week. It’s worth taking time out from work, play or sleep to bring your perspective to bear on what 14.04 needs to deliver, and what commitments you want to make to achieve that.

But… what will we call it? As TS Eliot put it, “the naming of cats is a difficult matter, it isn’t just one of your everyday games…”

It’s no trifling matter to tap the well of tempting tautological taxa in search of just the right mascot for something like 14.04. So many bad options! There’s the “tasty tailless tenrec” (wait for the letters from PETA), the “toxic taipan” (hello again my Aussie mates), and the  “tantric tarantula” (hold very still…). The “trigamous tayra” (bendy!) and “trippy tegu” just won’t do. We need something a bit more serious than the “twinkle-toed tamarin”, something a bit more transcendent than the the “toric terrapin”, a bit more thematic than the “thermic tamandua” (though I do like the reference to HEAT, something new in the OpenStack world) and a bit cooler than the “thermobaric thornytail”. There are quite a few good options too… Consider the “timely testudo”, that famous winning tortoise, or the “tenacious tapir” who always gets the job done, those might do. And who could resist the “telegenic tamias” other than, perhaps, the developers who have to type “telegenic” every time they make an upload!

Themes therianthropic seem a touch tub-thumping, and tigers Tasman a touch extinct. That tarsier is tactile but titchy too, the toad a bit witchy the the tree shrew, too-too. For a tip-top release nothing tepid will do.

So our titular totem, our tamper-proof taboo, our tranquil memento of mission and dues, our topical target of both cry and hue, the name for our LTS thoughtful and true: I give you, as Seuss would, with hullabaloo, the temperate and thrifty, the talented and tactful but ultimately, and tellingly, trusty tahr.

The tahr navigates Himalayan heights, shaggily suited, sure-footed and steady. A small tourist tahr population lived on my favourite Table Mountain, and while they’ve made way for indigenous animals, for a long time they symbolised hardiness and fearlessness, perched as they were against the cliffs. We’ll do well together. Let’s get cracking!

Two weeks with Mir

Tuesday, July 9th, 2013

Mir has been running smoothly on my laptop for two weeks now. It’s an all-Intel Dell XPS, so the driver stack on Ubuntu is very clean, but I’m nonetheless surprised that the system feels *smoother* than it did pre-Mir. It might be coincidence, Saucy is changing pretty fast and new versions of X and Compiz have both landed while I’ve had Mir running. But watching top suggests that both Xorg and Compiz are using less memory and fewer CPU cycles under Mir than they were with X handling the hardware directly.

Talking with the Mir team, they say others have seen the same thing, and they attribute it to more efficient buffering of requests on the way to the hardware. YMMV but it’s definitely worth trying. I have one glitch which catches me out – Chromium triggers an issue in the graphics stack which freezes the display. Pressing Alt-F1 unfreezes it (it causes Compiz to invoke something which twiddles the right bits to bring the GPU back from it’s daze). I’m told that will get sorted trivially in a coming update to the PPA.

The overall impression I have is that Mir has delivered what we hoped. Perhaps it had the advantage of being able to study what went before – SurfaceFlinger, Wayland, X – and perhaps also the advantage of looking at things through the perspective of a mobile lens, where performance and efficiency are a primary concern, but regardless, it’s lean, efficient, high quality and brings benefits even when running a legacy X stack.

We take a lot of flack for every decision we make in Ubuntu, because so many people are affected. But I remind the team – failure to act when action is needed is as much a failure as taking the wrong kind of action might be. We have a responsibility to our users to explore difficult territory. Many difficult choices in the past are the bedrock of our usefulness to a very wide audience today.

Building a graphics stack is not a decision made lightly – it’s not an afternoon’s hacking. The decision was taken based on a careful consideration of technical factors. We need a graphics stack that works reliably across a very wide range of hardware, that performs predictably, that provides a consistent quality of user experience on many different desktop environments.

Of course, there is competition out there, which we think is healthy. I believe Mir will be able to evolve faster than the competition, in part because of the key differences and choices made now. For example, rather than a rigid protocol that can only be extended, Mir provides an API. The implementation of that API can evolve over time for better performance, while it’s difficult to do the same if you are speaking a fixed protocol. We saw with X how awkward life becomes when you have a fixed legacy protocol and negotiate over extensions which themselves might be versioned. Others have articulated the technical rationale for the Mir approach better than I can, read what they have to say if you’re interested in the ways in which Mir is different, the lessons learned from other stacks, and the benefits we see from the architecture of Mir.

Providing Mir as an option is easy. Mir is a very focused part of the stack, it has far fewer tentacles and knock-on consequences for app developers than, say, the init system, which means we should be able to work with a very tight group of communities to get great performance. It’s much easier for a distro to engage with Mir than to move to SystemD, for example; instead of an impact on every package, there is a need to coordinate in just a few packages for great results. We’ve had a very positive experience working with the Qt and WebKit communities, for example, so we know those apps will absolutely fly and talk Mir natively. Good upstreams want their code widely useful, so I’ve no doubt that the relevant toolkits will take patches that provide enhanced capabilities on Mir when available. And we also know that we can deliver a high-performance X stack on Mir, which means any application that talks X, or any desktop environment that talks X, will perform just as well with Mir, and have smoother transitions in and out thanks to the system compositor capabilities that Mir provides.

On Ubuntu, we’re committed that every desktop environment perform well with Mir, either under X or directly. We didn’t press the ‘GO’ button on Mir until we were satisfied that the whole Ubuntu community, and other distributions, could easily benefit from the advantages of a leaner, cleaner graphics stack. We’re busy optimising performance for X now so that every app and every desktop environment will work really well in 13.10 under Mir, without having to make any changes. And we’re taking patches from people who want Mir to support capabilities they need for native, super-fast Mir access. Distributions should be able to provide Mir as an option for their users to experiment with very easily – the patch to X is very small (less than 500 lines). For now, if you want to try it, the easiest way to do so is via the Ubuntu PPA. It will land in 13.10 just as soon as our QA and release teams are happy that its ready for very widespread testing.

Very briefly – had an excellent show at Mobile Asia Expo. Very valuable feedback from carrier partners on our progress with Ubuntu’s mobile experience and ecosystem. And just heard that a US operator has joined our advisory group – alongside recent additions from Indonesia and Australia. So that means we have partners who cover parts of Asia, most of Europe, North  and South America. I’d like to get a perspective from Japan and Africa in the mix, then I think we can close the CAG as we’d rather have fewer, deeper conversations.

Nevertheless, those of you in the US will be very happy to know you are now represented in the Carrier Advisory Group!

Here comes the Carrier Advisory Group

Tuesday, June 18th, 2013

Last week we held the first meeting of the new Ubuntu Carrier Advisory Group, which helps us figure out how best to shape Ubuntu to meet the needs of the mobile industry.

It was very exciting!

We mapped out our approach to the key question I’ve been asked by every carrier we’ve met so far: how can we accommodate differentiation, without fragmenting the platform for developers? We described the range of diversity we think we can support initially, received some initial feedback from carriers participating immediately, and I’m looking forward to the distilled feedback we’ll get on the topic in the next call.

CAG members get a period of exclusivity in their markets. We’ll close the CAG to new members shortly.  We don’t need a very large group; just a few clear-thinking and thoughtful partners who have experience introducing new platforms. And with this initial group of members, we are all set to get really good insight for a really great launch next year.

Next week I’ll be in Shanghai for the GSMA’s Mobile Asia Expo, and looking forward to a round of in-person meetings with our advisory group. Mostly we’ll be meeting by telephone and video conference, given the very global nature of the CAG, but there are a few events which attract critical mass of attendees in the industry where we’ll arrange a CAG face-to-face as well.

Thanks to everyone who is participating in the project – Ubuntu’s touch experience is really coming along in leaps and bounds. I love hearing about the new devices to which it’s been ported, or new apps getting started. This is the frontier for personal computing, and we want free software leading the way. You all make that possible.

Congratulations and thanks to the entire extended Ubuntu community for today’s release of Ubuntu 13.04, the Raring Ringtail. Feedback over the past few months on raring has been fantastic – pretty much universal recognition of the performance and quality initiatives Rick’s team have led and which have been embraced across the platform and the community.

In the work to underpin a rolling release, we made huge strides in automated quality assessment and performance testing. From here on out, I’m going to treat the cutting edge of Ubuntu as a rolling release, because the team have done such an amazing job of making daily quality a reality. That’s a value that we have all adopted, and the project is much better off for it.

Slipping the phrase ‘ring ring’ into the codename of 13.04 was, frankly, a triumph of linguistic engineering. And I thought I might quit on a high… For a while, there was the distinct possibility that Rick’s Rolling Release Rodeo would absolve me of the  twice-annual rite of composition that goes into the naming of a new release. That, together with the extent of my travels these past few months, have left me a little short in the research department. I usually spend a few weekend afternoons doodling with a dictionary (it’s actually quite a blast, and I recently had the pleasure of actually knowing what some ponce was talking about when they described something as ‘rugose’).

So today I find myself somewhat short in the naming department, which is to say, I have a name, but not the soliloquy that usually goes with it!

Which is why, upon not very deep reflection, I would like to introduce you to our mascot for the next six months, the saucy salamander.

The salamander is one of nature’s most magical creatures; they are a strong indicator of a pristine environment, which is a fitting way to describe the new world emerging around Ubuntu Touch – new applications, a new SDK, a gorgeous clean interface. You’ll find salamanders swimming in clear, clean upstreams – which is exactly what’s forming around Ubuntu’s mobile ecosystem. It’s a way of saying ‘thank you’ to the tremendous community that has joined the effort to create a single unified experience from phone to PC, with tons of crisp and stylish core apps made by people from all over the world who want to build something fast, fresh and free. And we’re saucy too – life’s too short to be stodgy or stilted. Our work is our play – we make amazing things for a huge audience, we find space for pretty much every flavour of interface and do it with style.

Happy release day everyone! Here’s to a super saucy cycle.

It’s been two weeks since Rick Spencer made the case for a rolling release approach in Ubuntu. Having a rolling release is one of the very top suggestions from the hardcore Ubuntu user community, and after years of it being mooted by all and sundry I thought it deserved the deep consideration that Rick and his team, who represent most of Canonical’s direct contributions to Ubuntu, brought to the analysis.

It’s obviously not helpful to have mass hysteria break out when ideas like this get floated, so I would like to thank everyone who calmly provided feedback on the proposal, and blow a fat raspberry at those of you who felt obliged to mount soapboxes and opine on The End Of the World As We Know It. Sensible people the world over will appreciate the dilemma at being asked to take user feedback seriously, and being accused of unilateralism when exploring options.

Change is warranted. If we want to deliver on our mission, we have to be willing to stare controversy in the face and do the right thing anyway, recognising that we won’t know if it’s the right thing until much later, and for most of the intervening time, friends and enemies alike will go various degrees of apoplectic. Our best defense against getting it wrong is to have a strong meritocracy, which I think we do. That means letting people like Rick, who have earned their leadership roles, explore controversial territory.

So, where do we stand? And where do I stand? What’s the next step?

What makes this conversation hard is the sheer scale of the Ubuntu ecosystem, all of which is profoundly affected by any change. Here are the things I think we need to optimise for, and the observations that I think we should structure our thinking around:

Releases are good discipline, cadence is valuable.

Releases, even interim releases, create value for parts of the Ubuntu ecosystem that are important. They allow us to get more widespread feedback on decisions made in that cycle – what’s working, what’s not working. Interestingly, in the analysis that played into Rick’s proposal, we found that very few institutional users depend on extended support of the interim releases. Those who care about support tend to use the LTS releases and LTS point releases.

Release management detracts from development time, and should be balanced against the amount of use that release gets.

While reaffirming our interest in releases, I think we established that the amount of time spend developing in a cycle versus spent doing release management is currently out of whack with the amount to which people actually DEPEND on that release management, for interim releases, on the desktop. On the server, we found that the interim releases are quite heavily used in the cloud, less so on physical metal.

Daily quality has raised the game dramatically for tip / trunk / devel users, and addresses the Rolling Release need.

There’s widespread support for the statement that ‘developers can and should use the daily development release’. The processes that have been put in place make it much more reliable for folks who want to track development, either as a contributor to Ubuntu or as someone who ships software for Ubuntu and wants to know what’s happening on the latest release, to use Ubuntu throughout the development cycle. For those of you not aware, uploads to the edge get published in a special ‘pocket’, and only moved into the edge if they don’t generate any alarms from people who are on the VERY BLEEDING EDGE. So you can use Raring (without that bleeding edge pocket) and get daily updates that are almost certain not to bork you.  There is a real community that WANTS a rolling release, and the daily development release of Ubuntu satisfies this need already.

LTS point releases are a great new enhancement to the LTS concept.

On a regular basis, the LTS release gets a point update which includes access to a new, current kernel (supporting new hardware without regressing the old hardware on the previous kernel, which remains supported), new OpenStack (via the Cloud Archive), and various other elements. I think we could build on this to enhance the LTS with newer and better versions of the core UX (Unity) as long as we don’t push those users through a major transition in the process (Unity/Qt, anybody? ;-)).

Separating platform from apps would enhance agility.

Currently, we make one giant release of the platform and ALL APPS. That means an enormous amount of interdependence, and an enormous bottleneck that depends largely on a single community to line everything up at once. If we narrowed the scope of the platform, we would raise the quality of the platform. Quite possibly, we could place the responsibility for apps on the developers that love them, giving users access to newer versions of those apps if (and only if) the development communities behind them want to do that and believe it is supportable.

Phew.

That’s what I observed from all the discussion that ensued from Rick’s proposal.

Here’s a new straw man proposal. Note – this is still just a proposal. I will ask the TB to respond to this one, since it incorporates both elements of Rick’s team’s analysis and feedback from wider circles.

Updated Ubuntu Release Management proposal

In order to go even faster as the leading free software platform, meet the needs of both our external users and internal communities (Unity, Canonical, Kubuntu, Xubuntu and many many others) and prepare for a wider role in personal computing, Ubuntu is considering:

1. Strengthening the LTS point releases.

Our end-user community will be better served by higher-quality LTS releases that get additional, contained update during the first two years of their existence (i.e. as long as they are the latest LTS). Updates to the LTS in each point release might include:

  • addition of newer kernels as options (not invalidating prior kernels). The original LTS kernel would be supported for the full duration of the LTS, interim kernels would be supported until the subsequent LTS, and the next LTS kernel would be supported on the prior LTS for teh length of that LTS too. The kernel team should provide a more detailed updated straw man proposal to the TB along these lines.
  • optional newer versions of major, fast-moving and important platform components. For example, during the life of 12.04 LTS we are providing as optional updates newer versions of OpenStack, so it is always possible to deploy 12.04 LTS with the latest OpenStack in a supported configuration, and upgrade to newer versions of OpenStack in existing clouds without upgrading from 12.04 LTS itself.
  • required upgrades to newer versions of platform components, as long as those do not break key APIs. For example, we know that the 13.04 Unity is much faster than the 12.04 Unity, and it might be possible and valuable to backport it as an update.

2. Reducing the amount of release management, and duration of support, for interim releases.

Very few end users depend on 18 months support for interim releases. The proposal is to reduce the support for interim releases to 7 months, thereby providing constant support for those who stay on the latest interim release, or any supported LTS releases. Our working assumption is that the latest interim release is used by folks who will be involved, even if tangentially, in the making of Ubuntu, and LTS releases will be used by those who purely consume it.

3. Designating the tip of development as a Rolling Release.

Building on current Daily Quality practices, to make the tip of the development release generally useful as a ‘daily driver’ for developers who want to track Ubuntu progress without taking significant risk with their primary laptop. We would ask the TB to evaluate whether it’s worth changing our archive naming and management conventions so that one release, say ‘raring’, stays the tip release so that there is no need to ‘upgrade’ when releases are actually published. We would encourage PPA developers to target the edge release, so that we don’t fragment the ‘extras’ collection across interim releases.

 

That is all.

All the faces of Ubuntu

Thursday, March 7th, 2013

Harald,

Of course what Kubuntu and Xubuntu and Ubuntu GNOME Remix et al do matters. If it didn’t, we wouldn’t invest a ton of time and energy in finding ways to share the archives effectively. And I consider it one of the lovely things about Ubuntu that there is room for all of us here. As long as there are people willing to make it happen, there’s room for a new face.

You all make the broad Ubuntu family more diverse and more interesting. For which I’m grateful.

In return, you get the benefit of an enormous and concentrated investment in making a core platform that can be widely consumed (on top of the already enormous efforts of the open source community, Debian, and any number of other groups). That investment brings with it a pace of change, and a willingness to be focused on specific outcomes. Mir, which is a fantastic piece of engineering by a very talented team that has looked hard at the problem and is motivated to do something that will work well, is just one example. Every week, we’re figuring out how to coordinate changes. Why blow a gasket over this one? I’ve absolutely no doubt that Kwin will work just fine on top of Mir. And I’m pretty confident Mir will be on a lot more devices than Wayland. Which would be good for KDE and Kubuntu and Plasma Active.

So, before you storm off, have a cup of tea and think about the gives and gets of our relationship. Seriously.

Mark

Misplaced criticism

Thursday, March 7th, 2013

Jonathan says that Canonical is not taking care of the Ubuntu community.

Consider for a minute, Jonathan, the difference between our actions.

Canonical, as one stakeholder in the Ubuntu community, is spending a large amount of energy to evaluate how its actions might impact on all the other stakeholders, and offering to do chunks of work in support of those other stakeholder needs.

You, as one stakeholder in the Ubuntu community, are inviting people to contribute less to the broader project, and more to one stakeholder.

Hmm. Just because you may not get what you want is no basis for divisive leadership.

Yes, you should figure out what’s important to Kubuntu, and yes, you should motivate folks to help you achieve those goals. But it’s simply wrong to suggest that Canonical isn’t hugely accommodating to the needs of others, or that it’s not possible to contribute or participate in the parts of Ubuntu which Canonical has a particularly strong interest in. Witness the fantastic work being done on both the system and the apps to bring Ubuntu to the phone and tablet. That may not be your cup of tea, but it’s tremendously motivating and exciting and energetic.

Not convinced by rolling releases

Thursday, March 7th, 2013

The ‘rolling release’ meme has been a popular one for years in Ubuntu. It’s one of the top requests from members of our user community. And it’s popular with Canonical team members too (who, largely, come from the community and share its values).

The problem for me is straightforward: a rolling release isn’t actually a release at all. It offers little certainty for those who need certainty. And we essentially accommodate the need for daily crack with our development releases, which have become highly usable (for developers) because of the strong commitment the Canonical and community teams made to daily quality throughout the release cycle.

So I haven’t personally given any air time to the topic of rolling releases over the years.

This year, the topic bubbled up again, and given the level of interest I supported that the core Canonical engineering team do a deep assessment of what it would actually mean, in hard pro’s and con’s, and how we might implement it, so that a straw man proposal (‘one you can poke holes in’) could be presented. Rick put forward that proposal last week. It should be clear that Rick is a strong and sincere proponent of the idea, hence the passion with which the case is made, but he is not the sole decision maker.

It’s nonsense to portray Rick’s position as a final position for Ubuntu. The TB have not weighed in,  the CC (who were briefed that the assessment was being made and that a straw man would be proposed) are still considering their perspective, and I’m not convinced either. So, for those inclined to melodrama, you may want to calm down and join the conversation.

Some unexpected findings

In the course of Rick’s team’s assessment, several interesting and (to me) unexpected findings emerged.

First, there’s real confusion around interim releases. Between 12.04 LTS and 14.04 LTS there will be three interim releases on our current approach, and lots of people will find that confusing. Should ISVs target quantal AND raring AND ssssss? In practice, we have lots of data to say they can’t and won’t. PPAs are often inconsistent between interim releases. That suggests that having an ‘edge’ release (for which PPAs would over time build up a rich source of extra software) and LTS releases may be easier on that segment of the community.

Second, we have proven the LTS point release mechanism, which brings new hardware support and new software to the LTS releases. The cloud archive, for example, brings the latest OpenStack release to 12.04 LTS, and is by far the most popular way to deploy OpenStack. Point releases have brought fresh kernels, fresh OpenStack, and fresh Unity to 12.04 LTS, and there is no reason why we could not broaden that commitment. It’s worth discussing whether that doesn’t become a better mechanism to meet the needs of people who care about a stable release.

Third, the daily quality story really has been impressive. The amazing work of a sizable quality team has transformed the widespread expectations of participants and contributors in Ubuntu – raring is really useful, every day, with little risk of unproductive hours when things go wonky. That’s grown the number of *developers* running raring, and boosted Ubuntu in other ways as a result. I’m not convinced it’s good enough for end-users, but it’s worth digging in to see how it could get there.

Some unrealistic expectations

In the commentary I’ve seen during the course of the discussion, some of the expectations expressed by stakeholders strike me as unrealistic.

Ben Collins’ perspective, which addresses the need of a PowerPC OEM, is an example. Ben is a friend and former colleague, I’d like to be supportive, but the real cost of supporting an architecture is way outside the scope of Ubuntu’s non-commercial commitments. IBM and Canonical discussed bringing Ubuntu to the PowerPC architecture some years ago and chose not to; the gap is not something Canonical will close alone. I’m delighted if Ubuntu is useful for Ben, and pretty certain it will remain the best platform for his work regardless, but we should not spend millions of dollars on that rather than cloud computing or mobile, which have a much broader impact on both society and our commercial prospects.

Some unwarranted melodrama

The sky is not falling in.

Really.

Ubuntu is a group of people who get together with common purpose. How we achieve that purpose is up to us, and everyone has a say in what they can and will contribute. Canonical’s contribution is massive. It’s simply nonsense to say that Canonical gets ‘what it wants’ more than anybody else. Hell, half the time *I* don’t get exactly what I want. It just doesn’t work that way: lots of people work hard to the best of their abilities, the result is Ubuntu.

The combination of Canonical and community is what makes that amazing. There are lots of pure community distro’s. And wow, they are full of politics, spite, frustration, venality and disappointment. Why? Because people are people, and work is hard, and collaboration is even harder. That’s nothing to do with Canonical, and everything to do with life. In fact, in most of the pure-community projects I’ve watched and participated in, the biggest meme is ‘if only we had someone that could do the heavy lifting’. Ubuntu has that in Canonical – and the combination of our joint efforts has become the most popular platform for Linux fans.

If you’ve done what you want for Ubuntu, then move on. That’s normal – there’s no need to poison the well behind you just because you want to try something else.

It’s also the case that we’ve shifted gear to leadership rather than integration.

When we started, we said we wanted to deliver the best of open source on a cadence. It was up to KDE, GNOME, XFCE to define what that was going to look like, we would just integrate and deliver (a hard problem in itself). By 2009 I was convinced that none of the existing free software communities could create an experience that could challenge the existing proprietary leaders, and so, if we were serious about the dream of a free software norm, we would have to lead.

The result is Unity, which is an experience that could become widely adopted across phones, tablets, PCs and other devices. Of course, that is a disruptive change, and has caused some members of existing communities to resent our work. I respect that others may prefer different experiences, so we remain willing to do a large (but not unlimited) amount of work to enable KDE, GNOME, and other DEs to thrive inside the broader Ubuntu umbrella. We also take steps to accommodate developers who want to support both Unity and another DE. But if we want to get beyond being a platform for hobbyists, we need to accelerate the work on Unity to keep up with Android, Chrome, Windows and Apple. And that’s more important than taking care of the needs of those who don’t share our goal of a free software norm.

A once-in-a-lifetime opportunity

Everyone that I care about in open source has a shared dream: they want free software to become the norm, not the exception. And Ubuntu is the only way I can see for that to happen, which is why I spend all my time on it, and why so many other people spend huge amounts of time on it too.

I simply have zero interest in the crowd who wants to be different. Leet. ‘Linux is supposed to be hard so it’s exclusive’ is just the dumbest thing that a smart person could say. People being people, there are of course smart people who hold that view.

What I’m really interested in is this once-in-a-lifetime opportunity to create a free and open platform that is THE LEADER across both consumer and enterprise computing.

With Ubuntu (and Unity) we have that. It’s amazing. Think about it – unlike years gone by, a free software platform is actually winning awards for innovative leadership in the categories that count: mobile, cloud. Investing your time and energy here might have a truly profound impact on the world. That’s worth digging into. Just roll your eyeballs at the 1337 crowd, roll up your sleeves, find something interesting to improve, and join in. To the extent that you can master a piece, you will get what you want. If you think the grand vision should follow your whims, you won’t.

If we work hard, and work together, Ubuntu will become a widespread platform for phones, tablets and PCs. You’ll have the satisfaction of designing, building and fixing tools that are used every day by millions of people. That’s meaningful. And it’s worth looking hard at our practices to ask the question: how best to achieve that goal? Of those practices, interim releases are just as subject to evaluation and revision as any other.

Going faster

So, rolling releases are not real releases.

But cadence is good, releases are good discipline even if they are hard. In LEAN software engineering, we have an interesting maxim: when something is hard, DO IT MORE OFTEN. Because that way you concentrate your efforts on the hard problem, master it, automate and make it easy. That’s the philosophy that underpins agile development, devops, juju and loads of other goodness.

In the web-lead world, software is moving faster than ever before. Is six months fast enough?

So I think it IS worth asking the question: can we go even faster? Can we make even MORE releases in a year? And can we automate that process to make it bulletproof for end-users?

That’s where I think we should steer the conversation on rolling releases:

  • Can we make the update process from point to point really bulletproof? Upgrading today is possible, but to keep the system clean over multiple successive upgrades requires an uncommonly high level of skill with APT.
  • Can we strengthen the definition of point releases in the LTS so that interim releases are obviously less relevant?
  • Can we do a reasonable amount of release management on, say, MONTHLY releases that they are actual releases rather than just snapshots?

Daily quality has made the Ubuntu development release perfectly usable for developers. That’s a huge accomplishment. Now let’s think carefully about the promises we’re making end-users, and see if it isn’t time to innovate again, just as we innovated when we created Ubuntu on a six month cadence.

Ubuntu in 2013

Wednesday, December 26th, 2012

This is a time of year to ponder what matters most and choose what we’ll focus on in the year to come. Each of us has our own priorities and perspective, so your goals may be very different to mine. Nevertheless, for everyone in the Ubuntu project, here’s what I’ll be working towards in the coming year, and why.

First, what matters most?

It matters that we not exclude people from our audience. From the artist making scenes for the next blockbuster, to the person who needs a safe way to surf the web once a day, it’s important to me, and to the wider Ubuntu community, the people be able to derive some benefit from our efforts. Some of that benefit might be oblique – when someone prefers XFCE to Unity, they are still benefiting from enormous efforts by hundreds of people to make the core Ubuntu platform, as well as the Xubuntu team’s unique flourish. Even in the rare case where the gift is received ungraciously, the joy is in the giving, and it matters that our efforts paid dividends for others.

In this sense, it matters most that we bring the benefits of free software to an audience which would not previously have had the confidence to be different. If you’ve been arguing over software licenses for the best part of 15 years then you would probably be fine with whatever came before Ubuntu. And perhaps the thing you really need is the ability to share your insights and experience with all the people in your life who wouldn’t previously have been able to relate to the things you care about. So we have that interest in common.

It matters that we make a platform which can be USED by anybody. That’s why we’ve invested so much into research and thinking about how people use their software, what kinds of tools they need handy access to, and what the future looks like. We know that there are plenty of smart people who’s needs are well served by what existed in the past. We continue to maintain older versions of Ubuntu so that they can enjoy those tools on a stable platform. But we want to shape the future, which means exploring territory that is unfamiliar, uncertain and easy to criticise. And in this regard, we know, scientifically, that Ubuntu with Unity is better than anything else out there. That’s not to diminish the works of others, or the opinions of those that prefer something else, it’s to celebrate that the world of free software now has a face that will be friendly to anybody you care to recommend it.

It also matters that we be relevant for the kinds of computing that people want to do every day.

That’s why Unity in 2013 will be all about mobile – bringing Ubuntu to phones and tablets. Shaping Unity to provide the things we’ve learned are most important across all form factors, beautifully. Broadening the Ubuntu community to include mobile developers who need new tools and frameworks to create mobile software. Defining new form factors that enable new kinds of work and play altogether. Bringing clearly into focus the driving forces that have shaped our new desktop into one facet of a bigger gem.

It’s also why we’ll push deeper into the cloud, making it even easier, faster and cost effective to scale out modern infrastructure on the cloud of your choice, or create clouds for your own consumption and commerce. Whether you’re building out a big data cluster or a super-scaled storage solution, you’ll get it done faster on Ubuntu than any other platform, thanks to the amazing work of our cloud community. Whatever your UI of choice, having the same core tools and libraries from your phone to your desktop to your server and your cloud instances makes life infinitely easier. Consider it a gift from all of us at Ubuntu.

There will always be things that we differ on between ourselves, and those who want to define themselves by their differences to us on particular points. We can’t help them every time, or convince them of our integrity when it doesn’t suit their world view. What we can do is step back and look at that backdrop: the biggest community in free software, totally global, diverse in their needs and interests, but united in a desire to make it possible for anybody to get a high quality computing experience that is first class in every sense. Wow. Thank you. That’s why I’ll devote most of my time and energy to bringing that vision to fruition. Here’s to a great 2013.