Welcoming Google to the WebKit project
In my talk at LCE 2007, I touched on the issue of proprietary branches and their effect on developer morale.
On the WebKit/GTK+ team, we’ve had to deal with this issue a few times.
- A year ago, Adobe promised great new graphics features from their AIR fork of WebKit that never materialised. We chose to redouble efforts to improve the open Cairo graphics backend instead of sitting about waiting for their contributions, a decision that has paid off.
- More recently, a company has been working on a largely proprietary fork of the browser called OWB. It is remarkable that, looking at some of their recent code drops (which cannot be easily merged back to trunk due to refactoring), they still have bugs and performance issues that we fixed in WebKit trunk several months ago. It’s sometimes unpleasant to implement features that others are working on behind closed doors, but we do it in an open forum with peer review. What’s more, we do it better.
Fast forward, November 2007
Today, Google announced that it’s developing a WebKit-based browser as part of its Linux-based Android mobile platform.
In the hours since this news came about, contributors have already started to ask whether their work is about to be obsoleted or replaced by a Google code drop. It’s inevitable that there’ll be some overlap, but there’s no cause for concern from where we stand.
I’d like to make it clear that we’ve already discussed this scenario, and it’s life as usual for the GTK+ port. If there are contributions to components of the GTK+ port, they will be reviewed through the same processes as any other contribution. Same goes for other platforms.
Furthermore, it’s good that WebKit/GTK+ already has portable graphics capabilities to any forked browser since we’ve been tracking the very latest features including recent SVG updates, CSS transformation and CSS animation support. Another WIP feature of particular interest to mobile devices is the upcoming full page scaling support. Our work will be useful as a generic component for all new platforms.
With current efforts to bridge Web applications and the underlying platform and research into features like bridging JavaScriptCore and other engines, it’s likely that we are also ahead of the game in the Web-as-a-platform department.
All that said, I look forward to working together with the developers of the Android platform towards a more open and flexible mobile Web!
Will this turn into a separately branded fork of WebKit? Only time will tell.
Hi,
It’s sad that you post assertions about someone or a company without make the simple and correct effort to double check that your understanding is reflecting the truth. Let me reassess some of mistakes from your post:
I don’t really see what part of OWB is proprietary or outside webkit.
* OWB is BSD-licensed and fully available refactoring of the painful platform directory under a regular abstraction layer
* OWB drops regular merges from webkit trunk on our repository since the way back seems soooo difficultt (see below)
* about performance and bugs, we are more than happy that people file bugs in our trac system. But is this just a fact or a way to value your own solution?
* some people from Pleyo worked full time this summer to fix bugs within webkit trunk and not even of OWB own repository
* our “bal” approach has been rejected by the community, but we have proposed it. the fact that it’s not on apple’s repository is not our fault.
There are proprietary forks of Webkit, clearly, but filing OWB as such is either an error, or disloyal.
Regards
Jean-Charles Verdié
Pleyo CTO
Please don’t start holding your breath now. One of the “features” of the Android project is that you do NOT have to contribute back! (Wow! That sounds like guaranteed failure to me. One million forks and noone contributes back anything.)
So, why should anyone expect google, as part of this great project where noone has to contribute anything, to contribute to webkit?
It’s all in the FAQ…. see the summary at http://www.advogato.org/person/company/diary.html?start=86 if you don’t want to dig through the entire FAQ.
Jean-Charles:
> * OWB is BSD-licensed and fully available refactoring of the painful platform directory under a regular abstraction layer
Your port was not available for months. Now there is a code drop, but none of the changes are documented and revision history has been erased.
Will development continue openly on that branch now?
What is ClosedBAL?
> * OWB drops regular merges from webkit trunk on our repository since the way back seems soooo difficultt (see below)
That’s great, but the reverse would be far more interesting.
> * about performance and bugs, we are more than happy that people file bugs in our trac system. But is this just a fact or a way to value your own solution?
There was buggy graphics code in your Implementations directory. If I had time to spend fixing bugs that have already been fixed all over again, I would file them in your bug tracker.
> * some people from Pleyo worked full time this summer to fix bugs within webkit trunk and not even of OWB own repository
This is the default for other companies contributing to WebKit. This isn’t something to boast about, it’s what everyone else is doing already and they’re not making a fuss about it.
Personally, I was disappointed when you tried to pass off a months-old WebKit framebuffer/SDL port (inappropriate for a device using X11) as a browser solution for the N800 when open source companies had already tweaked WebKit SVN trunk directly for that platform. Was this anything more than a PR stunt?
I do not want to sound completely negative though. Most of the time, people don’t mind what you’re up to, and in fact some of the research you’ve done into new ways of abstracting the platform is quite interesting.
Alp
Feel free not to accept this post as it turns more to a personal discussion than a blog comment…. Up to you
>Your port was not available for months. Now there is a code drop, but none of
>the changes are documented and revision history has been erased.
We have never hidden what we were doing (first posts are back in 2006), but we did not feel like it was of any use to open an not-functionning, not even stable designed code. Many companies make their development internally before giving the whole code. The internal revisions, as a matter of fact, were of poor interest since what we see (and we’d love) is just to be an ongoing patch to regular webkit…
> Will development continue openly on that branch now?
Refer to trac tickets and roadmap
> What is ClosedBAL?
No sure there is any point in talking about it there, but hey, it’s your zone after all 😉
This is designed for our customers who want specific extensions or links with their own closed-sources assets. We are a company, we open our code while it does not give us the right to open other’s 😉
BAL, nonwithstanding others architectural interests, also aims to provide a way for these customers to keep their code under their own licenses choices.
>> * OWB drops regular merges from webkit trunk on our repository since the way back seems soooo difficultt (see below)
>That’s great, but the reverse would be far more interesting.
I just agree, trace history in webkit-dev and you’ll why, so far, we’ve not been able to propose the “reverse”. We have done a huge refactoring, that’s true, but it proved to be what we needed to do with Webkit, for our company’s interest, which is not something I believe we can be blamed for. We have different needs than the “platform” approach, that’s all.
> > * some people from Pleyo worked full time this summer to fix bugs within webkit trunk and not even of OWB own repository
> This is the default for other companies contributing to WebKit. This isn’t
> something to boast about, it’s what everyone else is doing already and
> they’re not making a fuss about it.
Please dont rewrite history: I’ve not come making any fuss, I’ve just answered to incorrect assertions, and pointing that little thing was just an item to help you in admitting that naming us as a “closed fork” was not the truth.
> Personally, I was disappointed when you tried to pass off a months-old
> WebKit framebuffer/SDL port (inappropriate for a device using X11) as a
> browser solution for the N800 when open source companies had already
> tweaked WebKit SVN trunk directly for that platform. Was this anything more
> than a PR stunt?
The sample port you are talking about was not aimed at all to be something that should be useful (or even usable) on N800, but just yet another proof that our approach made it way more simple to port to any kind of device/systems. And your disapointment is a consequence of your misknowlodge of BAL approach: it’s exactly designed not to make specific ports, because my company’s interest is in avoiding porting Webkit to X thousands systems, but simplifying it by just having to glue the BAL with the system.
Of course, having a useful version of origyn on N800 would take much more adapted port (of Webkit, or of BAL) but we’ve never pretended that our demo was aimed to reach this goal.
> I do not want to sound completely negative though. Most of the time, people
> don’t mind what you’re up to, and in fact some of the research you’ve done
> into new ways of abstracting the platform is quite interesting.
Well, hopefully some time we can be also added on the webkit repository as a “different vision”, which might may be interest some other “ports”.
As you will see with the next (huge) commit to come, we also propose a quite exciting way to easily extend JS to brind middleware capabilities to the browser and help putting together our vision of Web-Based UI & Platform. I hope it can be considered by the community just as I hoped so for the BAL approach…
Again, I was not answering to make any troll war or to advertise sand-labs, but I think that your judgment on us is unfair and that was my only motivation in answering your post.
Jean-Charles
Jean-Charles:
You’re whitelisted on the blog. Any comments you write will appear immediately 🙂
Your words sound very reasonable but I’m afraid they don’t match up with reality. The sand-labs port has been inaccessible (passworded SVN and Trac) for a long period, making it a proprietary fork. If that’s changing now, brilliant, but I was discussing the history of the project rather than future possibilities.
Seriously, I think there is no long-term problem here and if you’re opening up I’m sure we’ll be able to collaborate more closely, merging patches back and forth etc.
The only reason my post was not more strongly worded is that I have the utmost respect for you and your developers. I hope you realise that statements on your site like “N800 gets WebKit browser option” and “WebKit Safari based browser coming to Nokia N800” are actually offensive to the people who did a real Hildon/GTK+ port.
Jean-Charles:
> * our “bal” approach has been rejected by the community, but we have proposed it. the fact that it’s not on apple’s repository is not our fault.
I don’t recall it being proposed for inclusion. You mentioned it before actually releasing the code of your port, but did not explain it in detail or ever submit a patch or any kind of design document. So I don’t think you can say you have proposed it or that the community has rejected it. If you’d like to propose an alternate model for platform portability along the lines of BAL we are happy to review it.
As far as I can tell the BAL directory in the Pleyo port is basically a cut&paste of the platform directory with everything renamed. However, I’d be glad to hear an explanation of why this approach is better.