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.

Qt apps on Ubuntu

Tuesday, January 18th, 2011

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.

Linaro at work: porting, testing, and Android

Thursday, November 11th, 2010

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.


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.

I spent a lot of time observing our community, this release. For some reason I was curious to see how our teams work together, what the dynamic is, how they work and play together, how they celebrate and sadly, also how they mourn. So I spent a fair amount more time this cycle reading lists from various Ubuntu teams, reading minutes from governance meetings for our various councils, watching IRC channels without participating, just to get a finger on the pulse.

Everywhere I looked I saw goodness: organised, motivated, cheerful and constructive conversations. Building a free OS involves an extraordinary diversity of skills, and what’s harder is that it requires merging the contributions from so many diverse disciplines and art forms. And yet, looking around the community, we seem to have found patterns for coordination and collaboration that buffer the natural gaps between all the different kinds of activities that go on.

There are definitely things we can work on. We have to stay mindful of the fact that Ubuntu is primarily a reflection of what gets done in the broader open source ecosystem, and stay committed to transmitting their work effectively, in high quality (and high definition :-)) to the Ubuntu audience. We have to remind those who are overly enthusiastic about Ubuntu that fanboyism isn’t cool, I saw a bit of “We rock you suck” that’s not appropriate. But I also saw folks stepping in and reminding those who cross the line that our values as a community are important, and the code of conduct most important of all.

So I have a very big THANK YOU for everyone. This is our most valuable achievement: making Ubuntu a great place to get stuff done that has a positive impact on literally millions of people. Getting that right isn’t technical, but it’s hard and complex work. And that’s what makes the technical goodness flow.

In particular, I’d like to thank those who have stepped into responsibilities as leaders in large and small portions of our Ubuntu universe. Whether it’s organising a weekly newsletter, coordinating the news team, arranging the venue for a release party, reviewing translations from new translators in your language, moderating IRC or reviewing hard decisions by IRC moderators, planning Kubuntu or leading MOTU’s, the people who take on the responsibility of leadership are critical to keeping Ubuntu calm, happy and productive.

But I’d also like to say that what made me most proud was seeing folks who might not think of themselves as leaders, stepping up and showing leadership skills.

There are countless occasions when something needs to be said, or something needs to get done, but where it would be easy to stay silent or let it slip, and I’m most proud of the fact that many of the acts of leadership and initiative I saw weren’t by designated or recognised leaders, they were just part of the way teams stayed cohesive and productive. I saw one stroppy individual calmly asked to reconsider their choice of words and pointed to the code of conduct by a newcomer to Ubuntu. I saw someone else step up and lead a meeting when the designated chairman couldn’t make it. That’s what makes me confident Ubuntu will continue to grow and stay sane as it grows. That’s the really daunting thing for me – as it gets bigger, it depends on a steady supply of considerate and thoughtful people who are passionate about helping do something amazing that they couldn’t do on their own. It’s already far bigger than one person or one company – so we’re entirely dependent on broader community commitment to the values that define the project.

So, to everyone who participates, thank you and please feel empowered to show leadership whenever you think we could do better as a community. That’s what will keep us cohesive and positive. That’s what will make sure the effort everyone puts into it will reach the biggest possible audience.

With that said, well done everyone on a tight but crisp post-LTS release. Maverick was a challenge, we wanted to realign the cycle slightly which compressed matters but hopefully gives us a more balanced April / October cadence going forward based on real data for real global holiday and weather patterns :-). There was an enormous amount of change embraced and also change deferred, wisely. You all did brilliantly. And so, ladies an gentlemen, I give you Mr Robbie Williamson and the Maverick Release Announcement. Grab your towel and let’s take the Meerkat out on a tour of the Galaxy ;-)

GMailWatcher for webmail lovers

Thursday, September 16th, 2010

Owais Lone wanted this mentioned on Planet Ubuntu, so I’m proxying for his blog announcement since he isn’t yet an Ubuntu Member:

