First Blush CiviCRM

For the first time today, I am taking an in-depth look at CiviCRM's API and data model.  I must say I'm excited about its direction and the enthusiasm of its supporters, but I'm rather disappointed in some of its underlying principles.  I hope I look back on this someday and write myself off as nothing but a grouchy naysayer.

The data model appears to have been copied directly out of the pages of  The Data Model Resource Book.  I recognized this immediately because I spent hours poring over that book during my '03 Operon coding binge.

Finally peering at the code, I'm reminded of all those starry-eyed college students who wander through our local PHP user groups.  Packed full of fresh knowledge, they ramble on about how code should be OOP and how Polymorphism and object state are the only things that validate an application as "enterprise".  So, the old-timers say, "OK, but what about performance?  What about the practical execution of the shortest path between a and b?".

The kids quickly shrug off these comments: "We're not talking about 'a little bit' of performance", they sneer.   "We're talking about extensibility and maintainability".

They'll learn.

Because something isn't extensible or maintainable when the prerequisite to extending it is reading a college text book on esoteric concepts.  And something isn't maintainable when you need a 50 page guidebook to determine which file calls what object, which is an extension of whose interface.  And by the way, "a little bit" of performance adds up fast.

There are over 70,000 lines of code for just the CiviCRM code itself.  While this is a major typing accomplishment, I can only ask if someone should have worked a little smarter and made use of some of that excellent object-oriented reusability. 

I would like to have seen CiviCRM be written in a data-oriented manner, not in such a self-involved application oriented manner.  By placing all of the importance on all that code and object-oriented beauty, they have abandoned the notion of keeping the data integrity with the data.

The most important thing that a contact application can do is make its data available to other applications.  Not through an expensive and marginally useful SOAP interface, but through raw data access.  For this, you must include as much structure as possible in the database design.  Business rules and validation should be, if at all possible, handled at that layer as well.  I'm a big fan of PHP, but I'm not convinced that it should be the only thing that's allowed to have access to your CRM data.

It's impractical to rely on stored procedures  when MySQL, the most commonly available open source database, does not have a production-ready version that supports them. But I would like to have seen them lay the groundwork better by focusing on simple, data-oriented procedures rather than investing so much into PHP code.

But the biggest liability for CiviCRM is its license, which prevents people from modifying and distributing derivatives without making the source code available (as does the GPL).  Similarly, it prevents someone from creating and hosting derivatives without making the source code available (which the GPL does not cover).   This enforces the idea that the GPL is meant to stay free, even in more modern usage contexts. In principle, I agree that this is a great way to go. But I personally feel that removing the ability for additional parties to extend and adapt proprietary extensions of the software will limit its development. A product this complex needs could use more than one full-time organization's input to sustain itself. With high complexity and little documentation, there's not enough cost/benefit to justify making it an integral part of a sustainable business plan. Contrast this with an Apache/BSD style license, which has led to all kinds of corporate support and stable growth.