Real Partnerships

Most of the ideas around Social Source revolve around open, cooperative partnerships with key players in the nonprofit technology space. These partnerships are very much along the lines of the very simple kindergarten lesson: "Share".

Institutionally, it is critical (in a very practical way) that there be common, concrete interests. I like to think that if both organizations were going to independently invest their own resources in in doing a project, then that project is a good practical candidate for collaboration. But if you are a real go-getter, the fact you are willing to invest your own resources from the start tends to mean it is more efficient to do the project yourself rather than incur the overhead of a partnership.

How do you surmount this catch-22 and make close collaboration part of your organization DNA?

The Values of Openness

Sometimes I feel like the people get confused between the value of openness and the values of openness.

In this day of Venture Capitalists investing in Open Source "plays" (Draper Fisher Juvetson investing $2m in SugarCRM), there is perceived value in openness. John Roberts, the CEO of SugarCRM has a great quote: "We're going to destroy a $6 billion [CRM software] market and turn into a $1 billion market." Left unsaid is 'Us getting a slice of a $1 billion dollar market is a lot better than not getting anything in a $6 billion dollar market.'

SugarCRM recognizes the value of openness. The monetary value.

Now a little outfit called TigerCRM comes along and in the grand tradition of open source software, forks the SugarCRM code per the terms of the SugarCRM license. They take a copy of the code and run with it.

An engineer at SugarCRM got angry because their work was essentially copied and used.

Somewhere along the line, they didn't understand the values of openness.

To me, the values of openness are pretty straight forward:

• Share. Because in Kindergarten they taught me I would have a lot more fun with my toys if I played with them with others. I think they were right.
• Collaborate. Two heads are better than one. Very true in software development.
• Focus. Do what you do. Don't worry about what others do.

If you are in Open Source for the customers, for the business model, or for the money, you're probably stuck on the value of openness.

Take a step back, breath, and decide if you also believe in the values of openness.

Trains, Stations and Communication

I like to compare CiviCRM to a train leaving the station.

It has mass, it has momentum, it is on a track and its basic direction is set.

But even among trains, there are significant differences. When you travel on a TGV out of Paris, if you're not on the train when it leaves the station, your not going to get to your destination. Period.

If you travel on the stereo-typical India National Railways local, it looks something like this:



That is kind of how we envision CiviCRM. It moves slowly, people jump on and off, as long as you don't mind riding on the roof for awhile, you are welcome to join us.

http://objectledge.org/confluence/display/CRM/How+to+Participate

Lest people mistake the intent of my last post, we have no intention of leaving anybody behind. But the train is moving.

The CiviCRM train starts to leave the station

So we put out a public announcement today to most of the relevant lists about the CiviCRM documentation. CiviCRM is designed to be a GPL contact and relationship "engine" to handle NPO/NGO relationships for other NPO/NGO software applications.

For all the folks that got 50 copies of the announcement, sorry. I think that underscores the fragmentary nature of the NPO/NGO software development space that we all subscribe to the same 20 email lists to stay connected.

Anyway, pretty exciting stuff:

Please review our documentation. We need all the help we can get!

[apologies for somewhat excessive cross posting]



CiviCRM is seeking input on the design documents for

our open-source (GPL) relationship-management

application for the NPO/NGO sector. Four full-time

developers will start coding CiviCRM to the design

documents on 2/14/05. Get your input in by then!!



~~~~~~~~~~~~~~~~~

WHAT IS CiviCRM?

~~~~~~~~~~~~~~~~~

CiviCRM is a LAMP-based, open-source project to create

relationship management software for the nonprofit and

nongovernmental sectors. CiviCRM stores information on

the universe of people associated with a nonprofit

organization and on their interactions (emails,

donations, petitions, events, etc.).



http://objectledge.org/confluence/display/CRM/CRM+Project+One+Pager





~~~~~~~~~~~~~~~~~

INPUT ON WHAT?

~~~~~~~~~~~~~~~~~

CiviCRM manages contacts and relationships for other

software applications. Initially CiviCRM will manage

contacts and relationships for the Drupal/ CivicSpace

platform (www.civicspacelabs.org).



For other software developers to use CiviCRM, they

need to know the data model and the public API. The

data model defines what is available (individuals,

households, organizations, relationships, groups,

actions) and the API defines how developers access and

manipulate that data.



To review documents, follow the hyper link, scroll to

the bottom of the page, and click the “add a comment”

hyper link.



Feature overview (high level):

http://objectledge.org/confluence/pages/viewpage.action?pageId=592

Data model:

http://objectledge.org/confluence/display/CRM/Data+Model

Public API:

http://objectledge.org/confluence/display/CRM/CRM+v1.0+Public+APIs





~~~~~~~~~~~~~~~~~~~~~~~~~~~

HEY, I’M NOT A CODE-HEAD!

~~~~~~~~~~~~~~~~~~~~~~~~~~~

If the documents above make your head hurt, you can

still make a valuable contribution! Write a user

narrative for us about how a NPO/NGO would store,

group and manipulate information about individuals,

households and organizations.



User narratives are plain English stories about what a

NPO/NGO would do with CiviCRM.



To contribute a user narrative, follow the link below,

read the examples, scroll to the bottom and click the

“add a comment” hyper link.

http://objectledge.org/confluence/display/CRM/User+Narratives





~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

THIS IS COOL, HOW CAN I HELP IN MY COPIOUS SPARE TIME?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CiviCRM is an open, community process. We encourage

broad participation. The more you contribute time and

effort, the more impact you will have on CiviCRM.



Find out how to participate here:

http://objectledge.org/confluence/display/CRM/How+to+Participate



Alternatively, drop me, David Geilhufe, an email at

dgeilhufe AT-yahoo DOT-com. We’ll find a good way for

you to contribute and get all your questions answered.



Please distribute this announcement to anyone that you

think needs to know about CiviCRM



David Geilhufe

CiviCRM Team Member

dgeilhufe AT-yahoo DOT-com

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?