Hi there, I just started reading this mailing list (came back from a trip just now) and of course I was in on many of the discussions previously. I see various parties have some concerns and worries and ideas and I think a little bit of communication can make everybody happy. So, let me sketch out the shape the ECM project could take. These are my ideas, but I believe all parties involved right would agree with them (If not, then we should discuss it). Action counts more than words ----------------------------- We need to start the ECM project now, bootstrap it now. We need to commit developer resources to it, and we need action, and people to take charge. We want to do the simplest thing we can possibly do to get the infrastructure in place so we can make progress. I think this is the right approach to get some project started without getting bogged down in endless wish-list style discussions. We already had these long discussions last year surrounding the castle sprint, and before at EuroPython, and they led to nothing much more than wishlists nobody really reads. Not that these meetings and discussions weren't very valuable in the sense that they got the right people to talk to each other, but the artifacts produced aren't of great importance in my mind. Openness, neutrality -------------------- This is an open project, and we need to give everybody interested in the project, such as people at the sprint, a good chance to participate, give input, and join and commit resources as well. The more people productively participate in an open source project, the better for all of us, after all. As a first step, what we will do is approach the good people we already know about (such as the sprint participants), and also do a public announcement once we have a good core group running. Image and presentation counts in this. We need to present the image of an open project. Associating the image even in a URL or tools with a single existing Zope 2 project or party (such as CPS or Nuxeo) is not ideal on the medium term (and Nuxeo knows this), but practicaly beats purity for now and this discussion shouldn't stop us from making headway. Nuxeo people are, after all, contributing in a major way by starting this, and they're doing the best they can with the tools they know. We will however commit to moving to a more neutral presentation and location at a reasonably specific point in the coming months. Besides image, there are of course also actual governance issues concerning foundations and copyright assignments and the like. Practicality and doing things now beats an ideal governance structure and no work. No open source projects that I know of start with a governance model *first*, code later. Governance is needed, but we don't have to all get it in place right now as long as we all trust each other enough (and have the open source license to back us up). Paradoxically of course this whole mail is practically *about* governance issues, but I hope we can do it in an agile way to start with. Governance is important for the longer term, and we need to start working on fleshing it out, but after we actually have the ball rolling and there's stuff to work with. License ------- ZPL Some would prefer GPL, some would prefer BSD, but we all know and can work with ZPL. Credit ------ Credit and reputation is important in open source project, as it's one of the main things that is valuable -- after all the code is free for anybody to use. Credits are what is in the CREDITS file, but also what's on the website. The people and companies that invest time and money in this should get the credit, and people should not be allowed automatic credit if they just commit to this project by words only. Action counts. So, I propose the following fairly simple rule: People that commit time and effort in this project will get credit, by name. Companies that commit time and effort and money in this project will get credit, by name. Open source projects such as CPS, Silva, Plone and Zope that people may be affiliated with in other roles will *not* get credit. So, a credit will look like this: Martijn Faassen or perhaps like this: Martijn Faassen (Infrae) or perhaps like this: Thank you Infrae for doing great work on the Fooble Widget. But it won't look like this: Martijn Faassen (Silva) or this: The Silva project is on board for the ECM Project This also means that we'll eventually need to get rid of the bits of 'cps' that are in our presence online (in urls and such) now -- and I already know work is in progress to get this done. Reuse ----- Whenever we need a feature, we will invest time in looking whether there is already code out there that we can reuse. It may take effort to integrate the existing code, and it's often more fun to rewrite (and even quicker initially), but on the longer term it will help us in maintenance and understandability of the project, as people who are already familiar with the code in other contexts will understand it better. It will also give us a reputation for openness, which will encourage programmers to join in. A reputation for reinventing wheels in our own way will discourage programmers, and we don't want that. Standards --------- Very much related to reuse is standards support. We're very interested in the benefits standards bring to us in terms of increased interoperability and understandability by non-Zope non-Python developers. ... There is a lot more to say about these particular issues. For instance, to take one topic, I think people will be pleasantly surprised by the level of commitment there is to standards of the parties already involved in this project. Regards, Martijn
Hosting: Nuxeo: Zope service provider