[Serusers] Open letter to the SER Community

Greger V. Teigre greger at teigre.com
Wed Jun 15 10:19:58 CEST 2005


Dear Core Developers, Contributors, and Users,

I am sure there are many users of SER who now ask the question: What the h... is going and how will this impact SER and how I use SER? I will try to contribute with my interpretation of all this, hopefully to the benefit of those less familiar with SER. I ask you to bare with me, this email is a bit longer than the norm...

    In open source development, everybody is equal and on the surface have the same motives, but in cases like this, it's useful to know where people are coming from.  I, myself, work for a company that uses SER as a component in one of its products.  
    My interests in SER are twofold: 
1. The more features and the better open source SER gets, the better for my company 
2. The more carrier-grade features (stability, robustness, and scalability), the better

    When I first started using SER, I realised that #1 was held down by a very high threshold for first use + a sluggishness to include external contributions into the project.  I also saw that there was a lack of some carrier-grade features (like load balancing, monitoring, etc).
    So, this caused me to participate in the Getting Started documentation project, as well as to set up http://onsip.org to lower the getting started threshold and facilitate access to information relevant for carrier-grade setups. And I also volunteered to be the administrator of the new experimental directory for SER modules.

    Iptelorg.com and Voice System have both established businesses with SER as a core of their business model. Before an open source project gets the momentum (in terms of development community), a company with commercial interests in the open source project is crucial to the development of the project.  Once the project gets a life on its own, there will be conflicting interests between the commercial company and the open source project.  (Fraunhofer and then) Iptelorg.com has been this company for SER.  
    Iptelorg.com's business model has included building other components/extending SER and offer this as a carrier-grade platform.  Of course, they don't want to submit their commercial code to the public CVS, it's the basis for their revenues. However, when the community gets going, their commercial components start popping up with alternative contributions (like TLS). What to do? The reactions can be: 
1. Ignore it 
2. Submit own commercial code when there is no other choice 
3. Pro-actively push commercial code to the open-source project and continously improve own commercial code

    Voice System has a slightly different business model, but also they have their own commercial components and I believe they focus more on enterprises.  Do they contribute their commercial code to OpenSER? Of course not, they have exactly the same problems as iptelorg.com, but they need more features (to enterprises), while iptelorg.com needs stability (to carriers).

    So, my interpretation of the OpenSER announcement:  It's a branch with a different release philosophy, release sooner, bug-fix after release and bring in as much contributions as possible. Daniel-Constantin Mierla states "the SER code maintained by us will go further [...] The cvs was created just to ease the maintainance."
    However, the communication, both in the announcement, as well as on the website is another with a language clearly indicating that this is *something different from SER at iptel.org*.  To the casual user, this means choosing between two projects and also choosing where to contribute. 

(To me, this means that allthough I would love to get new functionality faster, I cannot possibly use the OpenSER project due to my need for testing and stability.)

    To the iptelorg.com and Voice System guys:  Even though SER originates in your Fraunhofer pet project, SER is no longer yours.  Close to 700 people have registered at ONsip.org.  There is a large and thriving community of SER users! This gives you, the core developers, a responsibility you didn't have before and you must act accordingly.

    Jiri and Bogdan-Andrei:  I plead you to talk together and resolve this to the benefit of the *community*, not your individual companies. There is no question that the openser.org website brings additional value to the beginner user (documentation + functionality) and that Jan Janak's release philosophy has been a benefit to those of us who rely on stability.  Your indifferences MUST be possible to resolve within the context of the community. Jiri: Be open to how contributions and releases can be handled without sacrificing stability.  SER needs contributions and Voice System has a point there!  Bogdan-Andrei: Try to figure out how you can resolve this without splitting the community in two projects. You really need the other iptel.org contributors in making your fresh releases stable as fast as possible!

    If this only boils down to different release philosophies and how contributions shall be taken into SER, I have the following suggestions:
- Let loose the Voice System guys on releasing new SER versions with new functionality, don't keep functionality in CVS HEAD too long
- However, do as ex. OpenLDAP and state CLEARLY which version is considered stable, make sure that source packages are available for all versions
- If absolutely necessary, keep two sites: iptel.org and openser.org, but please don't communicate that these are two different projects. If the code base is the same, they are not!  Ex. have one site for stable releases and one for newer releases.

    
    I will be happy to mediate in the talks if necessary. After all, I'm Norwegian and conflict mediation is one of the few things Norwegians are known for... :-)

Best regards,
Greger
g-)

PS! This open letter has also been posted to http://ONsip.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050615/8ac32662/attachment.htm>


More information about the sr-users mailing list