We now know that both projects continued separately. What does it mean to us, the users? First of all, you need to decide whether to go for SER or OpenSER. Deciding is based on knowledge, so first a few words about the organization of SER and OpenSER developments.
SERs source code is hosted in a CVS at cvs.berlios.de. The versioning of SER has confused many. The reason is that the versioning is based on CVS terminology. For example, the latest stable release of SER is 0.9.3, but in the CVS, this stable release has the branch name rel_0_9_0. A branch can be named anything, for example rel_stable_to_be. rel_0_9_0 means loosely "the branch that will be the next stable releasewith version 0.9.something". A less confusing branch name would probably berel_0_9_x.
Once a branch has been created it has a life on its own and the developers can continue to develop the main code branch, also called the HEAD or the trunk. This is important to know, because once a new branch has been created and is destined to become a stable release, no new features will be added, only bugs will be fixed. Any new features are added to the trunk. Currently, the trunk is also referred to as 0.10.x or 0.10.0 because the next main release will be 0.10.something.
This means that even though you have downloaded a package of 0.9.3, the rel_0_9_0 branch in the CVS may later be updated, but only with bug fixes. In order to get these bug fixes, you either have to download the code from the CVS repository or you have to wait until a new updated package is created.
The source package called 0.9.3 at http://ONsip.org/ is a package with the source files from the stable branch rel_0_9_0 at the date specified in the description field and in the README.ONSIP file. You can run the update_from_cvs script to get the latest changes from CVS.We also update the package once in a while where this update has been done.
If you are adventurous, you can download the trunk/head, but it can at times be impossible to compile, because developers add new functionality that may break things they didn't foresee (even though it compiled on their machine, other things may influence compilation). Also, added functionality may break other functionality, so even though SER compiles, you may end up with problems with your ser.cfg because the developer haven't tested exactly that scenario. These problems should be reported at http://bugs.sip-router.org
When Voice System announced OpenSER, they took SER 0.9.3, added (backported) many of the features found in the SER CVS trunk (0.10.x), and added additional features not found in SER CVS trunk. They called this release OpenSER 0.9.4, which was the first OpenSER release. Since then, they have released OpenSER 0.9.5.
Currently, OpenSER can use SER configuration files (ser.cfg), but not the other way around. This is because OpenSER have added new commands and in some cases new syntax. Now, that sounds good. The safe bet would be to go for OpenSER, right? Well, for now. The development and maintenance of SER and OpenSER can become complex. First of all, the developers of OpenSER have stated that they will continue to contribute to the SER development in addition to OpenSER. We still dont know what this means. Will all the OpenSER features be introduced in SERs CVS? This means a lot of double work and other SER developers may have introduced features that are not compatible with OpenSERs.
Also, it is highly likely that features found in OpenSER will find its way into SER. SERs developers may for some technical reason decide to implement the feature in a different way. This means that the ser.cfg used for SER can no longer be used by OpenSER.
Already, OpenSER has a different database format than SER. This means that migrating user data from one to another can be a problematic task. These differences are likely to increase.
And finally, it seems that most of the developments that are done by SER developers are ported to OpenSER by the OpenSER developers. At the time of writing this, OpenSER has six (6) registered developers, while SER has 25. Only time will show how interoperable the two projects will be.
As a side note: One of the authors of this document is the maintainer of a relatively new SER module called experimental. This CVS module is currently only available in the trunk/HEAD and contains SER modules and code that has not yet found its way into the CVS. The modules can thus be tried out and feedback gathered before they are introduced into the CVS trunk. The current modules are TLS support, SIP Path extension, and an Oracle database back-end.