The History of WebKit

Look back six years ago, to the year 2005, and the Web is a different place. The Browser Wars are still raging, and while Netscape is putting up a valiant fight, Microsoft and Internet Explorer are looking more and more invincible. It looks like the Web will fall to the evil Empire, and there’s little that anyone can do to stop it.

And then, on June 7, 2005, Bertrand Serlet stepped onto the stage at WWDC and announced something no one really saw coming — the soul of Apple’s little upstart browser, Safari, was being open sourced. And it was called WebKit. Apple was once again trying to give Microsoft a run for their money, and they were going about it in a totally different way then anyone would’ve expected.

Think about it for a second. Apple is a notoriously secretive company. Why would they want to oversee an open source software project? To answer that question — and to properly judge how successful this open source endeavor has been — we have to take a look back at WebKit’s roots. But I’d also be remiss if I didn’t touch on what WebKit is becoming today, and where it could be heading tomorrow. Knowledge of the past is important, because it helps us understand the present — and to better prepare for the future.

Born of Open Source

See, today everyone thinks of WebKit as being from Apple. It’s the soul of Safari, right? But the code wasn’t forged in the secret catacombs of Apple HQ. The code actually started life somewhere else entirely. Back in 1998, the code that would become WebKit was part of the KDE open source project’s KHTML and KJS engines. Initially KHTML and KJS were forks of an earlier rendering engine khtmlw or “The KDE HTML Widget”. There was much work to be done though, as the W3C had standardized both the [DOM] and [CSS] since the previous engine was released, so support for these features was an important priority.

Through most of 1999, a groundswell began to envelope KHTML, spearheaded by Lars Knoll. KHTML’s supporters and developers didn’t want the project to die, inspite of the daunting amount of work required. The hard work bore rich rewards. By the Spring of 2000, there was a shiny new set of rendering engines — KHTML and KJS — ready to be implemented in a new release of KDE. They were also a ripe and juicy open source project ready to be picked up by a certain Cupertino-based company.

Given “The Apple Treatment”

In January of 2003, at the Macworld Expo Keynote Address in San Francisco, Steve Jobs announced the open sourcing of WebCore, Apple’s port of the KHTML engine. That same day, Don Melton, the lead developer of Safari sent an email to one of the lead developers of KHTML and KJS which was published to the KDE developer mailing list. It introduced the Safari team from Apple, and made it pretty clear that they were both pleased and proud to be able to use the open source code in building Safari. Praising the efficiency of the code, and the skill of the coders who brought it into existence, Melton’s correspondence was above and beyond cordial. It looked like the beginning of a beautiful marriage.

Fast forward two years though, and we find that marriage on the rocks.

The open source community is built on passion, goodwill, and self sacrifice. It’s not for everyone. To be successful in it — and stand as an asset to the community — you have to be aware of these character traits, and be in possession of them yourself. Apple is a community as well, with its own culture and priorities. The attempted cooperation between KHTML and Apple’s WebCore was running into issues, and that was understandable.

Outside of the developers actually migrating changes from Apple’s WebCore, the KDE community seemed to be ignorant to the real time and effort required to “port” changes over to the KHTML engine. In the Spring of 2005, two developers working on KHTML, Zack Rusin and Carewolf, expressed their frustrations, in blog posts, with both the way Apple was “co-operating” and the way the greater KDE community was perceiving the relationship.

Apple was having a hard time co-existing with an established open source project. They were putting forth an effort to be a good open source citizen, but it was coming up short in the eyes of the KDE community. It appeared Apple’s open source attempt was failing. KHTML and KJS were great foundations for Apple to build off of, but it was proving near impossible for Apple to “give back” to the community in a way the community could make actual use of and be appreciative for.

Open Source, Apple’s Way

When you look at the way Apple works as a company, their methods are insular. Their beautifully polished creations are the product of a repetitive process of refinement. They have a system, and it works well for them. In hindsight it’s little wonder that trying to fit into the open source world didn’t work for them.

But Apple is not a completely heartless company. They knew that the core of their current advancements in web technologies were the result of the work of the open source community. And so here we are, where I started this story, on the 7th of June in 2005, with Apple announcing the open sourcing of WebKit.

WebKit is everything the WebCore and JavaScriptCore codebases were and then some. Along with their source control trees and bug tracking tools, all the code to create a functioning web browser was open sourced. Even from a philosophical standpoint, this tack made more sense for Apple than trying to be a team player. A project organized and driven by Apple, publishing code for the world at large to take and use lets Apple enjoy all the good press associated with open-sourcing a piece of software while still maintaining the control Apple’s so infamous for.

And take and use the world did.

Up, Out, and Away

From that point in history, a subtle change began. It didn’t happen in a grand, sweeping gesture. It was gradual, but undeniable. WebKit was taking over the browser market. Not by sheer market share numbers — at least not at first.

WebKit was taking over the hearts and minds of the citizens of the web. Apple, consistently seen as an advocate and friend to the design community at large, was going up to bat for web designers everywhere. WebKit was nimble and agile, able to implement new standards and techniques as they were being conceived and invented. It was the opposite of Internet Explorer. And the Web Community loved it. It’s a tradition that hasn’t stopped. More recently we’ve seen innovations in WebKit pushing many of the new parts of the CSS3 specification, as well as spearheading implementations of the HTML5 spec.

