Preamble
The Open Source Groupware Suite eGroupWare is a comunity effort, developed by people for their own enjoyment or to make their living from it.
The ultimate instance in the eGroupWare project are these developers. Developers are as well people writing code, as people translating, creating documentation or art-work.
We acknowledge a project can only be successfull if it picks up the wishes and needs of it's users AND it's developers.
The project is available under the GPL (General public license). The project seeks good relations and support of other open source projects and companies.
1. Project administration
The eGroupWare project has three equal and elected project administrators.
The Administrators are the link between the several developers and they have administration rights on our development platforms (at the moment sf.net and the egroupware.org website).
Administrators or a share of 20% the developers can call for a vote about new elections of the project administrators. This has to follow the decision making process outlined in the next paragraph.
I case of elections, each developer elect three candidates individually. The three candidates with the most votes on their side are the new project administrators.
2. Decision making process
Regular decisions should include a consulting with the developers base via the mailinglist and all three administrators.
Important Decisions for the project need as an absolute minimum the consense between two of the three project administrators.
Examples for important decisions:
- adding new developers or removing existing ones
- including new applications into the repository
- releases
- in doubt a decision should be considered important
If 20% of the active developers or one administrator is not satisfied with a decision, they can call for a vote by the active developers.
Votes need to be formulated in writing and be published on the mailinglist at least one week in advance.
They are considered accepted if 50% or more of the developers voting are agreeing.
3. Documentation of decisions and changes
All decisions done by the administrators or conducted as vote of the developers have to be documented in public.
These documented decisions have to be followed in future equivalent cases and guaranty that way an equal treatment of all developers and cases.
Changes of existing decisions or this constitution requires 2/3 of the active developers to agree!
4. Applications, authors and maintainers
If there is an author or main developer of an application, he should be the maintainer of that application.
For unmaintained applications or if the maintainer is no longer active, the project can appoint a (new) responsible maintainer.
The maintainer is the ultimate instance for decisions concerning that application. Administrator decisions or votes can not force him or his development into a certain direction.
If there is a major disagreement about the development of an application maintainer and there is an other developer willing to develop AND maintain the application in a different way, he can do so under a different name.
5. Official releases, standard applications and branches
The project can set criteria which applications have to meet, to be included in an official release.
If there are more the one application conducting a certain service, the project can appoint a standard applications for that service or decide to include multiple applications equally.
Every developer and the project itself is allowed to create branches for alternative developments or own releases.
Release branches can have special rules ensuring the quality of the release.
The eGroupWare constitution should be put into force by a first vote of the active developers.
(Editors note: The constitution was put into force by a 14 against 8 vote on 30. March 2005.)
