Mark Shuttleworth’s Ubuntu perspective
If the Linux community has a hero other than Linus Torvalds, it’s Mark Shuttleworth, a dot-com gazillionaire who started the Ubuntu Project, and who funds it out of his own pocket. If you’re not familiar with Ubuntu, it’s a distro based on Debian Linux, which is designed to offer a one-disc install of everything you need: operating system, device drivers, and lots of free applications.
Unlike many Linux distros, Ubuntu was intended to be used by civilians. Shuttleworth has pledged that Ubuntu will always be free.
I’m a fan of Ubuntu Linux, and think that Mark Shuttleworth is a good guy. However, to many in the Linux community, the South African entrepreneur is a rock star, a god. What’s more, Ubuntu Linux is seen by many as the first, and only, Linux distribution that might have a shot at gaining market share on the desktop. That makes it the only viable open-source alternative to Windows.
No matter whether you like Shuttleworth, or worship him, or hate him, or are fairly ambivalent, there’s no doubt that he’s very influential in the Linux community. So, his keynote address at the Linux Foundation Collaboration Summit (which I attended on June 13) was worth listening to, particularly because it presented a frank window into the state of the Linux platform.
Shuttleworth, naturally enough, praised the concept of the Collaboration Summit, the first time that such a wide swatch of the Linux community came together ostensibly to find better ways to work together to improve the platform, both technologically and in the marketplace.
“It’s a chance for us to build relationships, and accelerate collaboration,” he said. “I enjoy seeing the extent to which people who aren’t generally ‘free software folks’ are hearing about free software, and are starting to see that this world is more interesting than they thought it was.” (A word of caution: These quotes are based on my real-time notes at the conference, and I can’t guarantee that they’re word-for-word exact.)
Speaking to the non-Linux attendees (such as press and analysts), he said, “It’s not just Windows vs. Mac, there’s a whole other world out there. Many people want it to be Red Hat vs. Microsoft, or Ubuntu vs. Microsoft. but that’s not what it is.”
What separates Linux from Windows and the Mac, he said, is the large number of different parties, and different vested interests, who have come together to make the platform work. “Innovation works best when you have people who are inspired, and you let them work. However, you need a framework for innovation that brings them together.”
Enthusiasm isn’t enough, though, Shuttleworth said. “We have some disadvantages. The other guys can spend more, in hard dollars, than our guys. On the other hand, we have an extraordinarily rich pool of talent, and have the freedom to innovate. Collaboration sounds beautiful, but it’s hard. Collaboration means working together, but that’s labor —that’s real work.”
Shuttleworth warned against pitfalls caused by biases, or lack of knowledge, or the type of unhealthy group dynamic when projects are run by close-knit meritocracies with little patience for those people who are less technical, or who have a different perspective.
“Too often, people say ‘I don’t want to work with that distro,’ or ‘I didn’t know where to send my patch.’ We have lots of tools, like mailing lists. Unfortunately, they shake things up so that the loudest ideas bubble up. Think about poisonous people! How can you run a project so that the best ideas win, vs. the loudest ideas win?”
But even worse than collaboration within a project, he said, is broader collaboration between the myriad projects within the open source community. “We also have version control, wikis, Web sites, lots of tools, but most of those tools focus on collaboration within a project. If you’re in a project, you know where to go, and who to talk to within your project. The big problem is collaboration between projects.”
Shuttleworth pointed out a couple of areas where things fall down, like translations into other languages, bug management and patch distribution.
“One clear thing is that translations fail to move upstream. People translate what they’re using, but it doesn’t move up. It’s not intentional, but we don’t have standard processes or conduits so they can send their translations upstream. The same thing with bugs: You may have people who reported a bug to Red Hat, or SUSE, or Debian, or Ubuntu — but they’re like silos. We need a way to aggregate those eyeballs.”
He added, “It’s the same with patches. A patch solves one person’s need. How can we accelerate the process of moving patches upstream? We need something that’s more of a star topology, to move patches up and around.”
A bigger question, Shuttleworth asked is, “How do we minimize the barriers to participation, and include the v3 guys, and BSD, etc? A central database is not the answer.”
A minor question, which clearly irks Shuttleworth: “Why can’t I programmatically access the kernel development team’s database through APIs?”
Shuttleworth then jumped back to translations. “Here’s the point of friction: The tools are difficult. In order to contribute translations, you have to have Committer access [to a project], and that’s not good. How can we get people to contribute translations without requiring they be developers, or that they use development tools? There are also different frameworks [for localization]. Mozilla’s framework is different than OpenOffice, for example. It’s worth the effort to break down the barriers. We need to agree that the inability for work to flow across projects is a problem.”
On bug tracking, he added, “The biggest problem is the friction to file the bug! You don’t understand the bug tracker, or the project’s conventions, or even know if you would get a response. If you have to have a personal relationship [with someone on a project] in order to get a bug into the project, that ‘s a problem. We should think about federation, and find standard ways to describe bugs, and common APIs for submitting bugs.”
Shuttleworth commented, “In Ubuntu, we took as role models Mozilla because we like their roadmaps, Gnome because of their commitment to release cycles. We like blueprints of specifications, since they let micro communities form around a particular piece of work.”
He pointed out a real problem, that the meritocracies found in many open source projects may help development, but may hinder deployment and adoption. “How do we remove the hard lines between committers and everyone else, i.e., the line between first-class citizens and everyone else? Why is someone who receives a tarball [instead of accessing the source code repository] a second-class citizen? Getting everyone to participate is important.”
Shuttleworth concluded by speaking to people who run projects, and the lack of tolerance found within many projects: “Ultimately, we need to remember that while tools are important, it’s people that collaborate. People, not robots. The decision-making process is important. Unfortunately, meanness spreads: I get disappointed when I hear that if you disagree with me, you’re stupid. We agree on an awful lot. I would appeal to all of you to remember that leadership is important, and collaboration is more important than our differences.”