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.

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: -- 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

OpenSER became a brand name in the business of VoIP. A name change because of some legal issues is something you can communicate to your customers. Another fork because of some communication issues isn't. Come on, guys, get your things together... Andreas Mark Sayer wrote: _______________________________________________ Users mailing list Users(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

Bogdan, The answer is quite easy, since there is no real need to choose... there was one single feature (or however you call it) which didn't got approved for a new release... I'd loved to see this feature in the new release, but there's no reason for me (personally) to split because of this thing... I don't know how important this is to your business, that's another thing. But for all other businesses except yours, it's a really really bad thing to have another split. Whatever, Andreas Bogdan-Andrei Iancu wrote: > Hi Andreas, Hi Mark, > > I will ask you the same question I had to answer before coming to the > OpenSIPS solution: > > From business point of view, what do you prefer: > 1) stick to kamilio and face angry and unsatisfied customers > because of the software/project condition (starting with 1.3 we had a > lot of complains/bad experience with quality) > 2) make a change and make them happy. > > Or shortly - what you put more price on? name of the project or > quality of the project? > > I made my choice, even if for us, as business, things were more > delicate as Voice System founded OpenSER and now we move to work on a > new project. > > Decisions are not easy - red or blue pil? - but the project > (whatever name it has) as deliverable is the most important for me. > > Regards, > Bogdan > > Andreas Granig wrote: >> OpenSER became a brand name in the business of VoIP. A name change >> because of some legal issues is something you can communicate to >> your customers. Another fork because of some communication issues >> isn't. Come on, guys, get your things together... >> >> Andreas >> >> Mark Sayer wrote: >> >>> Wow ! Well said and as one of those users with a business that >>> depends on OpenSER, I agree completely. >>> >>> Mark >>> >>> At 10:56 a.m. 05/08/2008, Alex wrote: >>> >>>> 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

I will ask you the same question I had to answer before coming to the OpenSIPS solution: From business point of view, what do you prefer: 1) stick to kamilio and face angry and unsatisfied customers because of the software/project condition (starting with 1.3 we had a lot of complains/bad experience with quality) 2) make a change and make them happy.

From business point of view, what do you prefer: 1) stick to kamilio and face angry and unsatisfied customers because of the software/project condition (starting with 1.3 we had a lot of complains/bad experience with quality)

2) make a change and make them happy.

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.

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.

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.

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.

[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?

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?"

[..] Henning, I would ask you to review your conduct as of late, simple trivial things like removing bogdans admin access screams of something driven by emotion, and not a decision based on logic or facts. That and many little things (nothing that would by itself would be a case) that I have seen over the last few months on the lists (mostly devel list) lead me to question your ability to lead/motivate/empower. I have seen public finger pointing, redirecting, mandating, and much of this is the way it is going to be and I don't care what you think. There is a certain level of tact that seems to be missing (I know I miss it, and as such this email is devoid of any tact, but then I recognize what positions I best serve) [..]

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.