It was acknowledged that the components with the highest risk of conflict are the parts having the biggest impact upon radical changes, those are: the core and TM (further referred as common layer). Therefore we aim to turn them in a framework that allows independent extension development via APIs, callbacks and modules.

The core must stay simple and as small as possible, so it will provide:

• SIP parser
• SIP transport layer: UDP, TCP, TLS and SCTP
• Memory manager
• Locking system
• DNS management
• Configuration file parser and interpreter
• Hooks and APIs as interfaces to modules
• DB API
• code shared by modules has to be integrated as library, living under lib/ directory in the source tree

TM (transaction management) module shall preserve functionalities present in both projects.

A lot of code from core will be moved as library or module because it is purely just code sharing between modules or the functionality does not fit the purpose of the core.

There will be a maintainer-per-component collaboration model. One component may have one or many main maintainers and several other assistants. New contributions to a component should get the approval of the maintainer in a reasonable period of time. Resolution of conflict shall be given by rough consensus of the developers, supervised by the management teams of the two projects.

Licensing conflicts shall follow the rules from Licensing page.

Major changes inside the common layer have to be presented and discussed on developers mailing list. Bug changes and documentation improvements can be done independently.

Individuals matter

It is important to recognize that software design and writing is of intellectual and/or artistic nature. This means that the actual contributions are to be recognized as originating from their respective individual authors and notion of individual authors should be prevailing in the x-SER organism, in the way how the organism works, how resolutions are found, and how merits are acknowledged.