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

Mark Sayer datapipes at avtb.co.nz
Tue Aug 5 01:25:42 CEST 2008


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





More information about the Users mailing list