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

[Alex Balashov]

Bogdan,

Thank you for your reply.

You do raise a lot of good and constructive points.  The overarching 
theme of my response to them is that because I am not privy to the 
interior of the project narrative, I do not have the knowledge to 
critically evaluate or authenticate a great deal of what you say.  If 
the situation is as you suggest, then perhaps, indeed, you are doing a 
good and necessary thing.  I can only give the perspective of an outsider.

That said, I offer a few inline replies, from that very vantage point:

Bogdan-Andrei Iancu wrote:

> to be honest I preferred not to put details about the arguments as I did 
> want people to think I'm pointing burning fingers or I'm blaming  
> something or somebody. Of the arguments are to be found on the 
> discussions from the board list, but this is not public.

I can certainly understand appreciate the need to avoid public 
accusations or anything that could be construed as undermining anyone's 
personal integrity.

The flip side to this conservative approach to publicising internal 
affairs is that to the rest of us--those who are not project 
luminaries--it leaves the situation looking like some absurd, 
internecine feud replete with tribalism, factionalism, and egotism.

Of course, I think I--and the rest of us--know better than to suppose 
that this is actually the case, and know from passive observation of 
your erudition and epistolary character in the community that there are 
very likely real and substantive reasons for this move.  However, it is 
not necessarily taken that way by some of our superiors and clients; 
these are hard-nosed, often unsophisticated people who are not going to 
be preoccupied with the sociological nuances and personal traits of this 
particular open-source ecosystem.

So, managing the PR on these types of changes and finding that balance 
can often be the hardest challenge of all.  Personally, I'd favour a 
little more transparency to this issue, even at the risk of some fingers 
and being pointed and some feelings being hurt.  I'd much rather the key 
issues be diligently addressed in a public forum so we can all have a 
chance to evaluate them on some level.  Otherwise, we've got this 
largely unsubstantiated (from outside POV) claim that the 
OpenSER/Kamailio project branch is woefully mismanaged and stagnant, and 
well, that's it.

Maybe I'm just missing something rather self-evident that every other 
outside observer peripheral to the immediate development community 
knows?  If so, I am eager to be corrected.

> First of all, depends of how do you want to see the change: I see it as 
> a progress (actually this is the reason). None of the so far 
> values/investments are lost or degradated - they are carried on the next 
> versions/forms. It is like natural evolution - nothing disappears, 
> everything evolves.

Well.  I don't think anyone was supposing that OpenSIPS as a derivative 
of Kamailio implies something qualitatively inferior or some sort of 
downgrade.  It does evolve from the current point, of course.  The 
drawbacks are all the other things that I pointed out that come with 
factionalism and contending projects jockeying for the mantle of 
superior merit, the resulting damage to the cohesion of the commercial 
and OSS ecosystem in the vicinity, and the likely loss of economies of 
scale (and increased lopsidedness) resulting from a reallocation of 
competencies and focus on the development team.

If I read your general argument correctly from this and other threads, 
it seems to be something like: "I was material to the fork of OpenSER 
from SER a few years ago, and now I'm just doing it again - in order to 
bring you the same great value I did pulling this last time and for 
essentially the same reasons."  This may not necessarily be inaccurate, 
I'm just curious -- is that what you are essentially saying?

> there was no such system - in the last year, any person was component 
> enough to vote or take decisions in important technical matter. This is 
> not a methodology and the result was the quality degradation.

Couldn't this problem have been solved by implementing a more rigid, 
hierarchical distribution of authority that seems to be inevitably 
required with projects that start out 'organically' and grow in 
sophistication?

I realise that's hard to do with any group of people - especially a 
group of people not accustomed to working that way.  But it seems to me 
like just about anything is better than a code fork.

> I agree and as I said before, taking the decision of crating OpenSIPS 
> was one of the most difficult I ever done. I 'm aware of the impact it 
> has, but I look into the future and my present actions wants to secure 
> the project (under whatever name) for the future. Form my perspective, 
> looking back over the last year, I do not see any evolution with OpenSER 
> - just take a look at release 1.2 and release 1.4 (future) and tell me 
> it is the same - going in the same direction is dead-end.

As a casual reader of the changelogs and release notes, I was not 
particularly moved to say that 1.2.x and 1.4.x resemble each other, but 
because I do not dwell in the code nor participate in roadmapping I 
cannot possibly say for sure.  I would be eager to hear some of your 
thoughts on why you feel the direction of the incumbent OpenSER was 
stagnant.  It seemed to me as a mere user that there was movement 
forward on a variety of objectives.

>> 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.
>>   
> [bogdan]
> for me this is not an option.

I know.  I meant if I were a user of OpenSER, I might wonder if it's 
worth it to just snapshot the current release, take it in-house, and not 
worry about what I perceive to be perennial madness and instability in 
the realm of the official maintainers.  Maybe I'd backport some of their 
critical fixes but otherwise try to keep away from official releases.

By all accounts this is a bad approach from a management perspective, 
but its appeal is inversely proportional to one's confidence in the 
leadership and cohesion of the official project.

> exactly my point - there is no unity/consent/process/value in taken 
> decisions with OpenSER - see what happened with the 1.4 release. Do you 
> find it an example of reliability for  a business?

What, exactly, happened in the 1.4 release that should cast doubt upon 
it from a reliability perspective?  I ask because I genuinely do not know.

> I asked myself the same question and I debated the matter with other 
> people (I like to get as many opinions on some matters) - and the key 
> word is control - to organize the project in such a way to be 
> controllable. This does not mean to define rules, but to have a system 
> that will guarantee decision making based on value - being able to make 
> decisions, means you can control. It is like all the countries - there 
> is a form of control across each country (government, monarchy, etc) 
> that ensure the functionality of the country.

And you do not feel that a revamping of the ground rules in the 
incumbent project could have been achieved?  In other words, couldn't 
you have said to everyone:  "Look, what we've got right now isn't 
working [for the following reasons] and it must change, or I might have 
to go make my own fork?"

Best,

-- Alex

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599