admin statement about eGroupware20 issue, Part two: Deadline

[mipmip]

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

 

----------------------------------------------------------------------------------------------------------

Subject: admin statement about eGroupware20 issue

----------------------------------------------------------------------------------------------------------

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:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[Lars Kneschke-2]

"Pim Snel" schrieb:

>        
> 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.

Hello Pim!

Sorry for not responding earlier, but I got sick.

I'm extremely irritated about the deadline. Cornelius stated that we like to
stay in the project. And of course we need to find a way, how we can solve
the open topics. But I don't see any chance that we can fulfil all your
requests to stay in the project until the end of the deadline.

In the meantime we changed the project name to tine20.org. But about the
other things we need to have an open discussion. After we have finished the
discussion we can post a summary, we can all live with,

----------------------------------------------------------------------------------------------------------
> Subject: admin statement about eGroupware20 issue
>
----------------------------------------------------------------------------------------------------------

>
> 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.

From my point of view there are currently 3 core developers. A core
developer is some one who contributed already very long to the project and
also has a good understanding of the GroupWare core components.
From that point of view, we are talking about currently experimental code
from 2 of the 3 core developers of eGroupWare.

> 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.
Our newly code base represents a proof of concept for the next major release
of eGroupWare. It is our intention to let all developers of eGroupWare
decide if they like our newly written code or not.
I don't see any reason why we should not be able to state this.

> 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.
Of course it wouldn't be possible for us to found this working group until
the deadline. I'm also absolutely unsure who should be in this working
group? No other developer except Ralf has a deeper understanding of
eTemplate. And he already denied to work together with us in a personal
conversation.
It also make absolutely no sense to talk about these things now. We are
creating a proof of concept how eGroupWare 2.0 could look/work like in the
future. When we have finished the proof of concept, then we can start a
discussion how and which part of the old eGroupWare code needs to get
integrated in the proof of concept code base, to fulfil all developers
needs.

> 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.
I'm very unsure why you added this.

> 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.
We have no problems using the existing mailinglists. We doing this already.
But I don't see any reason why should use the eGroupWare.org svn- or
webserver currently. If we have finished the proof of concept phase and the
other developers of eGroupWare decided that they want to use our code base,
then we will of course switch to the eGroupWare.org's infrastructure. But
currently it absolutely makes no sense at all.

> 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.
Again. I don't see how we could fulfil this requirement until the deadline.

--
Lars Kneschke
CTO OfficeSpot.Net
Metaways Infosystems GmbH
Pickhuben 2-4, D-20457 Hamburg

eGroupWare 2.0 demo: http://www.egroupware20.org/demo
eGroupWare Support: http://www.egroupware-support.net
OfficeSpot.Net Collaboration Server: http://cs.officespot.net

E-Mail: mailto:l.kneschke@...
Web: http://www.metaways.de
Tel: [phone]
Fax: [phone]
Mobile: [phone]

Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
Handelsregister: Amtsgericht Ahrensburg HRB 4508
Geschäftsführung: Hermann Thaele, Lüder-H.Thaele



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core