Mark Shuttleworth | here be dragons

Competition is tough on the contestants, but it gets great results for everyone else. We like competitive markets, competitive technologies, competitive sports, because we feel the end result for consumers or the audience is as good as it possibly could be.

In larger organisations, you get an interesting effect. You get *internal* competition as well as external competition. And that’s healthy too. You get individuals competing for responsibility, and of course you want to make sure that the people who will make the wisest choices carry the responsibilities that demand wisdom, while those who have the most energy carry the responsibilities for which that’s most needed. You get teams competing with each other too – for resources, for attention, for support elsewhere, for moral authority, for publicity. And THAT’s the hardest kind of competition to manage, because it can be destructive to the organisation as a whole.

Even though it’s difficult to manage, internal competition is extremely important, and should not be avoided out of fear. The up side is that you get to keep the best ideas because you allowed them to compete internally. If you try and avoid it, you crowd out new ideas, and end up having to catch up to them. Usually, what goes wrong is that one group gets control of the organisation’s thinking, and takes the view that any ideas which do not come from within that group are a threat, and should be stopped. That’s very dangerous – it’s how great civilisations crash; they fail to embrace new ideas which are not generated at the core.

In Ubuntu, we have a lot of internal competition. Ubuntu and Kubuntu and Xubuntu and Edubuntu and *buntu-at-large have to collaborate and also, to a certain extent, compete. We handle that very well, I think, though occasionally some muppet calls Kubuntu the blue-headed-stepchild etc etc. It’s absolutely clear to everyone, though, that we have a shared interest in delivering ALL these experiences together with as much shared vision and commonality as possible. I consider the competition between these teams healthy and constructive and worth maintaining, even though it requires some fancy footwork and causes occasional strains.

The challenge for Gnome leadership

The sound and fury writ large in blog comments this week is all about how competition is managed.

Gnome is, or should be, bigger than any of the contributing individuals or companies. Gnome leadership should be in a position to harness competition effectively for the good of the project. That does, however, require very firm leadership, and very gutsy decisions. And it requires vigilance against inward thinking. For example, I’ve seen the meme reiterated multiple times that “one should not expect Gnome to embrace ideas which were not generated and hosted purely within Gnome”. That’s chronic inward thinking. Think of all the amazing bits of goodness in the free software stack which were NOT invented in Gnome but are a part of it today. Think how much better it is when goodness is adopted across multiple desktop environments, and how much harder it is to achieve that when something is branded “K” or “G”.

When we articulated our vision for Unity, we were very clear that we wanted to deliver it under the umbrella of Gnome. We picked Gnome-friendly technologies by and large, and where we felt we needed to do something different, that decision required substantial review. We described Unity as “a shell for Gnome” from the beginning, and we have been sincere in that view. We have worked successfully and happily with many, many Gnome projects to integrate Unity API’s into their codebase.

This is because we wanted to be sure that whatever competitive dynamics arose were *internal* to Gnome, and thus contributing to a better result overall in Gnome in the long term.

We’ve failed.

Much of the language, and much of the decision making I’ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome.

The key example of that is the rejection of Unity’s indicator API’s as external dependencies. That was the opportunity to say “let’s host this competition inside Gnome”. Even now, there’s a lack of clarity as to what was intended by that rejection, with some saying “it was just a reflection of the fact that the API’s were new and not used in any apps”. If that were the case, there would be no need for prior approval as an external dependency; the rejection was clearly an attempt to prevent Gnome applications from engaging around these API’s. It’s substantially failed, as many apps have happily done the work to blend in beautifully in the Unity environment, but there has been a clear attempt to prevent that by those who feel that Unity is a threat to Gnome rather than an opportunity for it.

Dave Neary has to his credit started to ask “what’s really going on here”?

In his blog post, he quoted the rationale given for the rejection of Canonical’s indicator API’s, which I’ll re-quote here and analyze in this light:

it doesn’t integrate with gnome-shell

That’s it – right there. Remember, this was a proposal for the indicator API’s to be an *external* dependency for Gnome. That means, Gnome apps can use those API’s *optionally* when they are being run on a platform where they are useful. It has NOTHING to do with the core Gnome vision. External API’s exist precisely BECAUSE it’s useful to encourage people to use Gnome apps on all sorts of platforms, including proprietary ones like Windows and MacOS and Solaris, and they should shine there too.

So the premier reason given for the rejection of these API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.

Now, I can tell you that I was pretty disgusted with this result.

We had described the work we wanted to do (cleaning up the panel, turning panel icons into menus) to the Gnome Shell designers at the 2008 UX hackfest. McCann denies knowledge today, but it was a clear decision on our part to talk about this work with him at the time, it was reported to me that the conversation had happened, and that we’d received the assurance that such work would be “a valued contribution to the shell”. Clearly, by the time it was delivered, McCann had decided that such assurances were not binding, and that his interest in an alternative panel story trumped both that assurance and the now-extant FreeDesktop.org discussions and spec.

But that’s not the focus of this blog. My focus here is on the management of healthy competition. And external dependencies are the perfect way to do so: they signal that there is a core strategy (in this case whatever Jon McCann wants to do with the panel) and yet there are also other, valid approaches which Gnome apps can embrace. This decision failed to grab that opportunity with both hands. It said “we don’t want this competition WITHIN Gnome”. But the decision cannot remove the competitive force. What that means is that the balance was shifted to competition WITH Gnome.

