Participation is possible on many different levels. If you find a bug report it to our Jira bug tracking system. Enhancement requests are best discussed on the sipX users list first. Would like to participate in our documentation effort on the sipX Wiki? 

Localization is in process and we are looking for help to translate the user interface as well as localize the voicemail and auto-attendant system. The German translation is well on its way; Polish and French are following. Both the user interface, dial plan, and voice prompts are adapted using plugins.

Support for plug & play management for additional phones & gateways is easy to build based on a plugin framework that auto-generates most of the required user interface in sipXconfig. You don't have to be a coder.

What do I really need to do to get my contributed code accepted into the project?   We don't have complicated rules and you do not need to sign away your rights to do so. Essentially you need to comply with our coding practices, in particular you need to accompany your code with an appropriate unit test. We also would like to know who you are so that we can keep track of who contributed what. Therefore we ask you to execute an online contributor agreement. You share the copyright of your code and give SIPfoundry the right to distribute it under the project's open source license. That's it. 

The sipXecs project team chose the L-GPL license for all its code. We did this explicitly to allow people to link against our libraries, including the sipXecs SIP stack (sipXportlib, sipXtacklib), the media library (sipXmediaLib), and the SIP user agent SDK (sipXtapi). We also chose the L-GPL license because we insist in a reciprocal license that allows us to form a community where improvements and bug fixes come back to the project. The more immediate these things flow back, the more active the project is and the better the interaction becomes.

Whenever you distribute our code the terms of the L-GPL license apply and we expect you to contribute back all changes you implemented. "Distribute" in this case and as defined in the L-GPL license, includes all forms of distribution. In particular it also includes cases where you keep title to servers placed on customer premises in a semi-hosted model or any other distribution of code where commercial benefit is derived from our software.

I f you are a software engineer asked to work on a project that involves our code and you are told not to contribute back, don't work on it. It is not ethical and also illegal. It will not look good on your resume.

Rules on how to contribute: Anyone is welcome to contribute as you would expect with an open source effort. In order to protect all contributors and in an effort to track code provenance (i.e. where does contributed code actually come from), we introduced a contributor agreement that establishes a shard copyright. All contributors will have to electronically file such a contributor agreement before we accept any code. Create an account on SIPfoundry, login and then go to the Developers section. In the right navigation there will be a link that takes you to the sipXecs or sipXtapi contributor agreement page.

All SIPfoundry projects allow anonymous read-only access; the source code repositories and issue trackers are available without creating any account on the server.

In order to have write access to these systems, you do need an account. At present, accounts for the issue tracker and source control systems are maintained separately. You can create an account by yourself on the SIPfoundry site and in our Jira issue tracking system. In order to get an account to edit our Wiki please post to the sipx-dev mailing list and request an account.

Initially new contributors are expected to submit patches and therefore you will not need a subversion account. Submit a patch by doing an "svn diff" against current mainline and attach the resulting patch to an issue in our tracker. We will review it and get it committed. 

The sipXecs project process is pretty straight forward and easy. It's main focus is four things: a) Make sure we maintain high development velocity, b) Enforce quality of whatever we release where all contributions have to follow our guidelines for unit tests, c) Continue to use modern tools, and d) Make sure we all enjoy what we are doing and can work together. 

Click on "READ MORE" below to learn more about the process used by the sipXecs projects, and how that process is reflected in our two major project tools: The subversion source control system and the Jira issue tracker.

It is always a good idea to discuss changes you want to make or suggestions you have on the sipx-dev mailing list before starting your own implementation. Many improvement requests and ideas are already logged in the Jira tracker, so go look and do a search.