CiviCRM is one of the core offerings of our company. Remaining close to the CiviCRM community is important to us, as it keeps us close to new developments in the tool, and allows us to offer our feedback for new releases.
CiviCRM helps us help non profits to do fantastic things with their data.
Being closely involved with the developers and documentation team on a daily basis ensures that we can give our clients the best and most up to date advice on how they can use CiviCRM to meet their needs.
The CiviCRM community is a great place for support, to exchange ideas and to contribute back. Working with other developers or users has often allowed me to pool our resources together and lower our costs, while ensuring better quality since there were more people using it.
Our capacity organization manages a largely segmented contact list for bulk mailing, events, training, groups and donors.
We are helping other organizations gain advocacy capacities, managing constituency making, campaigns and petitions
I've been working with CiviCRM since 2006 or thereabouts. The community is outstanding in providing support and sharing expertise, which combines with a strong product to enable me in turn to deliver better results for the organisations that I work with. I only hope that over time I will be able to repay the debt by supporting other newcomers to CiviCRM.
We help many not for profits implement CiviCRM through consultancy, training, configuration and custom development. Many of them come from a painful world of old Access databases, multiple spreadsheets and even paper. It's really satisfying to
help people move on with a system that's so much in tune with their own ethics of sharing and collaboration. We also 'eat our own dog food' and use Civi in-house for our client records because we love the flexibility and control it gives us.
For us it's important to share code and advice with other members of the community when we can because we know we get it back in help at other times. The community really is awesome and one of the friendliest and undaunting I've come across. We appreciate the huge value of the software to us and our clients so we try to contribute back and make it even better.
As non-profit consultants working for non-profit organizations, we found CiviCRM to be particularly well suited to answer the common needs of activist associations, charities and other medium-sized groups. Based in Montréal, we've helped local and international organizations migrate to CiviCRM to manage their memberships, events, communications and fundraising campaigns. We empower our clients and assist them when they need us.
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.
City Bible Forum is an Australian not-for-profit Christian organisation. We need to communicate effectively with our constituents, and CiviCRM gives us a comprehensive set of tools for managing relationships. Interestingly, we often find that new features are being added just as our need for those features is becoming apparent. It's the right fit for us.
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.