5 Aug
2008
5 Aug
'08
9:23 a.m.
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(a)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:
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.
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. 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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users