If you want CiviCRM to do something that it doesn't currently do, and you are sure that it doesn't do it, one approach is to fund the CiviCRM team to do this development.
If you choose to contract CiviCRM to develop functionality, your project will need to fit within some constraints:
- Your project will have to be of general use to the community, or at least a significant portion of it.*
- It will have to fit within the CiviCRM release cycle. The release cycle is decided based on the size of the consulting and community projects.
- the CiviCRM core team focuses on extending CiviCRM, not completely building your website / database. This means if you need a complete solution, you may need to work with a solutions provider in addition that will handle your project as a whole.
A typical approach is that you'll have a wide ranging discussion with lots of people in the community to make sure the functionality really is missing, create a specification that is of general use to the community and get feedback on this specification. Then get an idea from the core team about how many hours it would have and what the timeframe will be. The timeframe depends on the size of the project and what stage CiviCRM is at in it's release cycle.
*Keep in mind that many projects that at first seem very specific to your needs can actually be turned into something that is useful to others in the community. By doing a little homework and finding other CiviCRM users that may have similar needs (the forums are a great place to do this), you can not only figure out how to better design your project so that it is useful to others, but you'll also gain allies in getting it adopted into CiviCRM and to help you maintain it down the road. See the "What's in it for you" section below for more on this. Lobo noted in early 2012 that 80% or more of code written should be something that other folks can use and extend.
Examples of sponsored projects
- CiviCase has been sponsored by the Physician Health Program of British Columbia
- CiviCRM Standalone, multi site and scalability was sponsored by US Public Interest Research Group
- CiviCRM Profiles and a lot of early core functionality was sponsored by Quest Scholars
- Contact SubTypes for 3.1 is sponsored by Alpha International
- Multisite support was also sponsored by Greater Manchester Centre for Voluntary Organisation
The CiviCRM release cycle
There are two types of release for CiviCRM
- Major releases, for example 1.0, 2.0 and 3.0.
- Minor releases, for example 1.7, 1,8 and 1.9.
- Point releases, for example, 4.4.6, 4.4.7.
Every new release (major or minor) of CiviCRM has new functionality. For example, the move from 3.0 to 3.1 introduced the concept of contact sub-types. As of 2014, point releases include security and bug fixes but not new functionality.
New functionality is developed by the community in a place called TRUNK. After a certain amount of work has been carried out, an early release it released called an alpha release (here's a blog post of an alpha release to give you an idea of what that means http://civicrm.org/node/663). The first alpha release marks the start of a testing period. Once the version is considered feature complete, there follows a series of beta releases that are focussed on identifying and fixing issues. Alpha and beta versions look something like this:
If all goes smoothly the beta candidates are followed by a stable version:
The process of going from the first alpha to the stable version typically takes 3 months.
Your project and the CiviCRM release cycle
Smaller projects should be able to fit within one release cycle. Larger projects are likely to be spread over two or more release cycles.
To get your functionality into the next release, you'll have to have a project plan agreed with the core team before the end of the testing period of the previous release.
Larger contributions affecting dozens or hundreds of files cannot be merged into trunk late in the release cycle. To do so would compromise the amount of testing the release receives and thus the number of bugs missed and the stability of the final software release.
Ideally projects of this size should be merged during the development portion of the release cycle, and in no case after alpha1 or alpha2. Smaller code contributions affecting less than 20 files may be accepted later in the alpha release cycle. Do not expect to merge new functionality into trunk during the beta release cycle.
Make sure your project plan leaves slack between when you expect your testing before merge to be completed and the date when the core team expects the first alpha to be released.Things happen. Software development isn't perfectly predictable.
Missing the cutoff for merging your code into a version means that it has to be put off till the next version. That generally means it will be released about 9 months after the cutoff for the merge, given an average of about 6 months of time between minor releases. This will likely lead to extra work (which costs you) to make the ready to merge code ready again after trunk has received 3 months of commits during the alpha and beta portions of the development cycle.
As a sponsor of development, you'll be heavily involved in testing the functionality as it passes through the alpha and beta stages and should budget time to do that.
What's in it for you
By sponsoring the core developers to build your new functionality and include it in CiviCRM, you not only help the broader CiviCRM user community by giving them new features and abilities, but you also help yourself and/or your organization in the process. One of the most often overlooked aspects of software development is the amount of time and expertise needed to maintain the software after it is deployed.
Some examples of the things you'll encounter after you deploy your custom CiviCRM solution:
- Even the world's greatest coders still end up with bugs in their code, CiviCRM is not exempt from this
- Other systems that CiviCRM interacts with in your environment will change over time
- Your requirements and business processes will change over time
- New best practices in your field will emerge
- New versions of CiviCRM will be released
Who will keep your custom CiviCRM code up and running? By putting your custom code into the core system, you gain a set of partners in this endeavor. The core developers and the rest of the community that benefited from your additions to CiviCRM now also have a stake in helping you keep this code free of bugs, secure, and up-to-date. They'll need your help of course, but it's a lot better than going it alone.
When you include functionality that you need in the open source core of CiviCRM, you can find others to co-sponsor the development and/or later improvement of those features. Since you'll all benefit from the final product, each of you can contribute just a portion of the development cost. This saves money for all involved.
Open source contributions
Even if you never touch or spend a dime on your sponsored features after they go into CiviCRM, others very well may. Since it's open source, you'll benefit from their work too. They may find and fix bugs, add new features, or write documentation. Of course, they're under no obligation to do any of these things, and if you require that some of them are done, you should make sure you have the staff and/or money to guarantee that they are. But there will always be things you'd like to have but just don't have time or money to do yourself. Many times open source contributions from others can fill these gaps for you.
You can check the consulting contract and consulting rates on our Consulting Services Agreement page.