[Serdev] Re: [Serusers] OpenSER release

[Bogdan-Andrei Iancu]

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