In case you don’t already know, GmailWatcher is a Gmail notifier specifically designed for the Ubuntu Operating System. It relies heavily on Ubuntu specific packages like MeMenu, Notifications, DesktopCouch but I’m planning a stock Gnome version also so that people on Fedora, Suse and other rocking distribution can use it too.

Most notable features are:

  • Multiple Accounts
  • Google Apps support
  • Secure password storage using Gnome-Keyring support
  • Themable unread emails page
  • Preferences sync using U1

Right now, my target is to make it stable/usable enough in time for Maverick.

This post is essentially a call for user feedback. I would like to know what you don’t like about the way GmailWatcher works. Bugs, usability issues, appearance, anything that doesn’t count as a new feature.

Prompted in part by the critique of Canonical’s code contributions to the kernel and core GNOME infrastructure, I’ve been pondering whether or not I feel good about what I do every day, and how I do it. It’s important for me to feel that what I do is of service to others and makes the world a better place for it having been done. And in my case, that it’s a contribution commensurate with the good fortune I’ve had in life.

Two notes defined for me what I feel I contribute, in this last month. One was a thank-you from New Zealand, from someone who is watching Ubuntu 10.04 make a real difference in their family’s life. For them it seems like a small miracle of human generosity that this entire, integrated, working environment exists and is cared for by thousands of people. The other was a support contract for tens of thousands of desktops running Ubuntu 10.04 in a company. Between those two, we have the twin pillars of the Ubuntu Project and Canonical: to bring all the extraordinary generosity of the free software community to the world at large, as a gift, free of charge, unencumbered and uncrippled, and to do so sustainably.

The first story, from New Zealand, is about someone who is teaching their children to use computers from a young age, and who has observed how much more they get done with Ubuntu than with Windows, and how much more affordable it is to bring computing to all the kids in their community with Ubuntu. For them, the fact that Ubuntu brings them this whole world of free software in one neat package is extraordinary, a breakthrough, and something for which they are very grateful.

It’s a story that I hope to see replicated a hundred million times. And it’s a story which brings credit and satisfaction not just to me, and not just to the people who make Ubuntu the focus of their love and energy, but to all of those who participate in free software at large. Ubuntu doesn’t deserve all the credit, it’s part of a big and complex ecosystem, but without it that delivery of free software just wouldn’t have the same reach and values.

We all understand that the body of free software needs many organs, many cells, each of which has their own priorities and interests. The body can only exist thanks to all of them. We are one small part of the whole, it’s a privilege for us to take up the responsibilities that we do as a distribution. We have the responsibility of choosing a starting point for those who will begin their free software journey with Ubuntu, and we work hard to make sure that all of those pieces fit well together.

Ubuntu, and the possibilities it creates, could not have come about without the extraordinary Linux community, which wouldn’t exist without the GNU community, and couldn’t have risen to prominence without the efforts of companies like IBM and Red Hat. And it would be a very different story if it weren’t for the Mozilla folks and Netscape before them, and GNOME and KDE, and Debian, and Google and everyone else who have exercised that stack in so many different ways, making it better along the way. There are tens of thousands of people who are not in any way shape or form associated with Ubuntu, who make this story real. Many of them have been working at it for more than a decade – it takes a long time to make an overnight success :) while Ubuntu has only been on the scene six years. So Ubuntu cannot be credited solely for the delight of its users.

Nevertheless, the Ubuntu Project does bring something unique, special and important to free software: a total commitment to everyday users and use cases, the idea that free software should be “for everyone” both economically and in ease of use, and a willingness to chase down the problems that stand between here and there. I feel that commitment is a gift back to the people who built every one of those packages. If we can bring free software to ten times the audience, we have amplified the value of your generosity by a factor of ten, we have made every hour spent fixing an issue or making something amazing, ten times as valuable. I’m very proud to be spending the time and energy on Ubuntu that I do. Yes, I could do many other things, but I can’t think of another course which would have the same impact on the world.

