On May 12, 2005, at 10:08 AM, Jean-Marc Orliaguet wrote: > Paul Everitt wrote: > > >> >> I think the idea of bootstrapping is sound. I'd like to add in that >> bootstrapping should include some questions of "governance". A >> project that produces good code but bad cooperation is worse than a >> project producing bad code and good cooperation. Hopefully we have >> good results for both. :^) >> >> Thus, we need a phase where we assemble the people and projects that >> are interested and build up a culture of shared decision-making. >> Some of these people spent quite a bit of money (and time) to come to >> Paris. Let's respect that initial show of commitment and make sure >> they feel welcome. >> >> --Paul >> > > > > Hi Paul, > > It is naturally a question of reaching a balance between > cooperation and > code quality (not necessarily excluding one or the other). But to get > cooperation you also need to have something to show (screens, > mockups, a > proof-of-concept) to stir enthusiasm. I'm well too aware of projects > that start with good intentions and never reach a momentum because > developers believe that some great software design will magically > pop up > from having a community svn, and nothing happens. In this case, I mean less "cooperation between like-minded developers" and more at a macro level, "cooperation between projects". > In the case of Plone (which probably is what you mean with good Sorry, I wasn't clear. I meant "good cooperation between CPS, Plone, Silva, ZC, etc.". Like it or not, there are some human and business issues involved that can spoil the cooperation. In the beginning, we have to be attentive to fairness, because the primary goal is a *shared* architecture. For example, last year the Zope track at EuroPython was named the Zope/Plone track. I made that decision and it was certainly a mistake, as it generated mistrust. If possible, this Z3 ECMS project should be the shared voice of all participating projects. > cooperation?), things are different: there was something to build upon > from the beginning, i.e. the CMF, which means that most of the ground > design work had been done already. Looking backwards, you can see how > close to CMF's original design Plone has remained, not simply in terms > of code, but in terms of all the paradigms used that come from CMF, > because democratic decision-making on essential design issues (not > whether the navigation box should be to the left or to the right) is > difficult to achieve. > > To sum up: I don't believe that there is such a such as large- > community > software architecture design, and this is basically what is missing: > some good CMS design, ... and then comes the code and the svn. I agree with your sequence, I'll just add one thing at the beginning: inter-project trust. --Paul
Hosting: Nuxeo: Zope service provider