<div class="gmail_quote">On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard <span dir="ltr"><<a href="mailto:chuck@jumis.com">chuck@jumis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">



  

<div text="#000000" bgcolor="#ffffff"><div><div></div><div class="h5">I think Brent's question to the list may have some merit if looked at
from a different perspective.</div></div>
Let me try it... Peter: Are there any lessons learned about that
process Chromium went through?<br></div></blockquote><div><br></div><div>Darin Fisher shared most of the valuable information here.</div><div><br></div><div>In Chromium's case, we were forced to fork due to secrecy constraints during our initial development -- something which none of us liked from an engineering perspective, but which I suspect tends to apply to a large number of ports.  As a result, we became focused on making changes in a minimally invasive way, to lower the cost of merging.  The consequence of this was a much higher later upstreaming cost, as "the minimally invasive way" and "the right way" are frequently not the same.</div>
<div><br></div><div>Additionally, we froze our fork before our first public release, and didn't unfreeze until almost ten months later.  This added another burden to the unforking process.</div><div><br></div><div>It took something like a year of time and a large amount of engineering effort to unfork.  However, the alternative of staying forked forever incurs a perpetual cost on the development team, in addition to being worse for WebKit as a whole (due to the upstream codebase not truly reflecting ports' needs and other ports not benefitting from each port's work).  As a result, I think any company that intends to have a long-lived product based on WebKit is making a grave mistake if they don't dedicate significant engineering time to unforking, costly as that is.</div>
<div><br></div><div>PK</div></div>