I recognize that not everybody will feel the same way. Bringing their work to ten times the audience without contributing features might just feel like leeching, or increasing the flow of bug reports 10x. I suppose you could say that no matter how generous we are to downstream users, if upstream is only measuring code, then any generosity other than code won’t be registered. I don’t really know what to do about that – I didn’t found Ubuntu as a vehicle for getting lots of code written, that didn’t seem to me to be what the world needed. It needed a vehicle for getting it out there, that cares about delivering the code we already have in a state of high quality and reliability. Most of the pieces of the desktop were in place – and code was flowing in – it just wasn’t being delivered in a way that would take it beyond the server, or to the general public.

The second email I can’t quote from, but it was essentially a contract for services from Canonical to help a company move more than 20,000 desktops from Windows to Ubuntu. There have been several engagements recently of a similar scale, the pace is accelerating as confidence in Ubuntu grows. While Linux has long proven itself a fine desktop for the inspired and self-motivated developer, there is a gap between that and the needs of large-scale organisations. There isn’t another company that I’m aware of which is definitively committed to the free software desktop, and so I’m very proud that Canonical is playing that role in the free software ecosystem. It would be sad for me if all the effort the free software community puts into desktop applications didn’t have a conduit to those users.

There’s nothing proprietary or secret that goes into the desktops that Canonical supports inside large organisations. The true wonder for me is that the story from New Zealand, and the corporate story, both involve exactly the same code. That to me is the true promise of free software; when I have participated in open source projects myself, I’ve always been delighted that my work might serve my needs but then also be of use to as many other people as possible.

Ubuntu is a small part of that huge ecosystem, but I feel proud that we have stepped up to tackle these challenges.

Canonical takes a different approach to the other companies that work in Linux, not as an implicit criticism of the others, but simply because that’s the set of values we hold. Open source is strengthened by the fact that there are so many different companies pursuing so many different, important goals.

In recent weeks it’s been suggested that Canonical’s efforts are self-directed and not of benefit to the broader open source community. That’s a stinging criticism because most of us feel completely the opposite, we’re motivated to do as much as we can to further the cause of free software to the benefit both of end-users and the community that makes it, and we’re convinced that building Ubuntu and working for Canonical are the best ways to achieve that end. It’s prompted a lot of discussion and consideration for each of us and for Canonical as a whole. And this post is a product of that consideration: a statement for myself of what I feel I contribute, and why I feel proud of the effort I put in every day.

What do we do for free software? And what do I do myself?

For a start, we deliver it. We reduce the friction and inertia that prevent people trying free software and deciding for themselves if they like it enough to immerse themselves in it. Hundreds of today’s free software developers, translators, designers, advocates got the opportunity to be part of our movement because it was easy for them to dip their toe in the water. And that’s not easy work. Consider the effort over many years to produce a simple installer for Linux like http://www.techdrivein.com/2010/08/massive-changes-coming-to-ubuntu-1010.html which is the culmination of huge amounts of work from many groups, but which simply would not have happened without Canonical and Ubuntu.

There are thousands of people who are content to build free software for themselves, and that’s no crime. But the willingness to shape it into something that others will find, explore and delight in needs to be celebrated too. And that’s a value which is celebrated very highly in the Ubuntu community: if you read planet.ubuntu.com you’ll see a celebration of *people using free software*. As a community we are deeply satisfied to see people *using* it to solve problems in their lives. That’s more satisfying to us than stories about how we made it faster or added a feature. Of course we do bits of both, but this is a community that measures impact in the world rather than impact on the code. They are very generous with their time and expertise, with that as the reward. I’m proud of the fact that Ubuntu attracts people who are generous in their contributions: they feel their contributions are worth more if they are remixed by others, not less. So we celebrate Kubuntu and Xubuntu and Puppy and Linux Mint. They don’t ride on our coattails, they stand on our shoulders, just as we stand on the shoulders of giants. And that’s a good thing. Our work is more meaningful and more valuable because their work reaches users that ours alone could not.

