Small pieces loosely joined part II

In my previous post I talked about how venture capitalists see the next generation of technology investments. Others share a common view of the future:

"Connective and pervasive technologies are enabling new forms of human and machine interactions and relationships; they will present business [& nonprofit] institutions with a host of new possibilities for organizing people, processes, relationships and knowledge." (Institute for the Future)

In a Social Source world, the participants (vendors, consultants, customers) define new possibilities for organizing people, processes, relationships and knowledge with the goal or improving their own organization, and as a by-product, make their innovations available to a broader community, accelerating the adoption of their innovation. This is a function of open source licenses and open, modular architectures based on standards.

The key here is that organizations pursue their own interests. The Social Source ecosystem and licensing structure, which enable organizations to pursue their own interests better, faster, cheaper, makes it easy and automatic to share innovations with no action on the part of the "customer." The customer just needs to pursue their own interests.

The second notable issue is the critical nature of CRM to this vision of a new world-- organizing people, processes, relationships and knowledge.

This is why our fist piece of software is CiviCRM, a constituent relationship management engine. It is all about providing a common, open framework for organizing people and relationships. We fully expect other software will use CiviCRM as a common CRM repository.

Ultimately, this makes interoperation and compatibility between a CiviCRM-based knowledge management system and perhaps a CiviCRM-based donor database easier and more powerful.

The Big Idea

The Institute for the Future observes that we are in the middle of a collision of different forces:

1. "Companies in emerging high-tech industries have learned that working with competitors can build markets and help avoid costly standards wars."
2. "The open source movement has shown that world-class software can be built without corporate oversight or market incentives."
3. "Outsourcing has turned competitors into common customers of design firms and contract manufacturers."

Put these ideas together and you begin to see how far behind the curve the nonprofit technology sector is. Sure, where NPO technology and the broader technology market intersect, we see these themes -- computers, operating systems, groupware -- but in the nonprofit-specific technology sector, we see a market lagging behind. I'm talking about things like donor databases, advocacy platforms, membership management, etc.

Leading firms don't work with one another to build markets, but focus on building proprietary software platforms that seek to be all things to all people (Kintera and Blackbaud illustrate this point) or focus on a small little niche (membership management & case management software). Nonprofits still see open source as "iffy,"built by volunteers and not a viable option compared with proprietary commercial solutions. And finally, the nonprofit technology market makes little use of contract manufacturers/ design firms, instead vendors tend to follow a vertical integration strategy, providing customers with all the services related to their market -- installation, training, support, customization, etc.

A Social Source world actively embraces these themes and put them to work for the customer.

Social Source encourages competitors to work together and build standards that enable customers to switch from vendor to vendor without barriers. Imagine buying advocacy software from Kintera and deciding that you would prefer a consultant and technology support staff based in your city so you can get face to face treatment. Perhaps GetActive has staff in your city. Could you imagine switching from Kintera to GetActive with little pain and trouble? This starts to become possible if the two companies used the same open source technologies & software and agreed to the same standards. If both companies used the open source CiviCRM constituent relationship management core, the migration of basic CRM data would be relatively simple.

In a Social Source world, the software options are not created by a nonprofit staffer with little time and no formal software engineering training. Instead, very robust core software is built by qualified software engineers with the support of a broad open source community. Intermediaries like the Social Source Foundation and Aspiration provide governance, guidance and community building for the open source community.

Social Source means that when customers hire vendors, the project contributes to the whole community through the magic of open source. Competing vendors have an incentive to share innovations and employ the same software engineering organizations to create solutions to their customer needs. Doing so, they can deliver the functionality customers need at a low cost to the vendor.

But this Social Source vision requires a new ecosystem of integrators, hosters and developers to evolve. It requires customers and consultants and intermediaries to start understanding the dynamics that shape the new, new economy. And it requires imaginative and inventive people, funders and intermediaries to take the lead.

"Apps on top of apps on top of apps": small pieces loosely joined

From the pages of Business 2.0

Fred Wilson was a VS at Flatiron Partners during the bubble. He has recently started Union Square Ventures after asking the hard question, "Is profitable VC investment in technology innovation dead?"

His answer: "The reality is that core technology investing- everything from chips to enterprise software to communications equipment, all the stuff that big companies buy- has been on the wane for five to 10 years. So what's the next wave? The next wave is what we're calling applied technology. The Internet is a computing platform built on top of the core technology. Applied technology is what gets built on top of that: It's Web services."