WebKit started appearing in places other than Safari. In November of 2005 Nokia released a web browser based off WebKit for their S60) platform. With the release of the iPhone in January of 2007, WebKit hit mobile computing in an even bigger way. The growth seen in the iOS platform has been truly epic. And it makes sense that Apple would use its darling WebKit as the basis for Mobile Safari. What’s unprecedented is what the competing mobile vendors have done.

In November of 2007, 10 months after the iPhone’s debut, Google released the fruits on an acquisition: Android OS. Poised to take on Apple and the iPhone wherever they were headed, Android contained a little twist — its web browser was powered by WebKit. Here were two competitors benefiting off a common open source foundation. The true surprise though was that Apple was the major source behind that foundation. And they were playing nice.

Apparently Google liked what they saw in WebKit, because in the Fall of 2008, a beta of Google’s homegrown browser Chrome hit the interwebs. Once again, powered by WebKit. Are you starting to see the interesting tapestry being woven by WebKit?

In an interesting turn of fate, on July 7, 2009, we find Google announcing a new venture. They’ve begun work on a new operating system called [Chrome OS]. Effectively designed to take on both Microsoft and Apple it’s powered by … wait, you guessed it WebKit. This one of the most fascinating aspects of WebKit’s story. Born of open-source, yet crafted and honed by ultra-competitive Apple, WebKit now stands as the basis of Google’s future plans to compete with Apple. Isn’t open source software so intriguing?

A year later, in 2010, BlackBerry jumped on the mobile WebKit bandwagon and announced a new browser for BlackBerry OS version 6. Again, an intriguing turn of events: three of the biggest titans in the smartphone market — Apple, Google, and RIM — are all running WebKit as the backbone of a pivotal feature any smartphone should have, the web browser. And to think, Google and RIM have Apple to thank for all this. Apple. You know, that uber-secretive company from Cupertino.

It hasn’t just been headline grabbing companies that have taken advantage of the WebKit open source project. There have been a string of other small-name, and occasionally open source, browsers to be built on-top of WebKit, like Midori), Shiira, and Epiphany).

But one of the most fascinating places to find WebKit is in apps that aren’t strictly browsers. The availability of a high quality, open source browser has allowed many an indie app developer to include browser-based functionality into their apps. Reeder, one of the top-of-the-line RSS readers for OS X, uses WebKit code to provide a seamless experience when reading through feeds. Or use it in even more creative ways, like how Valve’s Steam platform uses WebKit to render its storefront UI.


Now, RIM’s adoption of WebKit is certainly interesting. And Google’s apparent reliance on it for their future growth and plans is truly fascinating. But there’s another competitor to Apple, a relationship that’s become especially heated of late, who is making prominent use of WebKit: Adobe.

Yes, even the purveyor of iOS’s sworn enemy — Flash — has embraced the rendering engine, incorporating it into the Creative Suite of apps, and even committing additions to the code base.

Now, the inter-company relationship between Apple and Adobe would take an entirely different article to discuss. I simply find it fascinating that a company with such stunningly different ideologies on what the Web should be built upon can find common ground in WebKit. What a testament to the WebKit project as a whole; the care, quality, and craftsmanship of its original developers and those writing and maintaining the code today.

The King is Dead, Long Live the King

Remember what I said Apple’s reason was for open sourcing WebKit was in the first place? To take Microsoft down, knocking them off as king of the browser market. There’s no “smoking gun” supporting that. No mailing list exchanges between Apple execs or Safari devs about their secret plot to take down IE. It’s my hunch, my educated guess, but I think it’s a sound one. More than that, I can present cold, hard numbers to prove that even if that wasn’t the original intention behind open-sourcing WebKit, it certainly was the end result.

According to data from Net Applications, Internet Explorer owned a stunning 89% of the browser market in 2005, the year WebKit was open sourced. Today that figure’s dropped to a comparatively unimpressive 54%. In contrast, Safari — the only WebKit-based browser in existence in 2005 — had measly 1.7% marketshare. Today though, WebKit-based browsers account for almost 20%.

Now, those statistics were quite obviously slanted towards desktop browsers. What about the numbers for mobile OS web browsing? What do those bear out? Well, WebKit-based browsers account for over 62% of mobile browser usage. Opera Mini takes the second place spot with 22%, Microsoft not even garnering enough usage to be given its own statistic. They’re included with the 15% of “Other” browsers.

You’d be hard pressed to find anyone interested in the tech industry today who isn’t saying that the mobile area is really the realm of the future. And WebKit already has a strong presence there, and there’s no reason to imagine that the WebKit team’s dedication to continuing innovation will change any time soon.

And In Conclusion

So there was a lot to this article, wasn’t there. If you’ve made it to the end, I’ll admit, I’m honored. I tried my best to tell as full and accurate a story as I could, but there’s still much detail that was left out.

To get the thoughts and perspective of two of the original coders of KHTML, and where they stood on WebKit a year after its open sourcing, watch their presentation at Yahoo!. To keep up to date on the future of the WebKit project, there’s no better place than the Surfin’ Safari blog.

One final word. If you, dear reader, enjoyed this article, please leave a comment. I’d love to hear if this sort of piece — a look at the history of aspects of the Web — is something you all would like to see more of. Or maybe you hated it, and thought it lasted way longer than it needed to. You can mention that too if you think you need to.