Hi all,
Bogdan-Andrei Iancu prepared this fork from Kamailio (formerly known as OpenSER) since July. This was done secretly, we were not aware of this. We've all done a great amount of work to resolve the existing trademark issues and create a better organisational backing for the project. Many contributors tried hard to improve the quality of the code base, a big number of bug and documentation fixes were done, doxygen code documentation was greatly extended.
Because of the project renaming our release schedule needed some adaptions. We discussed this in the last week on the developer list and found a new release date for Kamailio [1]. Version 1.4.0 will be released on the thursday, the 7. august.
Cheers,
Henning Westerholt
[1] http://lists.kamailio.org/pipermail/devel/2008-July/014926.html
Hi Henning,
working in open source means somebody is joining and contributing to a project as a free will option. I'm doing it because I have whatever reasons to do it. But does not mean I am forced to work on it or I have some obligation to do it. Also, In the mean while I'm free to work with whatever project I like. If I'm not longer interested in a project, I free to walk away (as free as I joined). This is the natural way of things in open source - whatever if you are happy with it or not.
Before making hard statements, please review what open source means. And also do not forget I am one of the co-founders of the OpenSER project and I invested really a lot of work and time in it. And what I doing, I'm doing just because I want to be able to carry on this work effort.
Thanks and regards, Bogdan
Henning Westerholt wrote:
Hi all,
Bogdan-Andrei Iancu prepared this fork from Kamailio (formerly known as OpenSER) since July. This was done secretly, we were not aware of this. We've all done a great amount of work to resolve the existing trademark issues and create a better organisational backing for the project. Many contributors tried hard to improve the quality of the code base, a big number of bug and documentation fixes were done, doxygen code documentation was greatly extended.
Because of the project renaming our release schedule needed some adaptions. We discussed this in the last week on the developer list and found a new release date for Kamailio [1]. Version 1.4.0 will be released on the thursday, the 7. august.
Cheers,
Henning Westerholt
[1] http://lists.kamailio.org/pipermail/devel/2008-July/014926.html
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
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.
- Darren
_____________________________
dmsessions@gmail.com http://www.darrensessions.com http://www.linkedin.com/in/dsessions _____________________________
On Aug 4, 2008, at 3:53 AM, Henning Westerholt wrote:
Hi all,
Bogdan-Andrei Iancu prepared this fork from Kamailio (formerly known as OpenSER) since July. This was done secretly, we were not aware of this. We've all done a great amount of work to resolve the existing trademark issues and create a better organisational backing for the project. Many contributors tried hard to improve the quality of the code base, a big number of bug and documentation fixes were done, doxygen code documentation was greatly extended.
Because of the project renaming our release schedule needed some adaptions. We discussed this in the last week on the developer list and found a new release date for Kamailio [1]. Version 1.4.0 will be released on the thursday, the 7. august.
Cheers,
Henning Westerholt
[1] http://lists.kamailio.org/pipermail/devel/2008-July/014926.html
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
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.
I couldn't have said it better myself.
Well done.
_____________________________
dmsessions@gmail.com http://www.darrensessions.com http://www.linkedin.com/in/dsessions _____________________________
On Aug 4, 2008, at 4:56 PM, Alex Balashov 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:
- The project will be around next year, more or less in its present
state.
- 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.
- 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.
- 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
Devel mailing list Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
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:
The project will be around next year, more or less in its present state.
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.
- 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.
- 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
Users mailing list Users@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:
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:
The project will be around next year, more or less in its present state.
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.
- 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.
- 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
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
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:
The project will be around next year, more or less in its present state.
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.
- 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.
- 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
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@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:
- 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:
- The project will be around next year, more or less in its present
state.
- 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.
- 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.
- 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
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Andreas,
The difference does not come only from one extra or minus feature - this is a bit of a superficial approach of the issues. As mentioned in the OpenSIPS announcement email, the reasons were more deeper and concerning than a feature. I do not want to copy'n'paste the list of problems identified with current OpenSER, so I will just point back to it. Please go over the reasons and you will note that the feature-rich is not part of it.
As said, it came to choosing out of two bad options - however bad it sounds for you a new project, at least I want to have the guarantee of progress and stability for the future. It is better than a dead-end. Again, I look into the future for taking my present actions.
Regards, Bogdan
Andreas Granig wrote:
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:
- 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:
- The project will be around next year, more or less in its
present state.
- 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.
- 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.
- 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
See my other email. I don't want to discuss these things in public.
Bogdan-Andrei Iancu wrote:
Andreas,
The difference does not come only from one extra or minus feature - this is a bit of a superficial approach of the issues. As mentioned in the OpenSIPS announcement email, the reasons were more deeper and concerning than a feature. I do not want to copy'n'paste the list of problems identified with current OpenSER, so I will just point back to it. Please go over the reasons and you will note that the feature-rich is not part of it.
As said, it came to choosing out of two bad options - however bad it sounds for you a new project, at least I want to have the guarantee of progress and stability for the future. It is better than a dead-end. Again, I look into the future for taking my present actions.
Regards, Bogdan
Andreas Granig wrote:
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:
- 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:
- The project will be around next year, more or less in its
present state.
- 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.
- 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.
- 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
On Tuesday 05 August 2008, Bogdan-Andrei Iancu wrote:
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:
- 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.
Hi Bogdan,
we're using 1.3 and are happy, and i guess this is also true for most of the other users. So please stay with the truth here. 1.3.0 was used from more users then the past releases, so its naturally that more bugs are found.
Cheers,
Henning
Hi Henning,
general statements (covering everybody) are difficult to support and guessing such matters is dangerous.
my opinion was strictly from my personal experience. Also based on the feedback from the list - the widely used version is still 1.2, after more than half of year of 1.3...
These are facts and not guessing
Regards, Bogdan
Henning Westerholt wrote:
On Tuesday 05 August 2008, Bogdan-Andrei Iancu wrote:
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:
- 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.
Hi Bogdan,
we're using 1.3 and are happy, and i guess this is also true for most of the other users. So please stay with the truth here. 1.3.0 was used from more users then the past releases, so its naturally that more bugs are found.
Cheers,
Henning
Bogdan-Andrei Iancu writes:
From business point of view, what do you prefer:
- 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)
bogdan,
were these complains made known to other developers? i don't remember seeing them. this is, in fact, the first time i read about these "complains/bad experiences".
- make a change and make them happy.
i still don't understand why you could not make them happy in OpenSER project. how has version 1.4 of OpenSIPS answered to these complains, which would have been impossible to do in OpenSER project?
-- juha
Hi Alex,
Thanks for the comprehensive email - even if it took me some time to read it, I have to admit this is a good analysis that pin points some of the problems that lead to the new project.
As it is quite impossible to comment is single chunk, I made some inline comments.
Best regards, Bogdan
Alex Balashov 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.
[bogdan] 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.
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.
[bogdan] thank you.
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.
[bogdan] 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.
Generally, when one chooses to invest in a rather serious and evolving open-source solution like OpenSER, one expects the following things:
- The project will be around next year, more or less in its present state.
[bogdan] actually this was one of the main reasons of the new OpenSIPS project. Unproper management in OpenSER was really affecting its future existence - the trademark problem was known since March with a deadline in September; I personally worked out the arrangement to have 6 months to do the transitions; but there was not management strength to do it and as a result 5 months were wasted and with ~ one month before the deadline a new name was selected; even so , no clear transition actions were taken (like SVN migration, website migration), etc....
- 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.
[bogdan] 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.
The sources of that direction and influence must be relatively cohesive and clearly identifiable.
- 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.
[bogdan] again, there is no such system - unfortunately there is only a large pool of people with no relation between. Such a system cannot offer unity and clearness.
- 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.
[bogdan] perfectly agreed.
So far, coming from the requirements direction, you pin pointed some aspects I found as problems in current OpenSER.
...
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.
[bogdan] 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.
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.
[bogdan] Indeed this is a tough question. The same question was raise when OpenSER forked form SER and things clarified in time. Even after 3 yeas, you will be surprise to still see the similarities between OpenSER and SER.
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.
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.
[bogdan] 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?
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.
[bogdan] 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.
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.
[bogdan] at least we have a consent about "enjoy, evolve and innovate".
One again, thank you for your email - it was a real pleasure to go thorough it.
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.
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
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@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:
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.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Alex Balashov writes:
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?"
alex,
it would have been great if bogdan had said that. i would certainly had agreed to the new decision making system whatever it would had been if it had kept bogdan happy. the problem was that bogdan never expressed a need to make the changes he now writes about.
my conclusion of this is that bogdan didn't really want to change OpenSER project for better, but wanted to start his own show.
-- juha
As a lurker on the list, and one who glances at the devel list but never posts to it, I'm shocked at the fact that someone could be on the board of OpenSER and not see this coming. I have no inside information, and yet over a month ago I said to myself "Self I wonder how long it will be before something substantial changes". Anyone, who didn't see something like this or the inverse (change within the openSER/Kamailio project) happening and does any more than a casual following, needs to get back into the clue line.
Unfortunately the timing is just terrible (name change and all), but I'm not suggesting that that should have effected the timing, it is just a fact. Not in any small part to the fact of droves of people who can't seem to figure out what is going on.
I think the only question that needs to be asked is which project has the framework in place, or plans to put in place, that will deliver you the goals you desire. Once you make that decision then get behind the project don't worry about the other one, feel free to contribute to both, and put the politics in a nice little box.
Alex I'm pretty sure, after only a slight interaction with bogdan, you will not get him to lay out issues to you which in turn point directly to people (at least in this forum). There is really nothing to be gained from it for him, and just risks a petty all out flame war which without careful reading and research only clouds the issue for the casual reader.
Again after only a casual reading of the devel list I've become a little concerned with the direction of openSER, and knew that change or crash was inevitable. Based on my lack of history with the project I didn't see that coming from bogdan, but I applaud his resolve in this. A fork of this nature is not something that is done lightly, at least not by a person with any intelligence and social skills. For anyone to assume it was the result of something petty, or a single feature are implying something very negative about bogdan, or they themselves are a few sandwiches short of a picnic. (I guess please say what you mean, don't leave us guessing if you are dumb or if you think bogdan is dumb)
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'm also going to let the pendulum swing the other way bogdan. I'm not sure I get the impression that you have done the best that you, or someone in your position could do to effect change of the project within. You are a great guy, and I respect your desire just to get things done and not argue about it, but I do think, given your past involvement the mutual respect you have from the community, that you could have done more.
Now before anyone thinks they need to rebuff any of those points I'll just say that all this has been said from a perspective of very little knowledge and information.(probably contributed by the lack of tact I mentioned earlier) If you don't agree just simple reply to this point with a "ya your way off there man, but thanks for something to read"
Cheers
Miles Scruggs Wide Ideas | Operations | miles.scruggs@wideideas.com
On Tuesday 05 August 2008, Miles Scruggs wrote:
[..] 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) [..]
Hi Miles,
i've tried hard to stay neutral in this local_route matter, but at some point i get really tired of this whole war, and just wanted this to stop. I thought that endless fighting are in the end more harmfull then having a decision.
And with the actual issue, the fork.. Well, if one lead developer does a fork, i find it justified to remove admin/ root access from certain resources. I think this fork damages both projects a lot, and was not a nice thing to do. It also misses a certain level of tact. If Bogdan declares that he still want to support the kamailio project, then this will be restored imediatly. I also discussed this with Daniel before the change, so it was not done solely from myself.
Of course there is a certain ammount of imformation you're not aware of, and this whole fork also not leave me cold, as i/ we depend a lot on OpenSER. Sure, i make errors, every day. Show me one who could say he works flawless. All i can do is try, learn from my errors and improve.
Thanks for the reminder,
Henning
Bogdan-Andrei Iancu writes:
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,
again, i don't see any reason that would have prevented you from making whatever changes in the direction of OpenSER project. the board certainly didn't prevent that and there was never any discussion about a need to change the "direction". i personally would have been more that willing (and still am) to resign from the board if i had known that i was blocking the progress you had secretly in your mind.
-- juha
Alex Balashov writes:
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.
alex,
i am kamailio developer and member of kamailio board and i have not heard of any plans of opensips fork before yesterday. bogdan, who was the initiator of OpenSER project, has not given any "back-room" hint that he was working on a new fork. sure he has had right to do so, but i consider it very strange that he did not express his intentions earlier, but prepared the new fork in secrecy.
now that we know that bogdan's interests are elsewhere, rest of OpenSER (now Kamailio) developers can try to take over bodgan's interest areas.
-- juha
-
Alex Balashov -
Andreas Granig -
Bogdan-Andrei Iancu -
Darren Sessions -
Henning Westerholt -
jh＠tutpro.com -
Mahesh Paolini-Subramanya -
Mark Sayer -
Miles Scruggs