probably depends on GtkApplication, and would need integration in GTK+ itself

Clearly, both of these positions are flawed. The architecture of the indicator work was designed both for backward compatibility with the systray at the time, and for easy adoption. We have lots of apps using the API’s without either of these points being the case.

we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen

We made the proposal, it was rejected. I can tell you that the people who worked on the proposal consider themselves Gnome people, and they feel they did what was required, and stopped when it was clear they were not going to be accepted. I’ve had people point to this bullet and say “you should have pushed harder”. But proposing an *external* dependency is not the same as trying to convince Shell to adopt something as the mainstream effort. It’s saying “hey, here’s a valid set of API’s apps might want to embrace, let’s let them do so”.

there’s nothing in GNOME needing it

This is a very interesting comment. It’s saying “no Gnome apps have used these API’s”. But the Gnome apps in question were looking to this very process for approval of their desire to use the API’s. You cannot have a process to pre-approve API’s, then decline to do so because “nobody has used the API’s which are not yet approved”. You’re either saying “we just rubber stamp stuff here, go ahead and use whatever you want”, or you’re being asinine.

It’s also saying that Unity is not “in GNOME”. Clearly, a lot of Unity work depends on the adoption of these API’s for a smooth and well-designed panel experience. So once again, we have a statement that Unity is “competition with Gnome” and not “competition within Gnome”.

And finally, it’s predicating this decision on the idea being “in Gnome” is the sole criterion of goodness. There is a cross-desktop specification which defines the appindicator work clearly. The fact that KDE apps Just Work on Unity is thanks to the work done to make this a standard. Gnome devs participated in the process, but appeared not to stick with it. Many or most of the issues they raised were either addressed in the spec or in the implementations of it. They say now that they were not taken seriously, but a reading of the mailing list threads suggests otherwise.

It’s my view that cross-desktop standards are really important. We host both Kubuntu and Ubuntu under our banner, and without such collaboration, that would be virtually impossible. I want Banshee to work as well under Kubuntu as Amarok can under Ubuntu.

What can be done?

This is a critical juncture for the leadership of Gnome. I’ll state plainly that I feel the long tail of good-hearted contributors to Gnome and Gnome applications are being let down by a decision-making process that has let competitive dynamics diminish the scope of Gnome itself. Ideas that are not generated “at the core” have to fight incredibly and unnecessarily hard to get oxygen. Ask the Zeitgeist team. Federico is a hero, but getting room for ideas to be explored should not feel like a frontal assault on a machine gun post.

This is no way to lead a project. This is a recipe for a project that loses great people to environments that are more open to different ways of seeing the world. Elementary. Unity.

Embracing those other ideas and allowing them to compete happily and healthily is the only way to keep the innovation they bring inside your brand. Otherwise, you’re doomed to watching them innovate and then having to “relayout” your own efforts to keep up, badmouthing them in the process.

We started this with a strong, clear statement: Unity is a shell for Gnome. Now Gnome leadership have to decide if they want the fruit of that competition to be an asset to Gnome, or not.

A blessing in disguise

Aaron’s blog post made me think that the right way forward might be to bolster and strengthen the forum for cross-desktop collaboration: FreeDesktop.org.

I have little optimism that the internal code dynamics of Gnome can be fixed – I have seen too many cases where a patch which implements something needed by Unity is dissed, then reimplemented differently, or simply left to rot, to believe that the maintainers in Gnome who have a competitive interest on one side or the other will provide a level playing field for this competition.

However, we have shown a good ability to collaborate around FD.o with KDE and other projects. Perhaps we could strengthen FreeDesktop.org and focus our efforts at collaboration around the definition of standards there. Gnome has failed to take that forum seriously, as evidenced by the frustrations expressed elsewhere. But perhaps if we had both Unity and KDE working well there, Gnome might take a different view. And that would be very good for the free software desktop.

The naming of cats is a difficult matter
It isn’t just one of your holiday games.
- T S Eliot, The Naming of Cats

For the next cycle, I think we’ll leave the oceanic theme behind. The “oddball octopus”, for example, is a great name but not one we’ll adopt this time around. Perhaps in 13 years time, though!

The objective is to capture the essence of our next six months work in a simple name. Inevitably there’s an obliquity, or offbeat opportunism in the result. And perhaps this next release more than most requires something other than orthodoxy – the skunkworks are in high gear right now. Fortunately I’m assured that if one of Natty’s successors is a skunk, it would at least be a sassy skunk!

So we’re looking for a name that conveys mysterious possibility, with perhaps an ounce of overt oracular content too. Nothing too opaque, ornate, odious or orotund. Something with an orderly ring to it, in celebration of the crisp clean cadence by which we the community bring Ubuntu forth.

There’s something neat in the idea that 11.10 will mark eight years since Ubuntu was conceived (it took a little longer to be born). So “octennial” might suit… but that would be looking backwards, and we should have an eye on the future, not the past. Hmm… an eye on the future, perhaps ocular? Or oculate? We’re certainly making our way up the S-curve of adoption, so perhaps ogee would do the trick?

