[webkit-dev] Re: Ports and Forks

[Maciej Stachowiak]

On Feb 16, 2007, at 1:43 PM, David Hyatt wrote:

> On Feb 16, 2007, at 8:28 AM, Alp Toker wrote:
>
>> Far from causing divergent forks and fragmentation, Mike is  
>> proposing a way to avoid each of the concerns you listed. I really  
>> don't care what version control system gets used, but I do care  
>> when a reasonable suggestions gets shot down so lightly.
>>
>
> Nobody "shot anything down."  As Maciej said in his message, if you  
> want to make a public fork, there's nothing preventing you from  
> doing so.

Here is what I actually do think. I believe other project leaders  
like Hyatt and Darin share many of these sentiments, but I speak  
mostly for myself:

1) We are strongly in favor of a unified development effort. Many  
organizations and individuals are interested in WebKit and we would  
like to encourage them towards development on the trunk in the main  
repository. We are willing to make changes and to work directly with  
other organizations to make this possible.

2) We are not really interested in promoting or encouraging separate  
repositories. Anyone who wants to make one is free to do so, and we  
will not trouble or criticize you. But we will not encourage it as  
the way to go.

3) We would like to share plans and design collaboratively. This is a  
challenge as development continues to becomes more distributed and  
less Apple-centric. So far we haven't done a great job of putting  
design documents or plans about development direction on the wiki.  
Right now, with our stabilization focus, it's hard to find the time,  
but I think you will find more of these over time. Darin and I have  
already discussed writing intros to some of the basic classes like  
RefPtr, Vector and HashMap. We also have some overviews of the code  
structure from various presentations that we could share.

4) We are not afraid of large structural changes. If you look at the  
development history of WebKit you will see we have made many large- 
scale changes. Even compared to the Safari 2.0 version of WebKit, the  
current code has been majorly changed. We are not afraid of newer  
contributors coming in and making big changes as well, if they are  
justified and the design is discussed.

5) We think unity on the core engine code (the actual web  
technologies like HTML, CSS, JavaScript, DOM, XML, XHTML, SVG, XPath,  
and so forth) is more important than unity on support libraries like  
networking and image decoding. For facilities that are already  
present on many operating systems, we lean towards reusing the system  
facilities rather than building our own full infrastructure from  
scratch like Gecko does. That's an important part of what makes the  
code suitable for limited-resource devices. That being said, we may  
find that more code needs to live in the engine over time, and we are  
not especially religious about the way things are partitioned now.

6) We will tend to give more weight to the opinions of those who have  
already been significant contributors to the project. If the first  
thing you bring to the project is a plan to change the project's  
philosophy and organization, we will not be as open to it as we would  
be if you started out bringing a bunch of code and testing. The  
WebKit project is a meritocracy, not a free-for-all.

Regards,
Maciej