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.

“in addition to”

Friday, October 19th, 2012

Nothing in yesterday’s post about inviting members of the community into some of the projects we work on in confidence implied that the Ubuntu development process is becoming less open.

Ubuntu set the standard for transparency as a company producing a distribution a long time ago, when we invited anybody who showed a passion and competence to have commit and upload rights, a strong contrast with the Fedora policy of the time, which required you to be a Red Hat employee. We continue that tradition with a leadership Community Council that has no requirement of Canonical employment, unlike our competitors. And we invite everyone to participate in the design and development of Ubuntu, which happens in public at UDS (week after next, as it happens) and online on IRC and Launchpad.

Every member of a community works on personal projects. Our competitors do so too. There are any number of changes thrust upon Gnome by Red Hat for example, that then get whitewashed as “maintainers discretion” or “designers design”. There are any number of reveals, prototypes, patents and other decisions that are taken in private, by all members of all communities. Even amongst volunteers its normal to see someone saying “I’ve been hacking on this for a while, now I want some feedback”.

What I offered to do, yesterday, spontaneously, is to invite members of the community in to the things we are working on as personal projects, before we are ready to share them. This would mean that there was even less of Ubuntu that was NOT shaped and polished by folk other than Canonical – a move that one would think would be well received. This would make Canonical even more transparent.

So please disregard the commentary by folk who assumed that the public discussion of Ubuntu development would somehow change. Instead, I hope you will welcome the idea that even Canonical’s most exciting initiatives will now be open to participation by members of the community. And I challenge you to find another place where you can participate at EVERY level in the design and construction of a free platform that is used by millions of people.

The dash to Copenhagen combined with a dash across the Atlantic has me righteously ramfeezled, but the roisterous reception we got at the OpenStack summit (congrats, stackers, on a respectable razzmatazz of rugible cloud enthusiasm) made it worthwhile. A quick shout out to the team behind the Juju gooooey, that puts a whole new face on cloud agility – rousing stuff.

Nevertheless, it’s way past time to root our next rhythmic release in some appropriate adjective.

The challenge, of course, has been the number of entirely inappropriate adjectives that presented themselves along the way. Go read the dictionary. R is just loaded with juicy stuff we can’t use without invoking the radge wrath of the rinky-dink chorus. Sigh.

Nevertheless, somewhere between the risibly rambunctious and the reboantly ran-tan, the regnally rakish and the reciprocornously rorty, there was bound to be a good fit. Something radious or rident, something to rouse our rowthy rabble.

So what will we be up to in the next six months? We have two short cycles before we’re into the LTS, and by then we want to have the phone, tablet and TV all lined up. So I think it’s time to look at the core of Ubuntu and review it through a mobile lens: let’s measure our core platform by mobile metrics, things like battery life, number of running processes, memory footprint, and polish the rough edges that we find when we do that. The tighter we can get the core, the better we will do on laptops and the cloud, too.

So bring along a Nexus 7 if you’re coming to Copenhagen, because it makes a rumpty reference for our rootin’ tootin’ radionic razoring. The raving Rick and his merry (wo)men will lead us to a much leaner, sharper, more mobile world. We’ll make something… wonderful, and call it the Raring Ringtail. See you there soon.

Update: for clarity, this ringtail is no laconic lemur, it’s a ringtail raccoon. However, for the sake of sanity, it’s not a raring ringtail raccoon, just a raring ringtail. There.

Amazon search results in the Dash

Sunday, September 23rd, 2012

It makes perfect sense to integrate Amazon search results in the Dash, because the Home Lens of the Dash should let you find *anything* anywhere. Over time, we’ll make the Dash smarter and smarter, so you can just ask for whatever you want, and it will Just Work.

The Home Lens of the Dash is a “give me X” experience. You hit the Super key, and say what you want, and we do our best to figure out what you mean, and give you that. Of course, you can narrow the scope of that search if you want. For example, you can hit Super-A and just search applications. But if you throw your query out to the Dash, we need to be a smart as possible about where we go looking for answers for you.

In 12.10 we’ll take the first step of looking both online and locally for possible results. The Home lens will show you local things like apps and music, as it always has, as well as results from Amazon. Note – these are not ads, they are results to your search. We don’t promote any product or service speculatively, these are not banners or spyware. These are results from underlying scopes, surfaced to the Home lens, because you didn’t narrow the scope to a specific, well scope.

What we have in 12.10 isn’t the full experience, so those who leap to judgement are at maximum risk of having to eat their words later. Chill out. If the first cut doesn’t work for you, remove it, or just search the specific scope you want (there are hotkeys for all the local scopes).

