[Users] Re: openser/ser - avoiding forks

[Daniel-Constantin Mierla]

Let's put it straight! First to clarify some things many users seem to 
be confused about.

SER was started and developed inside FOKUS Fraunhofer Institute, Berlin. 
All core developers of SER were employed until a stage by that 
institute. Many contributors were inteship students at FOKUS, many are 
still active contributors from their current location and others retired 
from SER development. The development of SER was somehow known (or 
promoted) as the "iptel" project (it is what the public mainly saw).

Now, none of the core developers are employed anymore by FOKUS. Some of 
them created a venture named "iptelorg.com" where some other core 
developers are employed now, and the others started "voice-system.ro". 
Because the iptelorg has the control of the SER project site (iptel.org) 
and a similar name, the general impression is that the SER was developed 
by iptelorg which is far from true. For example, Juha contributed most 
of the RADIUS code, enum and a lot of other modules...

Now, we are not saying that fork is good in general, otherwise it will 
be a fork each day :-), but when there is no willing to cooperate, 
hold-back policies and abuses for self-promoting I see no other way.

We will gladly participate in a *really* open source project. A very 
good example is the Linux kernel -- it is clear that many of the main 
developers and contributors are employed by major Linux vendors, which 
have enterprise/closed releases, but you don't see on the main page of 
kernel.org advertising for none of them. In the sources is no explicit 
advertising message, and so on ...

So the proposal is:

- move the project's main site on an independent host (I bet there are 
people willing to sponsor the hosting)

- remove all references that are intended for private publicity

- introduce a better management of the project, allowing people to be 
able to take over when someone is very busy or unwilling to cooperate

- make the project really open for contributions and contributors. 
Outstanding developers can be good reviewers for new contributors when 
the others are busy

- don't hide the new features from the community, we are on open source, 
what is the reason to have that ... so each new featured should be 
described shortly to the community, otherwise keep it in a private 
repository

- the next steps in develpment should be discussed between the 
developers to avoid overlapping and waste of time and to select the best 
way to do it

- members should have a fair attitude to the others and try to discuss 
each issue is a nice manner (without trying to impose from beginning own 
opinion and ideas)

This is shortly how we see it. If you agree (improvements are welcome), 
then we can move forward together, otherwise we will maintain further 
our code from SER as well as openser.

Daniel


On 06/15/05 16:06, Andrei Pelinescu-Onciul wrote:

>I think that a fork is bad for everybody. Whatever way you put it, it
>will still involve extra overhead at least for each code merge.
>
>So this mail is an attempt to come to a compromise that would be
>acceptable for everybody.
>
>My first proposal would be to have another branch on ser cvs (berlios).
>Something like openser_0.x.y (where the version number should reflect
>somehow that it's newer than 0.9 but not unstable).
>Bogdan and Daniel would mantain this branch and they would be able to
>release from it as often as they want. It would be some kind of stable
>on steroids :-)
>
>This would have the main advantage that code merges/diffs/fixes
>propagation would be much easier and much faster. Administrating all the
>stuff will be also easier (like common bug tracking system a.s.o).
>It would be also easier for users, it will be much more easier to keep
>track of the changes and to choose an appropiate version.
>
>There must be however some rules. Something like: backporting/forwadporting
>from unstable/stable should be ok, the same for minor patches (e.g. xlog
>colors), but not major code changes, not present in unstable and without
>the code maintainer approval (to maintain future compatibility).
>Adding new stuff (new modules) should also be ok, but it would be
>preferable that these module come from either unstable or experimental.
>
>The mailing list for development should remain serdev. For users it
>could  be a different one (if the changes or the mail traffic gets too big).
>
>
>As far as integrating new contributions faster in unstable, I agree that
>this is a problem, but I think we can sort it out. The experimental
>repository is a beginning and if there are better ideeas on how to speed
>things up while maintaing sanity, please speak. Maybe some kind of
>reviewed patches (e.g: someone sends a patch that adds a new feature in
>core, Bogdan reviews it decides it's ok and  blesses it => I will
>integrate much faster something blessed by other ser developer).
>
>
>If you don't agree with my proposal, please say what you don't like and
>what you would like changed so that  it would be acceptable for you.
>I'm sure that we can reach a compromise and hopefully improve ser
>development pace in the process.
>
>
>
>Andrei
>
>  
>