This is a post to start a discussion, something of an expansion of Dave's blog (Let's Market CiviCRM better
Today marks the 5th stable release of CiviCRM 4.3.
As we gear up to work on our next major milestone release CiviCRM 4.4, there's been a considerable excitement within the team for our MIH campaign.
Recently I was asked to compile a list of all CiviCRM releases since 3.1.0, identifying which were security releases so that we could make sure clients' sites were secure.
Imagine you're a non-profit employee or volunteer, responsible for managing donations.
If you are not fundraising in any of the Single European Payment Area countries, feel free to skip this blog -- unless you want
CiviCRM configuration is largely driven through the web interface and the database: if an administrator wants to add a new "report" or new "relationship type", he can accomplish this with a few clicks of the web interface. The new item is inserted into the database and immediately becomes live. This is great for web-based administration, but it's inconvenient for developers: if a developer writes a module or extension that registers something in the database, then he needs to write an installation routine to insert the item (and an uninstallation routine to delete the item). CiviCRM 4.2+ includes a better way: use the API and hook_civicrm_managed. This technique is already used in "civix" based extensions, but it also works with Drupal modules, Joomla plugins, etc.
A few weeks ago, I went to CiviCon.
At CiviCon San Francisco, and at the sprints that followed, we spent a fair amount of time on the subject of ‘CiviCRM as a self-sufficient and financially sustainable ecosystem’.