Interviews/Jono Bacon

Jono Bacon works for Canonical as the Ubuntu Community Manager.

Highlights

• Ubuntu has between 400 and 500 active developers, 70 of whom are paid by Canonical Inc. the for-profit company that is in charge of Ubuntu.
• Ubuntu has a transparent governance process. There is a technical council that is made up entirely of Canonical employees who are responsible for the direction of the project. There is the community council which is responsible for large community issues. There are 200 local team councils which handle local issues and report to the community council. And there are advocacy groups that are responsible for promoting Ubuntu and advocating for open-source software.
• When you set up any community, one of the most important things you can is differentiate between active, reliable contributors and “drive-by” contributors (people who just want to share/learn something, and then go away). These people are actually expensive. You have to mentor them, and you have to teach them. They sometimes don’t contribute much. We want what we call significant and sustained contributions. If someone has done this kind of contribution, they apply to be a member. The community council reviews the application and if they are approved they get an ubuntu e-mail address and an IRC cloak.
• We sponsor community members to meet with our developers. We get a bunch of people in a session, and what happens is that there are a ton of ideas. So much comes out! And some people volunteer to take on these features. Then we produce a roadmap which assigns the different ideas that were raised to different individuals. This provides a metric on something we all agree and how we’ll get there. There’s no more dangling ideas that don’t get completed.

Interview

Can you provide us with a high level overview of the Canonical inc., how it was created, its mission, and how it is structured?

Canonical was formed in 2004 when Mark Shuttleworth wanted to build the Ubuntu project. He went to community groups, primarily from the Debian community, and asked if they wanted to help out with Ubuntu. Then he started growing the organization, hiring more engineers. A few releases later, I joined to help build out a community of contributors and users with Ubuntu.

From day one, there’s been a firm commitment made to an openly-run and openly-governed community. We have a code of conduct, and we want it to be productive and welcoming. We have a source control system, we have various commercial services, we’re building services into the desktop, we have a management facility. All of these products (apart from Landscape) are free and open-source.

How was the first release developed?

The first one was predominantly staff because it was so new, but the community was definitely involved. Benjamin Mako Hill was one of the people who helped get the community involved. We had a community council and a team, and now we have an elaborate structure.

One of the challenges Wikimedia will face is not only developing an infrastructure and making sure that it scales over time. A lot of the things we’ve done at Ubuntu are some of the first lessons learned in the industry.

What is the governance structure?

We have two top-level bodies: community council (group of people who make decisions for community), and technical board (which decides policy). Both are open to anybody. Anyone can be a member. You don’t have to work at Canonical, and the majority of the community council does not work at Canonical. The technical board, however, is all staff from Canonical. That was how it worked for a long time.

As the community’s grown, the community council has become a bit overrun with queries, handling policy changes, conflict, questions, and the like. We made something called team councils to handle some of these smaller issues. We have 200 local teams all around the world. That team governance council reports to the community council. There’s advocacy: getting people interested in Ubuntu. A lot of people in open-source want to do this. These “LoCo” (local community teams) do this. One council governs all of these LoCo teams.

The final element is the concept of membership. When you set up any community, one of the most important things you can is differentiate between active, reliable contributors and “drive-by” contributors (people who just want to share/learn something, and then go away). These people are actually expensive. You have to mentor them, and you have to teach them. They sometimes don’t contribute much. We want what we call significant and sustained contributions. We want people who become rockstars in different parts of the community. If someone has done this kind of contribution, they apply to be a member. The community council reviews the application. Then they get an ubuntu e-mail address and an IRC cloak. But we were getting so many people applying to be members that the team councils can now approve memberships.

The second thing we did was set up regional membership boards to handle the applications. These are available in the Americas, Europe, and Asia/Oceana.

This is to say that it’s quite a complex governance structure.

Who contributes?

It’s a wide range. It’s a massive community. We have developers, people who do packaging work (fixing bugs), people who do “code development,” people who deal with long tail of packages, hundreds of LoCo teams (translating Ubuntu at points), active translation teams, documentation teams, marketing teams, QA community, people writing software, people running forums, people building training—pretty much anything you could think of. My goal is to make sure we have a workflow that welcomes people and gets them running as soon as possible.

What is the developer mix between paid, volunteer, and paid but by other companies?

The people who do packaging work: we have these numbers somewhere. Offhand, I’d reckon it’s 400-500 developers. A lot of people will just fix bugs, and another will take that and upload it. But not all of those people are using it all the time. So that number is a guess. About 70 of those people are employed by Canonical.

There are also other companies who work to integrate Ubuntu into their products. There are also some people who are likely paid from other companies, but I don’t know how many people there are.

How do you set the direction for the project?

The way people build the software is you take a piece of code released by an upstream product, then you package it using Debian package guidelines, then upload it to Launchpad, then Lauchpad will build it. That’s how things have worked with Debian and Ubuntu. We’re now moving to a system of version control.

