reticent wrote:
Bogdan-Andrei Iancu wrote:
having multiple options instead of only one proved
in many case to be
a progress engine. I would rather say that both projects will benefit
from this. And most important, the user (don't forget them) will: they
will have a larger diversity to choose from.
indeed, time (and to be more specific, allocated time for the public
SER) was an important factor for deciding to start OpenSER. Also
another factor was how to deal with new contributions and how to
*help* them to get into the main stream. Placing them in a separate
directory I think will not help too much - see the history of the snmp
module.
and about splitting the time between the two projects - I don't thing
will be a problem for us since we are the people who complain the
thing are not fast enough ;)
bogdan
Diversity is not necessarily a good thing in every situation, for
example diversity in a limited resource environment can lead to less
effective use of those resources and, in the end, may lead to the
opposite of what you describe (a progress engine).
tavis, I rather see what happened as a redistribution of same resources
in a more efficient way - is about team work, about each member
commitment and interest in finalizing or developing something.
Diversity is something we can talk a lot about - is about multiple
versus single, absolutism versus democracy, bigamy versus monogamy - for
sure this a vast subject to talk about, with arguments pro and against,
depending of the environment. But it is a too philosophical discussion I
will prefer not to get into it - at least not on this mailing list.
Also IMO diversity seems to be a argument against proprietary software
models, such as "Application X has this features A,B,C and doesn't see
it as necessary to implement features D and E for whatever reason
(generally non-technical) so i'll use Application Y because it has
features D and E (which i really need) however it does not have feature
B which i can do without"
An argument against proprietary models and (generally) not OSS because
(by definition) the latter is open to improvement and modification by
anyone who wishes to take the time and because of this a community is
created around that project. If there is a problem then, as a
community, we should make every effort to deal with it as such.
Now i don't particularily want to approach the problems associated with
self-defensive, impressionistic territorial behaviour that is quite
common in most OSS projects but it is (IMO) a serious one which is taken
into consideration by (i believe) many who post requests. If you have a
hard getting your point across i can see how it may seem impossible to
enact any great change without a very large amount of effort in which
case a simple branch is the easiest solution
what I really appreciate here is the fact that there are people who (at
least) identify the reason for this OpenSER fork (even if maybe its
justification is still not fully understood).
I think if you really are serious about branching SER
you should first
consult with the developers and users of SER to find out what they think
and if there exists a way resolve (or objectively document, for
reference in the least..) the issues you are having. I think that this
would be a reasonable approach, your sudden declaration of a branch is a
total surprise to (i'm sure) everyone on these lists and i think it may
not be the best approach.
OSS gives both users and developers more liberty to choose what to use
and what to work on.
From developer perspective, believe me, there were several talks /
discussions about the driven of SER project - even if thy were only
between the SER core team, sometime you could notice some break-outs
/peeks on the developing mailing list.
As for user - its the reason for which we come public with the project -
we want the users to benefit from what we believe/try to do more.
bogdan