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 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.

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. 

This is a set of guidelines for how sipXecs projects should choose filesystem names and layouts in the installed files and within the development tree. Deviating from these guidelines is not automatically a bug - there may be good reasons for doing so, but if possible they should be followed, and when not followed the reasons should be clear and the differences well documented..

These recommendations are based, at least roughly, on the Filesystem Hierarchy Standard. The intent is that the evolution of these conventions be toward closer conformance to that standard (and for the actual layout of files in the sipXecs project to evolve toward these conventions).