FreePBX is a true Open Source development effort. Providing GNU GPL v2, GPL v3 or AGPL v3.0 (or equivalent) licensing is all that is required to make a project Open Source. However, obtaining true community involvement is what makes a good project become great. This means transparent access to the project's activities and a development community with access to the project that is not limited to a sponsoring organization. These values are what fuel a really successful project.
The FreePBX Project uses the Atlassian JIRA (Issue Tracker) and Atlassian Bitbucket (Version Control System) applications in order to tightly integrate the GIT Activity, Ticket system and Development Wiki. We have integrated this system with our main site (freepbx.org) so that you are able to sign on to both sites when you create an account (https://www.freepbx.org/user/register). Without an account, you will not be able to submit tickets but you will still have access to all development tools and viewing privileges
To participate in the FreePBX project you must agree and submit a filled out copy of our code submission agreement: http://literature.schmoozecom.com/EUA/CodeSubmissionsAgreement.pdf (For more information on this Please see our FAQ). This is only required to submit code back to the FreePBX project
Accessing The source
Please take a look at our development documentation for setting up a development environment here: Setting Up a Development Environment
Code quality is very important when it comes to things such as security, maintainability. PHP tends to get a bad rap because it allows bad behavior. Just because you can do something doesn't make it the right thing. The following 3rd party links discuss quality coding practices. These guidelines can help both new and seasoned programmers when developing for FreePBX.
Browsing The Source
You can take a quick look at our source code:
- Core Modules
- Contributed Modules (Non-core)
- FreePBX Libraries (FreePBX Components/libraries or generators)
Community Design and Development
In addition to taking input and feedback from the community at large, FreePBX tries to keep its design and road map plans transparent and accessible. This means ideas are discussed in the Forum, in the Wiki and in the #freepbx-dev IRC channel. Live interaction can also be extremely beneficial, so many phone conversations do take place (after all we are all about phones...). We try hard to document the content of these conversations into the Wiki to further benefit from community review and input.
Project roadmaps are provided on this wiki under: Roadmap
The easiest way to get started is to simply take a look at our bug tracker. We have over Getting issues... currently open for FreePBX alone.
The wiki lists many ways to get involved. If you want to develop for FreePBX a good way to start is to contact one of the active developers. You can message them on https://community.freepbx.org them, or you can get onto the Development IRC channel #freepbx-dev on Freenode and make contact.
If you'd like to jump in and get your hands dirty by creating your own FreePBX module you can do so by utilizing our FreePBX Module Generator.
We also have a couple of php example modules you might find of interest.
|FreePBX Hello World Module||12 (For 13+ use below)||https://github.com/jfinstrom/FreePBX-HelloWorld|
|FreePBX Hello World Module||13+||https://github.com/jfinstrom/helloworld|
|FreePBX Hello World for UCP||13 (For 14+ use below)||https://github.com/jfinstrom/ucphelloworld|
|FreePBX Hello World for UCP||14+||https://git.freepbx.org/projects/FL/repos/freepbx-hello-world-ucp-14/browse|
The FreePBX team's Bitbucket allows developers who wish to assist in bug fixes and improvements to fork projects into their personal account on the FreePBX team's Bitbucket server. To sign up for an account on the FreePBX team's Bitbucket server, register for an account here.
Once registered, a developer can fork any of the sub modules found on the FreePBX team's BitBucket at https://git.freepbx.org/projects/FREEPBX or https://git.freepbx.org/projects/FPBXCN, by selecting a repository, then clicking the Create Fork option.
After cloning the repo on your dev environment, it might have checked out the master branch. Switch to the release branch you'd like to submit the fix for. For FPBX15, it would be 'git checkout release/15.0', then a 'git pull' for good measure.
From there, you can create a new branch. For this situation, it's recommended to have a branch name with "bugfix/ticketId", for example "git checkout -b bugfix/FREEPBX-21691".
Also, please make sure to modify your repository's permissions on your forked project so that the 'freepbx-dev' team has at least read permissions. This is so we can checkout your code and makes the code review process easier on us.
Once you have your code tested and working on your forked project, you can submit a pull request in the FreePBX team's BitBucket server after you have fully completed our CSA on file. After pushing your commit to the new branch, you should see a response with a link for creating the PR. When creating the PR, you'll want to make sure your fork and branch are selected as the source, and the destination is set to a release branch such as release/15.0.
NOTE: All bug fixes and feature requests should relate to a ticket at https://issues.freepbx.org. If you have written a module you would like included in our contributed repo (https://git.freepbx.org/projects/FPBXCN) simply create a repo for your module in the FreePBX team's Bitbucket server and then open a ticket in the bug tracker to make us aware of it and we can mirror your repo. Remember all code submissions through the bug tracker or through git require a CSA on file. If you are new to GIT please see our wiki for a general overview.
We have also created a tag in our issue tracker called "patches welcome" for items that seem like solid ideas but we do not have official resources for. A good place to get your feet wet may be in working on one of these issues. Our "Patched Welcome" issues are listed below.
Documentation, Documentation, Documentation
The more quality documentation that exists in a project, the more useful and valuable it becomes. This includes creating original content whether it be How-To Guides, Module Documentation or other forms. It also includes editing existing documentation for correctness and completeness and helping to get the site into a more standardized and organized form. If you have expertise in this area and would like to help drive it, please contact us.
Development Documentation is critical as well. If you are a developer, you probably know that this can be a weak point for many. There is a lot of information on the Development Wiki but it is also a priority of ours to put some effort into cleaning and updating the documentation, organizing it and augmenting it to make it easier for new developers to get involved.
- External FreePBX Development
- FreePBX Chown Conf
- FreePBX Internals
- FreePBX Menu Conf
- Packaging Modules
- Translating FreePBX
- UCP Development
- Unit Testing
- Using GIT
- vscode snippets
A Note about Third Party Module Development
New module submissions are a regularly occurring event and you will find many modules that have been submitted as tarballs in the Ticket system that are not available in the online system. Why is that?
The FreePBX project is designed as a Framework that can easily accommodate new modules and for that reason, new modules get written and submitted. This does not mean that we put every module that comes along into the project. As the project has matured and stabilized, we are putting a lot more thought into the architecting of the FreePBX as it continues to evolve and mature into a world class product. In order to do that, we need to carefully evaluate what officially enters the system since adopting a module has many implications. We try very hard once something becomes part of the project to take on the commitment of maintaining and supporting it and making sure that future upgrades of the project will continue to work with the Modules that are part of it. If you are thinking about writing a module that you would like to be part of the core project, you should talk with one of the active developers in advance.
This does not mean that the other modules are less valuable or inferior in any way, if we don't adopt them. If you have written a module you would like included in our contributed repo simply create a repo for your module on github. Open a ticket in the bug tracker to make us aware of it and we can mirror your repo. Remember all code submissions through the bug tracker or through git require a CSA on file. If you are new to git please see our wiki for a general overview