What else?

We fix it, too. Consider the https://wiki.ubuntu.com/PaperCut Papercuts project, born of the recognition that all the incredible technology and effort that goes into making something as complex as the Linux kernel is somehow diminished if the average user gets an incomprehensible result when they do something that should Just Work. Hundreds of Papercuts have been fixed, across many different applications, benefiting not just Ubuntu but also every other distribution that ships those applications. If you think that’s easy, consider the effort involved to triage and consider each of thousands of suggestions, coordinating a fix and the sharing of it. The tireless efforts of a large team have made an enormous difference. Consider this: saving millions of users one hour a week is a treasury of energy saved to do better things with free software. While the Canonical Design team played a leading role in setting up the Papercuts project, the real stars are people like http://www.omgubuntu.co.uk/2010/06/maverick-papercut-hunting-season-opens.html Vish and Sense who rally the broader papercuts team to make a difference. Every fix makes a difference, on the desktop http://ubuntuserver.wordpress.com/2010/01/20/ubuntu-server-papercuts-project/ and the server.

At a more personal level, a key thing I put energy into is leadership, governance and community structure. When we started Ubuntu, I spent a lot of time looking at different communities that existed at the time, and how they managed the inevitable tensions and differences of opinion that arise when you have lots of sharp people collaborating. We conceived the idea of a code of conduct that would ensure that our passions for the technology or the work never overwhelmed the primary goal of bringing diverse people together to collaborate on a common platform. I’m delighted that the idea has spread to other projects: we don’t want to hoard ideas or designs or concepts, that would be contrary to our very purpose.

We setup a simple structure: a technical board and a community council. That approach is now common in many other projects too. As Ubuntu has grown, so that governance has evolved, there are now multiple leadership teams for groups like Kubuntu and the Forums and IRC, who provide counsel and guidance for teams of LoCo’s and moderators and ops and developers, who in turn strive for technical perfection and social agility as part of an enormous global community. That’s amazing. When people start participating in Ubuntu they are usually motivated as much by the desire to be part of a wonderful community as they are to fix a specific problem or ease a specific burden. Over time, some of those folks find that they have a gift for helping others be more productive, resolving differences of opinion, doing the work to organise a group so that much more can be achieved than any one individual could hope to do. Ubuntu’s governance structures create opportunities for those folks to shine: they provide the backbone and structure which makes this community able to scale and stay productive and happy.

A project like Ubuntu needs constant care in order to defend its values. When you are tiny and you put up a flag saying “this is what we care about” you tend to attract only people who care about those things. When the project grows into something potent and visible, though, you tend to attract EVERYONE, because people want to be where the action is. And then the values can easily be watered down. So I continue to put energy into working with the Ubuntu community council, and the Canonical community team, both of which are profoundly insightful and hard-working which makes that part of my work a real pleasure. The Ubuntu community council take their responsibility as custodian of the projects community values very seriously indeed. The CC is largely composed of people who are not affiliated with Canonical, but who nevertheless believe that the Ubuntu project is important to free software as a whole. And the awesome Jono Bacon, the delightful Daniel Holbach, and unflappable Jorge Castro are professionals who understand how to make communities productive and happy places to work.

Something as big as the Ubuntu community cannot be to the credit of me or any other individual, but I’m proud of the role I’ve played, and motivated to continue to play a role as needed.

In more recent years I’ve come to focus more on championing the role of design in free software. I believe that open source produces the best quality software over time, but I think we need a lot more cogent conversations about the experiences we want to create for our users, whether it’s on the desktop, the netbook or the server. So I’ve put a lot of my leadership energy into encouraging various communities – both Ubuntu and upstream – to be welcoming of those who see software through the eyes of the new user rather than the experienced hacker. This is a sea change in the values of open source, and is not something I can hope to achieve alone, but I’m nevertheless proud to be a champion of that approach and glad that it’s steadily becoming accepted.

