[Kamailio-Users] [Kamailio-Devel] 1.4.0 release plans, project matters

[Andreas Granig]

Bogdan,

The answer is quite easy, since there is no real need to choose... there 
was one single feature (or however you call it) which didn't got 
approved for a new release... I'd loved to see this feature in the new 
release, but there's no reason for me (personally) to split because of 
this thing...
I don't know how important this is to your business, that's another 
thing. But for all other businesses except yours, it's a really really 
bad thing to have another split.

Whatever,
Andreas

Bogdan-Andrei Iancu wrote:
> Hi Andreas, Hi Mark,
> 
> I will ask you the same question I had to answer before coming to the 
> OpenSIPS solution:
> 
>  From business point of view, what do you prefer:
>   1) stick to kamilio and face angry and unsatisfied customers because 
> of the software/project condition (starting with 1.3 we had a lot of 
> complains/bad experience with quality)
>   2) make a change and make them happy.
> 
> Or shortly - what you put more price on? name of the project or quality 
> of the project?
> 
> I made my choice, even if for us, as business, things were more delicate 
> as Voice System founded OpenSER and now we move to work on a new project.
> 
> Decisions are not easy -  red or blue pil? - but the project (whatever 
> name it has) as deliverable is the most important for me.
> 
> Regards,
> Bogdan
> 
> Andreas Granig wrote:
>> OpenSER became a brand name in the business of VoIP. A name change 
>> because of some legal issues is something you can communicate to your 
>> customers. Another fork because of some communication issues isn't. 
>> Come on, guys, get your things together...
>>
>> Andreas
>>
>> Mark Sayer wrote:
>>  
>>> Wow ! Well said and as one of those users with a business that 
>>> depends on OpenSER, I agree completely.
>>>
>>> Mark
>>>
>>> At 10:56 a.m. 05/08/2008, Alex wrote:
>>>    
>>>> I would strongly concur with Darren here on all counts.
>>>>
>>>> I don't, of course, have any sort of inside perspective as I am not
>>>> involved in development, so I can't presume to judge the merits or
>>>> veracity of the various justifications given for this adventure.  Apart
>>>>       
>>> >from Bogdan-Andrei's brief treatment of the subject, explanations
>>>    
>>>> haven't been particularly forthcoming to the community;  this seems to
>>>> be a back-room affair that is still playing out.
>>>>
>>>> There are, certainly, times in the life of an open-source project where
>>>> a code fork may be justifiable;  irreconcilable differences over
>>>> development methodologies, project management practices, and overall
>>>> design philosophy and direction/roadmap may figure into these.  Also,
>>>> what Bogdan-Andrei has put forth concerning his freedom to pursue this
>>>> undertaking in light of prevailing and officially codified open-source
>>>> precepts is factually valid and logically ostensible.
>>>>
>>>> Now, that having been said, from the perspective of a user 
>>>> contemplating
>>>> the adoption of OpenSER in a serious industrial application, or 
>>>> worse, a
>>>> businessperson who has sunk substantial investment into deployment of
>>>> OpenSER, this is really, really bad.
>>>>
>>>> Much of the value of open-source projects comes from the fact that
>>>> despite the range of political characteristics potentially colouring 
>>>> the
>>>> development and its management (from profoundly hierarchical, as in the
>>>> case of the Linux kernel, to rather loose coupled and organic, as seems
>>>> to be the case with OpenSER), comes from certain rational expectations
>>>> that one holds regarding their security, stability, consistency and
>>>> continuity.  Industry is just as afraid of "fly-by-night" open source
>>>> packages as it is of fly-by-night vendors that may not be around 
>>>> tomorrow.
>>>>
>>>> Generally, when one chooses to invest in a rather serious and evolving
>>>> open-source solution like OpenSER, one expects the following things:
>>>>
>>>> 1. The project will be around next year, more or less in its present 
>>>> state.
>>>>
>>>> 2. Its development is coloured by a relatively consistent methodology;
>>>> even if the original core developers no longer contribute heavily to 
>>>> the
>>>> code base itself, their oversight, direction, vision, method and
>>>> quality-control is realised in the activities of those to which that
>>>> work has been delegated.
>>>>
>>>> The sources of that direction and influence must be relatively cohesive
>>>> and clearly identifiable.
>>>>
>>>> 3. In the case of something relatively low-level and niche like 
>>>> OpenSER,
>>>> a thriving ecosystem of first and third-party contributors and vendors
>>>> of commercial support must exist.  Nobody is going to trail-blaze
>>>> without any sense of reliance on anybody in particular.  This heavily
>>>> depends on #2, and on the consistency of the project as a unitary 
>>>> thing.
>>>>
>>>> 4. The project will retain a unitary character as much as possible;
>>>> there will not be bewildering an array of species and subspecies of the
>>>> code which will contain varying degrees of features, quality control,
>>>> bug fixes, and developer and organisational affinities.  All such
>>>> choices involve trade-offs that are unacceptable in serious work,
>>>> especially when the trade-offs involve some form of playing roulette,
>>>> gambling on the meritocratic superiority and pre-eminence of a
>>>> particular version and not another and its longevity.
>>>>
>>>> ...
>>>>
>>>> This type of code work heavily upsets these expectations and decreases
>>>> overall confidence in the project, which, especially in open-source, is
>>>> so profoundly a function of the people behind it and the ecosystem it
>>>> cultivates.
>>>>
>>>> How do I know whether the latest bleeding-edge modules that perform
>>>> low-level technical enhancements or fixups won't be in OpenSIPS, but
>>>> ones which offer more high-level integration paths and business logic
>>>> interworking in Kamailio?  What kind of compatibility can I count on if
>>>> I wish to switch?
>>>>
>>>> How do I know that critical bugs applicable to pre-fork code in 
>>>> Kamailio
>>>> will be fixed in OpenSIPS, or vice versa?  At the encouragement of Juha
>>>> Heinenen, I just submitted a bug report about a race condition on call
>>>> branching to the Kamailio Tracker.  How do I know whether it's going to
>>>> be addressed sooner in Kamailio or in OpenSIPS, if at all?  What if 
>>>> this
>>>> type of issue is closer to Bogdan-Andrei's core competency and interest
>>>> than that of the remaining Kamailio developers, or vice versa?  Now I
>>>> have to engage in this type of guesswork and detect the political 
>>>> winds.
>>>>   I shouldn't have to do this as a user;  I was counting on one
>>>> development team and one mission.
>>>>
>>>> How do I know there won't be more code forks or internecine feuds?  
>>>> If I
>>>> am a medium to large organisation with relatively high internal
>>>> technical capital, I may see an economic rationale in taking an 
>>>> existing
>>>> release and all maintenance of it in-house and *not* releasing the
>>>> changes back to the community (after all, too many "communities" to
>>>> choose from, if nothing else).  Or I may release it as my own code fork
>>>> later, once it's deviated enough.  Both of these damage and undermine
>>>> the incipient ecosystem surrounding OpenSER.
>>>>
>>>> Code works beget more code forks and more proprietary approaches by
>>>> shifting the mindset of users to a self-reliant approach as a matter of
>>>> pragmatic necessity;  if I can't really count on the project's 
>>>> integrity
>>>> politically, there's far less incentive to build business decisions
>>>> around it.
>>>>
>>>> Open-source contributors are also going to be less enthused about
>>>> contributing to a landscape full of code branches, as they have to make
>>>> similar bets about their relative merits and significance.
>>>>
>>>> As far as I can tell, OpenSER has a handful of core developers and one
>>>> to two dozen ancillary developers.  This isn't that big of a project
>>>>       
>>> >from an organisational perspective.  Somehow, open-source projects much
>>>    
>>>> bigger - with much more at stake - have managed to survive without this
>>>> type of feuding and forking.  MySQL, the Linux kernel, Apache, and even
>>>> Asterisk to a relatively high degree, are all examples of projects with
>>>> hundreds to thousands of active contributors that do not seem to suffer
>>>>       
>>> >from these types of problems, which is why I consider them relatively
>>>    
>>>> safe to invest in.
>>>>
>>>> Once again, I am not berating either side of this issue;  I don't have
>>>> the perspective to judge.  Likewise, I stand in awe and appreciation of
>>>> Bogdan-Andrei's significant technical contributions to OpenSER and the
>>>> offerings Voice System is poised to make, and can appreciate the
>>>> possible legitimate reasons he may have for wanting to make this split.
>>>>
>>>> But I think that I speak on behalf of the prevailing majority of users,
>>>> adopters, enthusiasts of and contributors to OpenSER when I implore you
>>>> guys to work your differences out, compromise, standardise, and merge
>>>> the code back into one project so that we can all continue to enjoy,
>>>> evolve and innovate with the best, most extensible, polymorphic and
>>>> featureful SIP server out there.
>>>>
>>>> Cheers,
>>>>
>>>> -- Alex
>>>>
>>>>
>>>> Darren Sessions wrote:
>>>>
>>>>      
>>>>> I can't tell you all how worrying another fork of SER or OpenSER is 
>>>>> to me.
>>>>>
>>>>> I have worked, known, or at least met most of the people in SER ->
>>>>> OpenSER -> OpenSIPS groups in some fashion over the last five or six
>>>>> years starting back with Jiri and Bogdan at iptel.
>>>>>
>>>>> I obviously don't understand what's going on that could possibly 
>>>>> cause a
>>>>> project fork but I think I can speak for a number of people as a
>>>>> former commercial support customer, present user, source tinkerer, and
>>>>> occasional consultant - when I say that this really does put a dark
>>>>> cloud over ALL of the projects.
>>>>>
>>>>> To start splitting up the core developers -again- between projects, to
>>>>> me, seems absolutely insane!
>>>>>
>>>>> This makes me extremely nervous going forward with either project 
>>>>> and I
>>>>> will be (as most will be) watching closely as this situation continues
>>>>> to unfold and details emerge.
>>>>>         
>>>> -- 
>>>> Alex Balashov
>>>> Evariste Systems
>>>> Web    : http://www.evaristesys.com/
>>>> Tel    : (+1) (678) 954-0670
>>>> Direct : (+1) (678) 954-0671
>>>> Mobile : (+1) (706) 338-8599
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.kamailio.org
>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>       
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.kamailio.org
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>     
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>
>>   
>