The former director of engineering for Google’s Fuchsia project, Chris McKillop, has shared with us some insights about how the project got started and where the operating system is going next.
Earlier this year, we reported that Chris McKillop, the director of engineering for Google’s Fuchsia project, had departed the company. During his 10 years at Google, he was initially part of the broader Android team before spending seven years helping to bring Fuchsia from concept to first launch and beyond.
I recently had the privilege of talking with McKillop about those early days of Fuchsia’s creation and about where he envisions the project going next. Along the way, we took a few insightful detours into the failures of the Nexus Q, the successes of Flutter, and Meta’s cancelled Fuchsia project.
When you started at Google in 2012, you were a member of Nexus Q and Android TV teams. When did the transition to Fuchsia begin for you, and what did that look like?
So, when I first joined Google, I joined a project called Android@Home, and Android@Home was building Nexus Q. I sorta came into the middle of it. It wasn’t from the very beginning, at all. I helped get it shipped and helped un-ship it.
I’m sure you’re familiar with the legacy of it. The takeaway from that is pay attention to what cables you keep in the box. We didn’t put speaker cables – we put an HDMI cable for a product that was mostly about speakers, and we got destroyed over it.
Then Google acquired Nest [in 2014], and in the acquisition of Nest, a lot of what we were doing at Android@Home ceased to be relevant. It had overlap with Nest, but Nest was clearly where [Google] was going.
So I salvaged out what we were doing at Android@Home, mixed it in with the Live TV work that was coming out of the original [2010] Google TV, and built Android TV out of it. We built that from 0 to 1.0.
Then this opportunity popped up in this group that Sundar [Pichai, who was a product chief at the time] and Larry [Page, Google co-founder and CEO at the time] had started, to basically look at the future of everything that Google was doing — so, unconstrained, “go look at this stuff.”
I think some people out in the world have referred to it as a “senior engineering talent retention program.” I’ve seen those words used. That’s sort of what it was. But I saw it as an opportunity to come in and work on some things.
I joined Google in January 2012, and about six months after, I started working on the pitch for Fuchsia. That’s where the name got picked. In the fall, after we unlaunched Nexus Q is probably when the actual first version of the deck got built.
One of the things with operating systems is that it takes a really long time to build them, and then it takes a really long time for them to actually achieve success. [You need to] start working on those things in an overlap. When I got to Google, no one was working on that.
I found that really surprising, since the windows were closing. If you didn’t start working on it, you’d be in the same situation Apple was in, in the 90s, before they acquired NeXT. Or you could be in a similar situation to the companies that used to build operating systems that either don’t exist or don’t build operating systems anymore, as they got supplanted.
A bunch of us started working on ideas. I actually put together a pitch deck for Fuchsia and didn’t get funding initially. But I never stopped thinking about it or working on it, and this opportunity came to help on this next-generation computing area.
I tried to get some people excited about [Fuchsia] and was not successful in getting that excitement. I suspect mostly because I hadn’t been at Google very long.
At that time, Fuchsia was never originally about building a new kernel. It was actually about an observation I made: that the Android team had their own Linux kernel team, and the Chrome OS team had their own Linux kernel team, and there was a desktop version of Linux at Google [Goobuntu and later gLinux], and there was a Linux kernel team in the data centers. They were all separate, and that seems crazy and inefficient.
The architectures were all different, which meant that outside developers couldn’t actually do work and attack all the platforms Google was offering. You had to do bespoke work.
[Companies Google was partnering with] had separate teams for the Chrome OS engagements and the Android engagements, which was crazy, right? Part of what we were talking about in the original pitch was actually fixing that for the long term.
Apple has a Core OS team. Microsoft has a team that’s dedicated to building Windows and the NT team. There’s a pattern that exists from people that have been doing [operating systems] for a long time that I basically wanted to copy, and then take some of the attributes from the way Apple did it that I haven’t seen anywhere else. I hadn’t seen it before I went to Apple. I hadn’t seen it after. I hadn’t been able to replicate it.
[We were asking questions like] how can we get some of those attributes like “full stack ownership” and really worrying about the performance from every layer of the stack, so that you can deliver the best experiences to users?
Speaking of Apple’s influence, you’ve often said the two main inspirations of Fuchsia (even lending the project its name) are the “Pink” and “Purple” projects from within Apple. Pink spun out of Apple to become Taligent, but was ultimately canceled. Meanwhile, Purple was the original iPhone OS, which changed the world of computing as we knew it. Could you share about how each of these had an influence on Fuchsia’s design?
Pink was actually the reason I got into operating systems. I was in high school when Pink was happening, and I was sort of a fanboy, following what was going on in the industry. They were doing some really interesting work around developers, developer methodologies, and object oriented design, but at the wrong layer of the stack. I wanted to think about it up and down the entire stack and take inspiration from that.
Then, I worked on Purple at Apple. There was a lot of really amazing work around touch, touch latency, and graphics performance that no one has replicated outside of Apple. It’s great for Apple that they have that, but I don’t think it’s great for the world that only Apple has that.
My hope was that, with some focus, you could replicate what’s there, if you were willing to own up and down the stack the same way they were.
One of the problems a lot of people have when they build things on top of Linux is the Linux system call interface. There’s all that stuff underneath you, but you don’t worry about it, and then you build stuff on top. Most people don’t fully own that stack when they’re using the Linux kernel.
It’s just really hard to do because of the nature of the community and the size and scope of that codebase. That’s part of what I wanted to do. [What if] we narrowed it down — if we only took from Linux what we needed to take from Linux?
You know, Apple didn’t write all of Darwin [the basis of macOS, iOS, and more]. They took FreeBSD, stuck it on top of Mach, and had an alternate universe of drivers so they could have that control. So could we do something similar? Those were the questions I was asking.
Also, when you’re building something new like this, you have to decide where you’re focusing. That’s part of the Purple [influence] too: Being focused on consumers. Not focused on data centers. Not focused on hard-core embedded systems where you’re doing real-time stuff for robots. But focused on consumer products and the problems that are faced by consumers and developers for consumers.
So that’s where the name came from.
You mentioned that you were having trouble getting interest built around Fuchsia within Google. What finally changed their minds and how did the ball finally start rolling?
When I moved over to this sort of “other project” and I left the Android team, this other project was looking at new ways of building applications, new ways of building UIs, new ways of doing things. They weren’t necessarily looking at new ways of building operating systems. I brought that to the table and took over those other projects as well.
One of the things that came out of that is Flutter — that’s the new ways of building UIs. When I joined, it was just Adam Barth, Eric Seidel, and Ian Hickson, and I helped them grow that team before I pushed Eric [to grow and] do it by himself. Great work [is happening] there.
[Editor’s note: Shortly before this article was published, the Flutter team announced that Eric Seidel is leaving Google to begin a new adventure.]
Then we started Fuchsia, and we used Flutter initially. The reason Flutter supports Fuchsia was [because] we were building this new operating system, and you want to talk about these new ideas. If the first thing you do is say, “We have to get all of Android running,” you’re never going to get to the point of being able to demonstrate anything.
Honestly, even just saying “I want to have all of Chrome running” — which is the second one we did, after we did Flutter — still took a really long time. You can see the commit history in Chromium of how long that took. These are huge applications, huge codebases to get running.
[Editor’s note: Work to get Chrome running on Fuchsia began in earnest in early 2017, with an early prototype available in late 2018. We didn’t see the full browser running there until March 2022.]
Thankfully, at least Chrome runs on Windows — runs on Mac, runs on Android, runs in a bunch of different places — and Windows has a lot of similar patterns to Fuchsia. They have the right cuts in the right places for us to be able to go in and do stuff. That’s not so much the case on Android.
We wanted to be able to demonstrate something very quickly. We wanted to be able to test these theories we had about how things could work in the future.
We actually put together some really compelling demonstrations of how we could move the needle in areas that matter to people. That’s when we started getting excitement built up around the project and grew.
When the rubber hits the road, you figure out where you were living in “idealized” territory.
That’s when we started focusing on “OK, where can we ship first?” Because, the thing is, lots of people start operating systems. There are operating systems started all the time. There are IRC chat channels in lots of places, lots of projects in GitHub, and lots of university kids.
Starting an operating system is actually not very hard. Shipping it to millions of people, on the other hand, has only been done a handful of times. It’s really important to me that projects ship, that it’s not just an academic research project.
It was good to be able to find that thing for us to go ship on. Even if [a device like the Nest Hub] is using a fraction of what Fuchsia is capable of, it doesn’t matter. We learned so much. When the rubber hits the road, you figure out where you were living in “idealized” territory.
As you said, operating systems are started all the time. You could say one of the key differences about Fuchsia is that there was an All-Star team of developers and thinkers that were working on that — from WebOS, BeOS, iPhone OS, the list goes on. What was it like working with these types of All-Stars?
We actually had a slide at one point — that I don’t have a copy of anymore because it’s a Google thing — but we had a slide of all the 1.0s that the initial Fuchsia team had [previously] shipped, and we could barely fit it on a slide.
Wow.
It was amazing. It was an amazing point that we were trying to make: This team understands what it takes to take something from idea to the first launch. It was an amazing group of people.
Some of them I had worked with before, obviously. You don’t have to go through very many “degrees of Kevin Bacon” with the operating systems [community]. You only need to get to about three degrees, and you’ve basically covered the world.
Like you can go from me [and connect to] Steve Sakoman, who was my boss at Apple when I first joined and co-founder at Be Inc. [With that connection,] I now [connect to] everyone at Be. And now, how long does this take [to be connected to everyone]? It doesn’t take long, right? It’s a very close community.
There was this point, in the early 2000s, where academia became obsessed with microkernels and then everyone sort of dove in on microkernels. Then with Android and the iPhone becoming so big, operating system research kind of dried up a little. So the same people who are doing operating systems then are the people doing operating systems now. The group doesn’t even grow by very much.
I think there’s finally new, interesting people coming into the space, but it was pretty stagnant for a while. It doesn’t take long to [connect] all the people. So it gets around that “Hey, there’s this new operating system being built; there’s this new thing happening.”
This team understands what it takes to take something from idea to the first launch.
Because we were very committed to doing it in the open, a lot of the people who worked on operating systems in the past [became interested]. Their work is locked up inside of whatever company they were working at, and that was very frustrating to them.
There’s one guy on the [Fuchsia] team who has a history of leaving a company and then spending the time after he’s left the company to transcribe his brain into GitHub. Because that’s the one thing — it’s in his head, and if he puts it on GitHub, it’s his forever.
That’s why we have LK, for example. LK is probably the most-installed operating system in the world that no one knows about. It and its progeny are on every mobile phone that shipped in the last decade.
And LK was a core basis of Fuchsia too, wasn’t it?
It was how we started the kernel, yeah, because it knew how to boot up on ARM and x86 and get things going. It didn’t have a user space or an application model, but it had a nice, very easy codebase from which you could sort of bolt into the middle and then start building the shell around it.
Then eventually we went back in and took that part out as well, but that was an amazing bootstrap. I mean, Travis [Geiselbrecht] is on the team; Travis wrote LK. There were a bunch of people who worked on LK in various forms and at other [companies] who are also on the team. So that made LK a very natural place for us to start.
And in the early days of that project, we were actually looking at really small embedded systems as well. So we were actually using LK for these other projects that we stopped working on when we focused in on Fuchsia.
LK is used in a lot of places. It’s used by Qualcomm, and it’s used in a lot of embedded systems now. And so yeah, it’s not hard to find the places it’s being used.
Having worked on many operating system projects yourself — iPhone OS, webOS, QNX, and Fuchsia, to name a few — do you see an upcoming generation of operating systems bringing revolutionary new ways to use a computer?
Maybe. We’ll see. Part of what I think needs to happen next is going to be around how… we get to the point where we’re not necessarily going from static application to static application while we’re doing things.
If you look at the work that happened in the 90s with OLE and COM, they weren’t wrong in their thinking, right? It’s crazy that I have to rebuild this entire application to add this one feature to it.
I don’t think they were thinking about it the right way. They weren’t thinking about security and privacy and the issues that arise when you have live code coming from the Internet that you want to put together with other code from the Internet — that neither of whom you know the developers and you want those things to work together.
So I think whoever can crack that is going to make a big change. If you look at the way Apple’s doing their widgets and around applications working together between the watch and the phone — you can tell they’re thinking about it.
You can see the Android team thinking about it. [The Fuchsia team was] thinking about it. If I look at the things happening around the world now, people are thinking about this.
It’s gonna take some time, and it’s not clear that there’s an answer yet. It’s a hard, hard, hard problem.
I think one of the things that is in the way is the security — the fundamental security architectures in the silicon. Look at the Spectre/Meltdown [exploits] and the style of exploits that are occurring. There has historically been an assumption of: “This part is safe and we don’t need to worry about that. We can use those hardware features to ensure these software objects and entities can operate correctly.” That’s not true anymore. There’s going to continue to be versions of [that style of exploit] found.
I actually think the next innovation is going to be that [silicon] level, which will then unlock these next levels. So it’ll come from the top and the bottom [silicon design and app architecture] at the same time. Then there’ll be something, once those things lock into place correctly.
It’ll be something new, and I don’t know how long that’s going to take. These things are not fast. I was talking to someone the other day about how the first RFC for the Internet was written in 1969. When you start talking about that with people, then you realize the scope of these large-scale standards-based things — which is how technology wins.
To have a world in which everyone is able to participate, you need to work on standards and interoperability.
If you want to have a world in which everyone is able to participate — which is a thing I’m a big believer in — then you need to work on standards and interoperability. And standards and interoperability are hard.
And for the last 15 years, [that ideal] has also been the antithesis of the growth of tech. Right? Technology’s all been about large, centralized, fast-moving companies building walled gardens of their worlds that they can then give to consumers.
You can’t show up and add a feature to Gmail. That’s just not how it works. I think it’s time for there to be new kinds of thinking.
Having had a front-row seat all of those years, where do you personally predict or envision Fuchsia being 10 years from now?
I think there’s a small chance that everything that Fuchsia has done ends up being inside the Linux kernel. They’re trying! They’re actually doing things now, which is great. That would be an awesome outcome, because it’s really about the features we were trying to build.
I’m not a big believer in NIH [not invented here] or that kind of thinking, but I do feel people become complacent. Linux had “won,” and so it was very easy to be complacent. When you have new things come along and show that new ideas are possible, then other people adopt those new ideas. I think that’s awesome. That’s always a possibility.
But I actually think, 10 years from now, everyone in the world is going to be trying to figure out how [best] to use Fuchsia. I think there’s gonna be some serious competitive advantages that using Fuchsia is going to give companies, and they’re going to need to figure out how they’re going to adopt it. That’s where I think [Fuchsia] will be in about 10 years.
I think everyone’s going to be trying to figure out how they can use Fuchsia too.
Some people already will have [adopted it by then]. I was sad when the Fuchsia fork at Meta was canceled. I actually think that they forked it too soon and that we hadn’t worked closely enough together during that.
I really believe that the architecture and the advantages that Fuchsia has over existing operating systems are real, and I think the team is doing their thing. Assuming that they finish the things that they’re off doing, I think everyone’s going to be trying to figure out how they can use [Fuchsia] too.
That’s one of the beautiful things about it being an open source project. Because it’s there, it will eventually be something that people will be looking at and going “Oh, we can use that too.”
Yeah, the [Fuchsia] team is doing great. I keep watching the Discord and talking to people.
That’s wild to think about. It really is. I was actually feeling the exact same way about Meta’s Fuchsia-based project. It sounded so exciting, but of course, we didn’t hear about it until Meta had already canceled it.
[Meta] had only forked a small subset of what Fuchsia is doing. At one point in time, Fuchsia had what we referred to as a “layer cake” model. That’s where we had the gems: Zircon, Garnet, and these layers above. The problem was [Garnet], the layer above Zircon, was already too opinionated for the team at Meta, and so they only forked the Zircon layer and below.
By the time we had actually made that realization on our own — that these layers were too opinionated — and had rebuilt [Fuchsia] so that it could be much more modular, [the team at Meta was] already way down this path that they were going on. So it was hard to see a way in which we’d be able to work together on that, even though I was trying to get them to consider “how could we be more collaborative.”
The guy who did that [Meta] fork is now at Google. He used to be at Microsoft — he was one of the NT guys. That’s actually part of the reason why. He saw [Fuchsia], and he was like, “Man, that looks a lot like what we were doing back in the day.” So he was excited about it.
Our sincerest thanks to Chris McKillop for taking time to share these insights!
FTC: We use income earning auto affiliate links. More.
Comments