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@lists.kamailio.orghttp://lists.kamailio.org/cgi-bin/mailman/listinfo/users