This post began as a comment on Matthew Gertner’s blog post The Browser Platform Wars. It’s a rant not an article, don’t take it personally.
In my experience (8 years building Mozilla based products and playing with WebKit since it was first released as WebCore in 2003) there are a few clear technical and social differences that can make WebKit a more attractive platform for developers than Mozilla. There are plenty of reasons that Firefox is a better product than Safari (I definitely prefer Firefox over Safari on my Mac), but that’s a different story.
The scale and complexity of the Mozilla codebase is daunting. Mozilla advocates will say that that’s because Mozilla provides more functionality, but the reality is that even if you don’t want all that functionality you still have to dig through and around it to get your work done. Much of the Mozilla platform is poorly documented, poorly understood and incomplete (the C++/JS binding security stuff was the most recent example I’ve looked at) while WebKit is smaller, simpler and newer. They use common c++ idioms instead of proprietary systems like XPCOM.
The scale of the Mozilla organization is also daunting. Mozilla’s web presence is vast and is filled with inaccurate, outdated content. Their goals are vague and mostly irrelevant to developers. By contrast WebKit’s web site is simple and straight-forward. Its audience is developers, it sets out goals that matter and make sense to developers, it explains clearly the process for participating and contributing in the project.
WebKit is designed for embedding. Within Apple there are several customers for the WebKit library – Desktop Safari, iPhone Safari, Dashboard, AppKit and more. Since WebKit already serves a variety of purposes it’s likely to work for other applications which third party developers will want to build. By comparison the Mozilla platform really only has one first-class customer – Firefox.
The WebKit community has welcomed non-employee contributors. They’ve even welcomed contributors who work for Apple’s competitors. There are WebKit reviewers from Google, Nokia and the open source community. By comparison, Songbird and Flock don’t have any Mozilla committers or reviewers who weren’t previously Mozilla Corporation employees even though they are two of the largest non-MoCo platform customers.
Perhaps I’m short-sighted, but I don’t see a clear path forward for Mozilla in competing with WebKit as a platform for web content display. The long history of Mozilla have left them with a large, complicated codebase that’s not getting smaller. The rapid growth and defensive attitude of the organization (probably brought on by the Netscape / IE wars) has left it without a culture that welcomes friendly competition. I think that Mozilla’s focus on the product above the platform is the right decision for them. I’m just glad we have an alternative web content platform.
You’re certainly right that Mozilla’s scale can make things challenging and there is also a lot of historical content that needs to be cleaned up.
This isn’t much of a segue, but I didn’t realize that Mozilla had been used with the hiptop. Do you know if they’re still using it? If so, I’d be interested in talking to someone there about using the Powered by Mozilla logo. If you’re still in touch with anyone there, I’d be interested in hearing more. Thanks.
Safari 4 Rocks!!!
There was a lot of elation from the Mozilla crowd when Apple hired Dave Hyatt in mid-2002. It could mean the end to IE for Mac. And since Mozilla had an open-source, cross-platform user interface browser engine (via XUL) and since Dave Hyatt contributed to Netscape, Camino, and was a co-creator of Firefox there was heavy anticipation on what role Mozilla tech would play in Apple’s new browser.
But Dave chose to build off of KHTML instead. That was not very well received. There was concern and puzzlement and frustration on a lot of Mozilla blogs. There were messages of reluctant welcome to another open source browser engine. Apple’s effort only had to be good enough to keep Apple from running back to Microsoft, and many would still flock to Camino and Firefox on the Mac. It wasn’t as good building off of Mozilla code, but it was still good.
That friendly competition stopped completely when Apple released Safari for Windows. In retrospect, Safari on Intel seems like just an excuse to cloak the work being laid for Apple’s Intel transition. “Intel optimizations? Oh, that’s just to improve Safari on Windows.” Since then Webkit has become a direct foe rather than a comrade.
Whatever trends Apple flirts with are only of marginal concern to Mozilla, but a knowledgable and well-respected contributor’s switch to KHTML should have triggered more than just a public relations effort. Mozilla should have taken that as a serious reason for honest introspection and refocusing of their goals (if not their code).
I have filed a few bugs in mozilla bug tracker and noticed that it is really hard go get even some trivial fixes (for “unsupported” platforms, in my case Gentoo Linux) in unless they are evangelized by their marketing guys.
I also noticed some total ignorance from at least one of their guys who seem to be just windows oriented and couldn’t even bother to figure out what the bug was about (in this case it was xulrunner should install pkg-config file)…
I think Firefox on the Mac is a user interface nightmare… plus Safari/Webkit is much, much faster.
@William, Dave Hyatt wasn’t the only ex-Netscaper on the Safari team, but he was the most visible, probably because he’d been more involved in the post-Netscape Mozilla stuff. I agree that that was the time for Mozilla to look at themselves and ask why their code hadn’t been chosen, but at the time, like now, they were focused on getting a product out. Remember, Mozilla 1.0 wasn’t out till mid 2002 and and Firefox wasn’t out till the end of 2004 while Safari development began before that – the Safari development team joined Apple in 2001.
IE 8 rocks. Everything else is teh suck! l053r5!!!!
To nitpick just a bit, they do remove code from Mozilla as well, (e.g. https://developer.mozilla.org/en/SOAP_in_Gecko-based_Browsers). We had used that in a previous project and had to go update our code. That’s why it doesn’t happen very frequently: a lot of that stuff is used somewhere.