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

[Alex Balashov]

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