Skip to end of metadata
Go to start of metadata

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

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

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.

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 relatively complete, there follows a series of beta releases.  These are also released for testing.  Alpha and beta versions look something like this:

  • 3.1.alpha1
  • 3.1.alpha2
  • 3.1.alpha3
  • 3.1.beta1
  • 3.1.beta2
  • 3.1.beta3
  • 3.1.beta4

If all goes smoothly the beta candidates are followed by a stable version:

  • 3.1.0

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.

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

Software lifecycle

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.

Cost sharing

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.

More Details

You can check the consulting contract and consulting rates on our Consulting Services Agreement page.

Labels
  • None

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.