A sit-down with Ubuntu founder Mark 'SABDFL' Shuttleworth

Talking to the distro's self-appointed benevolent dictator for life about 20 years of Ubuntu

Ubuntu Summit 2024 Canonical founder and CEO Mark Shuttleworth spoke to The Reg FOSS desk at Ubuntu Summit 2024 in The Hague about the Linux distribution's success, its missteps, his regrets, and what he'd tell his younger self.

In 1999, Shuttleworth sold his South African digital certification authority, Thawte, to Verisign, which paid $575 million. That gave him the money to fund a project, originally under nonameyet.com, to make a desktop flavor of Debian that was easy enough for non-technical people to use instead of Windows. The early years are described by Lionel Dricot in a blog post entitled 20 years of Linux on the Desktop.

Q. So, 20 years of Ubuntu. How does it feel?

A. Well, actually, I just feel grateful, because it's been 20 years of really interesting problems with really interesting people, so kept me mostly out of trouble.

Q. Are there any disappointments, any regrets so far, things that you hoped would work out and didn't?

A. I think there'd be a kind of ennui if you knew the answers before you played the game, right? So the things that I feel I've come to understand because of those mistakes, I treasure.

Q. What do you consider the mistakes? For instance, the Ubuntu phone? (For those who weren't watching in 2013, it didn't raise its Kickstarter funding.)

A. What do you consider the mistakes? So for me, the mistakes were first hesitating. In my mind, that kind of interaction was the way to go. I was 30-something – 30-low-something. As it was taking off, there were some other very large silicon companies who said, come partner with us. Don't worry about it. We're going to do something great. And I thought, well, surely they know what they're doing. And so I hesitated before saying, look, we have a vision of that converged compute experience. I think that hesitation was problematic.

Then the second mistake, I think, was that, at the time, we were very small, and to tackle that problem, in addition to the other things that we were trying to do, I needed to essentially set a vision and then allow a very rapid pace of hiring to try and tackle the problem. And I focused a lot on the design, the user experience story. Looking back, if I think about the UX story that we were trying to tell, of how you get this elastic fluid set of experiences, from the phone through other touch form factors, through to the PC – well, if I look now, many years later, at how iOS has continued to evolve, to me it's pretty clear that set of ideas is very interesting. But, because I couldn't impose as much rigor and discipline on the engineering as well as that UX story, I didn't think we did a great job of the quality of the engineering.

Q. What about Unity 8, or rather Lomiri, today?

A. I'm inspired by what that community continues to do. I hated culling all of that engineering on that – you know, walking away from all that work. On the other hand, with what I now understand about engineering, I would have attacked the staffing and the engineering rigor very differently. If I look back at that, the absolute thing is, we missed, and nearly killed the company, which is horrifying for me. The key takeaways were, if you have clarity, you need to go, even if it's controversial. Don't wait for others, because you won't know until it's too late whether that shared vision exists. And also, if you are going to blaze a trail on code that doesn't exist, be very, very careful about the rigor and the staffing of that. Or you can get all the right ideas, but not have a great implementation to stand up.

I mean, I absolutely consider that one of the things I would advise my younger self, but perhaps rightly or wrongly. The conclusions I draw from that are more about how to think about what you take on, how to drive it, and the timing of that.

If I go back to the kind of crunch point for Canonical and Unity, when I said that I wasn't proud of the engineering rigor of Unity, I felt differently about Mir. There are two things that I think were very clear to me about Mir. The first is that the idea in Mir is often misconstrued. It's often mischaracterized.

The idea in Mir is a very specific one: it's to build a definitive meeting point between people who want to innovate on experiences, lots of different kinds of desktop experiences, lots of different kinds of consumer experiences, and people who want to innovate on applications. You know, the primary user frustration in the open source world is that you can't have it all. You find yourself trapped in an ecosystem. You find yourself trapped in the KDE ecosystem, or the GNOME ecosystem, and then there's something beautiful from another ecosystem but it feels crap on your system, right? So the first thing to understand about Mir is that the sole and defining goal of that project was to essentially build the bridge between those two groups of innovators: those on the desktop experience, and those on mobile.

