[Users] Re: openser/ser - avoiding forks

Andrei Pelinescu-Onciul andrei at iptel.org
Thu Jun 16 17:51:04 CEST 2005


On Jun 15, 2005 at 22:42, Daniel-Constantin Mierla <daniel at voice-system.ro> wrote:

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

Let's try not to degenerate in another flame war and please try not to 
 exagerate it: no willing to cooperate, hold-back policies and all the
 other stuff...

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

This will take a while as some of the other core devepers are either
traveling or will be away for the next days (e.g.: me).

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

That sounds very scary... The general ser approach so far was every one
is maintaining its own code and other people should not go over it
without his approval (except for fixing bugs). The ideea here is that
the code maintainer might have his own plans for its own module and he
wouldn't want it changed "under him".
If I'm away for two months I wouldn't like to not recognize what I've
been working on when I'm back (this of course doesn't include bugfixes).
There is some  other point: a code maintainer might not accept a change.
While the change submitor, might think it's the best thing in the world,
not everyone might share his opinion.

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

Yes, I agree, but this doesn't mean that each and every contributions
will be applied. In fact I do think this problem is exagerated a lot,
given ser's history (you can look even at your linux kernel example,
lots of patches are unanswered, and very few make it to the kernel).
> 
> - 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


I don't agree with this (and with calling it "hiding"). This is a
documentation problem. I don't think "document everything or don't add
new features" is a good ideea. We do accept documentation patches, is
just not realistical to ask all developers to document each new minor
feature.

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

This depends on what you understand by next steps. I do see the
potential for interminable discussion.


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


Andrei




More information about the Users mailing list