There were designers working in free software before we made this push. I hope they feel that Canonical’s emphasis on the design-lead approach has made their lives easier, and the community at large more appreciative of their efforts and receptive to their ideas. But still, if you *really* care about design in free software, the Canonical design team is the place to be.

I do some design work myself, and have participated most heavily in the detailed design of Unity, the interface for Ubuntu Netbook Edition 10.10. That’s an evolution of the older UNR interface; most importantly, it’s a statement that Linux desktops don’t need to be stuck in the 90′s, we can and will attempt to build new and efficient ways of working with computers. I’ve been delighted with the speed at which some of Unity’s facilities have been adopted by hundreds of projects, their goal is to make using Linux easier and classier for everyone, so that pace of adoption is a measure of the speed at which we are reducing the friction for new users discovering a better way to use their PC’s.

Design without implementation would leave us open to accusations of wanting others to do our work for us, so I’m proud also to lead a wonderful team that is doing the implementation of some of those key components. Things like dbusmenu have proven useful for bringing consistency to the interfaces of both GNOME and KDE applications running under Unity, and I very much hope they are adopted by other projects that need exactly the facilities they provide. I’d credit that engineering team with their focus on quality and testability and their desire to provide developers with clean API’s and good guidance on how best to use them. If you’ve used the full set of Indicators in 10.10 then you know how this quiet, persistent work that has engaged many different projects has transformed the panel into something crisp and efficient. Utouch is coming up for its first release, and will continue to evolve, so that Ubuntu and GNOME and KDE can have an easy road to multi-touch gesture interface goodness.

Beyond my own personal time, I also support various projects through funding. Putting money into free software needs to meet a key test: could that money achieve a better outcome for more people if it were directed elsewhere? There are lots of ways to help people: $100,000 can put a lot of people through school, clothed and fed. So I really need to be confident that the money is having a real, measurable impact on people’s lives. The thank you notes I get every week for Ubuntu help sustain that confidence. More importantly, my own observation of the catalytic effect that Ubuntu has had on the broader open source ecosystem, in terms of new developers attracted, new platforms created, new businesses launched and new participants acknowledged, make me certain that the funding I provide is having a meaningful consequence.

When Ubuntu was conceived, the Linux ecosystem was in a sense fully formed. We had a kernel. We had GNOME and KDE. We had X and libc and GCC and all the other familiar tools. Sure they had bugs and they had shortcomings and they had roadmaps to address them. But there was something missing: sometimes it got articulated as “marketing”, sometimes as “end-user focus”. I remember thinking “that’s what I could bring”. So Ubuntu, and Canonical, have quite explicitly NOT put effort into things which are obviously working quite well, instead, we’ve tried to focus on new ideas and new tools and new components. I see that as an invigorating contribution to the broader open source ecosystem, and I hear from many people that they perceive it the same way. Those who say “but Canonical doesn’t do X” may be right, but that misses all the things we do, which weren’t on the map beforehand. Of course, there’s little that we do exclusively, and little that we do that others couldn’t if they made that their mission, but I think the passion of the Ubuntu community, and the enthusiasm of its users, reflects the fact that there is something definitively new and distinctive about the project. That’s something to celebrate, something to be proud of, and something to motivate us to continue.

Free software is bigger than any one project. It’s bigger than the Linux kernel, it’s bigger than GNU, it’s bigger than GNOME and KDE, it’s bigger than Ubuntu and Fedora and Debian. Each of those projects plays a role, but it is the whole which is really changing the world. So when we start to argue with one another from the perspective of any one slice of free software, we run the risk of missing the bigger picture. That’s a bit like an auto-immune disease, where the body starts to attack itself. By definition, someone else who is working hard all day long to bring free software to a wider audience is on the same side as me, compared to 99% of the rest of the world, if I want to think in terms of sides. I admire and respect everyone who puts energy into advancing the cause of free software, even if occasionally I might differ on the detail of how it can be done.…..