Alternatively, we could celebrate the visual language of Ubuntu with the “orange okapi”, or the welcoming nature of our community with the “osculant orangutan”. Nothing hugs quite like dholbach, though, and he’s no hairy ape.

What we want is something imaginative, something dreamy. Something sleek and neat, too. Something that has all the precision of T S Eliot’s poetry, matched with the “effable ineffability” of our shared values, friendship and expertise. Something that captures both the competence of ubuntu-devel with the imagination of ayatana.

Which leads us neatly to the Oneiric Ocelot.

Oneiric means “dreamy”, and the combination with Ocelot reminds me of the way innovation happens: part daydream, part discipline.

We’ll need to keep up the pace of innovation on all fronts post-Natty. Our desktop has come together beautifully, and in the next release we’ll complete the cycle of making it available to all users, with a 2D experience to complement the OpenGL based Unity for those with the hardware to handle it. The introduction of Qt means we’ll be giving developers even more options for how they can produce interfaces that are both functional and aesthetically delightful.

In the cloud, we’ll have to tighten up and make some firm decisions about the platforms we can support for 12.04 LTS. UDS in Budapest will be full of feisty debate on that front, I’m sure, but I’m equally sure we can reach a pragmatic consensus and start to focus our energies on delivering the platform for widespread cloud computing on free and flexible terms.

Ubuntu is now shipping on millions of systems from multiple providers every year. It makes a real difference in the lives of millions, perhaps tens of millions, of people. As MPT said, “what we do is not only art, it’s performance art”. Every six months the curtains part, and we have to be ready for the performance. I’d like to thank the thousands of people who are actively participating in the production of Natty: take the initiative, take responsibility, take action, and your work will make a difference to all of those users. There are very few places in the world where a personal intellectual contribution can have that kind of impact. And very few places where we have such a strong social fabric around those intellectual challenges, too. We each do what we do for our own reasons, but it’s the global impact of Ubuntu which gives meaning to that action.

Natty is a stretch release: we set out to redefine the look and feel of the free desktop. We’ll need all the feedback we can get, so please test today’s daily, or A3, and file bug reports! Keep up the discipline and focus on the Narwhal, and let’s direct our daydreaming to the Ocelot.

A wit said of Google Wave “if your project depends on reinventing scrollbars, you are doing something wrong.” But occasionally, just occasionally, one gets to do exactly that.

Under the Ayatana banner, we’ve been on a mission to make the desktop have less chrome and more content. The goal is to help people immerse themselves in their stuff, without being burdened with large amounts of widgetry which isn’t relevant to the thing they are trying to concentrate on. And when it comes to widgetry, there are few things left which take up more space than scrollbars.

For example, I spend plenty of time in a full screen terminal, and it’s lovely to see how clean that experience is on Natty today:

…but that scrollbar on the right seems heavy and outdated. We took inspiration from mobile devices, and started exploring the idea of making scrollbars be more symbolic, and less physical. Something like this:

Of course, since the desktop isn’t often a touch device, we need to think through pointer interactions. We wanted to preserve the idea of keeping content exposed as much as possible, while still providing for pointer interaction when needed. We also decided to drop the “one line scroll” capability, while preserving the ability to page up and down. Take a look at the result:

Overlay Scrollbars in Unity – implementation from Canonical Design on Vimeo.

The design work behind this has been done by Christian Giordano, who worked through the corner cases (literally) and provided a mockup for testing purposes. And the heavy lifting for Natty is being done by the indefatigable Andrea Cimitan, who is currently polishing up a gtk implementation of the concept for the release. Christian put together a blog post on the subject, and a great video which talks through the design process and a few of the challenges and solutions found:

Overlay Scrollbars in Unity from Canonical Design on Vimeo.

Code is available on launchpad, bzr branch lp:ayatana-scrollbar and in a PPA:

sudo add-apt-repository ppa:ayatana-scrollbar-team/release; sudo apt-get update
sudo apt-get install liboverlay-scrollbar-0.1-0
LIBOVERLAY_SCROLLBAR=foo gnome-appearance-properties

Well done, guys.

We made some mistakes in our handling of the discussion around revenue share with the Banshee team. Thanks to everyone who helped make sure we were aware of ‘em

Money is particularly contentious in a community that mixes volunteer and paid effort, we should have anticipated and been extra careful to have the difficult conversations that were inevitable up front and in public, at UDS, when we were talking about the possibility of Banshee being the default media player in Ubuntu. We didn’t, and I apologise for the consequential confusion and upset caused.

The principles from which we derive our policy are straightforward:

The bulk of the direct cost in creating the audience of Ubuntu users is carried by Canonical. There are many, many indirect costs and contributions that are carried by others, both inside the Ubuntu community and in other communities, without which Ubuntu would not be possible. But that doesn’t diminish the substantial investment made by Canonical in a product that is in turn made available free of charge to millions of users and developers.

The business model which justifies this investment, and which we hope will ultimately sustain that effort for the desktop without dependence on me, is that fee-generating services which are optional for users provide revenue to Canonical. This enables us to make the desktop available in a high quality, fully maintained form, without any royalties or license fees. By contrast, every other commercial Linux desktop is a licensed product – you can’t legally use it for free, the terms for binaries are similar to those for Windows or the MacOS. They’re entitled to do it their way, we think it’s good in the world that we choose to do it our way too.

