In his Open Voices interview with Jim Zemlin of The Linux Foundation, which went online today, Ubuntu CEO Mark Shuttleworth focuses on trust and process as key concepts underlying Linux and open source.
Trust relationships, and the management of trust, are what separate successful projects from the unsuccessful ones, he says.
Shuttleworth launched Ubuntu after selling Thawte, an X.509 certificate authority, in December 1999. He later launched himself into space aboard a Russian Soyuz rocket as one of the first "space tourists" and the first African to orbit the Earth.
He has been the "go-to" guy on desktop Linux for years because Ubuntu, with its extensive localization, has been an early leader in that space.
Following are some edited highlights from the interview:
I think if you look at where phones are going and where consumer electronics are going, we’re getting to the point where you can actually run a normal standard Linux platform, which doesn’t require any special development skills, on hardware that costs sub-$200, and that’s a very interesting tipping point.
On How open source works
You have a real diversity of hundreds, perhaps thousands of communities that are – and companies that are - interacting to produce the platform.
This is just as true of the traditional enterprise Linuxes, like RedHat and SuSE as it is of a community distribution like Debian or Gentoo. Folks often tend to try and think of Linux as coming from a monolithic provider, but it doesn’t. It’s this intensely collaborative effort to produce a Linux distribution.
Enhancing the productivity of collaboration between different groups is a real way to boost the platform as a whole. And at Ubuntu we feel this very, very keenly because not only do we want to collaborate with other upstream projects like Apache or X or Open Office, but we also very much want to be part of and collaborate with Debian which is a very large project in its own right.
Becoming really good at that process of interacting with other projects, sharing ideas, sharing code, sharing bug information and so on has been sort of a real driving theme.
If you look at the projects that are successful, that produce inspiring work and that produce it predictably and address issues and manage change well, I think they do two things very well and the first is, obviously, they have very good technical leadership.
Whether that comes from a company, whether it comes from an individual or whether it comes from a collection of individuals, it’s really important that there be a meritocratic process of letting the best thinker, the best idea, the best work effectively bubble to the top.
But they also do something else and that is that they manage a very positive social process. I think the best projects recognize that they have to maintain really constructive, positive relationships internally and with other projects if they want to continue to have really good ideas and get really good input.On Trust
It can be difficult to build relationships of trust and so I have seen some projects ultimately stalled because new folks who came in with new ideas weren’t able to establish a position of trust fast enough that they could start to contribute those ideas and so they would then move on....
We’ve seen some big transitions or difficult forks within really important projects like GCC and X where projects didn’t get that management or the trust relationship thing right; they weren’t able to give new ideas enough room effectively to blossom. And so, ultimately, those ideas had to go somewhere to get explored.
And if we can get better at that, then we make the whole ecosystem that much more powerful.
One thing that’s really important to understand is the difference between someone who works full-time for you and someone who works as part of a community contributor to your project that you’re interested in.
You get very different kinds of contributions from those two. Some companies think that once they open source a product or if they join the open source community, then other people will do all the work that they don’t want to do and that’s only really true of certain kinds of things.
What you get from the long tail of contributions in a community is a fleshing out, a rounding out of your product, a rounding out of the platform.
Companies that understand how to interact and engage with a community, how to have their own full-time guys doing the things that they will do best, but also expose enough of the platform, expose enough of the project for other people to come in and do interesting bits of work tend to do better.
In Ubuntu, we address that by trying to hire full-time professionals who are sensitive to and open to that kind of interaction and it takes a special kind of person to be able to straddle both sides of the software engineering world, right? The sort of rigorous industrial side, but then also the more free-flowing, itch-scratching community side of things.
On the Future
I think that the majority of the software industry as we think of it today is going to transition to a services-type economy.
I can absolutely see the day where you can play any game you want any time, you know, you don’t have to go out and get a CD; you just turn on the gaming device and say you want to play that game and it’s delivered to you over the network. But what you are paying for is the ability to participate, the service of participating in the gaming network.
Look at a company like VMWare which is fundamentally a proprietary software company, although they have taken really good steps towards open sourcing very specific key technology. In no way are they sort of resting on their laurels and saying, “Well, we have this wonderful proprietary technology that everybody must buy.”
They’re absolutely focused on delivering services at a higher and higher and higher level around that sort of ubiquitous platform that they’ve created. I think that’s a trend of the future.