In fact, we only started to do Mir after we saw that Wayland was making, in my view, the same mistake that X11 had made: working in a way that would make it ultimately impossible, again, to have all the nice things. So, you know, when people talk about Mir, I hope what they talk about is that what it actually is, is a definitive way to get apps from one ecosystem to work beautifully on another ecosystem – which can only be a good thing, right? It requires discipline, as all good things do. But that's what it is. It's not competing with Wayland. It is not and was not. It's not a Unity lock-in thing. The point was not to be that, yes. The other thing that I think is really important is that I completely believed in the engineering rigor of Mir. That team had been fastidious about performance and correctness and clarity, right? So that piece of that story I really believed in, even though, you know, it was controversial, so it needed to "die," in inverted commas, exactly so that it didn't become something that people could score points on Reddit by pounding on. But I wanted the work to continue, because I thought it was astonishingly good work, and I'm delighted now that other people seem to be finding some joy in it. So, yeah, bit of a sad story.

Q. Moving on a few years, what about LXD and the recent fork?

A. If I go back a long way, I've always tried to follow the advice of some of the best open source engineers I work with, about what's interesting and what projects we can support. And so, a group came to me a long time ago and said, you know, this LXC thing is really important, and it's being shut down by the big company that was hosting it. Effectively, we should hire those guys. So we did, and it was a nice community project, really focused on essentially creating some of the experiences that Solaris had. We didn't have a lot of money at the time, so I couldn't do too many of these kind of projects, but this one felt good, so I thought we should fund it.

That group essentially missed the Docker opportunity. Docker built on LXC, and just really nailed a user experience around applications. Absolutely nailed it, which left us then in an awkward position, as money was really tight. What should we do? Should we shut down LXC? You know, have those folk move on, which would be tough for them. And, again, if you think about how difficult it is to make those calls, you can't do everything. So instead, I said, no, we can continue this, but only if we fundamentally change the vision.

And that vision was one that I mapped out for the team, which is to say, look – LXC: these are the parts we need to make something that is more definitively LXD… think about it not as a set of libraries, which is LXC, but as a service that you can talk to. So I worked with product managers and others; we mapped that out, and the team took that on. One member of the team argued very passionately that the project would benefit from being under an Apache License, whereas, as you know, I prefer the GPL, and without a CLA [contributor license agreement] – because that was another controversial thing that we did that now is no longer controversial. Everybody does it, but at the time, it was a nice thing to pound Canonical for. And so I thought, OK, let's give this a chance, let's see.

Well, the simple fact is 97 percent of the code is written by Canonical. In other words, we saw no difference in contribution by using the Apache License, by allowing the project to be hosted somewhere else, and by not having a CLA. We saw no difference in contribution at all. We continued to grow the team and invest in it. We started to see commercial interest in that.

But one member of the team formed his own company, arranged to raise funding, and then announce that as community salvation. I find it very interesting. So that will play out as it plays out. I don't think it will be possible to argue for very long that that's a community-driven exercise. I find it fascinating that people would believe that it's Canonical that's forking. All I've done is said, look, we did the experiment with the Apache License, no CLA, and putting it on a different thing, and we saw no difference. With that developer gone, we will use the same approach, which has worked very well for all of our projects: we use the AGPL, we have a CLA, we continue to invest in the project, and I think it will be very successful.

Q. It seems to me that some of the opinions I am seeing online about snap are changing, and people are becoming more positive. I've had no problems with it in 24.04 or 24.10.

A. I'm really delighted that you're having that kind of smooth experience. The story of snaps is that for IoT, you need a very deep rigor around updates, and a very deep rigor around security, right? And so snaps and Ubuntu Core were conceived to try to give the operating system that rigor. Of course, what you don't have with IoT is humans, right? No users!

What I think is deceptive is the complexity of integration between pieces of software in a desktop environment. You know, your application sending notifications which have to be rendered in other places, and so on. Apps calling other apps, such as address books. What was interesting is that we started that journey with a real focus on security and almost autonomy for the system: the OS should be able to drive itself forward without ever needing a human.

When we brought that technology to the desktop, of course, we ran straight into the complexity of integration, and it has been an enormous amount of work to essentially evolve what snaps can do in terms of sharing information, while preserving the rigor and the security. It's a lot better now in Noble – the team has done fantastic work. I think we still have polish to do, but I'm getting increasingly confident that you should be able to consume an app from a completely different distro ecosystem, built in a completely different place, and feel that there are clear boundaries on what information of yours that app has access to. These days, we can't trust a given app with the whole system. We can only trust it with the things that it's really supposed to do, that we've deliberately chosen it to do. ®

PS: SABDFL? Self Appointed Benevolent Dictator For Life.

More about

TIP US OFF

Send us news


Other stories you might like