When Apple decided to make its own web browser back in 2001, it chose KHTML/KJS from the KDE project as the basis of its rendering engine. Apple didn’t merely “adopt” this technology; it took the source code and ran with it, hiring a bunch of smart, experienced developers and giving them the time and resources they needed to massively improve KHTML/KJS over the course of several years. Thus, WebKit was born.
In the world of open source software, this is the only legitimate way to assert “ownership” of a project: become the driving force behind the development process by contributing the most—and the best—changes. As WebKit raced ahead, Apple had little motivation to help keep KHTML in sync. The two projects had different goals and very different constraints. KDE eventually incorporated WebKit. Though KHTML development continues, WebKit has clearly left it behind.
When Google introduced its own web browser in 2008, it chose WebKit as the basis for its rendering engine. Rather than forking off its own engine based on WebKit, Google chose to participate in the existing WebKit community. At the time, Apple was clearly the big dog in the WebKit world. But just look at what happened after Google joined the party. (Data from Bitergia.)
Given these graphs, and knowing the history between Apple and Google over the past decade, one of two things seemed inevitable: either Google was going to become the new de facto “owner” of WebKit development, or it was going to create its own fork of WebKit. It turned out to be the latter. Thus, Blink was born.
Google has already proven that it has the talent, experience, and resources to develop a world-class web browser. It made its own JavaScript engine, its own multi-process architecture for stability and code isolation, and has added a huge number of improvements to WebKit itself. Now it’s taken the reins of the rendering engine too.
Where does this leave Apple? All the code in question is open-source, so Apple is free to pull improvements from Blink into WebKit. Of course, Google has little motivation to help with this effort. Furthermore, Blink is a clearly declared fork that’s likely to rapidly diverge from its WebKit origins. From Google’s press release about Blink: “[W]e anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat.” (There’s some streamlining in the works on the other side of the fence too.)
Does Apple—and the rest of the WebKit community—have the skill and capacity to continue to drive WebKit forward at a pace that matches Google’s grand plans for Blink? The easy answer is, “Of course it does! Apple created the WebKit project, and it got along fine before Google started contributing.” But I look at those graphs and wonder.
The recent history of WebKit also gives me pause. Google did not want to contribute its multi-process architecture back to the WebKit project, so Apple created its own solution: the somewhat confusingly named WebKit2. While Google chose to put the process management into the browser application, Apple baked multi-process support into the WebKit engine itself. This means that any application that uses WebKit2 gets the benefits of multi-process isolation without having to do anything special.
This all sounds great on paper, but in (several years of) practice, Google’s Chrome has proven to be far more stable and resilient in the face of misbehaving web pages than Apple’s WebKit2-based Safari. I run both browsers all day, and a week rarely goes by where I don’t find myself facing the dreaded “Webpages are not responding” dialog in Safari that invites me to reload every single open tab to resume normal operation.
Princes of Android
Having the development talent to take control of foundational technologies is yet another aspect of corporate self reliance. Samsung’s smartphone business currently relies on a platform developed by another company. Leveraging the work of others can save time and money, but Samsung would undoubtedly be a lot more comfortable if it had more control over the foundation of one of its most profitable product lines.
The trouble is, I don’t think Samsung has the expertise to go it alone with a hypothetical Android fork. Developing a modern OS and its associated toolchain, documentation, developer support system, app store, and so on is a huge task. Only a handful of companies in history have done it successfully on a large scale—and Samsung’s not one of them. Sure, it’s possible to staff-up and build that expertise, but it’s not easy and it requires years of commitment. I’d bet against Samsung pulling it off.
Facebook Home can also be viewed through the lens of developer-based self reliance. Facebook clearly wants to make sure it’s an important part of the future of mobile computing, but that’s not easy to do when you’re “just a website.” Home lets Facebook put itself front and center on existing Android-based smartphones.
It seems unwise for Facebook to build its mobile strategy on the back of a platform controlled by its mortal enemy, Google. But perhaps Home is just the first step of a long-term plan that will eventually lead to a Facebook fork of Android. If so, the question inevitably follows: can Facebook really take ownership of its own platform without help from Google?
Facebook has proven that it can expand its skill set. Over the past few years, it’s been hiring talented designers and acquiring companies with proven design chops. Facebook Home is the first result of those efforts, and by all accounts, the user interface exhibits a level of polish more commonly associated with Apple than Facebook.
Still, a lock screen replacement is a far cry from a full OS. Maybe Facebook just plans to ride the bear, relying on Google to do the grunt work of maintaining and advancing the platform for as long as it can, while Facebook slowly takes over an increasing amount of the user experience.
Some people wonder how Google can possibly have any power in the Android ecosystem if the source code is free. Facebook Home has been cited as an example of Google’s ineffectualness. Look at how one of Google’s fiercest enemies has played it for a fool, they say. Google did all the hard work, then Facebook came in at the last minute and co-opted it all for its own purposes.
But look again at the graphs above. Now imagine similar graphs for the Android source code. Any company with Android-based products that wants to be truly free from Google’s control has to be prepared—and able—to match Google’s output. Operating systems don’t write themselves; platforms don’t maintain themselves; developers need tools and support; technology marches on. It’s not enough just to just fix bugs and support new hardware. To succeed with an Android fork, a company has to drive development in the same way that Apple did when it spawned WebKit from KHTML, just as Google is doing as it forks Blink from WebKit.
This is not a real-time strategy game. Companies like Samsung and Facebook can’t just mine for more resources and build new developer barracks. Building up expertise in a new domain takes years of concerted effort—and a little bit of luck on the hiring front doesn’t hurt, either.
Facebook may already be a few years into that process. Its recent acquisition of the mysterious, possibly-OS-related startup osmeta provides another data point. Samsung, meanwhile, has just joined an exploratory project to develop a new web rendering engine.
Google certainly has its own share of problems, but what may save it in the end is its proven ability to tackle ambitious software projects and succeed. The challenge set before Facebook, Samsung, and other pretenders to the Android throne is clear. And as a wise man once said, you come at the king, you best not miss.
