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

[Mahesh Paolini-Subramanya]

Consider this another vote for transparency.

Transparency is the nature - and in many ways, the central paradox -   
of Open  Source.  Everybody can contribute.  The contributions aren't  
necessarily accepted into the main branch, and the public doesn't  
necessarily need to accept the main branch.
*But*, this, really, isn't necessarily about code, it is about how we  
get to the idea/nature of the 'main branch'
The contributions can be in the form of suggestions, recommendations,  
ideas, etc.  The entire dialog that goes along with the creation of a  
(successful) open source project is probably the *most* important part  
of the project.   And this, *this*, is where transparency becomes  
critical.  Lacking transparency, everybody is operating based on  
incomplete information.  Can we trust the decisions that get made  
based on incomplete - and possibly incorrect - information?
Yes, I/we know of *some* of the ongoing issues with SER/OpenSER/ 
whatever.  Have we been perfectly happy? No. But the previous split  
(SER/OpenSER) was largely public, and those of us who ended up picking  
one or the other did so based on this.  Not necessarily based on who  
was right/wrong, or who was stodgy/chaotic, or who had the better  
ideas, or who had the better code.
Instead, we made our decisions based on our particular interpretation  
of ALL of the above, and how it impacted us.

Now, we are being asked to do this all over again, except this time,  
we don't have much background!

The open source world is filled with other similar situations.  Heck,  
one could almost claim that this is part and parcel of any thriving  
ecosystem - software or otherwise.
My recommendation is to put it all out there.  Play the arguments out  
in public.  Lets see where things go

cheers

p.s.  This is *not* intended to imply that I am either for, or  
against, the (re)split.  I do, however, firmly believe that  
transparency is vital to the Open Source ecosystem
**********************************************
Mahesh Paolini-Subramanya    (703) 386-1500 x9100
CTO                                                         mahesh at aptela.com
Aptela, Inc.                                     http://www.aptela.com
"Aptela: How Business Answers The Call"
**********************************************

On Aug 5, 2008, at 1:34 AM, Alex Balashov wrote:

> 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
>
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/devel/attachments/20080805/03a98458/attachment-0002.htm