The community provides excellent forum support, new ideas and feedback on suggestions. The CiviCRM software suits many use cases and allows us to support a large number of diverse UK voluntary sector organisations.
Palante Tech works with social justice organizations on a tight budget to be more effective through technology. CiviCRM allows us to provide a high-quality low-cost database for community organizing, donor and membership management.
I've always been passionate about what non-profits and advocacy groups can achieve using technology. For me, CiviCRM shows an essential example of how non-profit and technology worlds can come together to provide real change - working as community, creating value for yourself, but also for others in non-profit sector.
It is super important for non-profits, advocacy and related groups to take charge of their destiny. Having control of your data is a good start. The crowd-sourced nature of an open source project in so in line with the co-operation and principles of most non-profits
CiviCRM is a project that strives to make the above possible. It is FREE as in kittens.
We help many not for profits implement CiviCRM through consultancy, training, configuration, support and custom development. Many of them come from a painful world of old Access databases, multiple spreadsheets and even paper. I love presenting demonstrations to new potential users; many are shocked by the scale of the software. CiviCRM is suitable for so many different organisations as it's been developed to cover so many bases off the back of community calls.
I maintain our own CiviCRM client database; it feeds into our drupal intranet to provide me with all the information I need at a click. I would be lost without it!
I've recently been exploring creating CiviCRM entities as Drupal entities - using the drupal Entity API. I think so far I have only just touched the surface of the possibilities for this integration but I thought I'd post what I think some of them might be
Entity Reference fields
Solr searching (not explored)
Views bulk operations (not explored)
Attaching drupal fields to CiviCRM entities (within drupal) (not explored)
I seem to spend a large amount of time helping people to get data back out of CiviCRM. I'm a big fan of the reports framework and up until 4.2 I made a number of improvements to the core reports for my customers. However, from 4.2 I switched to doing reports in an extension. I have been doing almost all my reports in the extended reports extension and have been playing with a few ideas in that extension. Some of them are well developed, others are in the early stages.
A few months Back John Derry from The Monthly Magazine wrote a blog about how they were planning to use CiviCRM for magazine subscriptions.
One of the biggest challenges faced by the Monthly was that it was essential for them to be able to process memberships / subscriptions paid for as a gift. They needed to collect details for both the giver and the recipient.
Slow pages are annoying and they can cost $$$. But improving performance often means re-writing chunks of code and is often expensive. Bad performance hurts us all. So the question is how can we improve it.
The main mechanism we have used in the community so far for banding together to fund these things is the MIH - the tricky thing for performance is framing the MIH in a useful way.
There are some specific areas of known slowness in CiviCRM which it would be great to address and we could raise specific MIH for. Some that I am aware of are:
Yesterday was CiviCon in San Francisco. I made it to CiviCon in London last year but this was my first US CiviCon. The gathering was even bigger this year with about 130 people and 4 concurrent sessions running throughout the day. It was great to see such an enthusiastic bunch of people and to catch-up with old friends and put a face to online connections. The venue was brimming with the open honest enthusiasm which seems to be part of the North-American culture.
Last week I wrote a blog about technical debt (comparing it to keeping a kitchen in order). I got a lot of feedback - most of it constructive. I'm going to resist belabouring the whole metaphor & limit this blog to a quick summary of some of the discussion that came out of it.
Do you like to whinge about CiviCRM code? Have you sat through others doing having a rant? I've certainly done both. Being in the drupal world people often like to compare CiviCRM code with drupal & CiviCRM usually comes up a bit short. I think that's like comparing my kitchen with Bill Gate's kitchen. There are a few good reasons why my kitchen is not as nice as his. However, should I look at his kitchen (in a magazine) then I might glean a few good ideas that I could use in designing my own. (Copying the colour scheme would be in my budget :-))
Although the API changes in 4.1 are not as obvious as took place in 3.4/4.0 there have been quite a few changes under the hood. This is a fairly detailed explanation of what's going on inside the API wrapper.
The way in which required fields & default values are set has been changed to be more consistent and to be self documenting.