CiviCRM is a great example of this. It is both built on top of core technologies (Internet, PHP, MySQL, Apache), but it is designed for others to build on top of it. Apps on top of apps on top of apps.

While the commercial world tries to figure out how to extract maximum profits at each layer, the Social Source approach is to build the core layers and let nonprofits pay consultant to fill in the blanks. As those blanks are filled in with contributed software, the entire sector gets better, more efficient and more affordable tools.

Effective, affordable and ubiquitous nonprofit technology

Social Source is a vision and practice of software development that specifically meets customer needs. Social Source changes the institutional and systemic incentives that govern the behavior of actors within nonprofit software development.

It starts with a simple idea:
Software customers need effective, affordable and easy solutions.

Commercial vendors in the proprietary world say they provide effective, affordable and easy solutions, but their definitions of those terms may not match the customers'.

**Effective**
Vendors tend to provide effective solutions for the problem that drives the purchasing decision. I buy effective fundraising software today, but in five years my needs have expanded and when it hasn't been upgraded because the vendor needs to maintain their profit margins and cannot afford to expand R&D, it might no longer be so effective.

Social Source uses open source development methodology to deliver effective solutions across the life cycle. CiviCRM, the Social Source Foundation's new nonprofit-centric contact and relationship management solution, can remain effective over the entire software life-cycle IF an social source community of volunteer and paid developers, consultants, vendors and users embrace the platform.

Commercial vendors only provide an effective solution if it is profitable. Blackbaud's Raiser's Edge was recently criticized by the transgender community because their demographic profile only included male and female. With an open source solution like CiviCRM, if the maintainers of the software won't change their software, you can hire someone or do it yourself without violating licensing agreements.

**Affordable**
Affordable to a vendor means the highest possible price that the market will bear. We call this in economics profit maximization. Customers clearly get value... they are willing to pay for it.

With open source software, there is a natural competion among vendors. You can only buy Kintera Sphere from Kintera corporation. With an open source solution like CiviCRM, you can buy the solution from any developer/integrator/consultant that understands how the software works.

The dual upside/downside is that this provides a large variation in vendor quality from college students on summer break to major corporate systems integrators. The customer will need to choose the best providers, but they can choose from a wide variety of price points and service levels so that the customer's specific needs are met. If you want Kintera Sphere, you pretty much only get Kintera Sphere at Kintera's price point and service level.

We call this the ecosystem around a piece of social source software.

**Easy**
Proprietary vendors tend to make using software easy. Getting, installing, modifying, customizing, understanding, etc. are all too often difficult in order to generate additional fee income that supports profit margins.

Social Source vendors have incentives to deliver "easy" in all aspects of their services. As they compete in the marketplace, they can't afford make any stage of the process difficult... the competition will acquire customers by making what was once hard, easy.

So how does this Social Source idea work all this magic? We'll take a deeper look in the next few days.

Building a Social Source Paper

Seems like all good ideas have a white paper... Network Centric Advocacy, Movement as a Network, Three Pillars of Social Source.

But I don't have that kind of attention span. So I thought I'd try to build a white paper from component ideas. A blog seems like a reasonable tool.

Have you ever read something that resonated so deeply with your own ideas it gave you new energy? The paper "Toword a New Literacy of Cooperation in Business" from the Institute for the Future, did it for me.

Plus it provides an organizing principal for my Social Source white paper.

Now every white paper needs a title, so here are some I came up with:

Social Source: An opportunity for nonprofits to be on the cutting edge of global change.
Social Source: Visioning a new model of nonprofit technology.
Social Source: Catalyzing a new model of social purpose technology.

I'll tell you what the paper is about tomorrow.

Open Source and "White Label" Applications

Long ago I made the arguement that all these nonprofits that build custom applications really need to get together and form a consortia to lower the costs of application development. Yes, there are many logistical hurdles, but two nonprofits with the same needs can get a custom application by commissioning the work as a consortia than each building a seperate custom application.

As CiviCRM begins to take shape (we released 0.1 and are working on 0.2), it is becoming easier and easier for nonprofits to band together and build "white label" applications on top of CiviCRM. Mark Sherman at the Progressive Technology Project has a problem... his members, grassroots organizing groups, have a common database need which they have all solved in different ways. By banding together they can commission a grassroots organizing platform that will serve their collective needs?

