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

[Andreas Granig]

See my other email. I don't want to discuss these things in public.

Bogdan-Andrei Iancu wrote:
> Andreas,
> 
> The difference does not come only from one extra or minus feature - this 
> is a bit of a superficial approach of the issues. As mentioned in the 
> OpenSIPS announcement email, the reasons were more deeper and concerning 
> than a feature. I do not want to copy'n'paste the list of problems 
> identified with current OpenSER, so I will just point back to it. Please 
> go over the reasons and you will note that the feature-rich is not part 
> of it.
> 
> As said, it came to choosing out of two bad options - however bad it 
> sounds for you a new project, at least I want to have the guarantee of 
> progress and stability for the future. It is better than a dead-end. 
> Again, I look into the future for taking my present actions.
> 
> Regards,
> Bogdan
> 
> Andreas Granig wrote:
>> 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
>