<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Consider this another vote for transparency.<div><br><div>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.</div><div>*But*, this, really, isn't necessarily about code, it is about how we get to the idea/nature of the 'main branch'</div><div>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? </div><div>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.</div><div>Instead, we made our decisions based on our particular interpretation of ALL of the above, and how it impacted us.</div><div><br></div><div>Now, we are being asked to do this all over again, except this time, we don't have much background!</div><div><br></div><div>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. </div><div>My recommendation is to put it all out there. Play the arguments out in public. Lets see where things go</div><div><br></div><div>cheers</div><div><br></div><div>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</div><div><div> <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; "><div><span class="Apple-style-span" style="font-family: Calibri; font-size: 15px; ">**********************************************<br>Mahesh Paolini-Subramanya (703) 386-1500 x9100<br>CTO <a href="mailto:mahesh@aptela.com" style="color: blue; text-decoration: underline; ">mahesh@aptela.com</a><br>Aptela, Inc. <span class="Apple-converted-space"> </span><a href="http://www.aptela.com/" style="color: blue; text-decoration: underline; ">http://www.aptela.com</a><br>"Aptela: How Business Answers The Call"<br>**********************************************</span></div></div></span></div></span></div></span> </div><br><div><div>On Aug 5, 2008, at 1:34 AM, Alex Balashov wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Bogdan,<br><br>Thank you for your reply.<br><br>You do raise a lot of good and constructive points. The overarching<br>theme of my response to them is that because I am not privy to the<br>interior of the project narrative, I do not have the knowledge to<br>critically evaluate or authenticate a great deal of what you say. If<br>the situation is as you suggest, then perhaps, indeed, you are doing a<br>good and necessary thing. I can only give the perspective of an outsider.<br><br>That said, I offer a few inline replies, from that very vantage point:<br><br>Bogdan-Andrei Iancu wrote:<br><br><blockquote type="cite">to be honest I preferred not to put details about the arguments as I did<br></blockquote><blockquote type="cite">want people to think I'm pointing burning fingers or I'm blaming<br></blockquote><blockquote type="cite">something or somebody. Of the arguments are to be found on the<br></blockquote><blockquote type="cite">discussions from the board list, but this is not public.<br></blockquote><br>I can certainly understand appreciate the need to avoid public<br>accusations or anything that could be construed as undermining anyone's<br>personal integrity.<br><br>The flip side to this conservative approach to publicising internal<br>affairs is that to the rest of us--those who are not project<br>luminaries--it leaves the situation looking like some absurd,<br>internecine feud replete with tribalism, factionalism, and egotism.<br><br>Of course, I think I--and the rest of us--know better than to suppose<br>that this is actually the case, and know from passive observation of<br>your erudition and epistolary character in the community that there are<br>very likely real and substantive reasons for this move. However, it is<br>not necessarily taken that way by some of our superiors and clients;<br>these are hard-nosed, often unsophisticated people who are not going to<br>be preoccupied with the sociological nuances and personal traits of this<br>particular open-source ecosystem.<br><br>So, managing the PR on these types of changes and finding that balance<br>can often be the hardest challenge of all. Personally, I'd favour a<br>little more transparency to this issue, even at the risk of some fingers<br>and being pointed and some feelings being hurt. I'd much rather the key<br>issues be diligently addressed in a public forum so we can all have a<br>chance to evaluate them on some level. Otherwise, we've got this<br>largely unsubstantiated (from outside POV) claim that the<br>OpenSER/Kamailio project branch is woefully mismanaged and stagnant, and<br>well, that's it.<br><br>Maybe I'm just missing something rather self-evident that every other<br>outside observer peripheral to the immediate development community<br>knows? If so, I am eager to be corrected.<br><br><blockquote type="cite">First of all, depends of how do you want to see the change: I see it as<br></blockquote><blockquote type="cite">a progress (actually this is the reason). None of the so far<br></blockquote><blockquote type="cite">values/investments are lost or degradated - they are carried on the next<br></blockquote><blockquote type="cite">versions/forms. It is like natural evolution - nothing disappears,<br></blockquote><blockquote type="cite">everything evolves.<br></blockquote><br>Well. I don't think anyone was supposing that OpenSIPS as a derivative<br>of Kamailio implies something qualitatively inferior or some sort of<br>downgrade. It does evolve from the current point, of course. The<br>drawbacks are all the other things that I pointed out that come with<br>factionalism and contending projects jockeying for the mantle of<br>superior merit, the resulting damage to the cohesion of the commercial<br>and OSS ecosystem in the vicinity, and the likely loss of economies of<br>scale (and increased lopsidedness) resulting from a reallocation of<br>competencies and focus on the development team.<br><br>If I read your general argument correctly from this and other threads,<br>it seems to be something like: "I was material to the fork of OpenSER<br>from SER a few years ago, and now I'm just doing it again - in order to<br>bring you the same great value I did pulling this last time and for<br>essentially the same reasons." This may not necessarily be inaccurate,<br>I'm just curious -- is that what you are essentially saying?<br><br><blockquote type="cite">there was no such system - in the last year, any person was component<br></blockquote><blockquote type="cite">enough to vote or take decisions in important technical matter. This is<br></blockquote><blockquote type="cite">not a methodology and the result was the quality degradation.<br></blockquote><br>Couldn't this problem have been solved by implementing a more rigid,<br>hierarchical distribution of authority that seems to be inevitably<br>required with projects that start out 'organically' and grow in<br>sophistication?<br><br>I realise that's hard to do with any group of people - especially a<br>group of people not accustomed to working that way. But it seems to me<br>like just about anything is better than a code fork.<br><br><blockquote type="cite">I agree and as I said before, taking the decision of crating OpenSIPS<br></blockquote><blockquote type="cite">was one of the most difficult I ever done. I 'm aware of the impact it<br></blockquote><blockquote type="cite">has, but I look into the future and my present actions wants to secure<br></blockquote><blockquote type="cite">the project (under whatever name) for the future. Form my perspective,<br></blockquote><blockquote type="cite">looking back over the last year, I do not see any evolution with OpenSER<br></blockquote><blockquote type="cite">- just take a look at release 1.2 and release 1.4 (future) and tell me<br></blockquote><blockquote type="cite">it is the same - going in the same direction is dead-end.<br></blockquote><br>As a casual reader of the changelogs and release notes, I was not<br>particularly moved to say that 1.2.x and 1.4.x resemble each other, but<br>because I do not dwell in the code nor participate in roadmapping I<br>cannot possibly say for sure. I would be eager to hear some of your<br>thoughts on why you feel the direction of the incumbent OpenSER was<br>stagnant. It seemed to me as a mere user that there was movement<br>forward on a variety of objectives.<br><br><blockquote type="cite"><blockquote type="cite">How do I know there won't be more code forks or internecine feuds? If<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I am a medium to large organisation with relatively high internal<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">technical capital, I may see an economic rationale in taking an<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">existing release and all maintenance of it in-house and *not*<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">releasing the changes back to the community (after all, too many<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"communities" to choose from, if nothing else). Or I may release it<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">as my own code fork later, once it's deviated enough. Both of these<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">damage and undermine the incipient ecosystem surrounding OpenSER.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">[bogdan]<br></blockquote><blockquote type="cite">for me this is not an option.<br></blockquote><br>I know. I meant if I were a user of OpenSER, I might wonder if it's<br>worth it to just snapshot the current release, take it in-house, and not<br>worry about what I perceive to be perennial madness and instability in<br>the realm of the official maintainers. Maybe I'd backport some of their<br>critical fixes but otherwise try to keep away from official releases.<br><br>By all accounts this is a bad approach from a management perspective,<br>but its appeal is inversely proportional to one's confidence in the<br>leadership and cohesion of the official project.<br><br><blockquote type="cite">exactly my point - there is no unity/consent/process/value in taken<br></blockquote><blockquote type="cite">decisions with OpenSER - see what happened with the 1.4 release. Do you<br></blockquote><blockquote type="cite">find it an example of reliability for a business?<br></blockquote><br>What, exactly, happened in the 1.4 release that should cast doubt upon<br>it from a reliability perspective? I ask because I genuinely do not know.<br><br><blockquote type="cite">I asked myself the same question and I debated the matter with other<br></blockquote><blockquote type="cite">people (I like to get as many opinions on some matters) - and the key<br></blockquote><blockquote type="cite">word is control - to organize the project in such a way to be<br></blockquote><blockquote type="cite">controllable. This does not mean to define rules, but to have a system<br></blockquote><blockquote type="cite">that will guarantee decision making based on value - being able to make<br></blockquote><blockquote type="cite">decisions, means you can control. It is like all the countries - there<br></blockquote><blockquote type="cite">is a form of control across each country (government, monarchy, etc)<br></blockquote><blockquote type="cite">that ensure the functionality of the country.<br></blockquote><br>And you do not feel that a revamping of the ground rules in the<br>incumbent project could have been achieved? In other words, couldn't<br>you have said to everyone: "Look, what we've got right now isn't<br>working [for the following reasons] and it must change, or I might have<br>to go make my own fork?"<br><br>Best,<br><br>-- Alex<br><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>Users mailing list<br><a href="mailto:Users@lists.kamailio.org">Users@lists.kamailio.org</a><br>http://lists.kamailio.org/cgi-bin/mailman/listinfo/users<br></div></blockquote></div><br></div></div></body></html>