We know that we need a healthy and vibrant ecosystem of application developers. We think services should work for them too, and we’re committed to sharing revenue with them. We want to be entirely aligned in our interests: better code means a better result for both of us, better revenue means more resources to do what we love even better. Our interests, and upstream interests, should be perfectly aligned in this. So we have consistently had the view that revenue we can attribute to a particular upstream should create a revenue share for that upstream. We support Mozilla in this way, for example. The numbers are not vast, but nor are they insubstantial, and while we are not obliged to do so, we do so happily.

Those are the principles, the policy is straightforward: Canonical seeks to earn revenue from services delivered to Ubuntu, and we will share a portion of that revenue with relevant projects who help make that possible. Our interests, and those of the projects, should be aligned to the greatest extent possible.

In engaging with Banshee leads at UDS, we should have been absolutely clear about our expectations and commitment. Apparently, we weren’t, and for that I apologise. There was certainly no conspiring or maliciousness, it apparently just never came up. But it was my expectation that we would share revenue with Banshee, I mentioned it briefly to someone closer to the conversation, but I failed to follow up until I heard rumours of a potential disagreement on the subject in recent days.

We also made a mistake, I believe, as this blew up in private conversations, when a well-meaning person presented a choice to the Banshee developers, who then of course made a choice. But our position isn’t at all what was communicated. Our position is that we’ll deliver the best overall experience to users, we’ll derive services revenue from that, and we’ll share it with upstreams where we can attribute it efficiently. It wasn’t in the mandate of that person to offer a choice outside of that framework, but it was an honest mistake.

So, every free software project out there should be confident of a few things:

Canonical would like you to succeed, would like to make it as easy as possible for many, many users to adopt your software, and is willing to share the benefits of that with you. Whether your software is promoted as the default in Ubuntu, or simply neatly packaged for easy consumption, we’d like our interests to be well aligned. We have a bug tracker that helps us pass issues to you if they are reported in Ubuntu first, we have a revenue model which matches that with passing through a share of revenues, too. And that goes for any kind of revenue that we can attribute to your project; for example, if we offer a support service specially tailored to people using your code, you can reasonably expect to agree a revenue share of that with us.

Canonical invests heavily in creating a big, addressable ecosystem that you can easily reach. That’s worth something. We also want a big, vibrant upstream community that innovates and makes its own investments. We know that contributions come both from volunteers and paid staff, and it’s good to be able to have a bit of both in the mix, for the sake of both the volunteers and the paid staff!

Documenting this position is obviously a priority; we should have done so previously, but we just relied on internal precedent, which is a dumb idea when you’ve grown as quickly as we have in the past few years. So we’ll do that.

As for the revenue share we’ve offered the Banshee team, I would love to see them use that to make Banshee even better. That’s what it should be for. Don’t be shy, don’t be nervous of taking the money and using it for your own project. Canonical has already provided much more in the way of funding to the Gnome Foundation than this is likely to, through initiatives like the bugzilla.gnome.org work that we funded, and many other forms of support. I think money generated by an app should go towards making that app rock even harder. But the offer stands for Banshee devs to take up if they’d like, and use as they’d like. If they don’t want it, we’ll put it to good use.

This certainly won’t be the last word on the subject. I expect these situations to become more common, not less. But I think that represents a great opportunity to see sustained investment in desktop free software, which we have been sorely lacking. I think our model gives projects a nice, clear roadmap: build awesome stuff, partner with Canonical and be confident you will share in the success of Ubuntu. This is the model which catalysed the founding of Ubuntu, seven years ago, this is what we’re here to do: make free software available freely, in the best quality, to the widest audience we can. That’s an opportunity for every project that cares about how many people get to use their stuff, and under what terms.

As part of our planning for Natty+1, we’ll need to find some space on the CD for Qt libraries, and we will evaluate applications developed with Qt for inclusion on the CD and default install of Ubuntu.

Ease of use, and effective integration, are key values in our user experience. We care that the applications we choose are harmonious with one another and the system as a whole. Historically, that has meant that we’ve given very strong preference to applications written using Gtk, because a certain amount of harmony comes by default from the use of the same developer toolkit. That said, with OpenOffice and Firefox having been there from the start, Gtk is clearly not an absolute requirement. What I’m arguing now is that it’s the values which are important, and the toolkit is only a means to that end. We should evaluate apps on the basis of how well they meet the requirement, not prejudice them on the basis of technical choices made by the developer.

In evaluating an app for the Ubuntu default install, we should ask:

* is it free software?
* is it best-in-class?
* does it integrate with the system settings and preferences?
* does it integrate with other applications?
* is it accessible to people who cannot use a mouse, or keyboard?
* does it look and feel consistent with the rest of the system?

Of course, the developer’s choice of Qt has no influence on the first two. Qt itself has been available under the GPL for a long time, and more recently became available under the LGPL. And there’s plenty of best-in-class software written with Qt, it’s a very capable toolkit.

System settings and prefs, however, have long been a cause of friction between Qt and Gtk. Integration with system settings and preferences is critical to the sense of an application “belonging” on the system. It affects the ability to manage that application using the same tools one uses to manage all the other applications, and the sorts of settings-and-preference experience that users can have with the app. This has traditionally been a problem with Qt / KDE applications on Ubuntu, because Gtk apps all use a centrally-manageable preferences store, and KDE apps do things differently.

