<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I couldn't have said it better myself.<div><br></div><div>Well done.</div><div><br><div><div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><br></div><div>_____________________________</div><div><br></div><div><a href="mailto:dmsessions@gmail.com">dmsessions@gmail.com</a></div><div><a href="http://www.darrensessions.com">http://www.darrensessions.com</a></div><div><span class="Apple-style-span" style="font-family: Arial; line-height: 14px; white-space: pre-wrap; "><a href="http://www.linkedin.com/in/dsessions">http://www.linkedin.com/in/dsessions</a></span></div><div><font class="Apple-style-span" face="Arial"><span class="Apple-style-span" style="line-height: 14px; white-space: pre-wrap; ">_____________________________</span></font></div><div><br></div></span></div></span></div></span></div></span></div></span><br class="Apple-interchange-newline"> </div><br><div><div>On Aug 4, 2008, at 4:56 PM, Alex Balashov wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I would strongly concur with Darren here on all counts.<br><br>I don't, of course, have any sort of inside perspective as I am not <br>involved in development, so I can't presume to judge the merits or <br>veracity of the various justifications given for this adventure. Apart <br>from Bogdan-Andrei's brief treatment of the subject, explanations <br>haven't been particularly forthcoming to the community; this seems to <br>be a back-room affair that is still playing out.<br><br>There are, certainly, times in the life of an open-source project where <br>a code fork may be justifiable; irreconcilable differences over <br>development methodologies, project management practices, and overall <br>design philosophy and direction/roadmap may figure into these. Also, <br>what Bogdan-Andrei has put forth concerning his freedom to pursue this <br>undertaking in light of prevailing and officially codified open-source <br>precepts is factually valid and logically ostensible.<br><br>Now, that having been said, from the perspective of a user contemplating <br>the adoption of OpenSER in a serious industrial application, or worse, a <br>businessperson who has sunk substantial investment into deployment of <br>OpenSER, this is really, really bad.<br><br>Much of the value of open-source projects comes from the fact that <br>despite the range of political characteristics potentially colouring the <br>development and its management (from profoundly hierarchical, as in the <br>case of the Linux kernel, to rather loose coupled and organic, as seems <br>to be the case with OpenSER), comes from certain rational expectations <br>that one holds regarding their security, stability, consistency and <br>continuity. Industry is just as afraid of "fly-by-night" open source <br>packages as it is of fly-by-night vendors that may not be around tomorrow.<br><br>Generally, when one chooses to invest in a rather serious and evolving <br>open-source solution like OpenSER, one expects the following things:<br><br>1. The project will be around next year, more or less in its present state.<br><br>2. Its development is coloured by a relatively consistent methodology; <br>even if the original core developers no longer contribute heavily to the <br>code base itself, their oversight, direction, vision, method and <br>quality-control is realised in the activities of those to which that <br>work has been delegated.<br><br>The sources of that direction and influence must be relatively cohesive <br>and clearly identifiable.<br><br>3. In the case of something relatively low-level and niche like OpenSER, <br>a thriving ecosystem of first and third-party contributors and vendors <br>of commercial support must exist. Nobody is going to trail-blaze <br>without any sense of reliance on anybody in particular. This heavily <br>depends on #2, and on the consistency of the project as a unitary thing.<br><br>4. The project will retain a unitary character as much as possible; <br>there will not be bewildering an array of species and subspecies of the <br>code which will contain varying degrees of features, quality control, <br>bug fixes, and developer and organisational affinities. All such <br>choices involve trade-offs that are unacceptable in serious work, <br>especially when the trade-offs involve some form of playing roulette, <br>gambling on the meritocratic superiority and pre-eminence of a <br>particular version and not another and its longevity.<br><br>...<br><br>This type of code work heavily upsets these expectations and decreases <br>overall confidence in the project, which, especially in open-source, is <br>so profoundly a function of the people behind it and the ecosystem it <br>cultivates.<br><br>How do I know whether the latest bleeding-edge modules that perform <br>low-level technical enhancements or fixups won't be in OpenSIPS, but <br>ones which offer more high-level integration paths and business logic <br>interworking in Kamailio? What kind of compatibility can I count on if <br>I wish to switch?<br><br>How do I know that critical bugs applicable to pre-fork code in Kamailio <br>will be fixed in OpenSIPS, or vice versa? At the encouragement of Juha <br>Heinenen, I just submitted a bug report about a race condition on call <br>branching to the Kamailio Tracker. How do I know whether it's going to <br>be addressed sooner in Kamailio or in OpenSIPS, if at all? What if this <br>type of issue is closer to Bogdan-Andrei's core competency and interest <br>than that of the remaining Kamailio developers, or vice versa? Now I <br>have to engage in this type of guesswork and detect the political winds. <br> I shouldn't have to do this as a user; I was counting on one <br>development team and one mission.<br><br>How do I know there won't be more code forks or internecine feuds? If I <br>am a medium to large organisation with relatively high internal <br>technical capital, I may see an economic rationale in taking an existing <br>release and all maintenance of it in-house and *not* releasing the <br>changes back to the community (after all, too many "communities" to <br>choose from, if nothing else). Or I may release it as my own code fork <br>later, once it's deviated enough. Both of these damage and undermine <br>the incipient ecosystem surrounding OpenSER.<br><br>Code works beget more code forks and more proprietary approaches by <br>shifting the mindset of users to a self-reliant approach as a matter of <br>pragmatic necessity; if I can't really count on the project's integrity <br>politically, there's far less incentive to build business decisions <br>around it.<br><br>Open-source contributors are also going to be less enthused about <br>contributing to a landscape full of code branches, as they have to make <br>similar bets about their relative merits and significance.<br><br>As far as I can tell, OpenSER has a handful of core developers and one <br>to two dozen ancillary developers. This isn't that big of a project <br>from an organisational perspective. Somehow, open-source projects much <br>bigger - with much more at stake - have managed to survive without this <br>type of feuding and forking. MySQL, the Linux kernel, Apache, and even <br>Asterisk to a relatively high degree, are all examples of projects with <br>hundreds to thousands of active contributors that do not seem to suffer <br>from these types of problems, which is why I consider them relatively <br>safe to invest in.<br><br>Once again, I am not berating either side of this issue; I don't have <br>the perspective to judge. Likewise, I stand in awe and appreciation of <br>Bogdan-Andrei's significant technical contributions to OpenSER and the <br>offerings Voice System is poised to make, and can appreciate the <br>possible legitimate reasons he may have for wanting to make this split.<br><br>But I think that I speak on behalf of the prevailing majority of users, <br>adopters, enthusiasts of and contributors to OpenSER when I implore you <br>guys to work your differences out, compromise, standardise, and merge <br>the code back into one project so that we can all continue to enjoy, <br>evolve and innovate with the best, most extensible, polymorphic and <br>featureful SIP server out there.<br><br>Cheers,<br><br>-- Alex<br><br><br>Darren Sessions wrote:<br><br><blockquote type="cite">I can't tell you all how worrying another fork of SER or OpenSER is to me. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I have worked, known, or at least met most of the people in SER -> <br></blockquote><blockquote type="cite">OpenSER -> OpenSIPS groups in some fashion over the last five or six <br></blockquote><blockquote type="cite">years starting back with Jiri and Bogdan at iptel. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I obviously don't understand what's going on that could possibly cause a <br></blockquote><blockquote type="cite">project fork but I think I can speak for a number of people as a <br></blockquote><blockquote type="cite">former commercial support customer, present user, source tinkerer, and <br></blockquote><blockquote type="cite">occasional consultant - when I say that this really does put a dark <br></blockquote><blockquote type="cite">cloud over ALL of the projects. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">To start splitting up the core developers -again- between projects, to <br></blockquote><blockquote type="cite">me, seems absolutely insane!<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This makes me extremely nervous going forward with either project and I <br></blockquote><blockquote type="cite">will be (as most will be) watching closely as this situation continues <br></blockquote><blockquote type="cite">to unfold and details emerge.<br></blockquote><br>-- <br>Alex Balashov<br>Evariste Systems<br>Web : <a href="http://www.evaristesys.com/">http://www.evaristesys.com/</a><br>Tel : (+1) (678) 954-0670<br>Direct : (+1) (678) 954-0671<br>Mobile : (+1) (706) 338-8599<br><br>_______________________________________________<br>Devel mailing list<br><a href="mailto:Devel@lists.kamailio.org">Devel@lists.kamailio.org</a><br>http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel<br></div></blockquote></div><br></div></div></div></body></html>