Friday, August 20th, 2010

Saw this URL fly by today… wow and thank you to the Ubuntu Ads guys :-)

So, who’s up for making Maverick Movies? It would be great to have a “10 best features in 10.10″ video collection for release. Unity’s awesome and then there are things to show off in OO.o, Gnome, Firefox…. giving credit where it’s due.

I put together https://wiki.ubuntu.com/MaverickMovies as a starting place to aggregate content. Have subscribed, so if you update that page I’ll see it. If that goes nicely, we can beef the process up in the runup to release.


Tuesday, August 17th, 2010

Oh yes, it’s that time of year again, when numerate pollsters make nasal proclamations about the naming of the next next version of Ubuntu. When gazers of balls crystal provide nifty suggestions for new new features and, of course, suitable nomenclature to match.

What will it be? A Naiant Nailtail would make a fine coat of arms, but we’re not really in the business of arms. Most of our businesses have legs. Most, I say. We could hedge our bets and go with the Neutral Newt, but it’s placing bets and seeing them through that raises the game for the free software desktop, and now’s a time of great change and invention, not a time for fence-sitting.

I’ve been procrastinating. The N-evitable nature of our cadence means that calls for something nicer than “Maverick+1″ are increasingly noticeable. Naively, I always assume that the answer will leap off the page. Instead, what leaps off the page is a gazillion permutations and combinations of nubile, naughty, naiad and nymph. Moving swiftly onward I linger on the possibilities of the Numbat. Nah. There’s no doubt Fourecks can be a rich source of inspiration, now’s not the time to celebrate Van Diemen’s Land, we’ve better plans for that. And speaking of Fourecks, the Nobby Noctule sounds like something dreamed up by Terry Pratchett, perhaps a fitting way to move beyond Adam’s 10.10.10, but it really is hard to sing the praises of a bat. Especially one with (k)nobs.

As you can imagine, after a few weeks with a dictionary and colouring in book of animals, I could draw this out N-definitely. The problem is NP-complete, which I’m now reliably informed by the good folks at HP means it’s provably quite difficult and not something that can be delegated to chips of the non-quantum kind. My chips are most definitely non-quantum though my bugs, strangely, are.

Where did that leave us?

Well, let’s look at what we want to get done.

We have this whole design thing in full flow, which is making Ubuntu sleeker and more stylish, as well as making it smoother for those who just want to get stuff done. We’ll make the N release the best-dressed ever. But classy covers don’t equate to good reads – we want style and substance to meet and get along famously. Once Maverick is out the door we’ll be turning our attention to making the most of the amazing capabilities of modern graphics hardware, both for outer beauty and for inner efficiency. There’s a lot more to GL than glitz and glamour, though we won’t say no to either.

We’re also putting a lot of work into chips and architectures (admittedly, not yet of the quantum sort) that keep cool, and help keep the planet cool in the process. So it would be nice to have a codename which reflects that goodness. Some sort of mascot for a cool planet would do the trick.

And so, we come swiftly to a conclusion: allow me to introduce the Natty Narwhal, our mascot for development work that we expect to deliver as Ubuntu 11.04.

The Narwhal, as an Arctic (and somewhat endangered) animal, is a fitting reminder of the fact that we have only one spaceship that can host all of humanity (trust me, a Soyuz won’t do for the long haul to Alpha Centauri). And Ubuntu is all about bringing the generosity of all contributors in this functional commons of code to the widest possible audience, it’s about treating one another with respect, and it’s about being aware of the complexity and diversity of the ecosystems which feed us, clothe us and keep us healthy. Being a natty narwhal, of course, means we have some obligation to put our best foot forward. First impressions count, lasting impressions count more, so let’s make both and make them favourable.