To address this, Canonical is driving the development of dconf bindings for Qt, so that it is possible to write a Qt app that uses the same settings framework as everything else in Ubuntu. We’ve contracted with Ryan Lortie, who obviously knows dconf very well, and he’ll work with some folks at Canonical who have been using Qt for custom development work for customers. We’re confident the result will be natural for Qt developers, and a complete expression of dconf’s semantics and style.

The Qt team have long worked well in the broader Ubuntu community – we have great Qt representation at UDS every six months, the Kubuntu team have deep experience and interest in Qt packaging and maintenance, there is lots of good technical exchange between Qt upstream and various parts of the Ubuntu community, including Canonical. For example, Qt folks are working to integrate uTouch.

I’d draw a distinction between “Qt” and “KDE” in the obvious places. A KDE app doesn’t know anything about the dconf system configuration, and can’t easily integrate with the Ubuntu desktop as a result. So we’re not going to be proposing Amarok to replace Banshee any time soon! But I think it’s entirely plausible that dconf, once it has great Qt bindings, be considered by the KDE community. There are better people to lead that conversation if they want, so I’ll not push the idea further here . Nevertheless, should a KDE app learn to talk dconf in addition to the standard KDE mechanisms, which should be straightforward, it would be a candidate for the Ubuntu default install.

The decision to be open to Qt is in no way a criticism of GNOME. It’s a celebration of free software’s diversity and complexity. Those values of ease of use and integration remain shared values with GNOME, and a great basis for collaboration with GNOME developers and project members. Perhaps GNOME itself will embrace Qt, perhaps not, but if it does then our willingness to blaze this trail would be a contribution in leadership. It’s much easier to make a vibrant ecosystem if you accept a certain amount of divergence from the canonical way, so to speak Our work on design is centered around GNOME, with settings and preferences the current focus as we move to GNOME 3.0 and gtk3.

Of course, this is a perfect opportunity for those who would poke fun at that relationship to do so, but in my view what matters most is the solid relationship we have with people who actually write applications under the GNOME banner. We want to be the very best way to make the hard work of those free software developers *matter*, by which we mean, the best way to ensure it makes a real difference in millions of lives every day, and the best way to connect them to their users.

To the good folks at Trolltech, now Nokia, who have made Qt a great toolkit – thank you. To developers who wish to use it and be part of the Ubuntu experience – welcome.

Congratulations to Team Linaro on their first full release yesterday. For those not yet in the know, Linaro is a collaborative forum with dedicated engineers making sure that Linux rocks on ARM (and potentially other architectures). Staffed by a combination of Canonical and new Linaro engineers, together with secondees from the major ARM silicon vendors, it’s solving the problems of fragmentation in Linux across that ecosystem and reducing the time to market for ARM devices.

Linaro uses the same cadence as Ubuntu and we’re able to collaborate on the selection, integration and debugging of key components like the kernel, toolchain, X.org (still ), and hundreds of small-but-important libraries and tools in between. Team Linaro was @UDS and it was very cool to see the extent to which their sessions drew attendance from the wider Ubuntu community – I think there’s a growing interest in efficient computing across the Ubuntu landscape.

The Linaro team is pleased to announce the release of Linaro 10.11.
10.11 is the first public release that brings together the huge amount
of engineering effort that has occurred within Linaro over the past 6
months. In addition to officially supporting the TI OMAP3 (Beagle
Board and Beagle Board XM) and ARM Versatile Express platforms, the
images have been tested and verified on a total of 7 different platforms
including TI OMAP4 Panda Board, IGEPv2, Freescale iMX51 and ST-E U8500.

The advances that have happened in this cycle are numerous but include a
completely rebuilt archive using GCC 4.4.4 and the latest ARM optimised
tool chain, the Linux kernel version 2.6.35, support for
cross-compiling, a new hardware pack way of building images, 3D
acceleration improvements, u-boot enhancements and initial device tree
support, a new QA tracking structure, the list goes on.

Android in the house

The road ahead looks even more interesting. For the next cycle, the Linaro team is going to build an Android environment on the same kernel and toolchain that we collaborate on with Ubuntu. For folks building devices, picking a board that’s part of the Linaro process means you’ll be able to get either an Ubuntu-style or Android-style core environment up and running at Day 1, which should reduce time to market for everyone.

If the Linaro team pulls this off, it will mean that Linaro provides an intersection point for the majority of the consumer electronics x86 and ARM ecosystem, regardless of the end OS. I’m sure over time we’ll find more groups that are interested in joining the process, and I see no reason why they couldn’t be accommodated in this cadence-driven model.

More players, more diversity in services

It was also good to see folks from Montavista and Mentor at Linaro@UDS this year. Whether the Linaro kernel and toolchain plug into their own distros, or they start to offer their services around the Linaro/Ubuntu/Android BSP’s, the result is a healthier ecosystem with fewer snags and gotchas for device makers.