This works really well when the underlying technology is open source. No one owns the technology and everyone owns the technology. As a practical matter, it means a group of nonprofits is not locked into a single vendor and can be assured that they have the rights to do whatever they want with the technology that is produced.

What other unbuilt applications are out there that NPOs could collaborate on?

Both/And - Open Source and Commercial Worlds

Sonny Cloward takes me to task (nicely) for my tendency to create a black and white distinction between open source and commercial/proprietary models in the nonprofit sector.

And to be honest, I am in a continuous struggle between marketing speak (simple statements that get core ideas across) and a more sophisticated discussion. The black/white stuff is more marketing speak than anything else-- the real world is more complicated.

So let me try to lay out some core principles:
(1) Amortization. The cost of software should be amortized across as many possible users of that software. If I have 1,000 customers, they each pay 1/1000th of the development costs.
(2) Affordability. Technology should be available and affordable to the broadest range of the nonprofit sector as possible.
(3) Customer Control. Decisions about software functionality should be as close to the customer as practical. If I need the thing to do "A", I or a consultant I hire can make it do "A".

Some more general core principles include those from the National Strategy for Nonprofit Technology:

• Technology Transparency
  
• Open Systems
  
• Fair Exchange
  
• Fair Compensation
  

OK, so leading with the principles, it is important to realize "open source" meets only one of the principles- open systems. By itself, it probably creates more problems than it solves.

The current implementation of Salesforce.com for nonprofits meets a whole lot more of these principles than open source alone. In fact, it was for that reason that Paul Hagen and I went to Suzanne DiBianca, the ED of the Salesforce.com Foundation, a couple years back to accelerate its deployment and suitability for NPOs.

The thing I call Social Source brings all these principles together into an ecosystem that serves customer, rather than vendor needs. It is the ecosystem of consultants, integrators, developers, and customers that create the benefit for the nonprofit sector. I can certainly do this in a proprietary model if I can convince the community to give up their intellectual property rights.

Open source is the foundation of the social source approach because it puts everyone developers, integrators, hosters and customers in an equal power position. Everyone controls the technology and no one controls the technology. Innovations are automatically shared (primarily through the community, but reinforced by the license).

If tomorrow Oracle made a hostile bid for Salesforce.com, the likelihood of them maintaining their services for nonprofits would be in serious doubt. This is not a reflection on the good hearted people at the company, it is simply the reality of U.S. corporation owning intellectual property--when ownership changes, the new owner calls the shots.

Again, let me be clear, if I were advising a client today I would encourage them to go to a trustworthy vendor (and there are lots of them out there) and purchase a solution. It will work for them and there are currently no good alternatives.

If I'm talking to a Foundation about how to improve the way the nonprofit sector uses technology, I'm going to make the case that we need a new model- social source.

Open source is a necessary, but not sufficient condition for this new model. We still need vendors, economic transactions, NTAPs, collaboration, educated customers, support and training options. But when you build your model on open source, control devolves to the folks with the need...the customer. This is not such a bad thing.

Further reading on Social Source:
Jonathan Peizer
Gideon Rosenblatt

Death of Mission-based Software Developers?

Groundspring's announcement that they are getting out of the software development business marks a sad day nonprofit technology. Combined with the recent firing of Microedge's CEO, there are some interesting cracks appearing in the proprietary commercial model of nonprofit technology. Lucy Bernholz makes a great observation:


"Looking over the landscape of markets, vendors and products, I can tell you what I think will happen next. And it won't involve the customers (read: foundations, nonprofits, donors) getting what they want or need UNLESS they act faster than they've ever acted, in ways they haven't before, and with an eye to the motivations of market forces that are virtually foreign to them."

She's still stuck in the paradigm of proprietary commercial software vendors, but she well articulates the need for mission-based software developers to serve the desires and needs of nonprofits. The commercial world hasn't and probably won't be able to meet those needs.

We think the future is a network of commercial and nonprofit entities that drive an open source community that develops software. We think nonprofits need to:

1. Act faster than they have ever acted before in adopting alien technologies and business models (open source).
2. Act in ways they have yet to understand (partners in open source communities that develop software).
3. Keep an eye on market and social forces that are foreign to them (open source ecosystems).

It's a radical thought, but one with significant potential to meet nonprofit technology needs in an affordable, ubiquitous, effective,and understandable (to nonprofits) way.

Where Have The Values Gone?

