[webkit-dev] Open Design beyond Open Source

[Mike Emmel]

On 2/16/07, David Hyatt <hyatt at apple.com> wrote:
> I don't really understand this email at all.
>
> As Maciej already said, if you want to have a public fork of WebKit,
> there's nothing stopping you.  If you want to have a public branch of
> WebKit in our repository, there's nothing stopping you (Nokia has
> such a branch, and we grant commit privileges to people for the
> branch only so they can work there unrestricted).  The project
> already supports forks and branches, so what are you asking for here?
>

One issue is simply technical which is access to the repository on a
continued basis.
Git makes a much better source control system than svn in this regard.
So at the source control level a SVN branch does not meet my needs.
I'm quite happy with git and will stay on it. Feel free to google on
discussions of the two
SCM's I'm using git for several reasons.

Next I'm comfortable for the most part submitting patches on bugs. The
problem I ran into was my work was diverging significantly from the
main webkit tree and now only portions of the tree are shared.

No problem I'm fine with that but I can still provide small patches
for the shared code but any reunification of my current work would be
difficult and require a lot of discussion
if its accepted at all. For my needs the changes were both invasive
and required mainly because I'm using webkit as the foundation for a
XML programing platform not a web browser.

Sorry to describe what I did in detail but the point is its a major
fork with its own goals.
My credo of open design says that if you do a major fork you work hard
to isolate shared code and differences so that the projects do not
diverge.

Now back to the main webkit svn. This means that for webkit to support
a family of forks based on common XML/HTML libraries the current SVN
structure is not good enough instead what needs to happen is for the
browsers to become forks of a common code base.

I don't expect you to make these changes but if we can do a federation
of git servers the variants can be seen and discussed and a consensus
is possible in time on exactly what this core code is. Given the
chance and given the time I think a lot of ideas that would be
rejected out of hand right now would be acceptable later.

And finally my concept of open design mean that once you choose a
common code base everyone commits to developing the common code this
means one graphics stack and one networking library not wrappers for
curl io channels or other libraries like font rendering. It means
everyone commits to making a common implementation that works on on
platforms the same way. At the moment webkit has three different
network implementations with two that are incomplete and the third
tightly tied to Apple internal api's.

I think this is a even harder sell.

But the point is to allow differences where they make sense but to
rigorously remove arbitrary choices when they don't offer any real
value instead they cause platform variation. To be honest I cannot see
how apple could easily accept this thesis.
This would mean supporting open font network and graphics libraries for apple.
But if you really want a true standard browser with consistent
rendering across and networking support across platforms this is a
must. And additional benefit of choosing only one graphics library and
one networking stack etc is that a lot of the complexity in the
current code base and the work in platform disappears. You get a
smaller faster more consistent browser.


A git federation allows these concepts to be publicly viewed reviewed
discussed and accepted or rejected. In a sense it allows the
scientific review process to be applied to code.


So what I'm asking for are three things a chance to propose ideas and
changes to the core code base which make it both more standard and
cross platform this includes determining what the heck this core code
actually is.

A chance to code up other ideas I have that are non-standard and may
not ever make it into the "main" tree but publish those alongside the
main tree with the reasons for the differences.

A way to encourage others to follow their own ideas about xml
applications lets see what happens and along with this a simple way to
start a port thats easy for people to join.

In short agree to share the full implementation of code that should be
common and also support differences where they are done for real
logical reasons reasons not simply to support competitive
implementations of the same basic logic.



What would apple need to do ?

1.) Simply make a better web page so people can write a small
paragraph about their work and provide a link to a website or
repository.

2.) Consider a mini version of sourceforge to host git and possibly
svn repositories for related projects. I don't know how easy it is to
go across svn repositories but git->git and
git-> svn is easy. This is really a tools issue.

3.) Do nothing.

The problem with number 3 is right now a number of WebKit ports exist
that are not part of the main tree so the SVN branch solution has
already in a sense failed. I'm aware of at least 4 WebKit ports not
part of WebKit SVN.  I don't think doing nothing is working. Instead
the fragmentation you don't want to happen has already happened.
I have no idea how many others a out there I'm sure their are more.

In any case my proposal encompass how to support new idea's designs
and code supporting those ideas so open debate is possible.

A SVN branch does not solve this problem.






> dave
> (hyatt at apple.com)
>
> On Feb 16, 2007, at 7:00 AM, Mike Emmel wrote:
>
> > I think its time to step back from the details of a project and
> > explain a bit of a new concept I'm working on. Its  a very short
> > description but I hope it helps.
> >
> > The concept is called open design.
> >
> > The thesis is open source is not good enough.
> >
> > The reason that open source fails is that the create any significant
> > new project using traditional programing methods requires the creation
> > of a huge framework of code to support the project.
> >
> > X11,WebKit,KDE,Gnome etc etc etc.
> >
> > These large projects become stratified and locked into design
> > decisions often made early in the project and competitive open source
> > projects face a huge uphill battle of creating a new framework to
> > compete with the old one. New ideas tend to be rejected out of hand
> > and no one wants to make major changes to the framework because it
> > would break legacy support.
> >
> >
> > Open Design goes beyond this model and recognizes that with a complex
> > project and certain points in the design multiple solutions are
> > possible thus forks are not only possible but a good thing.
> >
> > In a project developed using Open Design not just open source you
> > identify these places where forks can be supported and you code
> > support for them. Generally this means the creation of well defined
> > internal api's and careful control of interdependencies in the project
> > so mutiple api's can be supported.
> >
> > Open Design strives to ensure that as many projects as possible use
> > the same core source code and it works hard to identify exactly what
> > this core is.
> >
> > In reality what I'm proposing for WebKit is that it adopt Open Design
> > principals welcome forks and branches.
> >
> > This will allow WebKit to mature into a Open Design project with a
> > well defined and tested set of core libraries supporting a wide range
> > of products and frameworks.
> >
> > What WebKit should not do is fall in the trap of creating yet another
> > monolithic framework.
> >
> > Sure you can create yet another monolithic framework that might be
> > slightly better than our current ones but in reality your  missing a
> > opportunity to think outside the box and be different.
> >
> > Git and git-svn are just a good way to support forks Linus has chosen
> > open design for the Linux Kernel he just has not told people he has
> > gone beyond the open source model.
> > I've just put a name to the process.
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>