On the webkit-dev mailing list back in April, there was an interesting thread that Michael Nordman from the Google Chrome team started with a message titled, “AppCache functionality provided by the embedder of webkit” (related to the offline-Web-applications feature in HTML5). Michael begins that message with this paragraph:

I’m working on the app cache for Chrome. We’ve decided to hoist most the functionality provided by the app cache into Chrome’s main browser process, so we won’t be using most of the implementation provided by WebKit. I’d like to work through what changes to make within WebKit/WebCore to allow an embedder pull that off. Any suggestions would be much appreciated.

Darin Adler responded with some thoughts and a question (to which Michael replied) but the discussion about specifics didn’t go anywhere after that (not on the mailing list at least), because in the next message in the thread, Maciej Stachowiak replied to question the general approach — in fact, to question whether the WebKit trunk should be providing mechanisms to facilitate replacements of parts of its own core code:

It’s been a recurring theme for the Chrome team to request hooks to bypass WebKit functionality and replace it with Chrome-specific code that lives outside the WebKit tree. So far this has been mostly for code developed when Chrome was originally a secret project. While we felt it was best to grandfather in the existing carve-outs, in general I believe this is not the best way to move the WebKit project forward. I would not like to see this pattern replicated for newly developed functionality.

Earlier in the same message, Maciej cites a reason why facilitating the proposed general approach can have a potentially negative side effect:

One downside of this approach is that, if the application cache ever needs to change, it may be necessary to make changes to two separate implementations hosted in different repositories. In addition, quality-of-implementation improvements to one version won’t benefit the other.

That seems like a very legitimate concern. But in a reply (the final message in the thread), Michael brings up what seems to be another legitimate concern:

WebKit could grow a stronger sense of frontend vs backend that don’t share an address space for features that require touching browser wide state. The current model for webkit doesn’t lend itself well for that. We struggle with that a fair amount.

So, hold that thought in your mind for a minute while you step back and consider: It seems like the Chrome team may have some significant concerns/doubts about the efficacy of the specific parts of the implementation design for this particular feature that’s in the existing WebKit trunk. Otherwise, why would they invest very valuable development resources in a duplicate implementation of the same feature, rather than offering to contribute to refining the existing implementation? Or it seems like a case of wanting to be able — while building against the WebKit trunk, I assume, instead of in a separate branch/fork — to at least experiment more easily with being able to plug in an alternative implementation, and see whether or not it actually works better in practice. To me at least, that seems to be what Michael is touching on in the first part of his reply:

There may be an opportunity to replace WebKit’s impl of this feature with one that has more manageable dependencies. Perhaps chrome’s implementation could be the basis for that replacement which could then be used within WebKit proper and within Chrome’s browser process.

A first step along this path could be enabling somebody to wire in a different implementation that is lagging the current incarnation found in WebKit at the moment and not ready for the prime time just yet.

Anyway, if one of the development organizations involved in the project believes there’s a specific shortcoming in the current WebKit architecture (e.g., lack of a “stronger sense of frontend vs backend”), it does make one hope they can find a way to get the issue resolved — because the soundness of the fundamental architecture of WebKit is often cited by browser-development organizations as one of the key reasons for choosing WebKit as the basis for their applications. And if the project cares about continuing to get more organizations to adopt WebKit in the future, it is important to try to ensure that the architecture continues to be a sound as it practically can be, and continues to be as attractive to potential WebKit application developers as it can be.

So in this specific case, it seems like the project as a whole may have a conflict between, on the one hand, a position expressed by one set of stakeholders in the project that it’s potentially important to facilitate mechanisms for experimenting with “wired in” alternative implementations of existing features, and, on the other hand, a position from other another set of stakeholders that providing mechanisms which facilitate development of “carve outs” that bypass existing code is ultimately not going to good for the project as a whole.

It’s difficult to see how the project can find a way to fairly and impartially resolve the conflict in this case (assuming there actually is one that’s really in need of resolution here). Perhaps as the project continues to grow, if it starts to find itself running into more such cases, it might make sense to either choose an individual ombudsman of some kind (for lack of a better description) or a steering-committee group responsible for helping to arbitrate conflicts when they do come up.