I think I sat through the seminal NTC experience-- the introduction to fundraising session with Cheryl Gipson (Groundspring), Allan Pressel (CharityFinders), and Cathy Packard (Ctr for Nonprofit Magmt, Dallas).

You had someone whose mission is to help nonprofits with technology (Cheryl), someone whose mission is to sell nonprofits technology (Alan), and someone whose mission is to provide effective consulting (Cathy). Basically, in any session where a guys says "I'm not here to give a sales pitch" and then proceeds to demo their product, you are pretty safe in assuming his primary purpose for being in the room is to generate sales leads.

So why is NTEN hellbent on making NTC a tradeshow rather than a national Nonprofit Technology Conference? It is great for vendors, since they can mask their product demos under good titles like "Introduction to online Fundraising". Its not so good for a nonprofit seeking vendor neutral information on nonprofit technology issues.

Why aren't the vendors locked in the exhibition hall? Why do we call it a science fair instead of an exhibition hall?

Tooo many questions. For me the answer comes down to history.

When the Nonprofit Technology Enterprise Network (NTEN) was conceived, this was the vision (quoted from the National Strategy for Nonprofit Technology-NSNT).

While our original commitment was to analyze and map needs and opportunities, this process has taught us that effecting a solution requires a fundamental breakthrough that represents a collective change in behavior for the entire sector. We need a "big bang" to change fundamental assumptions about how the sector moves forward a new way of thinking and of working together that shatters old assumptions and creates a new sense of possibility. There are four core principles we believe can fuel this "big bang": Technology Transparency, Open Systems, Fair Exchange, and Fair Compensation.

• Technology Transparency is the idea that information technology should be a tool whose suitability, benefit, and ease of use makes it employment second nature (like the telephone).
• Open Systems is an approach to technology innovation that emphasizes continuous contribution by many authors, with the results owned by no one, and by everyone.
• Fair Exchange is the principle that those who receive the benefit of another’s technology should in some fashion reciprocate, propelling still more forward movement.
• Fair Compensation is the idea that those who bring their time and talents to the cause of empowering nonprofits with technology deserve due recognition, financial and otherwise.

We believe that if all players commit to these principles and to working with those who also commit to the principles nonprofits will realize the vision to use technology well, funders will have the confidence to support such work, and technology assistance providers will be most effective and creative.

It is telling to me that NTEN has chosen to move away from these core principles, this vision for a healthy nonprofit sector, and to a corporate model of vendors, customers, sponsorships and "schwag".

Perhaps that is part of the reason that nonprofits have yet to use technology well, funders don't support the work, and technology assistance providers have been transformed into vendors.

NTEN without a voice

OK, how silly is it to get to a conference for a little evangelism on CiviCRM and lose your voice? I had a sore throat on Wed and spent just a little too much time talking. I think, perhaps, that the universe is giving me a message-- talk less, listen more. So when you see me at the NTEN NTC, please feel free to carry the conversation ;)

Vision, Action and Inclusion

So I like to talk about a Social Source Ecosystem. The idea that there can be lots of developers, consultants, intermediaries, customers, and users all centered upon some mission-focused, nonprofit-specific software.

For an ecosystem to work their needs to be nourishment and symbiotic relationships among the different players. Since we live in capitalism, money often becomes the logical nourishment. But capitalism is not so good at creating non-monetary symbiotic relationships. These are the keys to making real social source ecosystems work. Relationships between players where no money changes hands, but enough value changes hands that those players become inextricably linked to one another's successes and even failures.

The ecosystem comes about because their is a vision of what can be and an evangelism that shows the different players that there is value in participating. The ecosystem must also be accessible to all-- be inclusive of all the players.

So once you all the players out there and they are all start taking action, conflict arises.
To gain nourishment in the ecosystem, players have to begin taking action. They sometimes overwhelm other players in the ecosystem, they sometimes cooperate with others in the ecosystem, but eventually the system finds a balance.

So the conflict becomes:
Vision requires collaboration to help others see what you see
Inclusion is best supported in collaborative cooperative environments
Action often requires autonomy
and the general nature of an Ecosystem is that there are winners and losers.

Now put that all together and it becomes very difficult for a single person, a single organization or a single entity to catalyze a Social Source Ecosystem.

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?

Create a living Nonprofit Tech Taxonomy

Marnie Webb had a good idea to stop talking about something and actually try a little action... imagine that.