In terms of how we govern that, we have the archives. They’re broken into two: main (the most visible, reliable, front-end), and everything else goes into universe. We have co-developers who work on main, and we have a process to assess their experience, and they can then upload to the archive. The technical board handles this now. The people who work in universe have a separate group called “Masters of the Universe” (MoTu) has its own council, and they handle applications there.

A group of people review the changes that come in, and then package them together. A module is a bucket of software that lives in a source-control system. For example, you may have a module that brings together some of the infrastructure and design. Then there are likely upstream projects, too, with front-end components. A module can be comprised of a bunch of packages that make up the Ubuntu system.

Can you describe the version release process?

The first thing we do it create a release cycle. We attach milestones to a calendar. We have a bunch of alphas, and then a beta, and then a release candidate, and then a final version. Then we have further milestones, like a feature freeze, when all feature development stops. Similarly for translation and documentation. And then an art freeze.

Every piece of software needs what we call “bake time.” People using it, and testing it, and finding bugs and fixing bugs. You need time for the software to mature.

Once we have that, we need to decide what goes into it. We have a bunch of stakeholders. The platform is broken in seven management teams at Canonical. Foundation, desktop, kernel, community, QA, mobile and so on. Each of these teams puts forth features they’d like in the new version. We gather input across the board, the community and commercial groups and customers. We take all of these needs and break it down into a strategy.

Then we take all of these needs and discuss them in sessions. The goal of these discussion is to flesh out agreements of what we’re going to do in the next cycle.

How do you determine what to focus on?

The challenge here is that it turns into a laundry list of what people want. We can’t do everything, obviously! We have calls, we document people’s requirements. Note that this is just for Canonical. We have a development staff, so we need to do this. It’s about balancing different needs.

So we come up with a series of requirements and then put together a roadmap. I’m actually starting to do this more with the community. I encourage the community to build roadmaps and build that into our workflow itself.

How do you integrate community members into the versioning process?

One of the problems that was seen at UDS, and one that Wikimedia might face, is that volunteers don’t really care about strategy. They want to work on something interesting. They want to be rewarded. They want to feel engaged. Generally, most people who want to be involved with Wikimedia probably don’t want to be involved with strategy.

We sponsor community members to meet with our developers. We get a bunch of people in a session, and what happens is that there are a ton of ideas. So much comes out! And some people volunteer to take on these features. The next session, a lot of that stuff has never been done. I’ve tried to produce a flyer that explains how we do roadmaps for a cycle. Each cycle is broken down into a series of goals, with related objectives and actions. So now, after we agree on things, we document them in a roadmap. This provides a metric on something we all agree and how we’ll get there. There’s no more dangling ideas that don’t get completed.

This ties everyone together. There’s a sense of accomplishment and achievement. There’s also accountability.

Are there any tensions in the community (e.g., paid vs. volunteers, accountability structures) It’s been fairly smooth, to be honest. Any tension you might see is when a decision is made without consultation with the community. Sometimes that happens. For example, the decision to build Ubuntu One was made largely by Canonical. It’s fundamentally a commercial service.

The community is largely okay with that. If Canonical makes money, they’re likely to feed that back into Ubuntu.

What lessons have you learned?

I’ve been here for three years, and I’ve learned so much about how community works. Running a community means you have to understand the people who are there. It’s about having an organization that is lightweight but that also gets people involved. We only have governance because we need it.

The other thing I’ve discovered is that experience is really critical to running a good community. You need people who’ve been doing the work, people with experience. People need to know when to expect things. Not a lot of people have that experience.

When I join Canonical, I felt I had decent experience, but I hadn’t been a leader in a large community. So that’s where I cut my teeth. And that’s the reason why I wrote the book.

How do you ensure that new members feel welcomed and know how to plug in?

There’s no single process. It depends on the context. If there’s a new developer, there’s one process. If there’s a new translator, there’s a process. The key thing is that it’s lightweight and transparent.

What do you think is the most valuable learning?

The roadmaps are really critical.

What is the right number of people for paid developers?

It varies from team to team. A lot of it is based on the direction we’d want to go in. For example, we decided we want to build our design expertise, so that required hiring more people. We hire people based on the level needed for our priorities.

How do you think about participation barriers?

Face-to-face time is really valuable. It’s more efficient than communicating online. You can make progress in one hour with the right people there in person than we can over three weeks of phone calls. It’s also important to build bonds. The social interactions are really important. People can become friends, which means the social part is critical. The challenge here is that this is a barrier because not everyone can attend face-to-face meetings. We try to have IRC clients running during meetings, and videotape key sessions, too.

We’ve tried out VoIP, too, and that was actually incredibly disruptive. You need to identify goals, build a roadmap around those goals, and then identify the resources you need.

How do you think about usability?

Everyone thinks they’re good at it, but few people actually are. What we’ve discovered is to hire a usability team. It’s the best way to do it for us. Hire a team of interaction designers, hire a team of visual designers, identify the problems, and put them to work. I think that Wikimedia might be well-served by just hiring a team to do this.