3 ms·
No, it could even mean fewer fixes, because coopetition is a delicate balance. Every man-hour you put into the common project helps your competition as much as
by iSnow 14y ago
No, it could even mean fewer fixes, because coopetition is a delicate balance. Every man-hour you put into the common project helps your competition as much as yourself (outside competition like Mozilla and Microsoft excluded).
So if you remove some coders from the common codebase and shift them towards other parts of the browser that have more to do with your specific brand (JSC in Apple's example, V8 or cloud integration in Google's), up to a certain point you gain a net benefit - your brand develops faster and your partners invest more.
Of course, if each party acts like that, the common project gets stale - the tragedy of the commons.
From my completely unfair outsider view, it seems to me that Apple, for example, has more or less lost interest in WebKit and tries to stifle progress to defend their lackluster Safari against Chrome and MobileChrome.
- interpol_p 14y agoDo you have specific examples of how you consider Apple to be "stifling" progress to defend Safari? I use both Safari and Chrome (and WebKit nightlies). I vastly prefer Safari to Chrome, but their underlying use of WebKit seems quite similar. Competition has seemed to help WebKit in the past (especially between Apple and Google). If you recall, they both contributed a new process model to WebKit (http://betanews.com/2010/04/09/the-big-change-coming-to-safari-5-kernel-level-multi-processing/ http://betanews.com/2010/04/09/the-big-change-coming-to-safa...). It could be argued that Apple's contribution in this area was more useful to users of the WebKit framework, while Google's was restricted to Chromium. That said, Google makes many great contributions too.