To quote Marnie:
"So, more precisely how does this work? Sign up for a del.icio.us account. Put the bookmarklets in your link bar. And then, when you are on a site that has some link to nonprofit technology -- and you decide whether you think it does or not, there are no rules -- bookmark it. Apply the tag "nptech". That's going to allow us find everyone's bookmarks. After that, use whatever tag you'd like."

Marnie's entire coherent logic for the thing is here: http://ext337.blogspot.com/2005/01/time-to-get-serious-about-nonprofit.html

The original thread that started this discussion is here:
http://www.omidyar.net/group/compumentor/news/11/

When you make the decision to "Just Do It"

For years I've been selling a vision of a nonprofit sector powered by open-source, mission-focused, enterprise software and an organization of sufficient scale to drive that vision. Over the holidays I finally found the folks that are taking the plunge. (I too decided to get wet)

Large things don't start with large ideas. Large things start with small actions. Over two weeks, two very small actions started building the foundation for a vision--something I wasn't able to accomplish over a year of trying.

One is the CRM project. This project is working to create a LAMP-based core to CRM information for mission-focused nonprofit and nongovernmental applications (fundraising, advocacy, etc.). It is amazing what happens when folks decide to roll up their sleeves and just get the work done.

The other is a business plan for an organization to seed, grow, and extend the ecosystem for these nonprofit, open-source software projects.

The CRM project is a first technical step to a set of products (software engineered to be useful to end users, not just developers) that have the potential to change the face of nonprofit technology. CivicSpace Labs is on the front end of this effort with many other folks starting to jump on board as the train starts moving out of the station. Unlike the TGV in Europe, people don't need to board this train at the station.... much like Indian Railways, people can hope on the train at any point, many of whom will sit on the roof in the open air. The train goes slow, but it gets to its destination eventually.

The Magic of Thinking Big

Nonprofit technology is about category killers. Andrew Blau in his paper, "More than Bit Players" (www.surdna.org/documents/morefinal.pdf), makes the point that one of the most important aspects of organizational behavior on the Internet can be summed up in two words: “size matters."

Folks like VolunteerMatch, NPower, CompuMentor/TechSoup all illustrate this concept.

When I think about my own interests in Social Source, I struggle with the apparent conflict between a single, large monolithic entity--a category killer (the implication of 'size matters') and an organization that supports, nurtures and encourages a vast number of smaller organizations.

Social Source requires the aspects of being a category killer-- 1) lead the capture earned income from the marketplace (to lead in market share) and 2) lead the capture of philanthropic dollars. At the same exact time, that revenue (both earned income and philanthropic) and the benefits of that revenue need to be effectively transferred to a vast number of smaller organizations that contribute code and serve nonprofits.

How do you be both the 800-pound Gorilla AND an equal partners with an entire community of folks looking to help the nonprofit sector?

Tipping Points...(how things really happen)

I have been on the "wouldn't it be great if people built open source software that specifically met nonprofit needs" bandwagon for so long, I wonder if I'm wrong, dreaming, or just plain crazy. Things are starting to look up.

For the past couple years some amazing folks have had their heads down doing stuff... Techrocks (now defunct) built ebase. Groundspring created their products and with the help of a dot com refugees, picked an open source strategy for their software. Many, many personalities and players were talking about the ideas.

Fascinatingly enough, it is the infusion of talent from both the dot com sector and the broader open source community that seems to have driven the idea of npo-specific open-source into reality. Today we have civicspace, advokit, groundspring and other projects.

The slowness of this evolution, I think, boils down to the fact that we don't have any hackers in the NPO space. The big nonprofits that do software projects hire contractors of a more traditional ilk. This is changing too, with folks like Aspiration doing a good job of bringing hackers together... to bad they don't seem to do quite as good of a job getting traditional NPOs leaders into the room.

As Bob Dylan said, "Times they are a'changin".

In 2003 a bunch of people packed into one of the "small" rooms at the last Roundup in Oakland, CA (before it got itself all corporatized into the Nonprofit Technology Conference run by NTEN -- not that there is anything wrong with that ;) That packed room had a spirited discussion about what it really was going to take to develop open source software for the nonprofit sector. In that room, strategies were hatched that said basically, the software development side of open source is theoretically interesting, but impractical. Hence the Nonprofit Open Source Initiative's quite intelligent focus on leveraging existing open source products for nonprofit use.

(I was always the guy babbling about open source software development)

As I look back on the notes we wrote down from that session. Some of which are here. I think about how much momentum is building.

I think its all pretty cool.