One group asked me explicitly if Linaro was a Canonical show, and I was glad to say it isn’t. Canonical can’t possibly do everything that embedded Linux needs done, but our competence in cadence and release management makes us good custodians of a public project, which is what we do with Ubuntu itself. Participation and collaboration are at the heart, and they benefit from being partnered with a commitment to delivery and deadlines. We can’t do everything in a single cycle, but we can provide a roadmap for things like kernel defragmentation, the device-tree work, enablement of an ever-increasing cross-section of the ARM ecosystem, and transitions between versions of GCC or Python or X or even Wayland. So Canonical makes a good anchor, but Linaro has room for lots of other service-providers. Having multiple companies participate in Linaro means that the products we’re all shipping get better, faster.

Testing

The Linaro team is also going to focus on repeatable, rigorous testing of the core platform in the next cycle. That harmonises nicely with our growing focus on quality in Ubuntu, and the need for better quality and testing in open source in general. I’m interested to see what tools and results the Linaro team can produce in the next six months. Open source *can* be bulletproof, but it can also degrade in quality if we don’t put the right processes in place upstream and downstream, so this is a very welcome initiative.

The next major transition for Unity will be to deliver it on Wayland, the OpenGL-based display management system. We’d like to embrace Wayland early, as much of the work we’re doing on uTouch and other input systems will be relevant for Wayland and it’s an area we can make a useful contribution to the project.

We’re confident we’ll be able to retain the ability to run X applications in a compatibility mode, so this is not a transition that needs to reset the world of desktop free software. Nor is it a transition everyone needs to make at the same time: for the same reason we’ll keep investing in the 2D experience on Ubuntu despite also believing that Unity, with all its GL dependencies, is the best interface for the desktop. We’ll help GNOME and KDE with the transition, there’s no reason for them not to be there on day one either.

Timeframes are difficult. I’m sure we could deliver *something* in six months, but I think a year is more realistic for the first images that will be widely useful in our community. I’d love to be proven conservative on that but I suspect it’s more likely to err the other way. It might take four or more years to really move the ecosystem. Progress on Wayland itself is sufficient for me to be confident that no other initiative could outrun it, especially if we deliver things like Unity and uTouch with it. And also if we make an early public statement in support of the project. Which this is!

In coming to this view, several scenarios were considered.

One is the continued improvement of X, which is a more vibrant project these days than it once was. X will be around a long time, hence the importance of our confidence levels on the idea of a compatibility environment. But we don’t believe X is setup to deliver the user experience we want, with super-smooth graphics and effects. I understand that it’s *possible* to get amazing results with X, but it’s extremely hard, and isn’t going to get easier. Some of the core goals of X make it harder to achieve these user experiences on X than on native GL, we’re choosing to prioritize the quality of experience over those original values, like network transparency.

We considered the Android compositing environment. It’s great for Android, but we felt it would be more difficult to bring the whole free software stack along with us if we pursued that direction.

We considered and spoke with several proprietary options, on the basis that they might be persuaded to open source their work for a new push, and we evaluated the cost of building a new display manager, informed by the lessons learned in Wayland. We came to the conclusion that any such effort would only create a hard split in the world which wasn’t worth the cost of having done it. There are issues with Wayland, but they seem to be solvable, we’d rather be part of solving them than chasing a better alternative. So Wayland it is.

In general, this will all be fine – actually *great* – for folks who have good open source drivers for their graphics hardware. Wayland depends on things they are all moving to support: kernel modesetting, gem buffers and so on. The requirement of EGL is new but consistent with industry standards from Khronos – both GLES and GL will be supported. We’d like to hear from vendors for whom this would be problematic, but hope it provides yet another (and perhaps definitive) motive to move to open source drivers for all Linux work.

Marcus and Ivanka in the Canonical Design team sat me down for some words of wisdom a few months ago. “You think you need a logo, but what you really need is a new font. One that sets the standard for both professional design, and embracing the values of Ubuntu in the way it’s produced.”

And how right they were.

Figuring that we wanted to do this once, properly, we said we’d build a complete family: various weights, variable-width and mono, across some of the key language groups of our community. We knew we couldn’t do everything but we figured we could establish a rigorous core upon which everything could be done. We’d fully hint and kern the work too, so it’s good enough to be a default interface font for something we all use all day long. A huge project, one that will take some time to finish. But today we’re publishing the first source for Ubuntu, the font, a milestone worth celebrating.

Marcus introduced Bruno Maag of Dalton Maag, who expressed a willingness to engage around an open font, and we agreed to buy the rights to the work completely, so that it could be licensed freely.

Bruno pulled together a very energetic team of typographers: Lukaz, Amelie, Shiraaz, Malcolm and more, all folks who live and breathe type and typography and keen to explore this rather crazy idea of inviting crowds into the inner sanctum of type design.

We knew at the start we were bringing together two very different worlds. We wanted a process which would ensure participation without drowning out the clear leadership needed for a coherent result. Bruno steered Marcus, Ivanka, me and others through a core initial process where we defined the range and scope of what we wanted to take on, and the values we wanted reflected in the result. I learned that a font is grounded in real values, and fortunately we have a strong expression of the six attributes that we value in Ubuntu and Canonical: collaboration, freedom, precision, reliability, adroitness, accessibility. That small team was best positioned to distill those into the typeface, and shape the broad strokes of the work.

