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

Tue Aug 5 05:12:38 CEST 2008

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