Podcast
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Links
Follow Me
Follow Me
Join Viktor, a proud nerd and seasoned entrepreneur, whose academic journey at Santa Clara University in Silicon Valley sparked a career marked by innovation and foresight. From his college days, Viktor embarked on an entrepreneurial path, beginning with YippieMove, a groundbreaking email migration service, and continuing with a series of bootstrapped ventures.
Exploring the Depths of Linux and Open Source Innovation with Mark Shuttleworth
Play On
16 JUN • 2024
1 hour 4 mins
Share:
Join Viktor Petersson on “Nerding Out With Viktor” as he dives into a captivating conversation with Mark Shuttleworth, the visionary founder of Ubuntu and Canonical. This enlightening episode traverses Mark’s extraordinary journey from his early days with technology in South Africa to his pivotal role in shaping the Linux ecosystem.
Mark begins by sharing his early fascination with technology, recalling how his dual interest in science and business led him to start a certificate authority (CA) company during the mid-‘90s. This venture caught the attention of Netscape, leading to significant success and Mark’s subsequent involvement with Verisign. He then takes us through his remarkable transition from the business world to space exploration, delving into his intensive training in Russia and experience as the second private space tourist.
As we shift our discussion to the inception of Ubuntu, Mark explains his deep admiration for Debian’s technical and social framework and his vision to make Linux more accessible to a broader audience. He details the challenges and motivations behind creating Ubuntu, a distribution designed to complement Debian while addressing the needs of both the open-source community and enterprise users. Our conversation explores Ubuntu’s evolution, including significant decisions like adopting SystemD and the introduction of Snaps.
Mark provides insightful perspectives on the development and philosophy behind Snaps, emphasizing the importance of secure application distribution and discussing the challenges of integrating complex desktop environments. We touch on his leadership within the open-source community, the controversy surrounding Snaps, and the necessity of continuous innovation to meet the evolving demands of technology users.
As we continue, Mark introduces the concept of Ubuntu Core, an innovative approach to building secure, transactional systems for IoT devices and desktops. He elaborates on the technical intricacies and shares his vision of a future where devices can be securely managed and updated, ensuring integrity and reliability. This segment offers a fascinating look into how Ubuntu is positioning itself at the forefront of secure and efficient computing solutions.
In the final part of our conversation, we discuss the current landscape of open-source licensing, the challenges faced by small independent producers, and the importance of sustainable business models in the open-source ecosystem. Mark advocates for a balanced approach, recognizing the diverse needs and motivations of different stakeholders in the software industry. We examine how these dynamics influence the development and distribution of open-source software and what the future might hold for this collaborative model.
Join Viktor Petersson on this enlightening and thought-provoking episode as we delve deep into the past, present, and future of Linux, open-source software, and the technological landscape with one of the industry’s leading innovators. Whether you’re a tech enthusiast, a cloud computing professional, or someone interested in the future of IT infrastructure, this episode is packed with valuable insights and engaging discussions.
Tune in to “Nerding Out With Viktor” and get ready to explore the remarkable journey and visionary insights that continue to shape the tech world today.
Transcript
Show/Hide Transcript
Welcome back to nerding off with Victor today I have none other than Mark Shuttleworth on the podcast.
Mark, among other things, is the founder of Ubuntu, or canonical to be precise.
Needless to say, he's someone who has had a big impact on the Linux world and I'm super excited to note out but all things Linux today.
Welcome to the show, Mark.
It's great to be here.
Thank you.
Amazing.
So I think I first briefly met you at Ubuntu developer Summit at Copenhagen back in 2012.
A lot of things have happened to that.
I've been to a lot of the developed events, but I think tracking back, I think roughly that's the first time we met in person and it's quite a while ago by now.
But before we get to that date, I want to start with the early days and kind of unpick your history really back into the early days of toth, really.
And you were in the CA space maybe like give the audience a bit of backstory of how you came to start a CA company and how you got into that space in general.
Well, so I always been fascinated by technology.
I guess most of us nerd out with Victor are the sorts of people who just find technology and science fascinating.
And going into university I had wanted to, I wanted to, I'd initially wanted to really focus on science.
I was kind of a maths physics character for various reasons.
I kind of got drawn into a split world where I was half focused on technology and half focused on business, which was very stressful for me because I had no family background in it.
I never really wanted to be in business.
This would have been about sort of 94, 95 and the Internet was just starting to arrive in South Africa and you could watch the packets arrive.
In those days you would literally watch packets arrive.
But I find it fascinating.
I thought for someone who grew up at the tip of Africa, miles and miles away from, you know, the traditional centers of science and technology, the idea that you could be part of a conversation with people who were right at the cutting edge of that was just amazing to me.
Right.
I was a student that lived on campus literally legally, but so I was very kind of immersed in all of that and I needed to raise some money for my studies effectively.
And I started to fall in love with the idea of helping other people get on the Internet as a way of doing that.
Like being a bit of an expert in how it all worked.
Much like today, I think there are people who are ahead of the curve on machine learning or neural networks, AI, Mljdev, they would be essentially building out a side hustle in consulting and being experts and so on.
So I was doing that in Cape Town and I got really interested in how business would be done over the Internet.
At the time, it was largely seen as kind of a science thing or an academic thing.
The faculty that I was in was very dismissive of the incentive.
They're like, that's a computer science thing.
You're in the business faculty, you're not in computer science.
I ended up having to get a computer science professor to supervise what I was doing because they wouldn't do it.
But I was really interested in how commerce would take place.
And at the time, that was very controlled by us companies, and the Internet was growing outside of the US, and there just wasn't an efficient way to think about how e commerce could be global.
There were crypto regulations that stopped Netscape and other american companies from shipping strong crypto outside, but there were open source implementations of strong crypto outside.
And so I started to get into that as angle effectively, and consulting and helping people with that.
And the prize for me was the idea of getting into that certificate authority story because, you know, as a potential opportunity, it didn't require a lot of bandwidth.
If you think about where I was, Cape Town, there wasn't any bandwidth, so I couldn't get into an opportunity like an eBay or a yahoo or those sorts of Internet opportunities.
They just required you to have a lot of money and a lot of bandwidth.
Neither of those was available to me.
So the certificate authority idea kind of was emerged out of that interest in crypto and commerce and security.
Crypto in the good old traditional sense, yes.
Not the current swamp of madness, but crypto as a way of keeping people's secrets, especially in a commercial environment.
And so I envisaged a way of doing digital certificates, which is essentially a franchise where a local expert in Australia, a local expert in the UK, a local expert in Germany, would all take responsibility for the identity piece of things for corporates, web services and so on there.
I pitched that to Netscape.
They like much to my enduring sort of amazement, they said, okay, that sounds like a reasonable plan.
Go for it.
God bless California.
So they said, they took in your root certs, essentially, at that point.
Okay.
And then from there, it was a very competitive dynamic.
Obviously, the browser was the big thing, and so the other browser vendors followed suit.
And at that point were sort of a tier two because we only worked with newer browsers, a tier two provider to that market, very focused on the international market and I.
And trying really hard to do a good job of it.
You know, it's an interesting problem.
How do you really know that someone represents the company that they say they represent right when they're in.
Yeah.
And you have these small country that's I guess, beyond in later years, but you have these like extra signed or verified casi asserts and all that I can these days.
I think that has become old fashioned, extended control of the domain, really.
Right.
So in those days we really focused on the paperwork, like, is that a real company?
Is it really registered?
Right.
Interesting.
And then that obviously got on the radar for verisign and that was, I guess, your big ticket out to independence.
In your future or future, do pursue whatever you want.
How was that?
You want to say a few words about the exit or how was that?
Rolling that up into her son?
It's an experience that obviously not many people will have.
I highly recommend it.
If you don't fortune.
But also there are lots of ways to mess it up.
You'll have lots of people that come and want to give you urgent advice when there's money on the table.
I think holding one's nerve and staying pretty true to what's really helped through all of that.
Right.
So the deal was done and, you know, I continued to work a little bit for verisign in the.
In the handover.
And then I had to sort of imagine a future where essentially professionally I didn't.
I had no structure.
You know what I mean?
Like it was.
You were kind of cast out a little bit into.
Into a freewheeling sort of world of.
Of unstructured world, which is exciting but also unsettling.
Right.
Like, if you like working with people and you like moving something forward to suddenly be kind of wealthy, but essentially at a loss.
It was a weird experience.
Yeah.
Is that when you started finding purpose and you went on your space exploration path, was that just after or how did that timeline look like?
Yeah, pretty much.
So that was clearly not.
It wasn't me looking for a new career.
I just thought there was this moment.
The geopolitics of the old Soviet Union had led to this kind of collapse of the soviet space program.
The US was essentially trying to make sure that soviet rocket scientists effectively were kept gainfully employed.
So it was a time when there were better relations essentially across that border.
That was the international space station program.
The Clinton administration had really kind of pushed for that.
And I saw an opportunity essentially to be part of that transition of the russian space program to a more commercial future and also have the chance to fly.
I really wanted to do that as a member of a crew.
I didn't want to do that just as a passenger.
So I kind of had to go and spend a year in Russia, which I loved, absolutely loved the people.
I loved the history of Star City.
The fact that your flight instructor for this specialism, or that specialism could have been an instructor for Gagarin, Alexei Leonov, the soviet version of the Mercury seven.
Right.
All of that history was still just literally there in the buildings and in the people.
It was wonderful.
And you were the second private space tourist in history, I believe.
Is that the case?
Yes.
Dennis Tito was an American who got their head of me.
Yeah, well that's quite a bit of bragging, right?
I would argue.
It'S a very long time ago now.
I think if I was still bragging about that it would be a bit sad.
So I had to then find another career.
Right, fair enough.
So you then started looking at the Linux world.
This is roughly timeline.
So Ubuntu, the first Ubuntu release is around that time.
And it was a fork of Debian.
Well, I guess it still is a fork of debut in a sense.
Walk me through the early days, like what were you optimizing for in the early days?
How did you pick the choices, Debbie in particular as the avenue for that?
I'm curious about the line of thinking around that.
So in the nineties I became a Debian developer.
I embraced as I was getting into that Internet technology, I was also getting into open source and Linux played with Slackware, played with some others, but Debian immediately, and this is very early in the history of Debian.
Debian immediately struck me as just a very beautiful balance of technical approach, social approach and so on.
Although it was kind of less codified in 1990, 619 94, it really had the sort of the key ideas in it of the distributed team collaboration community and those sorts of things with a kind of a strong commitment to universality which I found very beautiful.
So I became a DD.
I think my main package that I contributed was the Apache web server effectively, believe it or not, Debian didn't have a package of that when I.
Oh wow, okay.
And I needed it, so I made a deb of it and I just kind of loved that.
I was busy with crypto certificates and business effectively.
But I, you know, I'm always trying to figure out where is the world a little bit broken and what can you do to fix it.
I think you should always use your talent both to do things that you find interesting, but also to do things that move the world forward in a positive way.
So with the certificate authority thing, I was looking at the fact that the industry was really only focused on the US.
Well, what about the rest of the world?
And I was trying to solve for that.
In starting to think about Linux.
What I was interested in is I thought, okay, Debian has this really elegant, beautiful community and technology structure.
We were seeing the proprietorization of Linux in the move from kind of, what was red hat Linux to rel and fedora that kind of fork and split and from a distance I watched that and thought oh well, this will never work.
You know, Debian will, you know, will easily.
No one's going to fall for that, right?
And actually the opposite happened.
So while I was learning to become a space cadet, Debian was declining and red hat was growing.
And I couldn't understand that.
I couldn't understand why the better technology and the more open community and so on was not getting the adoption that red hat was getting.
So I kind of became a bit sad.
I thought, look, you know, the more open source is losing to something that I, you know, I understand, right.
You know, Red Hat was essentially presenting themselves as a next generation Solaris, right?
But I didn't like it and I thought maybe I could do something about it.
I also knew that was going to be a very, that was going to be a big commitment.
You know, it wouldn't happen easily.
So I waited quite a long time to see if that dynamic would change.
But it didn't, right?
The number of Debian users was declining.
The number of Debian's ability to get releases out was declining.
And red hat was going from strength to strength.
For me this was very interesting also, but concerning, I think now I look back at that and I understand that for the enterprise market there's a set of things that people really want, they have to have essentially that is also quite uncomfortable for communities.
Provide.
It isn't interesting work in the same way.
You don't have the same sense of autonomy.
You're not deciding for yourself what it should get to scratch.
It may beautiful, what you do as a contributor to an open source project on personal terms, but it doesn't cross the gap to necessarily what the enterprise is looking for.
And weirdly enough, as a 27 year old I didn't understand that.
I just believed in the beauty and the elegance and the technology and the community.
I was frustrated about that.
I tried to push Debian to address some of those things.
And one of the beautiful things about Debian is that it resists that kind of influence.
So you have, somebody comes in and says, you should all do that and I'll push and make it happen.
And people say, who the hell are you?
Done?
And I think that's actually a strength.
Right.
I think that's part of why Davian is still so strong and so clear is that it isn't so easily subject to influence, mine or anybody else's, right?
And so as I came to understood that, I was like, well, maybe I can do this differently.
Maybe I can.
Essentially, you know, if you think of Debian as a political movement, right, often when you have a complex social dynamic you'll end up with a political movement that gets an armed wing, right?
And these characters are willing to, you know, fight a bit harder and do the stuff that nobody else wants to do.
In the end, you have to understand that it takes both of those things to create success.
Right, I.
Right.
And so that's where I started to think, well, maybe the right way to do this was to complement Debian with an institutional focus that would, you know, create a sort of a virtual circle between what we do and what Debian does.
That leaves Debian to be great at what Debian is really spectacularly great at.
But it also enables that same ecosystem work.
All of the production of the devs, all of the thinking through how deviant works.
It enables that to reach an audience that Debian, on its own, I think can't reach.
Right?
Yeah.
I might be proven wrong, but so far I think that's proven correct.
Right.
So I don't see Ubuntu as a fork of Debian.
I see it as the other half of the same coin.
Right.
That's fair enough.
How is that symbiosis today in terms of, like, sharing codebase and sharing, I guess, fixes.
And how is that looking today?
I think.
I mean, we've not fundamentally fought.
Right.
So when the big issues came up, things like system d as much as, honestly, I didn't like it.
We did it right.
Because at the end of the day, the alignment with Debian, you know, is important.
It's not.
It's not something, you know, we also have to maintain a certain independent view of what's right.
If.
If Devin were to take a decision, I think, for fundamentally wrong reasons, if some person organization got unhealthy influence there and did stuff that I thought was unhealthy.
Well, we would blindly follow that off a Cliff.
Right.
But as much, again, as much as I thought that there was a lot of risk to Debian in that move, it was a move they made.
We chose to follow.
So I think we do our part in making sure that gap never gets out of control socially or technically.
I also, I mean, it's a simple fact.
There's a huge amount of contribution that flows back to Debian that is either directly from people at canonical or the broader Ubuntu community.
It's funny how people will characterize that.
Often people have a view.
They want to say, oh, this relationship is amazing.
So everything good that comes from that.
Or they say, well, this relationship is totally toxic.
So nothing good comes from that.
My own view is that it's complicated.
You've got a thousand people here, more than a thousand people there.
They all have their own sorts of interests and agendas and time that they're willing to put on to certain things.
And so you have to look at that as kind of like a tapestry, a weaving rather than a single thing.
And each of those threads are slightly different.
They're a different color.
They've got different properties of strengths.
The weaving, I think, is very healthy.
Right.
And I think if you look at the move that we made canonical Ubuntu made to address time t the arm 32 time t that was a huge move.
Cost us a lot of money.
We did it and we did it through Debian in the sense that we produced an enormous amount of work to contribute to Debian to make it possible for Debian to do that.
We could have done that differently, but doing it that way again keeps the two platforms closer together to take a good thing.
Yeah, no, I mean, I think you are spotted in the assessment because canonical is obviously big on taco and big on enterprise deployment where you really go head to head with rail.
Really.
And I think that's a space that Debian is not really suited to play in because these contracts, like you correctly pointed out, they need SLA's, they need all these other agreements that you wouldn't be able to get from an open source distribution even though the plumbing might be the same.
It's the commercial arrangement that is very different.
Okay, so let's go forward to kind of today and forward.
So snaps is obviously something that separates debian from Ubuntu in a great way.
And I would say Snap is probably one of the most controversial package managers in the last decade, if not more.
I would argue.
And that's something that stems from chemical.
What was the original reason?
And thinking around that, how does that kind of morph, the relationships?
I'm curious about how that has been perceived from your vantage point.
It's kind of curious to me that snaps are controversial.
Right.
Okay, so you're really upset that somebody's doing a ton of really hard, low level work to make more secure application distribution possible in a different way.
When people kind of pound the table about that, I'm sort of like, okay, so what would you like?
Would you like those people to have a monopoly on all the different ways you can get software?
Doesn't sound like a healthy idea at all.
You know what I mean?
We're not asking for monopoly.
I'm not out there saying that app image is bad and flatback is bad and Nix is bad.
Quite the opposite.
I'm out there saying, hey, it's great that we've got all of these things.
So I'm a little bit skeptical, and I think people should be a little bit skeptical about anybody who says, oh, it's.
It's obviously a bad thing that somebody is creating something.
Right.
And, like, this is how the world moves forward.
People take a deep breath, and they commit themselves and years of their careers to a thing which will do something.
Right.
And you get it all as open source.
That's not bad at all.
Right.
I think one of the interesting things about leadership is that you get.
Sometimes you get to experience it from different angles.
You know, you get to experience guerrilla leadership.
You know, when we started Ubuntu, were total guerrillas.
Guerrillas in the sense that, you know, total outsiders.
No reputation beforehand.
You know, we came kind of came out of nowhere.
You couldn't have predicted that Ubuntu would form, canonical form, you know, I mean, like, it's a sort of.
There's no economic reason for that to happen.
It happened because I was kind of passionate about it and I had the means to do it, but it's not a normal thing.
Right.
Yeah.
And so leading in that circumstance, you know, when no one had any expectations or fear of, you know, you get to say, hey, we should go do this, and 99% of people ignore you.
1% of people say, well, that's a really interesting idea.
You know what I mean?
Like, that's a really interesting idea.
Yes, let's do that.
Right?
Yeah.
No one cares.
Right.
You're just nobody.
Nut jobs off on the sidelines.
Right.
So leading under those circumstances is kind of fun because you can propose almost anything that you think is right and some people will agree and off you go.
No one else cares, right?
Yeah.
If you fast forward and suddenly the majority of Linux desktops are Ubuntu and you say, hey, there's a problem, we should do that now it's all different, right?
Because 1% of people will still say, oh, that's a really interesting idea, let's do that.
But 40% of people who are using your desktop will say, don't change anything.
I don't want any change.
Right.
And 59% or, you know, whatever's left will say, you know, ubuntu is this mortal threat to us.
Anything they do is a bad idea.
So shut them down, shut them down.
So it's the same leadership idea.
It's like, okay, how do we solve these problems?
But the context in which you're trying to lead is totally different, right?
Yeah.
And so personally it's a fascinating experience.
I really struggled with it when, you know, we started trying to get more bold and we found that people would react to the fact that were trying something rather than the details.
You know, sometimes I end up in a conversation with snaps.
I'll say, okay, just take five minutes and talk me through the technology of snaps, you know, and then tell me why it's a bad idea.
Right?
And people say, I'm like, okay, so you don't know what we're doing, right.
So why are you so opposed to it?
Yeah.
You're opposed to it in those circumstances.
If that's you're opposed to it because you don't like the idea that we might do something good, right?
So it must be intrinsically bad if we're doing something like, okay, look at the technology.
The technology in snaps, you know, it came from a realization that if were successful in getting more people to use Linux, then there would be more software that would be produced for Linux where it would not be true that you could trust it because you had the source.
So if you think about it in the debian context, in an Ubuntu context, when we got started, the argument of trust was because, look, we have all of the source, it was all built together.
We can look at every part of it.
If there's a problem, we can find that and fix that, right?
Yeah.
Then you add a Skype binary to that.
Now it is a sign of success that we get a Skype binary, but we can't use the same argument around trust for Skype.
And I think it's true to say that amongst the larger distributions were way ahead of anybody else in saying, well, we believe we're going to be successful for consumers.
We believe we can attract the isvs.
Therefore best we have technology that can essentially protect the system from some piece of software that we don't know anything about, we don't know who built it, we don't know what's in the code, we don't know what it does, we don't know, you know, I mean we have to sandbox it, right?
Yeah.
So I think it was an important realization, a realization that grew out of kind of belief in the future of open source as a platform and sincere desire to do stuff that would fix that.
Right?
Yeah.
The other thing it came from was again looking at the technology.
So I first got exposed to containers because ironically, so IBM had a team that was building LXC which was really kind of trying to bring into Linux, it was trying to bring Solaris technology, Solaris zones into Linux.
For whatever reason, IBM shut that down.
And I was advised by canonical engineers, hey, that team is doing something really interesting, we should bring them in.
So we did.
Then Docker happened.
And what was interesting is that Docker was essentially saying, look, the kernel capabilities that underpin zones or underpin LXC, you could use those slightly differently to get this kind of developer experience, the Docker developer experience.
And so it's kind of amazing.
Docker is a phenomenal new way of looking at how you ship a set of software to achieve a goal.
For me, I was interested in the underlying capabilities and I thought it was still important that you should be able to get system containers zones where it's like a whole machine and Docker.
So for me it's not a problem to have both of those.
A lot of people say, well, why do you keep funding LXE when we've all got Docker now?
Well actually we keep funding Docker work.
We make containers and LXC.
I think it's important for the world to have both of those, right?
Yeah.
When were looking at the application container problem, we said, well, one of the challenges with Docker is that one party, the application vendor, glues together system libraries and the application, and that's the Docker container.
And now you have a lot of duplication on the system because you've got these system libraries again and again and you have to trust that party to do both things.
When actually the world gets better, when you have experts, the system people do the system and app people do the app and you somehow make that reliable, right?
Yes, so that's why we started digging in.
We said, can we use the same kernel container primitives that give us Lexi and give us Docker?
Can we use those in a different way?
Which then gives us a better experience in terms of that relationship between the system and the application.
The other thing we realized was that Docker is really designed for things that integrate over the network.
You know what I mean?
If you think about three postgres docker images running there that are a cluster, they're talking to each other over the network because you can't guarantee that anyone is on the same machine as another one.
If you've got 20 machines in a Kubernetes cluster, one postgres process could be here, one could be there, one could be somewhere else, remove them, kill them here, restart them there.
So the network is the integration layer, but on a device, the integration on the desktop or in an IoT device integration is much more complicated.
You've got screens, who gets access to those?
You've got microphones, you've got keyboards, you've got cameras, you've got address books, you've got.
So integration is super complex and rich.
And we looked at how you would do that with Docker and it was just clear that you would end up with Docker command lines that were like pages of text because you'd be trying to use the thing that was designed for Kubernetes type use cases, you'd be trying to use that on device.
So we just took the view that's just a bit smelly from a technical point of view, that's possible, but it doesn't seem like a good idea.
And you're going to be constantly arguing with the Docker people about what you need in Docker, which they don't care about.
Those arguments usually don't go well.
So we just said, let's make the investment, let's build the capability.
We also said let's be really good about doing that in a way where it isn't tied to a single platform.
Let's make it so that you can use the snap that someone built for Ubuntu.
You can use it on Debian.
That's technically really hard because you have to go much deeper in the separation and much deeper in the integration so that can all work without SeG faults and oops, without API incompatibilities and so on.
And so we really had to go very deep into it.
Now we came up with a set of approaches, a set of solutions, a set of ideas.
So it's composed squash FSS.
It's digital signatures on those pieces.
It's a declarative language for integration points between those things.
If you go and look at those, it's pretty beautiful work.
You know what I mean?
If you could put that in an art gallery, I think it would be worth looking at from talking about other people.
And I think this is totally legitimate and I think it's great.
Other people have said, oh, that is an interesting set of problems.
We also want to invest in that and do it differently.
And they've made different technical choices.
And in the long run, I think the world should see that as good.
Right?
Like if canonical gets hit by a bus, great.
We've got flatpak appimage and others, right?
There are others out there.
If Flatpak turns out to have made some terrible technical choices, okay, great.
We've got snaps, right?
Yeah.
So for me, this is all goodness, right?
Like it's risky to make an investment, be out on a limb, but I believe in doing those things.
I think it achieves good things.
I mean, I would agree with that.
I mean, if you look back at package history, like going back to the, well, you mentioned Slackware in the past, in before, and that was a tarball.
Deb files are tarball with some wrappers and some hooks.
I mean, and I think ogre, one of the core developers, he phrased it really well a few years ago when I spoke to him about this and he said about security model around tarballs.
Sorry about dev files.
Do you really trust somebody to have root on your machine when you install a packet?
Because that's essentially what you're doing with a debt file.
They have root on your machine.
They can do anything arbitrary, guarded purely by the notion that it's open source.
Yeah, I read an article recently which was, you know, a really, it was labeled a rant, so at least it was kind of self aware in that regard.
But it was essentially saying so, you know, outrageous that the latest version of Buntu doesn't have a GUI way to install the dev.
Now we should get to that for sure.
But that GUI way should give you a lot of reasons to think carefully.
Right?
Like it shouldn't be easy for someone to say, oh, could you run this as, by the way, right, like you should want a lot of supporting scaffolding to help people take that decision well.
Right.
We're never going to get rid of debs.
You know what I mean?
Like dibs are amazing.
Canonical.
We're never going to get rid of debs.
Yeah, but we also have to use them in a way that is astute and ultimately gets the best result for people who trust us.
Right?
Yeah, but if someone wants to do.
Whatever they want, they're fine to, they can use Debian.
You know what I mean?
The world is full of options.
Don't rant at me for trying to build a way where the average person can use open source and feel pretty confident in it.
Right?
Yeah.
I mean, I think in today's era, it's so easy to obfuscate malicious code with AI, and it's got to be almost impossible.
I mean, we had many close calls and even real calls with that lately.
Right.
So it's.
That's just ones we know about, right?
Yeah, exactly.
And that's when sandboxing becomes even more critical and important.
And so I was, I agree that the premise of Snapchat, we're big fans of Snapshot screely, of course, but it'll be used to forever.
The learning curve is steep, and I think that's the big, I guess, beef.
A lot of people coming from the old school way, kind of similar to when systemd was introduced.
It adds a lot of good things, but it also raises the bar of complexity quite significant to package something more, package service.
I think it's a super important point.
It's similar again to things like Kubernetes where if you have a simple, if you've got a database, some middleware and a front end, and you're running that perfectly happily, and you then say, oh, I'm going to make it all better with Kubernetes, it's true, you might make it better in certain ways, but you are going to make it quite a bit more complicated, too.
There's all these extra things that suddenly you have to think about.
What we can achieve with snaps is that those things get solved between us and the community so that most people don't have to think about them, that stuff just works.
One of the challenges is the desktop integration is much harder than IoT integration.
And so when the security confinement technology stops something from being integrated, for an end user, that's really painful.
Right.
But for me, the path through that is forward, not backwards.
Right.
The path through that is to say, okay, we just have to keep investing and working on how all these pieces fit together on the desktop so that you can have a great desktop experience.
You aren't asked to make kind of like complicated technical choices.
And in general, we can defend parts of your system from other parts of your system.
Right?
Yeah.
And I think I'm a big fan of things like cubes, right.
Where you have like high level isolation and even virtualization level for every single application.
That's not viable for many practical reasons on a day to day desktop, unless you're like a pen tester or like a super high threat to yourself.
Right.
But I think the concept of sandboxing more and more is very good.
I think that line between container and VM is a very interesting one.
Right.
And confidential computing, the idea that VM is kind of encrypted to the host can't even know what's going on in there is very interesting.
Right.
So we are going to get.
There's still tons of amazing kind of science and technology coming in that regard.
I keep going forward as fast as we can.
Absolutely.
And this gives me kind of a natural segue to core or the core.
And maybe for those not familiar with it, do you want to do a kind of your pitch of what core is to the audience so they get a better understanding what that is?
Right.
So what if you could build a system where every significant component was isolated from every other component in a way where it could be updated transactionally like a docker image, but where you could still have the rich integration that you need in a desktop or device context?
And so that's Ubuntu call.
Right?
That's saying, you know, this is going to raise everybody's adrenaline levels.
What if everything was a snap?
You could put it differently.
You could say, what if the whole system was a set of vms?
Or what if the whole system was a set of microservices?
Or what if the whole system was a set of containers, right?
I.
The same proposition, right?
For me, if I imagine a world where there are ten to 100 devices on the Internet for every human that's on the Internet.
And I'm not talking about servers in data centers.
I'm talking about your webcam as a Linux device, your speakers as Linux devices, your tv as a Linux device, garage door opener as a Linux device in your household.
You have all of these Linux devices, all of them on your network, all of them in your home.
It starts to become, I think, really important to think about the integrity of those devices, the ability to have confidence in them even when you don't actually know that much about them.
Those questions are very hard.
How do you create trust in an environment where I.
There isn't that much to work with.
Right?
Yeah.
The Internet.
If we go back to the start of the conversation, the Internet felt a little bit like that, you know, the 1990s saying that on the Internet no one knows you're a dog, right?
Yeah.
And how do you bootstrap that trust?
Like where does it come from?
What will we come to kind of use to bootstrap that?
I think those are really interesting questions.
And here, you know, it is important for us to develop answers.
Core is a way of saying, look, can we get to a future where if you install Linux on your laptop by default, you have that level of integrity and certainty about the components of the system without losing the freedom and the flexibility you have to just muck about.
Our approach to that is going to be different to Red Hat's approach to that.
And red hat, don't forget red Hat's 20 times the size of canonical by revenue.
20 times.
So we have to be a little kind of like guerrilla still, in thinking about how we also attack that problem independently.
We could just go along with what the big dog does, but we're not really adding any value.
Yeah, I mean I'm a big fan of core.
And when for?
Well, back in the days when it was called snappy, the reason why I got really excited about it at screen when we assessed various platforms, Washington, you probably remember Coreos back in the days when that was still a thing before they were bought by red hat and kind of silently killed off.
The idea behind that I found super fascinating was this exact thing that you described.
But for a server, basically av partitioned system and everything is mounted, read only, you have your containers, that's where everything lives.
And beyond that you can just throw away the device in the sense of like there's nothing persistent stored on that device.
And I think that was encapsulated by core pretty well.
And that's where I'm very bullish on.
I'm still very bullish on the concept.
Now one of the things that I got excited about because I haven't really thought about this in the lens of core before until the last Ubuntu summit where there was this talk about ephemeral desktops.
And I know that was a kind of premature announcement, but I really liked the idea of ephemeral desktops in general.
And core makes for a.
A very good random environment for that.
More so than any other Linux environment, at least from my perspective maybe.
Where is your head around that in terms of ephemeral desktops and ephemeral workstations?
So I think the desktop is possibly the most important platform to get right.
If you think about the security of the software developer situation.
It's hard to argue that you don't want good security in that kind of environment.
Right.
It's also, I think, important to recognize that you need a good experience in that environment.
So I think there is a meme that great developers have to suffer this idea that if it's too easy, then you're not a great developer.
I think that's exactly wrong.
I think great developers often are willing to make choices that are unusual choices relative to the rest of the consumer population because they know things that the rest of the consumer population doesn't know.
They can be confident about things that other people wouldn't be confident in, but they don't want to waste their time on stuff that isn't letting them express their developer ambition.
Right.
Put their time into building the future.
So that's, for me, that's what Ubuntu is really about.
It's saying, okay, let's enable developers to work with the latest and greatest open source and build the future, whether that future is the next entertainment thing, or the next science thing, or the next business thing, or government thing, or AI thing.
But let's try and do that in a way where they still have a great experience, where they don't have to worry about the system itself to do that.
I think we want to ship the latest open source.
Yeah, I think we want to work with all of the silicon and PC type manufacturers so that when you use Ubuntu, not only are you using the latest open source, but it's optimized for intel or Nvidia, AMD, Qualcomm, whatever your silicon substrate is, bring all of the latest developer tools to that environment.
Enable that environment to upgrade and evolve without you having to spend a lot of time on it.
Right.
And enable it to be secure.
So if you want to run, you know, some proprietary application, some game or some that, you don't have to worry that is potentially a backdoor into your system in the way that it would be if it was a dev or an RPM.
Yeah, all of that makes me really want to do an Ubuntu core based desktop.
All of that.
Yeah, and I think we can achieve that without getting rid of devs.
We'll still have devs there.
Right, but you can use for your current developer experience.
But when you do that, you won't be putting your email at risk, you won't be putting your password manager at risk, your ssh keys at risk, as long as the kernel does what it's supposed to do, we'll have better robust safeguards effectively.
Yeah, I mean, and that speaks a lot to, I mean, chrome OS is for the average desk worker, like we use materially.
Like that's every non engineer.
Like you get provisioned a chrome Osborks because we know it's secure.
We know that what you really need to do is just in a browser anyways.
It boots up into a browser for the non developers out there.
That probably captures what 90% of the, 95% of what people do on a day to day in a desk job.
Right?
So getting that experience right on core, I think that's really, that's super interesting.
The other thing I wanted to zoom in a little bit on core in particular, because you mentioned that the shipping of images and snaps, rather, you can tell where you kind of unpeel the layers of core that a lot of the inspirations are I guess, drawn from your early like, ca days.
I think in terms of design, how things are signed, how things are to verified.
I feel like the more I understand about core, the more you start to see those correlations.
Do you want to speak maybe more how you think about that security side with snap updates and Snapcore perhaps?
Yeah.
So if I go back to the sort of the birth of snaps, we had a previous iteration of the idea of kind of like an app package, which was part of our mobile phone effort, and that was called a kind of click package.
And that was very much built in a rush as part of trying to get the phone story out there.
And we initially started, when we started thinking about IoT, we said, oh, well, why don't we just use that package here?
And so when I sat down to look at it though, I just didn't think it had the rigor.
That's not necessarily a criticism of the people who built it.
I like them all.
It's just that when you're building something to achieve that goal, you tend to kind of, all of your eyes are there.
And when I was sitting looking at it, I had a set of goals in my mind about integrity of the system, the ability to know, you know, how to take a decision automatically.
That would be the correct decision, and provably so.
Right.
And that required a bunch of thinking and designing that we didn't need to do to quickly ship them.
Like a mobile phone concept.
Right.
And so the architecture of snaps, you're absolutely right, there's a series of digitally signed documents.
Those documents describe what we call it as the voices.
Right.
So if you think about a printer.
Think about a projector in a boardroom of a bank, right?
Running a Netflix app.
Think about the voices, right?
You've got the projector manufacturer, like Epson or whoever it is, they want to say what happens on that device?
It's an Epson branded device, right?
They're sort of responsible for that.
It's their brand.
Right?
You, you may have the operating system provider, like canonical, ubuntu.
We want to say what happens on that.
We're responsible for certain things.
You, you have the bank, it's their building, right?
Like they want to say what happens on that device, right?
And then you have Netflix, right?
It's there.
It's their, it's their movie catalog, right?
They want to say, what happens to that app on that device, right?
Yeah.
So suddenly everything gets complicated.
And this is the sort of scenario that were thinking through when we did this 2.0 of click packages, which became snap.
And the heart of that was sort of a 30 to 60 page document that written by me and our CTO where we said, look, let's not be in a rush.
We're not trying to ship a phone quickly.
That's all done.
Let's sit through and design what we really want to solve this problem of how the pieces of software on a system can evolve moving forward.
You know, there's an update of this, there's a refresh of that.
There's a new thing that wants to install here where all of those different actors are saying what they want to say, and the device is able to take the right decision and move forward in a very reliable way, which means that if it makes a mistake, it can go backward and move forward differently when a better idea is put to it.
And that technically required a lot of thinking.
The cryptography around that is all about integrity of the documents and the software and so on.
Since then, obviously, it's evolved significantly.
It's now a very rich system to describe how pieces of software should relate to each other through an update, upgrade process and so on and so forth.
I think the team continues to do really beautiful engineering.
If you think about configuration of that.
If you think about configuration of that printer.
Sorry, that projector, you go through the GUI of the projector that's up on screen.
Well, that is not network manager's GUI.
That's going to be the projector software GUI.
But there you need to specify an IP address.
Is the IP address of a projector?
Is that a projector app configuration item or is it a system configuration item?
So the team continues to do really, I think, trailblazing work, deep work on how things like configuration live in a system that's a shared system.
Right.
It is a projector.
So that projector app should be pretty much in control, except it's also on Ubuntu, which means things like network manager sort of may need to be in control.
How do you do that?
Right.
That's a really beautiful, very hard problem.
I don't hear a lot of discussion of that problem on Reddit, but to.
Me it's the sort of problem you.
Really have to solve and think deeply about and invest in if you want to build the future.
Yeah.
And I think that assertions is another thing that we use quite heavily internally of, like where you can say, here's how the state should be, we've cryptographically signed this with our PGP keys.
Unless that checks out, the device restored out.
And that's something that you're absolutely right, that you don't get to those level of details and understanding until you actually run this at scale and really understand the problem space well enough.
So I think that's.
Yeah, I think that's Kudos to the team for engineering because I think there's a lot of brilliant thought going into that, to be honest, because I think that's something you see very often.
If you imagine some piece of equipment in a remote place, in a mine or out at sea or something, you may not have an Internet connection, but you want to update that device and you don't want just anybody to put software on the device.
So the way snaps work is you present the device with some signed documents and some signed software and say, does this make sense to you?
If it makes sense to you, move forward.
Right.
And then the device is able to decide.
Right.
Based on what has been told by all of those voices in the digitally signed documents.
Right.
So it is a beautiful mechanism.
I think other people are going to attack the same problem and they'll probably come up with their own solutions.
That's healthy, in my view.
Yeah, absolutely.
All right.
The thing you want to wrap up this session with is something that is a very hot topic right now, in particular, from the hashicorp to IBM play that's been playing out for the last few weeks.
It's open source licensing, and we kind of briefly chatted about this before.
But how do you see this play out?
Obviously, it's a very complicated topic, and you guys are somewhat in the center of that in one way or another, either packaging all those packages together and distributing them or obviously writing new pieces of software like snaps and pushing that out.
How do you see this landscape evolving and shaping?
And I'm just curious about picking your brains on that.
I'd start with analogy to the Creative Commons, right?
Like if you think about how Creative Commons came about, Larry Lessig, who's a professor of law at Stanford, I think is observing sort of objectively at a distance this open movement, and sort of says, well, wouldn't it be interesting to have something similar for the written word, for content, right?
And because he's not attacking it from a point of view where it's his content and he's trying to push his license for his content, he sort of does a more objective view.
He says, look, let's recognize that there are different things that people might care about and let's build a kind of a standard model of content open, of open content licensing which recognizes those different things.
And so we end up with Creative Commons share alike Creative Commons, this, that, attribution required, et cetera, right?
Like a physics model of the quote of the quarks and the leptons of content licensing in an open way, right?
I think that's still a very elegant piece of work, right?
And you don't see the same kind of insane, almost religious arguments in the Creative Commons world that you see in the licensing world, because I think licensing came from the software licensing came from people who were really licensing their own work, right?
It was stormin and the GPL, it was the BSD crowd and so on.
So of course I think just less objectivity and less attempt to find a universal way of thinking about this, right?
So I think that's one of the challenges in the open source world.
I would say that my view is because we're distro, we've got to accept that people are going to have different opinions about the licensing of their work and we have to just work with lots of software.
I didn't say they were saying you can't get your software in Ubuntu if you don't adopt my view of licensing.
That would be nuts.
So we're a bit more like Larry Lessig and saying, look, we have to accept a range of views of this and people are entitled to use their views.
So that's one starting point.
I'm a little bit uncomfortable when people come with overt agendas and saying that other people are wrong.
I'm just saying, well, no, other people care about different things.
Wrong.
They just care about different things.
That's I think the first principle, for me, I think the second principle is sustainability.
Right?
There's a question of, look, software is not going to write itself, not in the immediate future anyway.
You want to think in every case where software is being written, who's writing it, what do they need, what's motivating them?
And again there the answer is, it's different.
If you've got someone who's writing software, they work for a government and they're writing software to express government policy, then what they need and what's going to be sustainable there is totally different than if you've got someone working inside a giant tech company and they're writing software that they want other people to have access to and use, which is totally different than if you've got a research group at a university, which is totally different than if you've got a startup.
Right?
Yeah.
And I think part of the challenge is that a lot of the debate and discussion presumes that everybody should be looking at this from the same perspective.
And they just aren't.
They just aren't.
You've got to walk a mile in the other person's shoes.
You've got to say, okay, if I was working at a government department, publishing software, I would feel differently about this.
Right?
And that's okay.
Yeah.
If I was a Google, I would feel differently.
But what we have is we have people who are at a giant tech company instructing other people that their license is wrong.
And I'm like, hold on a sec.
Your circumstances, what works for you is just totally different than what's going to work.
Can't you see that?
Like, where's the empathy?
Right?
So that's the second sort of thing for me.
And then the third thing is to say, look, we have to find things that work for small independent producers.
Like, I would hate a world where the only open source is going to come from governments and giant tech companies.
That would be a terrible world.
We lose a lot of the richness of innovation.
And the reality is different licenses play out differently from a sustainability point of view.
They play out differently depending on what you think the business model is.
If you're a giant tech company, your business model is actually account ownership.
You know, 350 of the Fortune 500 are already customers of yours.
You can take a new piece of software to them, you don't have to sell it per se, you don't have to pay to go in there at risk, you're already paid to be there, right?
Your posture, from the point of view of making money out of software, which is making it sustainable, which is not a bad thing.
Right.
It's not a dirty word.
Your posture is totally different than if you're a tiny company, right.
And those licenses, very appropriate licenses are then going to be different.
They really are.
So again, when you have people with one set of circumstances lecturing another group, I'm like, well, it's unhealthy, right?
Yeah.
I mean, where I do think we've gone wrong, I think there are two big problems.
One is that in a world where everybody thinks the business model is SaaS, there's a fundamental asymmetry.
The clouds just have a big advantage because they already have the customers and they really have all the machinery to make this piece of SaaS fairly easy to produce.
They don't have to do all this other stuff, they really do it right.
They really have their customers, they already have the credit card details, they have a small piece of work to do to make sales relative to what a Montgomery has to do or something else.
That's one big asymmetry, right?
The other issue is money is VC.
When a small organization takes a lot of money they also have to take a lot of direction and that direction isn't really interested in the open source or the software.
This is where I think things have really gone wrong, is that the business model of funded open source for a while has been SaaS.
SaaS, you're at a disadvantage to the clouds.
You have to spend a lot more to make a SaaS than Amazon has to spend or Microsoft to spend or Google has to spend, right?
And if you're getting that lot more money from VC's, those VC's now want a big return.
And it's this confluence of factors that is leading to the VC funded companies making some pretty dangerous moves.
Right?
I have empathy for that.
I don't think it's a great idea, but I have some empathy.
So what I would really like to see is new business models for those independent producers that aren't so fraught with tension with the public clouds and also sources of funding, which is the same real thing fundamentally that don't push them to China, do much more work than they need to do to produce the open source, which then has to generate a return.
And so ideally what I'd like to see is we get to a place where you, as a smart bunch of open source developers, you can plot a course to independence, you can work for yourselves, you can earn good money doing that so you don't feel bad that you're not working at a big tech company.
I don't really care about giving the VC's a return.
I think that's their problem.
Sorry.
But then I think we could get into a healthier place.
Right.
What you're seeing right now is kind of experimentation to try to figure out what that might look like.
It's a bit messy.
It's not the end of the world.
We're going to get there.
Right?
Yeah.
The role I would like canonical to play in all of that is to be a mini tech company, not a big tech company, and not an independent producer.
That to be in that tasteful place where we can help small producers reach the market without necessarily having to raise large amounts of vc, which then forces them to dangerous moves and antisocial moves.
Fundamentally, I have to try to figure out how we try to do that.
I think that's a moral obligation to use our position in the market, such as it is.
We're not Google, not red hat, we're 20th the red hat size.
But to use our position to try to help those independent producers become sustainable and successful.
If they want to go make billion dollar exits, good luck to them.
Then they probably do need to take VC.
Then they may have to make some antisocial moves and so on and so forth.
I'm not here to help them do that, but I would like to see good developers who, pursuing their dreams, get a great, you know, have a secure future for that.
Right.
That's an important.
Yeah.
And I mean, one of the good things with open source, I guess that there is a built in failsafe, which is the fork, which happened with my sequel, which happened to, well, what's happened to Hashicorp now?
But, yeah, yes, but like, when Maria happened, I thought, that's a bit smelly.
You know what I mean?
Like, well, Monty got paid very handsomely by sun.
Now he wants to get paid again.
They weren't investing in the R and D.
Oracle continued to do a great job investing in MySql R and D.
Like, don't hate on a company just because they're that company.
Hate on them if they do terrible things.
Oracle's been a great steward of mysql.
It's still open source.
They're investing very healthily in it.
There's nothing wrong with that.
So, yes, you can fork, but if you're going to fork, you have to figure out what your own sustainability plan is.
And I didn't think Marias was very good.
Right?
And look.
Look how that played out.
Open tofu.
Really?
Do you know what I mean?
Like, those are all folks who have ridden on the back of terraform right now.
They're saying they're going to do a, you know, they're going to fork it.
And there's moral high ground in that.
Okay.
But you better be sustainable, and sustainability isn't now copying someone else's code and changing the license.
Right.
It's actually writing it.
So I don't know that fork is a simple answer.
Sometimes it's the answer, but I don't know that it's a simple.
Yes.
Yeah.
I mean, it brings back to the question about funding and open source in general, which is a far more complex problem than licensing.
I would.
It is the important question.
Right.
Yeah.
I'm a chairperson who says all open source should be amazing and you should fix my bugs and I don't want to pay anything.
And by the way, make it permissive licensing.
Good luck with that.
Anybody who maintained any.
Let me know how that works out for you.
Yeah.
Like anybody who has maintained any level of open source code knows the burden that it takes and it's not.
It's fun sometimes and.
Yeah, exactly.
So I think that's a largely unsolved problem, unfortunately, today.
But I hope that something that.
I think you're right, that is the core of the issue that hopefully we'll see some progress.
Yeah, we'll get there.
We'll get there.
I'll try to help.
Yeah.
I think you've done a great job with that as well, so.
Yeah, absolutely.
Mark, thank you so much for coming on the show.
That's a wrap.
Very much.
Appreciate it.
And some really good conversations.
So thank you so much, Mark.
Have a good one.
Lovely to see you.
Thank you for the invitation.
Bye.
Found an error or typo? File PR against this file or the transcript.