Ubuntu is a global phenomenon, and we knew at the start we didn’t have the breadth of eyeballs close at hand to keep the font on track as it expanded. So we planned a process of expanding consultation. First within Canonical, which has folks from nearly 30 countries, and then within the Ubuntu community. We published the font to Ubuntu Members, because we wanted folks who participate and contribute directly to Ubuntu to have the strongest say in the public process of designing the font. We heard from Greek, Turkish, Hebrew, Arabic, Indian, Chinese and many other cultures. Not everyone has glyphs in this first round, but everyone has had a hand in bringing us to this milestone.

The design team needed help with this outreach program, and it turned out that a longstanding member of the community, Paul Sladen, has a personal interest in typography. We noticed a marked uptick in the pace of bug triage when Paul got involved, and it was going so well we asked him to tackle it semi-professionally. The result has been really fast feedback to people making comments. I’d like to thank Paul for bringing that crucial stewardship to bear on the community engagement process, we would not have made it to the deadline without him.

We also had the benefit of a tool produced by Richard Lee and others in the design team, which lets people identify specific issues in the font, particularly as rendered in various web browsers on various platforms. fonttest.design.canonical.com is very cool: it lets you pick the characters, weight and size, takes a screenshot for you in most browsers, or helps you capture the essential details for the bug report. Fonts are software, but they are not software as we know it, Jim. So the tool helps us keep track of all the tricky details that might help debug a problem someone’s having.

A key open question, of course, was licensing. There are two obvious candidates, among quite a large field: the OFL, from SIL, and the GPLv3 with a font-specific clause added. Digging into this in more detail turned up a tricky situation: both approaches have issues which precluded us from adopting them immediately. We started speaking in some detail with Nicolas Spalinger of SIL, and Dave Crossland, who has done extensive analysis on the libre font process and dynamics. We offered to underwrite an SFLC review of the OFL, and SIL has expressed a willingness to participate in that, with a view to finding common ground that would bring Dave, ourselves, and many others under one common font licence, but we were running out of time. So we came to the compromise of an interim license, which you can find at bzr branch lp:ubuntu-font-licence While licence proliferation sucks, I’m optimistic we’ll converge in due course. James Vasile from the SFLC will help ensure the final result is wiser with the help of all the experience the SFLC gained in stewarding the GPLv3, and SIL and Dave will bring deep typographic industry insight.

Dalton Maag have started talking more widely about their experiences so far in the process. I was worried that they might be put off by the rowdy nature of open commentary, but I would credit them with a sterling constitution and thank them for the way they stepped up once the bug tracker really started to hum. There are few issues that are escalated which don’t get a rapid response and framing. Of course, there are differences of opinion, but in many cases genuine issues have been identified and handled. The team at DM have gotten into a great cadence of weekly iterations, and Paul has been ensuring that work makes it into the hands of Ubuntu users. As of today, *all* Maverick users have it installed by default (I believe this is true for Kubuntu as well, at least I answer questions in support of that goal).

What’s really interesting is that DM have said there is world-wide interest in the project. Many professional typographers are starting to think about open fonts. Now is the time to set a very high standard for what is achievable. There are hard questions to be answered about how the business of typography will evolve in the face of open and free type, but historically, those questions have best been answered by the bold: those who get involved, those who put themselves in the front line.

Going forward?

In due course, we’d like the Ubuntu font to reflect the full, extraordinary diversity of the Ubuntu community. We can’t do it all at once, and so we’re proposing a process for communities and cultures that feel part of the Ubuntu family to participate. If you want the Ubuntu font to speak your language, you need to do a few things to prepare for it. The hard, hard part is that you’ll need to find a qualified, local typographer who is interested in participating and in leading the design of your glyphs. You may need to find several, as we won’t necessarily embrace the first candidate. This is a serious matter: we welcome the crowdsourcing of bugs, glitches, rendering problems, hinting and kerning issues, but we want coherent, professional contributions on the core design. If that sounds exclusive: yes it is. Quality takes time, quality takes precedence. There are other fonts with lots of coverage, we have only one shot to get your glyphs done really beautifully then freeze them, metrically, for all time in the Ubuntu font.

The broader process looks like this.

First, you need to create a wiki page for your language / culture / glyphset (could be Klingon! Phoenician! Elvish ) on wiki.ubuntu.com/UbuntuFont/Coverage. There, you need to document the glyph set you think is required, and any historical quirks that are peculiar to doing it well, such as OpenType features or alternative approaches.

Second, you need to file a bug on launchpad.net/ubuntu-font-family called “Ubuntu Font should support [Klingon]“. If you want, you can invite members of your community to note that they are affected by the bug. We’ll be looking for ways to prioritise communities for attention.

Third, you need to contact local typographers, and tell them about Ubuntu, open content, open typography. If they are still listening, you have just opened the door on the future for them and given them a big head start . They will need to be willing to contribute to the font. They will know how much work that will be. They won’t be paid to do it, unless the local community can find a way to raise the funds, but since there is a genuine sense of excitement in the air about open typography and this project in particular, we think you’ll find bold and insightful typographers who are keen to be part of it. Add their details to the wiki page, especially details of their typographic portfolio. Update the bug with that information.

The tools used for open font design are in a state of flux. There are some exceptional technical pieces, and some dark swampy bits too. Dalton Maag will be leading sessions at UDS with folks from the open typography community, with a view to producing what Dave Crossland described as a “lovely long list” (I’m paraphrasing) of bugs and suggestions. Be there if you want to get a professional typographers insight on the toolchain today and what might be possible in the future. All of the Ubuntu font sources are published, though the license does not require source to be published.

