Published
Monday, November 2, 2015 - 03:32
Written by
My name is Chris Burgess, I currently live in Dunedin, Aotearoa and I'm working with Fuzion. I'm @xurizaemon on Twitter, Github, IRC etc & blog at http://chris.bur.gs
 
With CiviCRM, I'm helping over 50 non-profit organisations raise funds, manage membership, run complex case management systems, communicate, build election campaigns, and change the world. Right now that looks like expanding options for CiviCRM provision & hosting, exploring ways of improving CiviCRM's user experience for onboarding new contacts, doing some prototype work on config management with a view to deploying updates, and recently mentoring a student in the Google Summer of Code. Come join us - we're hiring!
 
Outside of CiviCRM recently, I've been part of a project to improve visibility and engagement with legislation in NZ which picked up several awards in GovHack here, running a small commercial project involving sales of automated venue access via the web, and enjoying working on some collaborative team functionality. I find I think a lot about how we can optimize for a happy team environment. I'm also helping Fuzion build systems to manage our growing clientele both in the Drupal-sphere, and improve efficiency and security for ourselves and our clients.
 
What brought me to CiviCRM was a moment when working as technical advisor / implementer for the Green Party of Aotearoa New Zealand in I think 2007. The party was an early proponent of OSS, and I heard they were planning a CRM project using a closed-source platform. I thought, "there has to be a better match here", did some research and learned about CiviCRM, fired it up on my laptop, and took it to show to a conference. I just wanted to put an OSS option on the table for them, but I got asked to implement the migration and that was that, I was onboard. By pure chance, Lobo was just down the road from the city in NZ where the decision was made, and Pete Davis who runs Fuzion was working with the party at the time.
 
One of my favourite things about CiviCRM, and an early impression as well, is how open and encouraging the community is. I loved Donald's attitude to my bug reports - "that's a really good bug!" he'd say, and I wasn't familiar with being rewarded for finding problems. I'm a proactive trouble-seeker, I love looking for bugs, but until then I hadn't found an environment where this was encouraged.
 
The CiviCRM userbase is a feature - I find working with social change orgs rewarding, because I'm in a position to use my skills to enable some positive difference, and from a small city at the bottom of the world I'm able to do that to international effect.
 
Years on, what excites me now is seeing CiviCRM go through a period of renewal, both in terms of the codebase and in terms of the community also. I'm looking forward to see where this takes the project! Attending the Denver sprint renewed my enthusiasm for the project a lot; there were improvements underway which I hadn't seen until then.
 
Right now I see CiviCRM both reinventing itself and maturing at the same time. A year or two ago I encouraged CiviCRM to adopt some approaches that the Drupal security team implement - formalising the process of reporting and handling security bugs, committing to our users that we'd announce them on a schedule, that sort of thing. I think that's been a good step for CiviCRM, it helps organizations make informed choices and plan accordingly. If you're a big org you need to have the security of your data on the radar; many of the options in the CRM market have no public visibility into how they approach security.
 
I hope to see continued improvement in CiviCRM's security as the codebase is renewed, and I'd like to see CiviCRM users and providers up their game when it comes to securing their sites. In my book, SSL is not an optional extra for any CiviCRM site.
 
I'm looking forward to seeing CiviCRM's interfaces with regard to deployment and config management improve too. I think this is a place where CiviCRM will go quickly over the next couple of releases, based on the work that's already happening in the core development framework. 
 
I have a CiviCRM confession: I feel guilty for suggesting the custom_php override functionality in CiviCRM to Lobo at the Melbourne CiviCRM Bootcamp back in 2008. It allowed some good customization at the time, but it's a part of CiviCRM I'd love to see removed today, I think it's a problematic approach in retrospect, and there are better ways to do that now! If that ever bit you on an upgrade, I apologize for my part in its creation :)
 
CiviCRM has given me an opportunity to work alongside some really meaningful causes, and I'm grateful for that and for being able to be part of the community over the years. Thanks!

Comments

Great post, Chris. Is that an environmentally green halo behind you head in the photo? ;)

I think a schedule has been great.  The security of CiviCRM data is paramount, thanks for your hard work. 

Tell us, what better ways than custom_php, then?

Custom PHP overrides (and templates!) are bad because you're coding to an unstable interface. Using civicrm's hooks and API let you code to a stable interface. Do that :)

Ouch you are fessing up to php overrides? Over-honestly has no rewards :-)