admin statement about eGroupware20 issue

[ralfbecker]

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:

1) 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

2) 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

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core