Here’s a quick Q&A on the main FUD-points.

Why are you putting ads in Ubuntu?

We’re not putting ads in Ubuntu. We’re integrating online scope results into the home lens of the dash. This is to enable you to hit “Super” and then ask for anything you like, and over time, with all of the fantastic search scopes that people are creating, we should be able to give you the right answer.

These are not ads because they are not paid placement, they are straightforward Amazon search results for your search. So the Dash becomes a super-search of any number of different kinds of data. Right now, it’s not dynamically choosing what to search, it’s just searching local scopes and Amazon, but it will get smarter over time.

I don’t wan’t to search Amazon for the Terminal

Use Super-A. You can tell Unity exactly what you want to search. And in future you’ll be able to do that from the home lens, too, more easily than the current Lens Bar at the bottom of the Dash.

I want to control what is searched on the Home Lens

So do I! Designs and patches welcome in the usual places. I’m pretty sure by 14.04 LTS we’ll have the kinks unkinked. Till then, come along for the ride, or stick with 12.04 LTS. We can’t wait till it’s perfect before landing everything, because the only way to learn what’s not perfect is to have other people – real people – use it.

I can’t believe you just changed Ubuntu. I liked it the way it was.

Looks like those six months are nearly up again ;)

This is just a moneymaking scheme.

We picked Amazon as a first place to start because most of our users are also regular users of Amazon, and it pays us to make your Amazon journey  get off to a faster start. Typing Super “queen marking cage”  Just Worked for me this morning. I am now looking forward to my game of Ultimate Where’s Waldo hunting down the queens in my bee colonies, Ubuntu will benefit from the fact that I chose to search Amazon that way, Amazon benefits from being more accessible to a very discerning, time-conscious and hotkey-friendly audience.

But there are many more kinds of things you can search through with Unity scopes. Most of them won’t pay Ubuntu a cent, but we’ll still integrate them into the coolest just-ask-and-you’ll-receive experience. I want us to do this because I think we can make the desktop better.

Why are you telling Amazon what I am searching for?

We are not telling Amazon what you are searching for. Your anonymity is preserved because we handle the query on your behalf. Don’t trust us? Erm, we have root. You do trust us with your data already. You trust us not to screw up on your machine with every update. You trust Debian, and you trust a large swathe of the open source community. And most importantly, you trust us to address it when, being human, we err.

The query should be encrypted!

It will be in the release version.

I want to control this in the settings!

Yes, we agree, and designs and work are under way to make that possible. That should land in 12.10 too, or as an update, or in 13.04.

In summary – please don’t feed the trolls. We’re interested in feedback in what sorts of things would be useful to search straight from the home lens, and how to improve the search results, as well as provide better control of the process to you.

Here is the key question, as I see it:

Can Canonical and the Ubuntu community handle the responsibility associated with this sort of service?

Well, if we want to run a modern platform, that updates automatically and provides users with the full benefit of living in a connected world, then we have to be able to do that. If we can’t we won’t be relevant. So we should talk about the appropriate kinds of privacy policy, appropriate encryption, appropriate settings and preferences, to make this all world class.

Quality has a new name

Monday, April 23rd, 2012

This quirky scheme of adjectives and animals presents a pretty puzzle every six months. What mix of characteristics do we want to celebrate in the next release? Here we are, busily finalizing the precise pangolin (which was a rather perfect product placement for a scaly anteater, all things considered) and before one realises it’s time to talk turkey, so to speak, about Q! Our code names may raise a quizzical eyebrow here and there, but they capture the zeitgeist of a cycle and shape our discussions in surprising ways. The quest for a name has no quick answer unless, of course, you jump to the last paragraph ;)

12.04 being an LTS we’ve been minding our P’s and Q’s, but many of our quality-oriented practices from 12.04 LTS will continue into Q territory. We’ll keep the platform usable throughout the cycle, because that helped hugely to encourage daily use of the release, which in turn gives us much better feedback on questions of quality. And we’ll ratchet up the continuous integration, smoke testing and automated benchmarking of the release, since we can do it all in the cloud. We have, so to speak, stacks and stacks of cloud to use. So quality is quotidian rather than quarterly. And it is both qualitative and quantitative, with user research and testing continuing to shape our design decisions. The effort we put into polishing Unity and the rest of the platform in 12.04 seem to have paid off handsomely, with many quondam quarrelsome suddenly quiescent in the face of a surge in support for the work.

But the finest quality is that without a name, so support for “quality” as a codename would at best be qualified. Every release has quality first these days – they all get used, on the server, on devices, and while the term of maintenance might vary, our commitment to interim releases is just as important as that to an LTS.