While it may not in fact get you a pony, the world of free software is the platform upon which the future is being built. So the Narwhal, as the closest thing to a real live unicorn, is an auspicious figurehead as we lay down the fabric from which dreams will be woven. Dreams of someone’s first PC, dreams of someone’s first million instances in the cloud: whatever your vision of the future, we hope the Natty Narwhal will have something to offer. Test your gems against that unicorn – some will be glass, others of value. Perhaps the unicorn will bring you Luck, perhaps a cure for poisons proprietary. One thing is certain: we’ll be building it together with thousands of the most generous, insightful, fun people on the planet – not only those in the Ubuntu community, but those who participate in the whole of the free software ecosystem, from a2jmidid to zzliplib, with Debian (happy Birthday!, now longer in the tooth, wiser, but as potent and principled as ever) a special partner. I’m looking forward to the ride, and the result!

Gestures with multitouch in Ubuntu 10.10

Monday, August 16th, 2010

Multitouch is just as useful on a desktop as it is on a phone or tablet, so I’m delighted that the first cut of Canonical’s UTouch framework has landed in Maverick and will be there for its release on 10.10.10.

You’ll need 4-finger touch or better to get the most out of it, and we’re currently targeting the Dell XT2 as a development environment so the lucky folks with that machine will get the best results today. By release, we expect you’ll be able to use it with a range of devices from major manufacturers, and with addons like Apple’s Magic Trackpad.

The design team has lead the way, developing a “touch language” which goes beyond the work that we’ve seen elsewhere. Rather than single, magic gestures, we’re making it possible for basic gestures to be chained, or composed, into more sophisticated “sentences”. The basic gestures, or primitives, are like individual verbs, and stringing them together allows for richer interactions. It’s not quite the difference between banging rocks together and conducting a symphony orchestra, but it feels like a good step in the right direction ;-)

The new underlying code is published on Launchpad under the GPLv3 and LGPLv3, and of course there are quite a lot of modules for things like X and Gtk which may be under licenses preferred by those projects. There’s a PPA if you’re interested in tracking the cutting edge, or just branch / push/ merge on LP if you want to make it better. Details in the official developer announcement. The bits depend on Peter Hutterer’s recently published update to the X input protocols related to multi-touch, and add gesture processing and gesture event delivery. I’d like to thank Duncan McGreggor for his leadership of the team which implemented this design, and of course all the folks who have worked on it so far: Henrik Rydberg, Rafi Rubin, Chase Douglas, Stephen Webb at the heart of it, and many others who have expanded on their efforts.

In Maverick, quite a few Gtk applications will support gesture-based scrolling. We’ll enhance Evince to show some of the richer interactions that developers might want to add to their apps. Window management will be gesture-enabled in Unity, so 10.10 Netbook Edition users with touch screens or multi-touch pads will have sophisticated window management at their fingertips. Install Unity on your desktop for a taste of it, just apt-get install ubuntu-netbook and choose the appropriate session at login.

The roadmap beyond 10.10 will flesh out the app developer API and provide system services related to gesture processing and touch. It would be awesome to have touch-aware versions of all the major apps – browser, email, file management, chat, photo management and media playback – for 11.04, but that depends on you! So if you are interested in this, let’s work up some branches :-) Here’s the official Canonical blog post, too.

Tribalism is the enemy within

Friday, July 30th, 2010

Tribalism is when one group of people start to think people from another group are “wrong by default”. It’s the great-granddaddy of racism and sexism. And the most dangerous kind of tribalism is completely invisible: it has nothing to do with someone’s “birth tribe” and everything to do with their affiliations: where they work, which sports team they support, which linux distribution they love.

There are a couple of hallmarks of tribal argument:

