Because we find the current situation damaging for the official
egroupware.org project, the admin team feel the need to extend our
statement about the eGroupware20 issue with a deadline. The deadline
is Monday, December 10 at 22.00 CET.
We strongly request the initiators behind “eGroupware20” to take
action and comply with one of the options we mention in our “admin
statement about eGroupware20 issue” before the deadline is reached.
The original statement without modification is listed below.
The eGroupWare admins
Ralf Becker, Pim Snel, Miles Lott
This statement is based on the admins understanding of the eGroupWare
project and it’s constitution: www.egroupware.org/constitution
We acknowledge and appreciate the intentions of the people behind
eGroupware20 to improve the eGroupWare code.
However, we cannot allow the use of the name eGroupWare or eGroupware20
outside of this project, as it implies that it is an officially
sanctioned part of the eGroupWare project.
The current eGroupware20 movement is not officially sanctioned, which
leaves only two possible alternatives:
- eGroupware20 returns as part of eGroupWare
=======================================
It acknowledges a few important points with regard to its public
appearance, representation and operations:
a) That it is currently experimental code from a subset of eGroupWare
developers.
b) That it does not necessarily represent at its current state a new
eGroupWare version, a future release or the future of eGroupWare. This
will be determined at a later date due to the enormity of the potential
change to project-wide operations as well as its effect upon our
customer base, whether or not they are consulting clients of our
developers or other project members.
c) That the selection of technologies and coding methods used in its
design should give consideration to our current development community.
This may become something that we will need to maintain as a community
effort in the future, assuming it will be accepted as a future version
of egroupware by the community. Preferably, this should be handled as a
working group with agreed membership to avoid the need for a
project-wide votes on every single change, which may tend to slow the
progress of development.
d) That eGroupWare is more than just the name and a core functionality.
We strive to maintain variety and open architecture. It would require a
huge consensus to change this into a more narrowly focused software
project to the exclusion of some peripheral applications.
e) That it uses the existing project infrastructure including svn, the
website, mailing lists, etc., to which all other project members may
have access. Typical access controls may be used to limit write access,
but for the most part our usual method of staying out of each other’s
business should continue to work.
f) This new working group must balance the desires of any sponsor with
the needs and wishes of the project, including its administration,
developers and customers. This should always be a primary consideration
when working on the core API.
OR
- eGroupware20 goes its own way as a new project
=================================================
a) This new project should select a new name not containing the name
egroupware or suggesting any relationship to our current efforts.
b) This new project should discontinue the use of domains containing the
name egroupware.
c) This does not necessarily mean that the two will never merge again or
otherwise be affiliated.
We hope for a peaceful resolution to this situation which allows all
current project members to continue to work on the future of the
eGroupWare project.
The eGroupWare admins
Ralf Becker, Pim Snel, Miles Lott
