Developers are a crucial part of any successful software platform. In the same way that an operating system is “just” a means for people to use applications, a platform is “just” a means for developers to create applications and make them available to people.
There are three primary ways in which Ubuntu can help developers do their work. They are all related, but distinct, and so we should consider them individually:
1. Developing for Ubuntu
Today, Ubuntu bundles thousands of free software applications, for both clients and servers, most of which are packaged by Debian.
In both of these cases, many of these applications are actually developed on other platforms, and ported to Ubuntu, either by the free software community or by the creators of the software.
2. Developing on Ubuntu
Ubuntu is already quite popular among developers, who mainly run Desktop Edition on their workstations. They might be developing:
- web applications (with server-side and browser components)
- portable applications (e.g. using Java, or Adobe AIR)
- mobile applications (e.g. for Android or iOS)
- native applications, which might target Ubuntu Desktop Edition itself, or supporting multiple platforms through a framework like Qt
3. Distributing through Ubuntu
Like other modern operating systems, Ubuntu isn’t just a platform where applications run, but also a system for finding and installing applications. Starting with APT, which originated in Debian, we’ve added Software Center, the ISV partner repository, and various other capabilities in this area. They all help to connect developers with users, facilitating distribution of software to users, and feedback to developers.
So, where should we focus?
Some developers might be interested in all three of these, while others might only care about one or two.
However, most of the developer improvements we could make in Ubuntu would only address one of these areas.
For this reason, I think it’s important that we consider the question of the relative importance of these three developer scenarios. Given that we want Ubuntu to flourish as a platform, how would we prioritize them?
I have my own ideas, which I’ll write about in subsequent posts, but here’s your chance to tell me what you think. :-)
When most people talk about Ubuntu, they usually mean our flagship product, Ubuntu Desktop Edition. Sometimes, they might mean the Ubuntu project, or the community of people who work on it, or various other things.
Similarly, Debian might mean the Debian operating system, or the package repositories, or the project, and so on.
This gets a little confusing sometimes. When I’m talking about Ubuntu, I’ve started to use more specific terminology to explain what I mean, and this seems to help people understand better the nature of the whole Ubuntu. In particular, I use the three Ps:
- a portfolio of products, including Desktop Edition, Server Edition, Netbook Edition, Kubuntu and more. These are software bundles which can be downloaded, pre-installed on retail computers, and so on. Each one is designed to meet a certain set of user needs, and to work on a specific form factor of computer.
- a technology platform, which can be used to build a wide range of products. It is primarily of interest to developers, who build derivative distributions, OS products, applications and infrastructure using Ubuntu packages. This platform is the common foundation of the Ubuntu products above, and includes things like the global package repository. Joel Spolsky does a good job of explaining why platforms are distinctly different from products, and should be treated as such.
- an open community project, which collectively produces, distributes, promotes and supports the products and the platform. The Ubuntu project has a philosophy, a government, and various tools and processes to help contributors work together. Canonical supports the Ubuntu project by providing resources and infrastructure, and also directly participates in Ubuntu at various levels.
This breakdown may seem a bit obvious to those of us “on the inside”, but it’s confusing to people who are encountering it for the first time. I’m sharing this in the hope that if more people start using the same words, it will get easier for people to understand how these pieces fit together. I’ll also be linking to it a lot, to help put things into context using this framework.
In my professional role as Ubuntu CTO, I take on a number of different perspectives, which sometimes compete for my attention, including:
- Inward – supporting the people in my department, alignment with other departments in Canonical and reporting upward
- Outward – connecting with customers, partners and the free software community, including Debian
- Forward – considering the future of the Ubuntu platform and products, based on the needs of their users, our customers and business stakeholders within Canonical
- Outside-in – taking off my Canonical hat and putting on an Ubuntu hat, and looking at what we’re doing from an outside perspective
My recent work, as Canonical has gone through a period of organizational growth and change, has prioritized the inward perspective. I took on a six-month project which was inwardly focused, temporarily handing off many of my day-to-day responsibilities (well done, Robbie!). I’ve grappled with an assortment of growing pains as many new people joined Canonical over the past year.
With that work behind me, it’s time to rebalance myself and focus more outside of Canonical again. It’s good to be back!
In my outward facing capacity, I’ll shortly be attending Web 2.0 Summit in San Francisco. I attend several free software conferences each year, but this is a different crowd. I hope to renew some old ties, form some new ones, and generally derive inspiration from the people and organizations represented there. Being in the San Francisco Bay area will also give me an opportunity to meet with some of Canonical’s partners there, as well as friends and acquaintances from the free software community. With my head down, working hard to make things happen, it’s easy to lose perspective on how that work fits into the outside world. Spending more time with people outside of Canonical and Ubuntu is an important way of balancing that effect.
Looking forward, I’ll be thinking about the longer term direction for the Ubuntu platform. The platform is the layer of Ubuntu which makes everything else possible: it’s how we weave together products like Desktop Edition and Server Edition, and it’s what developers target when they write applications. Behind the user interfaces and applications, there is a rich platform of tools and services which link it all together. It’s in this aspect of Ubuntu that I’ll be investing my time in research, experimentation and imagination. This includes considering how we package and distribute software, how we adapt to technological shifts, and highlighting opportunities to cooperate with other open source projects.
My primary outside-in role is as chair of the Ubuntu Technical Board. In this capacity, I’m accountable to the Ubuntu project, the interests of its members, and the people who use the software we provide. Originally, the TB was closely involved with a range of front-line technical decisions in Ubuntu, but today, there are strong, autonomous teams in place for the most active parts of the project, so we only get involved when there is a problem, or if a technical question comes up which doesn’t “fit” the charter of an established team. It’s something of a catch-all. I’d like to re-establish the TB in a more central role in Ubuntu, looking after concerns which affect the project as a whole, such as transparency and development processes. I’m also re-joining Debian as a non-uploading contributor, to work on stimulating and coordinating cooperation between Debian and Ubuntu. I’m looking forward to working more with Zack on joint projects in this area.
This change will help me to support Canonical and Ubuntu more effectively as they continue to grow and change. I look forward to exercising some mental muscles I haven’t used very much lately, and facing some new challenges as well.
“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so”
– attributed to Mark Twain
There is a lot that I don’t know about what goes on in my organization. This isn’t only because I can’t observe everything, or because it’s too complex, or because I make mistakes. These are all true, of course, but they’re also obvious. Much more devious is the way the flow of information to me is distorted. It’s distorted by me, and by the people around me, whether any of us are aware of it or not. This is most apparent in considering how people feel about their managers: this is why I have a deeply flawed view of what it’s really like to work for me.
My theory is that power bends information like gravity bends light. The effect is more pronounced with people of greater mass (more authority), and lessened with distance (less direct influence). The more directly you influence someone else’s fate, the more it is in their self-interest to be guarded around you. This means that the people closest to you, who you receive the most information from, may have the most difficulty being open with you, especially if it’s bad news. It also means that the higher your standing in the corporate hierarchy, the more influence you wield, the more people are affected by this.
Pretty scary, right?
Some managers respond to this terrifying reality by trying to collect more information. They’ll quietly cross-check what people are telling them, asking people in different levels of the organization, routing around managers, hoping to get “the real story”. This usually backfires, because it signals distrust to the people involved and makes the distortion worse.
Another common response is to check in constantly, trying to monitor and control the work as closely as possible (so-called micro-management). This is even worse; not only does it signal distrust, but managers who do this become more personally attached to outcomes, and lose perspective on progress and quality due to information overload, self-enhancement bias, and neglect of managerial work. The more it becomes “your” work rather than the team’s, the harder it is to see it objectively.
So what’s a better way to respond to this phenomenon? Here’s what I try to do:
- Accept it – You’ll never have certainty about what’s happening, so get used to it, and don’t let it paralyze you. Learn decision making strategies which cope well with information noise, and allow you to experiment and adapt.
- Admit it – Everyone else knows that you have this distortion field around you. If you pretend it isn’t there, you’ll appear deluded. Acknowledge that you don’t know, don’t understand, and can’t control.
- Trust – The more you trust someone, the more they trust you. The more someone trusts you, the more confident they can be in telling you what they think. Be grateful for bad news, and never shoot the messenger.
- Delegate – Enable people with a less distorted view of the situation to make local decisions. Don’t make people wait for information to propagate through you before acting, unless there is a clear and sufficient benefit to the organization.
I was inspired to think and write about this today after listening to Prof. Robert Sutton’s speech at the California Commonwealth Club, which Lindsay Holmwood shared with me.
In our first few years, Ubuntu experienced explosive growth, from zero to millions of users. Because Ubuntu is an open project, these people don’t just use Ubuntu, but can see what’s happening next and influence it through suggestions and contributions. The volume of suggestions quickly became unmanageable through ad hoc discussion, because the volume of feedback overwhelmed the relatively few people who were actively developing Ubuntu.
In order to better manage user feedback at this scale, Ubuntu Brainstorm was created in 2008. It’s a collaborative filtering engine which allows anyone to contribute an idea, and have it voted on by others. Since then, it’s been available to Ubuntu developers and leaders as an information source, which has been used in various ways. The top ideas are printed in the Ubuntu Weekly Newsletter each week. We experimented with producing a report each release cycle and sharing it with the developer community. People have been encouraged to take these suggestions to the Ubuntu Developer Summits. We continue to look for new and better ways to process the feedback provided by the user community.
Most recently, I asked my colleagues on the Ubuntu Technical Board in a meeting whether we should take responsibility for responding to the feedback available in Ubuntu Brainstorm. They agreed that this was worth exploring, and I put forward a proposal for how it might work. The proposal was unanimously accepted at a later meeting, and I’m working on the first feedback cycle now.
In short, the Technical Board will ensure that, every three months, the highest voted topics on Ubuntu Brainstorm receive an official response from the Ubuntu project. The Technical Board won’t respond to all of them personally, but will identify subject matter experts within the project, ask them to write a short response, and compile these responses for publication.
My hope is that this approach will bring more visibility to common user concerns, help users understand what we’re doing with their feedback, and generally improve transparency in Ubuntu. We’ve already selected the topics for the first iteration based on the most popular items of the past six months, and are organizing responses now. Please visit brainstorm.ubuntu.com and cast your votes for next time!
For some time now, we’ve been gearing up to begin development on Ubuntu 11.04. While some folks have been putting the finishing touches on the 10.10 release, and bootstrapping the infrastructure for 11.04, others have been meeting with Canonical stakeholders, coordinating community brainstorm sessions, and otherwise collecting information about what our priorities should be in the next cycle.
We’re using what we’ve learned to plan the Ubuntu Developer Summit next week in Orlando, where we’ll refine these ideas into a plan for the cycle. We’re organizing UDS a little bit differently this time, with the main program divided into the following tracks to reflect the key considerations for Ubuntu today:
- Application Developers – Making it faster, easier, and more enjoyable to develop and distribute new applications on (and for) Ubuntu
- Cloud – Delivering the best experience of cloud computing, whether hosting in a public cloud or building your own private cloud
- Hardware Compatibility – Measuring and improving compatibility with a wide range of laptops, netbooks, servers and desktops
- Multimedia – Formulating the best software stacks for graphics, audio and video in Ubuntu
- Package Selection and System Defaults – Choosing the right components to keep Ubuntu lean, flexible and ready-to-run, while ensuring that the pieces fit and work together cleanly
- Performance – Squeezing the best performance out of today’s free software stack, from the Linux kernel and GNU toolchain through user interfaces
- Ubuntu the Project – Continuously improving the way we work together to produce Ubuntu, both within the project and with our upstream and downstream partners
You can click on the links above for a preview of the schedule for the week, with links to more detailed blueprints which will develop during and following UDS. If you’ll be joining us in person, then I’ll see you there! If not, be sure to review Laura’s guide on how to participate remotely.