1. “The other guys have never done anything useful”. Well, let’s think about that. All of us wake up every day, with very similar ambitions and goals. I’ve travelled the world and I’ve never met a single company, or country, or church, where *everybody* there did *nothing* useful. So if you see someone saying “Microsoft is totally evil”, that’s a big red flag for tribal thinking. It’s just like someone saying “All black people are [name your prejudice]“. It’s offensive nonsense, and you would be advised to distance yourself from it, even if it feels like it would be fun to wave that pitchfork for a while.

2. “Evidence contrary to my views doesn’t count.” So, for example, when a woman makes it to the top of her game, “it’s because she slept her way there”. Offensive nonsense. And similarly, when you see someone saying “Canonical didn’t actually sponsor that work by that Canonical employee, that was done in their spare time”, you should realize that’s likely to be offensive nonsense too.

Let’s be clear: tribalism makes you stupid. Just like it would be stupid not to hire someone super-smart and qualified because they’re purple, or because they are female, it would be stupid to refuse to hear and credit someone with great work just because they happen to be associated with another tribe.

The very uncool thing about being a fanboy (or fangirl) of a project is that you’re openly declaring both a tribal affiliation and a willingness to reject the work of others just because they belong to a different tribe.

One of the key values we hold in the Ubuntu project is that we expect everyone associated with Ubuntu to treat people with respect. It’s part of our code of conduct – it’s probably the reason we *pioneered* the use of codes of conduct in open source. I and others who founded Ubuntu have seen how easily open source projects descend into nasty, horrible and unproductive flamewars when you don’t exercise strong leadership away from tribal thinking.

Now, bad things happen everywhere. They happen in Ubuntu – and because we have a huge community, they are perhaps more likely to happen there than anywhere else. If we want to avoid human nature’s worst consequences, we have to work actively against them. That’s why we have strong leadership structures, which hopefully put people who are proven NOT to be tribal in nature into positions of responsibility. It takes hard work and commitment, but I’m grateful for the incredible efforts of all the moderators and council members and leaders in LoCo teams across this huge and wonderful project, for the leadership they exercise in keeping us focused on doing really good work.

It’s hard, but sometimes we have to critique people who are associated with Ubuntu, because they have been tribal. Hell, sometimes I and others have to critique ME for small-minded and tribal thinking. When someone who calls herself “an Ubuntu fan” stands up and slates the work of another distro we quietly reach out to that person and point out that it’s not the Ubuntu way of doing things. We don’t spot them all, but it’s a consistent practice within the Ubuntu leadership team: our values are more important than winning or losing any given debate.

Do not be drawn into a tribal argument on Ubuntu’s behalf

Right now, for a number of reasons, there is a fever pitch of tribalism in plain sight in the free software world. It’s sad. It’s not constructive. It’s ultimately going to be embarrassing for the people involved, because the Internet doesn’t forget. It’s certainly not helping us lift free software to the forefront of public expectations of what software can be.

I would like to say this to everyone who feels associated with Ubuntu: hold fast to what you know to be true. You know your values. You know how hard you work. You know what an incredible difference your work has made. You know that you do it for a complex mix of love and money, some more the former, others the more latter, but fundamentally you are all part of Ubuntu because you think it’s the most profound and best way to spend your time. Be proud of that.

There is no need to get into a playground squabble about your values, your ethics, your capabilities or your contribution. If you can do better, figure out how to do that, but do it because you are inspired by what makes Ubuntu wonderful: free software, delivered freely, in a way that demonstrates real care for the end user. Don’t do it because you feel intimidated or threatened or belittled.

The Gregs are entitled to their opinions, and folks like Jono and Dylan have set an excellent example in how to rebut and move beyond them.

I’ve been lucky to be part of many amazing things in life. Ubuntu is, far and away, the best of them. We can be proud of the way we are providing leadership: on how communities can be a central part of open source companies, on how communities can be organised and conduct themselves, on how the economics of free software can benefit more than just the winning distribution, on how a properly designed user experience combined with free software can beat the best proprietary interfaces any day. But remember: we do all of those things because we believe in them, not because we want to prove anybody else wrong.