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

[Bogdan-Andrei Iancu]

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