Re: [webkit-dev] Open Design beyond Open Source
Hi George and Maciej, let me just add in some comments from my side :) On Saturday 17 February 2007 08:23, Maciej Stachowiak wrote: > Hey George, > > Thanks for sharing your concerns. > > On Feb 16, 2007, at 10:29 PM, George Staikos wrote: > > On 16-Feb-07, at 9:22 PM, Mike Emmel wrote: > >> Here is the link of what you have to go through to commit now. > >> > >> http://webkit.org/coding/contributing.html > >> > >> People wanting to do a new port are not going to go through this long > >> trial program just to commit in fact that have not. The KDE team has > >> pre-existing interest and both OSX and S60 are commercial. The two > >> true open source ports gdk/windows plus the wx widget port have > >> basically been failures so far. > > > >If you mean to say that the impression given off by the webkit > > project is one of "we don't want you" or at least "we're not really > > interested in having more people join our project", I have to > > agree. I still don't get the feeling of a welcoming project. Is > > it a form of extreme paranoia that some new developer might > > introduce a bug? Maybe I'm not sure I consider that a valid > > reason though. > > We really do want the WebKit project to be open to new contributors. > We spend a lot of effort working on this. If we didn't care about > having new developers join, we wouldn't have the whole public > repository and web site at all. Fortunately this has happened. We've had a split situation (between apple and KDE) for years, and with the WebKit project, we can finally start to pull into the same direction. Not everything is perfect currently (as some of the mails show), but in general I see things moving into the right direction. > It is true that the WebKit project has somewhat higher barriers to > entry than other large open source projects, like KDE. But I believe > the barriers are lower than some others, like Mozilla. Well, an HTML rendering engine has basically by definition a higher level of entrance as a project as KDE. This is purely due to the fact that the problems are more complex. With a huge desktop as KDE, people can always find corners that suit them and are easy enough to deal with. To be able to contribute in a good way to WebKit (at least code wise) requires some more knowledge to start out with. Also in KDE the number of contributors to khtml was always rather small, and Dirk, Harri, Antti and myself kept a rather close eye on the core parts (DOM, CSS, JS and rendering). Also there every commit was reviewed. This often happened after the fact, which gave us problems and long discussions from time to time. So a pre submit review is IMO a good thing. > Here are the barriers I think we have: > > 1) We require code review for all changes. > > 2) We do not grant commit access automatically; we expect people to > have a track record of being good contributors. Note that this is > more about showing that you can work with others and are not a source > of conflict or negativity. It is not about coding skills. > > 3) We do not give review privileges automatically. This is more about > understanding project policies and having good judgment > > 4) We require all code changes that affect processing of web content > to come with a regression test case (if it is possible to make one). > > I think getting a patch reviewed is easier than in Mozilla, where you > need a review and a "superreview" and adherence to all review > happening in bugzilla is much more strict (we often bypass that and > do review via email or IRC for established developers). But perhaps > it is harder than for KDE, where things are often committed without > review. I agree to both here. Having worked a bit with mozilla as well, I have to say that WebKit is definively doing a lot better. > I think it is also easier to get commit privileges than in Mozilla. I > checked some stats, and everyone who has contributed more than 5 > patches so far this year already has commit rights. That says to me > that the people actively contributing have the access they need. Now, > it may be that some people were discouraged from even contributing in > the first place. But that shows a lack of commitment to me. > > >> So from and opens source perspective webkit is not a smashing success > >> in drawing in the open source community only the KDE team has really > >> contributed and they were the original developers. The S60 port also > >> has a history of working with KHTML before webkit was made > >> a open project. > > > > I wouldn't say so. I think the KDE contribution is effectively > > nil. The Qt port is distinct from KDE plans. KDE as a community > > has yet to find a way to work together with WebKit for reasons that > > I think you're also experiencing and perhaps not clearly > > articulating. Yes I'm writing this from @kde.org and have > > contributed a huge amount to KDE, KHTML, etc over the past 8-9 > > years. Until I have the KDE community feelin
Re: [webkit-dev] Open Design beyond Open Source
On Feb 16, 2007, at 10:57 PM, David Hyatt wrote: (2) I think we should allow for ports to operate in a similar fashion on tip of tree if they need to. Basically within platform- specific code (like say the Qt port), we should be much more open about granting commit access to interested contributors and let the people working on that port decide if they want to make review required or not. This would allow people to - for example - fix build bustage without having to consult anyone or seek review (assuming the fixes don't impact core engine code or other platforms in any way). For what it's worth - it's already project policy that you can fix "obvious" build bustage without review in an emergency. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
Hey George, Thanks for sharing your concerns. On Feb 16, 2007, at 10:29 PM, George Staikos wrote: On 16-Feb-07, at 9:22 PM, Mike Emmel wrote: Here is the link of what you have to go through to commit now. http://webkit.org/coding/contributing.html People wanting to do a new port are not going to go through this long trial program just to commit in fact that have not. The KDE team has pre-existing interest and both OSX and S60 are commercial. The two true open source ports gdk/windows plus the wx widget port have basically been failures so far. If you mean to say that the impression given off by the webkit project is one of "we don't want you" or at least "we're not really interested in having more people join our project", I have to agree. I still don't get the feeling of a welcoming project. Is it a form of extreme paranoia that some new developer might introduce a bug? Maybe I'm not sure I consider that a valid reason though. We really do want the WebKit project to be open to new contributors. We spend a lot of effort working on this. If we didn't care about having new developers join, we wouldn't have the whole public repository and web site at all. It is true that the WebKit project has somewhat higher barriers to entry than other large open source projects, like KDE. But I believe the barriers are lower than some others, like Mozilla. Here are the barriers I think we have: 1) We require code review for all changes. 2) We do not grant commit access automatically; we expect people to have a track record of being good contributors. Note that this is more about showing that you can work with others and are not a source of conflict or negativity. It is not about coding skills. 3) We do not give review privileges automatically. This is more about understanding project policies and having good judgment 4) We require all code changes that affect processing of web content to come with a regression test case (if it is possible to make one). I think getting a patch reviewed is easier than in Mozilla, where you need a review and a "superreview" and adherence to all review happening in bugzilla is much more strict (we often bypass that and do review via email or IRC for established developers). But perhaps it is harder than for KDE, where things are often committed without review. I think it is also easier to get commit privileges than in Mozilla. I checked some stats, and everyone who has contributed more than 5 patches so far this year already has commit rights. That says to me that the people actively contributing have the access they need. Now, it may be that some people were discouraged from even contributing in the first place. But that shows a lack of commitment to me. So from and opens source perspective webkit is not a smashing success in drawing in the open source community only the KDE team has really contributed and they were the original developers. The S60 port also has a history of working with KHTML before webkit was made a open project. I wouldn't say so. I think the KDE contribution is effectively nil. The Qt port is distinct from KDE plans. KDE as a community has yet to find a way to work together with WebKit for reasons that I think you're also experiencing and perhaps not clearly articulating. Yes I'm writing this from @kde.org and have contributed a huge amount to KDE, KHTML, etc over the past 8-9 years. Until I have the KDE community feeling welcome and confident in participating, and until we have functioning code and development happening for a useful kpart, I don't see our Qt port as anything relevant to KDE. I'm trying to make it relevant, and I want it to be relevant, but it really isn't. I've had a webkit SVN account for almost 2 years now. I first tried to merge WebKit code back to KDE after all the KDE developers effectively gave up, and after successfully merging JavaScriptCore (with Maksim's help), determined that it just wasn't feasible to go any further without a complete replacement. I then started the current Qt port and managed to enlist several KDE developers to help me. At least one has given up again already, unsurprisingly. We made some great progress but it's an absolutely ridiculous development model as far as getting real work done. So far we had: 1) Work outside webkit SVN to start the port -> webkit renames and refactors hit us hard 2) Port again, also outside of WebKit SVN (note: we were doing a very large number of commits/week. far more than now) 3) Spend far too much time merging from WebKit SVN, especially when things like renames and refactors happen 4) Eventually give up and merge back to webkit SVN 5) End up in a ridiculous situation of having one member of the porting team as the only person with rights to review the work. Interesting, since that person has no-one who can review his work unde
Re: [webkit-dev] Open Design beyond Open Source
I think this is a constructive email, George. Thanks for writing it. Specific responses below. On Feb 16, 2007, at 10:29 PM, George Staikos wrote: We made some great progress but it's an absolutely ridiculous development model as far as getting real work done. So far we had: 1) Work outside webkit SVN to start the port -> webkit renames and refactors hit us hard There's not much to say here except that the porting layer was obviously still under construction. Trying to build a house on top of a foundation that is shifting is going to be hard. If the porting efforts had begun now instead of months ago when the porting layer was still in a high state of flux, there would not have been very much pain. 2) Port again, also outside of WebKit SVN (note: we were doing a very large number of commits/week. far more than now) 3) Spend far too much time merging from WebKit SVN, especially when things like renames and refactors happen These are problems that are solved by working in the WebKit SVN if the later problems you mention are addressed. 4) Eventually give up and merge back to webkit SVN 5) End up in a ridiculous situation of having one member of the porting team as the only person with rights to review the work. Interesting, since that person has no-one who can review his work under the formal rules. The guy who started the port, and the guy who invented KHTML altogether are not given review rights. 6) Work slows down drastically as developers are discouraged and are stuck in procedure that has relatively little value for the given situation. I agree that for work within a specific porting layer that it's clear that the rules should be different, especially in the earlier stages of development. I think there are several ways to address this issue: (1) Branches - This is the way Nokia has been working. I don't recommend it for any newly-starting ports, but it worked for Nokia because they had done an initial implementation already. However the rules are different for the Nokia branch. People have commit/review access for that section and can basically use it as they see fit. (If Nokia wants to make review optional, it's their branch, so that's fine). (2) I think we should allow for ports to operate in a similar fashion on tip of tree if they need to. Basically within platform-specific code (like say the Qt port), we should be much more open about granting commit access to interested contributors and let the people working on that port decide if they want to make review required or not. This would allow people to - for example - fix build bustage without having to consult anyone or seek review (assuming the fixes don't impact core engine code or other platforms in any way). For core engine code, being very locked down and paranoid is a good thing, but I see no reason to apply that paranoia to porting layers. dave ([EMAIL PROTECTED]) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
On 16-Feb-07, at 9:22 PM, Mike Emmel wrote: Actually their are five ports. QT OSX Gdk Windows and S60 you forgot the windows port. Of the five the windows port and gdk port are not progressing that well and don't have a lot of developer support. The QT S60 and OSX ports have a lot of developers with commit access and these port are proceeding so its 3 live ports and 2 half dead ones. Here is the link of what you have to go through to commit now. http://webkit.org/coding/contributing.html People wanting to do a new port are not going to go through this long trial program just to commit in fact that have not. The KDE team has pre-existing interest and both OSX and S60 are commercial. The two true open source ports gdk/windows plus the wx widget port have basically been failures so far. If you mean to say that the impression given off by the webkit project is one of "we don't want you" or at least "we're not really interested in having more people join our project", I have to agree. I still don't get the feeling of a welcoming project. Is it a form of extreme paranoia that some new developer might introduce a bug? Maybe I'm not sure I consider that a valid reason though. So from and opens source perspective webkit is not a smashing success in drawing in the open source community only the KDE team has really contributed and they were the original developers. The S60 port also has a history of working with KHTML before webkit was made a open project. I wouldn't say so. I think the KDE contribution is effectively nil. The Qt port is distinct from KDE plans. KDE as a community has yet to find a way to work together with WebKit for reasons that I think you're also experiencing and perhaps not clearly articulating. Yes I'm writing this from @kde.org and have contributed a huge amount to KDE, KHTML, etc over the past 8-9 years. Until I have the KDE community feeling welcome and confident in participating, and until we have functioning code and development happening for a useful kpart, I don't see our Qt port as anything relevant to KDE. I'm trying to make it relevant, and I want it to be relevant, but it really isn't. I've had a webkit SVN account for almost 2 years now. I first tried to merge WebKit code back to KDE after all the KDE developers effectively gave up, and after successfully merging JavaScriptCore (with Maksim's help), determined that it just wasn't feasible to go any further without a complete replacement. I then started the current Qt port and managed to enlist several KDE developers to help me. At least one has given up again already, unsurprisingly. We made some great progress but it's an absolutely ridiculous development model as far as getting real work done. So far we had: 1) Work outside webkit SVN to start the port -> webkit renames and refactors hit us hard 2) Port again, also outside of WebKit SVN (note: we were doing a very large number of commits/week. far more than now) 3) Spend far too much time merging from WebKit SVN, especially when things like renames and refactors happen 4) Eventually give up and merge back to webkit SVN 5) End up in a ridiculous situation of having one member of the porting team as the only person with rights to review the work. Interesting, since that person has no-one who can review his work under the formal rules. The guy who started the port, and the guy who invented KHTML altogether are not given review rights. 6) Work slows down drastically as developers are discouraged and are stuck in procedure that has relatively little value for the given situation. Not a good model. Maybe it works in an office with a couple of infrequent contributors, but it doesn't work so well for a distributed network of people trying to contribute significant amounts of code. I fully agree that some sections of webkit need strict review control, testcases, bug reports, and other formal procedures. I strongly support it in fact. The current situation is not limited to just this. Moreover, it feels very much like a Brusselized project, in stark contrast to where it came from originally. This feeling applies to "ports" as much as anything else right now. In my book this makes WebKit a failed open source project so far. I wouldn't go that far. I would call it a successful open source project with a rather closed community at the moment. Open source doesn't need community, but it sure helps. I really don't think there are any technical problems, just social ones. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
So far I've heard: (1) Switch the entire repository over to a new version control system, with no real reasons cited other than what appears to be a religious preference for your own particular favorite version control system. (2) Throw out all the built-in graphics/networking code from the OS and write new common code, despite the fact that apps on KDE and OS X use the engine in an embedded context to display UI that has to interact seamlessly. (3) Weird complaints about lack of port documentation when there is an open Wiki available for use. (4) That the open source project is a "failure" because it doesn't do exactly what you want. At this point I think you're just insane, so I'm done with this thread. You obviously have no idea what you're talking about. dave ([EMAIL PROTECTED]) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
On 2/17/07, Adam Roben <[EMAIL PROTECTED]> wrote: On Feb 16, 2007, at 3:41 PM, Mike Emmel wrote: > 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. This seems like a perfect job for our wiki at http:// trac.webkit.org/. In fact, our wiki already contains information about how to build the Windows and GDK ports, and is just waiting for more information to be added about these and other ports. > 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. This is not so much a failure of Subversion as it is a failure of communication. To the best of my knowledge, very little if any information about these other ports has been communicated to the WebKit community other than a few recent emails to this mailing list. Those ports that have made themselves known to the community (S60, Qt, GDK) seem to be having no trouble living within the webkit.org Subversion repository, either as a branch (in S60's case), or as part of the trunk (as Qt and GDK are). The S60 port is slowly moving towards being included in the trunk, and this seems to be the model that gives the most benefit to everyone. What makes this process difficult is when ports are developed outside of the community process and then try to integrate themselves back in later. There's lots of room in the WebKit community for ports, and we encourage anyone working on or considering starting a port to join us in #webkit and on this mailing list so that we may figure out how we can best work together. -Adam Subversion does not meet my needs I'm not asking for access to the subversion repository either on the head or as a branch. Git is working great for my needs I'm really happy with it and if subversion is working for you git should to. Also I'm not the only one from what I can tell subversion worked for 3 ports and failed to meet the needs of at least 4 and probably more. Actually their are five ports. QT OSX Gdk Windows and S60 you forgot the windows port. Of the five the windows port and gdk port are not progressing that well and don't have a lot of developer support. The QT S60 and OSX ports have a lot of developers with commit access and these port are proceeding so its 3 live ports and 2 half dead ones. Here is the link of what you have to go through to commit now. http://webkit.org/coding/contributing.html People wanting to do a new port are not going to go through this long trial program just to commit in fact that have not. The KDE team has pre-existing interest and both OSX and S60 are commercial. The two true open source ports gdk/windows plus the wx widget port have basically been failures so far. So from and opens source perspective webkit is not a smashing success in drawing in the open source community only the KDE team has really contributed and they were the original developers. The S60 port also has a history of working with KHTML before webkit was made a open project. In my book this makes WebKit a failed open source project so far. I suspect if you moved the gdk ports and windows ports to git repositories and allowed and easy way for developers to register these ports would become active. Your going to have to pretty much allow open commit access to get enough developers to get these ports going. Git does not work that great on windows and I don't know how to federate svn repositories. But if you want these ports to succeed your going to have to do an open enrollment to get a community going. In any case the lack of a vibrant community to supporting either the windows port or gtk should be of concern. Finally I was asking either to do a simple wiki description of adopt support for git. I'm happy enough to do a wiki page and I'll continue to submit patches via bug reports. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
On Feb 16, 2007, at 3:41 PM, Mike Emmel wrote: 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. This seems like a perfect job for our wiki at http:// trac.webkit.org/. In fact, our wiki already contains information about how to build the Windows and GDK ports, and is just waiting for more information to be added about these and other ports. 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. This is not so much a failure of Subversion as it is a failure of communication. To the best of my knowledge, very little if any information about these other ports has been communicated to the WebKit community other than a few recent emails to this mailing list. Those ports that have made themselves known to the community (S60, Qt, GDK) seem to be having no trouble living within the webkit.org Subversion repository, either as a branch (in S60's case), or as part of the trunk (as Qt and GDK are). The S60 port is slowly moving towards being included in the trunk, and this seems to be the model that gives the most benefit to everyone. What makes this process difficult is when ports are developed outside of the community process and then try to integrate themselves back in later. There's lots of room in the WebKit community for ports, and we encourage anyone working on or considering starting a port to join us in #webkit and on this mailing list so that we may figure out how we can best work together. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Open Design beyond Open Source
On 2/16/07, David Hyatt <[EMAIL PROTECTED]> 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 a
Re: [webkit-dev] Open Design beyond Open Source
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? dave ([EMAIL PROTECTED]) 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Open Design beyond Open Source
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
