Standards, simplicity, power and flexibility

So we're building this CRM "engine" for nonprofit and nongovernmental organizations, CiviCRM.

As we design the data model, we are presented with the standard trade-offs. Who are we building for? The software developer that will build a software application using CiviCRM as a repository for their contact and relationship information? The nonprofit or non-governmental organization that will store their contacts and relationships in CiviCRM?

I'm coming quickly to the conclusion that power and flexibility are FAR less important than standards and simplicity.

Let me give you an example. A software developer builds a program like Advokit, which tracks the fact that "George" (fname for contact_ID=1) is a "precinct captain" (relationship_type) for "Democrats of Peoria" (name for contact_ID=2) using CiviCRM.

Another software developer writes a program that allows a nonprofit to track the hours worked for both volunteers and employees. In their model, they basically enable their functionality for any record in CiviCRM with relation_type=volunteer.

Democrats of Peoria is currently using Advokit and now wants to add hours tracking.

If CiviCRM focused on power and flexibility, it would be up to the user to do some stuff to make everything work. They would specify that "George" is a "volunteer" for "Democrats of Peoria" in addition to being a "precinct captain", allowing George's hours to be tracked. If "George" latter becomes a paid "canvasser" for "Democrats of Peoria", then the NPO would have to remember to go back and updates all of George's relationship_types; in this case changing him from a "volunteer" to an "employee".

If CiviCRM focused on standards and simplicity, the nonprofit should have to do very little to make the two systems work seamlessly together.

CiviCRM would implement certain "reserved" relationship_types. One would be volunteer, another would be employee. Every custom relationship_type would have a child relationship to a reserved relationship.

The Advokit guys would create the custom relationship_type "precinct captain" as a child of the reserved relationship_type "volunteer". George would start out automatically as both a "precinct captain" and a "volunteer". When George becomes a "canvasser" he automatically becomes an "employee" because the custom relationship_type "canvasser is a child of "employee".

At this point folks go, "What is this guy smoking? Have we got to the standards and simplicity yet?"

The standards are complex: we enforce a taxonomy on people developing software that uses CiviCRM as an engine for contacts and relationships.

The simplicity comes in from the prospective of the nonprofit using the system.

Democrats of Peoria implements Advokit making George a precinct captain. A week latter, they implement hours tracking. The hours tracking software works seamlessly (as a "precinct captain", George is already a "volunteer" courtesy of the software developer working within the standards). When the nonprofit re-classifies George as a canvasser, hours tracking works seamlessly-- no updates are required in the hours tracking software (because "canvasser" is a child of "employee" courtesy of the software developer working within the standards).

Isn't it better for us all to be 100% customer focused, no matter what the technical implications?