Nevertheless, the process for designing your community glyphs will likely involve a mix of free and proprietary tools, at least for the next months. We’ll ask DM to review the portfolios of candidate typographers, and make recommendations for who should be given the go-ahead to lead the work, language by language. Once core glyphs are designed, we’ll facilitate LoCo-based community feedback, much as we did for the main font. We want local Ubuntu members to have the strongest public voice in feedback to their typographer. And Canonical, with DM, will provide feedback aimed at keeping the whole consistent.

Once the glyph design process is wrapped, the typographer will lead hinting and kerning. That’s the tough, detailed part of the job, but essential for an interface font that will be used on screen, everywhere on screen, all the time. And at that point we’ll start automating feedback, using fonttest, as well as starting to integrate those glyphs into the main Ubuntu font. We’ll publish point releases to the main Ubuntu font, with major releases designating points where we update the set of “fixed and metrically frozen” glyphs, point releases denoting occasions where we add or update beta glyphs in the public test font.

In each point release, we’ll include perhaps one or two new glyph sets for beta testing. We’ll prioritize those communities who have followed the process, and have the most substantial community interest in testing.

Phew. If you got this far, you’re interested . This is going to be one of those things that lives a very long time. It will take a long time to get everybody represented. But we’re going to do it, together.

Delighted to receive this today, and to proxy it through to Planets U and G:

Dear Ubuntu Community Council members,

on behalf of the openSUSE Board, I would like to extend this
invitation to you and your community to join us at the
openSUSE Conference in Nuremberg, Germany October 20-23, 2010.

This year more than seventy talks and workshops explore the theme of
‘Collaboration Across Borders‘ in Free and Open Source software
communities, administration and development. We believe that the
program, which includes tracks about distributions, the free desktop and
community, reaches across the borders between our projects and we
would like to ask you to encourage your community to visit the
conference so we get the chance to meet face to face, talk to and
inspire each other.

More information including the program and details about the event you
can find in our announcement at http://bit.ly/oconf2010

Thank you in advance and see you in October!

Henne Vogelsang
openSUSE Board Member

We’ll gladly sponsor a member of the Ubuntu community council to go, busy finding out if anyone can make it. I can’t, but appreciate the sentiment and the action and think it would be great if members of the Ubuntu community can take up the invitation.

Regardless, best wishes for the conference!

We’ll be using Scribus for much of the DTP internal to Canonical. Our templates etc will be published in Scribus, so folks who need to knock up a flyer or brochure have the pieces they need ready to hand. However, there’s a problem, in that the stable Scribus package is really quite old.

The Scribus team is making good progress on the next version of Scribus, but I couldn’t find an easy way to test their trunk. So I thought to make a PPA with a daily build. Whenever I’m testing or evaluating a new app I like to check out trunk, just to get a feel for the pace of activity and quality of the work. A crisp, clean, stable trunk is a sign of good quality work, which will likely mean good quality elsewhere like documentation and project governance. Chaos on trunk means… chaos generally, as a rule.

I wrote to Oleksander Moskalenko, one of the upstream developers and Debian maintainer of the Scribus packages, including a complete set of Ubuntu packages with pretty awesome documentation for how to get the newer versions for testing. He kindly offered to review the package and made some suggestions for things to look out for. And then I got lucky, mentioning that I wanted to do this on #kubuntu-devel, because Philip Muskovac turns out to be in the middle of a quest to do daily build PPA’s of most of KDE!

We already had a Bzr import of Scribus trunk for some reason, so tip is easily accessible via LP and bzr.

Philip knocked up a package recipe combining trunk with a clean packaging branch based on Oleksandr’s scribus-ng package. Et voila, LP is now doing all the work to deliver us a nice dose of Scribus goodness every day. So here’s an invitation to DTP-heads everywhere: if you’d like to see the very latest work of the Scribus team, just add that PPA to your sources and grab scribus-trunk:

sudo apt-add-repository ppa:scribus/ppa
sudo apt-get update
sudo apt-get install scribus-trunk

Generally, if the packaging branch is clean, a daily build is pretty stable, it might need a tweak now and then but that work is useful to the packager as an early warning on packaging changes needed for the next version, anyway. And it’s usually easier to fix something if you know exactly what changed to break it

I’d like to thank Philip and Oleksandr for rocking the park, and the Scribus folks for a wonderful tool that will get wider use now within Canonical and, hopefully, elsewhere too.

The Scribus trunk packages seem to work very well on Unity, the Qt/dbusmenu integration is tight in this newer version, so it’s very usable with the panel menu and launching it full-screen feels right on my laptop. I’m enjoying the extra detailed control that Scribus gives with the use of fonts over apps like OO.o and AbiWord, since I’m becoming a font nerd these days with all the work on Ubuntu.

There is a flag day transition to be aware of, though, as newer Scribus files are not compatible with those of the stable scribus. Nevertheless, both this trunk build and the scribus-ng packages Oleksandr maintains seem pretty stable to me, so we’ll be using the newer format and holding our breath till the actual release. No pressure, team Scribus

Update: Philip’s published Lucid packages as well!