There has been a bit more than a year since the “core team” of developers of SER split and a group working for Voice-Sistem forked the new OpenSER project. I was one of the most vocal against a fork without trying to reconcile the indifferences in public. I believe one of the problems was that SER was an open source project okey, but many things happened behind the scenes, and the community just had to follow in the wake of events, instead of the community driving development.

Since then, OpenSER has been quite successful in creating a more open community around development. With two main releases last year, OpenSER has driven a lot of new wanted functionality into the code and many new contributors have been added to the list. Also, many of the old contributors to SER, the “tinkerers”, who are also involved in standardization work etc, are contributors and users of both SER and OpenSER.

Meanwhile, SER developers have focused on some core, architectural work: redesigning the database model, rewrite of TLS support, timers, and TCP, built-in ser.cfg support for “selects” (selecting parts of the SIP message), better built-in support for variables (avpairs), a new, generic management interface, including an XMLRPC front-end. These new features are badly documented and SER has not been released after version 0.9.0.

This summary illustrates why I bother to get involved in SER and why I haven’t “jumped ship” to OpenSER: I am involved in development and management of a SIP service (who aren’t?!) and as we are not keen to drive SIP development on our production servers, we want a server that is robust and where we don’t have to do full release testing and quality assuarance too often. Still, I want bug fixes, security patches, as well as the ability to fix the code where we need to and where we have control.

Can’t you do that with OpenSER? Sure you can, but you have to invest quite some time in it. Some people still run SER 0.8.x for exactly the same reason we still run 0.9.4: If it works, don’t touch it. (but yes, OpenSER has some nice large-scale deployment features that SER doesn’t have)

Can you do that with SER? Well, not really right now. That’s why we will stay with 0.9.x for the time being. There are some very obvious things missing from the SER open source project. That’s where I will focus my efforts (comments and suggestions are welcome!)

It is obvious to me that at this point, the future well-being of SER is hinging on whether (and to which degree) the current SER developers will embrace a more public communication form, as well as more stringent, “best practice” rules for development (like roadmap, cut-off time for adding new features and “document the new features you add”)…

And who are the SER developers? Looking at the commit log the last year, an overwhelming number of commits come from addresses. Up to now that has meant former (now Tekelec) employees.

However, has been by no means similar to mySQL or JBoss. There has been no coherent strategy or corporate focus around the open source project. But as long as, it’s practically for the developers to communicate around SER as on an internal project.

By inviting (and me with it) to join more actively, the balance is shifting and with it comes new opinions, agendas, and hopefully the combined strengths of people with different background and priorities.

The know-how and network of companies and people who is the result of the original SIP Express Router software project at FOKUS Fraunhofer, Germany, is impressive, but not visible to the casual subscriber to serusers@iptelorg/ (and I must admit, I still discover things I didn’t know).

However, collaborating without having a physical presence (as open source most often is) requires some “glue” in the forms of communciation channels and some basic rules. Thus, I look forward to helping out on the non-coding (glue) side of the open-source project and work with all (SER/SERWeb/SEMS) contributors to extend the project’s reach and usability for the community!

Stay tuned!

Leave a Reply

Post Navigation