Our focus on quality permeates from the platform up to the code we write upstream, and our choices of upstream components too. We require tests and gated trunks for all Canonical codebases, and prefer upstreams that share the same values. Quality starts at the source, it’s not something that can be patched in after the fact. And I’m delighted that we have many upstreams using our tools to improve their quality too! We have awesome tools for daily builds from branches, continuous integration support in Launchpad, the ability to provide a gated trunk with tests run in the cloud for projects that really care about quality. Rumours and allegations of a move from Upstart to systemd are unfounded: Upstart has a huge battery of tests, the competition has virtually none. Upstart knows everything it wants to be, the competition wants to be everything. Quality comes from focus and clarity of purpose, it comes from careful design and rigorous practices. After a review by the Ubuntu Foundations team our course is clear: we’re committed to Upstart, it’s the better choice for a modern init, innit. For our future on cloud and client, Upstart is crisp, clean and correct. It will be a pleasure to share all the Upstart-enablement patches we carry with other family friends as soon as their release is ready and they can take a breath, so to speak.

From a styling point of view, we think in terms of quadruples: this next release starts a cycle of four, which will culminate in 14.04 LTS. So there’s an opportunity to refresh the look. That will kick off with a project on typography to make sure we are expressing ourselves with crystal clarity – making the most of Ubuntu’s Light and Medium font weights for a start. And a project on iconography, with the University of Reading, to refine the look of apps and interfaces throughout the platform. It’s amazing how quaint the early releases of Ubuntu look compared to the current style. And we’re only just getting started! In our artistic explorations we want to embrace tessellation as an expression of the part-digital, part-organic nature of Ubuntu. We love the way tessellated art expresses both the precision and reliability of our foundations, and the freedom and collaboration of a project driven by people making stuff for people. There’s nothing quixotic in our desire to make Ubuntu the easiest, steadiest, and most beautiful way to live digitally.

On the fauna front, the quotable campaign for the Queer Quokka is quorate but, it must sometimes be said, this is not a democracy. One man’s favourite furball is another’s mangy marsupial. No, the quintessential stories of Q will be all about style on the client, with a refresh of our theme and typography, a start on new iconography and perhaps even a new form factor taking flight. So brown is out and something colourful and light is called for. On the cloud front, the new virtualized network madness called Quantum will make its appearance. Being a first cut, it’s more likely to be Folsom than wholesome, but it’s going to be worth calling out, and the name is reminiscent of our package-oriented practices, where goodness is delivered one piece at a time. And so the stage is set for a decision:  I give you the Quantal Quetzal, soon to be dressed in tessellated technicolour, now open for toolchains, kernels and other pressing preparatory packages.

Holistic UI is smarter UX

Tuesday, March 27th, 2012

In the open source community, we celebrate having pieces that “do one thing well”, with lots of orthogonal tools compounding to give great flexibility. But that same philosophy leads to shortcomings on the GUI / UX front, where we want all the pieces to be aware of each other in a deeper way.

For example, we consciously place the notifications in the top right of the screen, avoiding space that is particularly precious (like new tab titles, and search boxes). But the indicators are also in the top right, and they make menus, which drop down into the same space a notification might occupy.

Since we know that notifications are queued, no notification is guaranteed to be displayed instantly, so a smarter notification experience would stay out of the way while you were using indicator menus, or get out of the way when you invoke them. The design story of focusayatana, where we balance the need for focus with the need for awareness, would suggest that we should suppress awareness-oriented things in favour of focus things. So when you’re interacting with an indicator menu, we shouldn’t pop up the notification. Since the notification system, and the indicator menu system, are separate parts, the UNIX philosophy sells us short in designing a smart, smooth experience because it says they should each do their thing individually.

Going further, it’s silly that the sound menu next/previous track buttons pop up a notification, because the same menu shows the new track immediately anyway. So the notification, which is purely for background awareness, is distracting from your focus, which is conveying exactly the same information!

But it’s not just the system menus. Apps can play in that space too, and we could be better about shaping the relationship between them. For example, if I’m moving the mouse around in the area of a notification, we should be willing to defer it a few seconds to stay out of the focus. When I stop moving the mouse, or typing in a window in that region, then it’s OK to pop up the notification.

It’s only by looking at the whole, that we can design great experiences. And only by building a community of both system and application developers that care about the whole, that we can make those designs real. So, thank you to all of you who approach things this way, we’ve made huge progress, and hopefully there are some ideas here for low-hanging improvements too :)