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

Tue Aug 5 01:09:45 CEST 2008

I couldn't have said it better myself.

Well done.

_____________________________

dmsessions at gmail.com
http://www.darrensessions.com
http://www.linkedin.com/in/dsessions
_____________________________

On Aug 4, 2008, at 4:56 PM, Alex Balashov 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
>
> _______________________________________________
> Devel mailing list
> Devel at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080804/d0e82526/attachment.htm>