A Social Source Ecosystem: Group Selection

In one of my early presentations on the potential of open source software for nonprofits, I had a slide called “Sounds like Socialism.” The slide tried to address a perception that a utopian view of sharing software and innovations simply couldn’t work. In our market-driven capitalist society, if you don't buy it, it can't be valuable.

The concept of group selection injects a decidedly cut-throat capitalism aspect into the concept of Social Source. The Institute for the Future notes,

“…groups work best when their members provide benefits to one another, but many of these prosocial behaviors do no survive through natural selection.” Individuals who effectively compete with other individuals succeed in evolution; those that cooperate are less successful.

How then do we conceive of a Social Source ecosystem? If it’s not one group of individuals and organizations sharing software in a utopian collaboration of nonprofits, what is it?

Group selection is the concept that individuals are not the only ones subject to natural selection—natural selection also operates at the group level—groups of individuals. Cooperation within a group can be a very important asset when competing against other groups.

This has implication for the Social Source ecosystem competing with the commercial software ecosystem, but also for the internal organization of the Social Source ecosystem.

Applying this to the Social Source ecosystem suggests there is no monolithic groups or single leader. Instead, some core principles (open source licenses) simply guide the entire system. Conflict and competition at a wider scale in the Social Source ecosystem will encourage local cooperation in order to compete in the wider group.

In the case of technology like CiviCRM, there is a strong incentive to support the creation of multiple donor database solutions, multiple volunteer management solutions, etc. The competition among those solutions will actually make those solutions stronger.

This leads both to competition among groups sharing volunteer management code for their specific solution, but also supports much broader cooperation as multiple volunteer management solutions share innovations at the CiviCRM level.

Things are getting curiouser and curiouser as I think through how a Social Source ecosystem might work.

Social Source Symbiosis

The Institute for the Future's second concept for a new literacy of cooperation is symbiosis.

"...a mutually beneficial relationship that can evolve between different organism's in a system."

Symbiosis is not an instant thing, one doesn't issue a press release and announce a symbiotic relationship with customers, partners or vendors. Over time, reciprocal actions build relationships, yet reciprocity is a hard problem.

In a Social Source world, symbiosis is created with the winning strategy for a game of "tit for tat."

1. Be nice - don't defect at the first opportunity.
2. Retaliate - defect if others do.
3. Forgive - switch to cooperation when your opponent does.
4. Be clear - always react in the same way to your opponent's behavior.

In a Social Source world, you create open source software and share it with the world (be nice). If vendors and consultants choose to use the software without contributing back to the community, you withhold engineering support, priority bug fixes, and custom feature implementation (retaliate). When a vendor or consultant changes their minds and starts contributing back to the community, actively support their success (forgive). And all the while, communicate what a Social Source value system and ecosystem look like for others can behave as is expected (be clear).

Already, CiviCRM is becoming both endosymbiotic and exosymbiotic in the Social Source ecosystem. Endosymbiotic means one organism is literally inside of another. This is the relationship between CivicSpace and CiviCRM with CivicSpace's 0.8.2 release. Neither piece of software is entirely "whole" without the other.

CiviCRM is also exosymbiotic with content management systems like Drupal and Mambo. The pieces of software reciprocate (track a common set of users), but are seemingly distinct and can operate entirely separately. Ultimately, as CiviCRM becomes the basis for donor management, advocacy, and case management applications, a network of symbiotic relationships will evolve.

One interesting lesson from biology is that parasitism drives rapid evolution. In a Social Source ecosystem, not everyone needs to or even should cooperate and collaborate. Individuals and organizations that adopt software by "defecting" in the game of tit for tat by not contributing code and innovations back into to the community.

Social Source Sync

Synchrony: the process by which patterned behavior is created among many individuals without conscious control.

In a Social Source ecosystem there are a lot of actors: developers (building software), hosters (providing software as a service to customers), integrators (modifying software for customer needs), customers (using the software), etc.

Traditional proprietary software vendor models try to coordinate those actors under a single vendor. Developers have to use the SDK (software development kit) approved by the intellectual property owner. Hosters have to pay the intellectual property owner royalties. Integrators are only available from "partner programs" organized by the intellectual property owner. At least some portion of the customer spend to use the software goes to the intellectual property owner.

Even in the nonprofit sector this command and control model is prevalent.

The rational for this command and control model is that the resulting system has rules, standards and is predictable... if no one is in control, that would be too risky.

The concept of Synchrony challenges this analysis. If you have a system of actors that is communicating and engaging in some type of rhythmic give and take, those actors will, over time sync up with one another.

In a Social Source world, software developers, integrators, hosters and customers all communicate with one another, ask one another to meet their need, and contribute innovations back and forth. Over time, this rhythmic give and take yields coordinated cooperative action.

...the combination of strong and weak links can create unexpected and spontaneous outbreaks of coordinated behavior across decentralized networks.

The partnership between the Social Source Foundation and CivicSpace labs to build and deploy CiviCRM is a good example of strong links in the network. Each organization also has many weaker links in the nonprofit technology sphere, the political sphere and the open source community.

This emergent Social Source ecosystem has already begun rhythmic oscillation... PicNet and CivicActions are starting to use the technology for customers and are increasingly communicating with the partners with the strong links (CivicSpace Labs and Social Source Foundation). Over time, if enough actors join the system, communicate and exchange innovations, unexpected coordinated behavior should start breaking out across the network.

We believe these yet to be discovered opportunities for coordination will create major positive changes in the field of social purpose technology for non-profits and NGOs.

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.

Getting that NPO Open Source start-up itch again

So I never really thought of myself as a serial entrepreneur. Then I looked back at my past and it is just littered with start ups. There was the nonprofit back in 1998 (Youthlink) with at risk kids and web design. Then there was Eastmont, a community technology center. Then Digigroups, an enterprise software firm, then Social Source Software, and now the Beaumont Foundation of America.

Every time, I find myself pursuing the vision, building the plan, and getting organization to execute. Heck I even think I'm pretty good at it.

So now the itch has returned. Beaumont is entering a period of stability and that whole open source software development for nonprofits idea is on my mind again. Equally on my mind, however, is paying the mortgage. If anyone want to put up $250k or so to get started, drop me a line. ;)

Social Source Software one pager

Social purpose organizations (NGOs & nonprofits) are entering the information age with a vengeance. They are creating software systems to improve internal operations, communicate with stakeholders, and more effectively achieve their missions. Yet, social-purpose organizations lack access to affordable technology that meets their unique business processes and evolves as they adapt their processes to interact with their constituencies using technology.

This creates an organizational divide between the very small percentage of non-governmental organizations that can afford to adopt private sector software development strategies, and those that barely afford to deploy a few computers and a database in support of their mission.
Increasingly, all social purpose organizations are compelled into using the same software development strategies as the private sector, often contracting with software vendors whose other project is a corporate database. This is a vision of software that does not, and cannot meet the sector’s needs. Paying a corporation commercial rates every time mission-related software is needed is uneconomic for organizations that can better spend their money providing direct services to real people.

The social source technology development model—where organizations directly improve technology because it is liberated from the legal constraints of intellectual property, as long as improvements are subsequently contributed back into the community for others to improve upon—represents an unrealized opportunity for the social purpose sector to develop and disseminate state-of-the-art technology that is mission driven. With access to affordable social source technology, social purpose organizations can mould technology in their own image.
Social source software development is composed of four characteristics:

• Open source application logic. The basic application can is freely distributed and others can modify it as long as changes are contributed back into the community.
• Lowest technical requirements. Build software to the lowest possible technical requirements allowing benefits to accrue to high- and low-budget nonprofits equally.
• Collaborative. Build software collaboratively. Pool financial and intellectual resources to expand the functionality and lower costs at the same time.
• Community. Build a community around software. Over the long term, social source software can improve, evolve, and achieve economies-of-scale if there is a community of organizational users making incremental changes.

Higher education recently launched the Open Knowledge Initiative (web.mit.edu/oki/), a major social source project headed by MIT and Stanford, involving over 10 additional university partners. In the nonprofit sector, applications like ebase (http://www.ebase.org/) are being created by progressive organizations using a social source development model with contractors and in-house development staff.

Social purpose organizations can build social source software without changing their current model of releasing an RFP and hiring a contractor. In the simplest case, the contractor simply builds the software with open source technologies and that application is made available to others.

For more information on social source software and how you can use it in your organization, visit www.social-source.com.

Unlocking the Potential of Open-Source

Community building is fundamentally about the belief that local problems can be and are best solved at the local level by local stakeholders. The experience and relationships of local communities drives the identification of solutions that are likely to work for local problems. Combined with local, regional, and national resources, these solutions are implemented and supported by the people with the largest stake in seeing the problem solved.

What if we were to apply this philosophy to technology development in nonprofit/nongovernmental organizations (NGOs)? Already, nonprofit organizations are building technology to support their needs. Organizations like the Fast Forward Neighborhood Technology Center have built databases with national resources to help other CTCs improve their internal operations. Project Open Hand in San Francisco has built a custom database to manage their delivery of over 400 meals per day to people living with HIV & AIDS.

Local technology solutions are being created to solve local technology problems. This is fundamentally different from the concept of traditional software development where an entrepreneur builds a piece of technology for CTCs or HIV/AIDs meal providers because they expect to realize a profit on the sale of that technology.

Open Source principles and practices allow the principles of community building to be applied to technology development in the nonprofit sector. The key principles are licensing, distribution, and community.

Þ Distribution refers to the availability of software—can I download it or get it via other means? Open source allows easy access to software usually via the web.
Þ Licensing refers to who has the legal right to use, modify, and distribute a piece of software. An open source license allows people to use, modify and redistribute software freely.
Þ Community refers to the ongoing group of stakeholders that support, extend, and improve the software. Open source software has a number of people continually changing the software and contributing those changes back to others.

In applying these principles to my two examples, we can see where community building and open source share many of the same goals and values.

Distribution

The CTC database embraces the open source principle of distribution by making the technology freely accessible from the America Connects Consortium web site. The existence of the technology is advertised to people interested in community technology. The Project Open Hand product, however, is not available for download. In fact, a reader of this article might never have otherwise known the technology existed.

An open source approach would mirror how the America Connects Consortium distributes the CTC database. The technology would be easily downloadable and would be advertised to people that might be interested in it.

Licensing

For licensing, Project Open Hand chose not to license their software at all. Other HIV/AIDs meal providers have no legal right to use their software. If they want similar functionality, they will need to build it themselves at a cost of over $100,000. A commercial software alternative is a virtually impossibility since the potential market is so small.

Fast Forward’s database is owned by the Education Development Center, Inc. Their license reads, “This material may be downloaded, reproduced and distributed only in its complete, original form. The material can not be sold, modified or incorporated into other works or materials without the express, written permission of EDC.” As a CTC, if I want to legally add a single field to the database, I must obtain written permission from EDC. If someone wanted to modify the database to better meet the needs of local CTCs, they would need to obtain written permission from EDC.

Under open source licensing principles, local stakeholders would be able to determine for themselves how best to employ the technology according to their local needs. If the technology met needs, they could use it in its native form. If the software needed slight modification to be useful, they would not have to seek and receive permission before beginning the process of meeting their needs. If a group wished to modify the technology significantly and distribute it to an entire sub-group, perhaps PowerUp centers or Ohio CTCs, they could do so. The most common open source software license is the GNU Public License (GPL).

Community

The final open source principle of community is both the most beneficial and the most difficult to achieve. Community refers to the group of people that can innovate and extend a piece of technology. Rather than have technology like a CTC or HIV/AIDs meal provider application remain static, the community makes it dynamic by adding new functionality, fixing problems, and generally making needed changes.

In both examples, the original “owner” of the technology is the only member of the community. Single-member communities are easy to manage…it is pretty easy to avoid conflicts with yourself. At the same time, there is value in the diversity that comes from community. Different ideas, different needs, and different resources lead to innovative and effective solutions. This is at the heart of why we value community building. Now we can bring some the same concepts into community technology through open source and realize some of the same benefits.

What can I do?

Þ If you participate in a technology project, take the time to examine the project through the lenses of the three open source principles of distribution, license, and community.
Þ Consider licensing software you are responsible for under the GPL.
Þ Encourage those responsible for software that you use to license their software under the GPL.

Resources

http://www.nosi.net/
Nonprofit Open Source Initiative. NOSI seeks to support nonprofits in adopting and using open source software.

http://www.fsf.org/copyleft/gpl.html
GNU General Public License (GPL). The most common open source license.

http://www.americaconnects.net/research/ctcds.asp
CTC Management Database from the America Connects Consortium.

http://www.openhand.org/
Project Open Hand

Social Source Newsletter v1#2

Social Source Newsletter
August 2002 v1 #2

This occasional newsletter is dedicated to exploring the relevance of open source software development and concepts to nonprofit organizations.

-----------------------------------------------------------------------
IN THIS ISSUE
-----------------------------------------------------------------------

What can be learned from one of the first nonprofit open source communities? Can we learn how and why open source is relevant to nonprofit organizations from their experience?
~ What is Ebase?
~ How do they balance community, leadership & fundraising?
~ Should there be open source nonprofit software built by nonprofits?
~ What lessons can be learned?

NOTE: I am not affiliated with Techrocks and write this impression of ebase as a member of the ebase community of consultants.

===========================
What is Ebase(R)?
===========================

Ebase is the name of a constituent relationship management system built by nonprofits for nonprofits. The name ebase is owned by Techrocks, the underlying software is licensed under a GNU Public License (GPL) -compatible free software license. Ebase allows four "freedoms" important for any open source product:

--> Freedom to run the program, for any purpose
--> Freedom to study how the program works, and adapt it to your needs
--> Freedom to redistribute copies so you can help your neighbor
--> Freedom to improve the program, and release your improvements to the public, so that the whole community benefits

As long as you don't call it ebase, you can do whatever you like with the software.

Ebase is a freely downloadable application built in Filemaker for Windows and Mac OS. Ebase v2.0 is designed for nonprofit leaders, fundraisers, activist organizers, and database administrators. It allows them to track, manage, and maximize relationships with their donors, volunteers, members and other constituents via every major touch point: email, web, phone, mail, etc.

===========================
History of Ebase
===========================

In 1997, TechRocks created Ebase, constituent relationship management (CRM) software built by and for nonprofits. Driven by the need of a number of environmental organizations for an affordable and robust donor management tool, Techrocks (then Desktop Assistance) created a donor management application that was latter made available to a broad range of nonprofits.

Ebase has always been built with the community in mind. The first version was built with the participation of a small number of nonprofits. In June 2000, a much larger group was convened to define the design direction for v2.0. Most recently, for three days at the end of May at a retreat center up an eight-mile dirt road in Montana, 30 people worked 13 hour days to figure out how ebase can best serve their NPO constituencies and what the community needed to do to make ebase a viable, effective alternative to commercial constituent relationship management solutions.

This was an open source process in terms of software *requirements* but not in terms of software *development*, which fell primarily on the shoulders of two Techrocks staffers: Bob Schmitt and Clif Graves.

~ It is (relatively) easy to find nonprofit partners that will help you figure out what your application is suppose to do.
~ It is hard to find nonprofit partners that will help you code (via contributing developers or contributing money).
~ Nonprofit open source seems to start from customer needs rather than the traditional open source route of starting from cool technical functionality.

===========================
Community Process Yields Results
===========================

Ultimately, TechRocks created an application where a nonprofit can map their business process, convert that business process into what are called item codes, and have a powerful, customized CRM application. Far from a contact manager, over a year of intensive software development on version 2.0 has yielded an application comparable with, and more useful to nonprofits than, commercial solutions targeted at small and medium sized businesses, such as Microsoft CRM (formerly Great Plains). The quality of this application I attribute mostly to Techrock's open, community process of defining what the application should do.

The inherent complexity of this type of application requires that most nonprofits have support in implementing Ebase v2.0 and that a community of consultants and trainers be available to support ebase installations. Recognizing this, TechRocks began to build a community of users, consultants, and developers in 2002 that can support and extend Ebase using open source strategies relevant to their nonprofit mission. This process started well after the application was built.

~ Do you build the software first, build the community first, or try to build both at the same time? Techrocks is having luck with the software first and the community next.
~ The biggest pro of Techrock's approach is that the community has something concrete (defined, working software) to rally around.
~ The biggest con of Techrock's approach is that the community seems to figure that Techrock's must not need any help, making community building a difficult challenge.

======================================
Leadership: Who Leads, How Do you Grow Leaders
======================================

Is an open source community an egalitarian meritocracy based on socialist values?

Is an open source community composed of a single leader with a number of community members that benefit from, and support to a certain extent, the leader's work on software development?

Basically, who leads and what is their leadership style?

Techrocks is in a clear leadership position on the project which has made the production of software based on community requirements by Techrocks staff fairly simple. This same style has not stimulated other individuals and organizations to contribute to ebase with code, developers, financially, or even just with some sweat-equity writing documentation. Interestingly enough, this has not been the case with open source projects like Zope.

The more I think about this, the more I am convinced that the nonprofit sector has more experience in community, collaboration, and community leadership than any existing open source effort. The sector has worked hard on collaboration. We have built an specialty in community building. Most of the nonprofit sector is fundamentally about bringing people together. These are the lessons that should be integrated into nonprofit open source communities.

So the conclusions that I reach have nothing to do with open source and everything to do with community.

~ Strong leadership encourages nonprofit participants **not** to make significant investments because they think the leader will make those investments.
~ Collaboration is a ladder built on trust starting with information sharing leading to coordination leading to cooperation leading to collaboration over a significant period of time.
~ As the more time goes by and community matures, more and more resources external to Techrocks are being invested in ebase. Perhaps their model of taking responsibility and then seeding it the community will be effective.

========================================
Responsibility/Fundraising: Managing it/Paying For It
========================================

Techrocks has taken sole responsibility for managing and paying for ebase. This is fundamentally different from a community collaborative or open source community where responsibility/funding is shared among a small group of player (often the group is very small- two or three players). By taking this role, they were the sole fundraisers for the project. Without Techrocks, there is no software.

In open source communities, the software often lives on after a major partner leaves (even in communities like Zope where a corporation is behind the software). With the effort to port Ebase to a non-Filemaker platform, Techrocks is working on bringing together partners that will form more of a collaborative of shared responsibility for the code and for fundraising. This may bring ebase to the point where the software is not dependant on Techrocks.

Another characteristic that the ebase project highlights is that nonprofit open source projects are more funding dependent than traditional open source efforts. Nonprofits do not have software
development resources and therefore need to buy them as part of a project. Throw in the overhead rates, and it takes a significant amount of money for a nonprofit to participate in an open source project.

- If a single organization takes total responsibility for a project, the project is totally dependent on the organization. The open source goal of having the software live on beyond the involvement of key partners cannot be achieved.
- There are plenty of examples of nonprofit collaboratives with joint responsibilities and fundraising (mostly lead agency models), but I know of no examples of a nonprofit software project run this way.

===============================================
Nonprofit Open Source Is Different From "Normal" Open Source
===============================================

Traditional open source projects have one set of players: developers. Developers decide what to build, build it, and use the resulting software.

Nonprofit open source is a lot more complex. There are technology service organizations (TSO), intermediaries like Techrocks and NPower that deal with nonprofit technology trends and provide direct services to nonprofits. There are consultants that support TSOs and also
provide direct services to nonprofits. There are customers, the NPOs that will actually use the software. There are developers, often hired by customers or TSOs to build software.

I feel like nonprofit open source communities need to be driven by the TSOs. TSOs are the only organizations specifically focused on NPO technology trends and sector initiatives. These are the folks with the tech savvy to understand the benefits of open source and the connection with customers to ensure that something useful gets built. They are also the ones to identify, within the sector, where the commercial options fall short.

Customers will always be the source of software requirements, but are unlikely to be sophisticated in their thinking-- most ebase customers don't really want to be part of an open source community, they just want to download the software, use it, and have their questions answered.

Consultants that deal with NPO needs every day are looking for the best solutions. In the case of ebase, they find the low start up costs, ability to customize the code base, and responsiveness of the ebase community created by Techrocks, allows them to deliver solutions that meet their clients needs in ways that commercial options cannot.

Finally, professional software developers don't have much of a role in ebase. The ebase development team is on Techrocks' staff. This is one place that where the quality of software can be increased if professional developers are engaged in building the tools in the first place.

==================================
Is There a Need for NPOs to Create Software?
==================================

One of the most common reactions to Nonprofit Open Source in the NPO technology community is that nonprofits are not software developers. They should just take software " off the shelf" from commercial vendors (or even the traditional open source community) and use it. Along with this argument comes the one that NPOs need never find themselves in a situation where they need to build custom software.

Yet the fact is, today, millions of dollars are being spend by NPOs on custom software.

Should nonprofits like Techrocks build software?
They met an unmet need and are currently number 3 in the marketplace. The market seems to think it was a good idea. They serve a size of NPO that few commercial entities would consider a market.

Should collaboration (via GPL License) be the rule in nonprofit software development?
So far ebase is the only major example. Most of the TSO community seems not to think it is a good idea (the software they build is not open source).

What is the strength of nonprofit open source?
Depends on from whose perspective you examine the question. Ebase works well for TSOs, consultants, and customers. Does it work better than commercial solutions? The installed base of ebase seems to indicate yes. So perhaps the strength is that it more precisely aligns the functionality of the software to the needs of customers.

-----------------------------------------------------------------------
TAKE ACTION
-----------------------------------------------------------------------
~ Explore a partnership with another organization to build a piece of software critical to your mission, but not provided by commercial software developers.
~ Send david an email with 5 reasons open source *is* or is *not* relevant to nonprofit organizations.

-----------------------------------------------------------------------
REFERENCES
-----------------------------------------------------------------------
http://www.ebase.org/
http://www.techrocks.org/
http://www.zope.org/
http://www.fsf.org/

Social Source Newsletter v1#1

Social Source Newsletter
July 2002 v1 #1

This occasional newsletter is dedicated to exploring the relevance of open source software development and concepts to nonprofit organizations.

-------------------------------

IN THIS ISSUE

-------------------------------

Steve Wright Proves that Open Source can be Plug and Play!

~Three hours to a functional server

~Novice-friendly

~Coaching is key

University-based Models of Nonprofit Open Source Development

~Universities building custom software for nonprofits

~Is the model replicable and/or scalable?

=================================

PLUG & PLAY OPEN SOURCE
=================================
When I talk to people about open source solutions, I often get what I like to call the "command line" reaction: Everything must require the command line. Everything must be hard. Apparently, everything must be scary.

With modern open source distributions, this does not have to be the case, as Steve Wright from the salesforce.com/foundation points out.

[Quoted with permission]
>I send out a version of this email anytime some one mentions open
>source. Here is my latest Open Source story.
>
>In a total of 3 hours I sat down with a Community Technology Center
>(CTC) lab manager who had no previous experience with Linux and
>installed a Mandrake Linux OS server which included: 1) Apache - Web
>Server 2) Mysql - Database 3) PHP - ASP like programming language that
>enables interactivity on your website. There are several web portal
>systems that are being developed for on-line communities that use this
>language. You do not need to know any MySQL or PHP to install these
>portals and they provide a community web interface that allows for
>individual logins, discussion groups, newsletter-like functionality.
>Image upload/viewing. Content creation with NO HTML knowledge
>necessary. The installation requires some nerdability but mostly it
>requires the desire IO MAKE It happen. Check out
>http://www.postnuke.com. 4) SAMBA - Windows networking server
>5) NetaTalk - Appletalk server
>
>EVERYTHING worked "out of the box." When I left this machine was
>serving webpages AND acting as a cross-platform Intranet server. The
>only cost involved was the machine and the $30 for the Mandrake CD's
>(which can be downloaded or copied for free.)
>
>Steve Wright
>Program Director
>Salesforce.com/foundation

=================================

How to Make Plug & Play Open Source Work
=================================
I drew some conclusions from Steve's experience.

Mentoring
~~~~~~~~~
A lot of technology adoption can be driven by mentoring. Sitting down with someone and helping them install software via "shoulder to shoulder" training is a strong model. A good question to ask yourself as a nonprofit is whether you are willing to be mentored, or would rather pay for the luxury of not thinking about technology by hiring a consultant.

Commitment
~~~~~~~~~~~
I would guess that the long term success of Steve's effort is 100 percent dependent on the commitment of the CTC lab manager to figuring out how this stuff works. They have a great head start, however, since the open source tools Steve is using are no more difficult to use than networking a couple of PCs.

Consultants need to become familiar with open source options
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If it really is this easy, perhaps we should be focusing on "shoulder to shoulder" training for nonprofit consultants so that they can have open source tools in their toolbox right next to IIS and Access. Given that it is apparently *that* easy, why is it that I haven't heard stories from the NPowers of the world about how they have successfully installed open source solutions? If they have tried to use open source tools and found them *not* to work in certain situations, these stories are equally important.

Open Source is not for everyone
~~~~~~~~~~~~~~~~~~~~~~~~~
I am always very cautious in evangelizing open source too aggressively. Steve was able to install the software simply and easily. BUT, what is the total cost of ownership (TCO) of this solution vs. others?

Will these agencies have the internal staff to support the server over the long term? Will Steve be called on every month to tweak some small feature of the servers that have been installed? Will Steve eventually wish these people just stop calling? ;)

Hopefully, the TCO study that is being implemented by the Nonprofit Open Source Initiative (NOSI) will answer some of these more strategic, long-term questions. If you want to participate/ contribute to the in the NOSI TCO study, visit http://www.nosi.net/ and join the email list.

A good list of OS software for nonprofits would be nice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Maybe we need to convince the guys at http://www.freshmeat.net/ to add "nonprofits" to their list of intended audiences. I've had discussions with the foundry manager at http://www.sourceforge.net/ about creating a nonprofit foundry and it seems to be around the corner (see the beta at http://nonprofit.foundries.sourceforge.net/).

There are also efforts to produce a CD of relevant software, though the various distributions (Mandrake, Red Hat) seem to do a good job of putting it all in one place. Perhaps the next phase is to create an .rpm that cuts down Steve's install time from 3 hours to 20 minutes (An .rpm is an 'installer' for Linux systems that installs and configures software without user intervention).

-------------------------------

TAKE ACTION
-------------------------------
~ Teach yourself how to install Mandrake and and do some shoulder-to- shoulder training with an accidental techie or nonprofit technology consultant.

~ Share a similar story by writing it up as a case study and posting it on the NOSI web site or email list. Perhaps others will be inspired by and learn from your experience.

-------------------------------
REFERENCES
-------------------------------
http://www.nosi.net/
http://www.freshmeat.net/
http://nonprofit.foundries.sourceforge.net/
http://www.salesforcefoundation.org/
http://www.postnuke.com/
http://www.mandrakelinux.com/en/

======================================================================= The Coolest Thing I"ve Seen All Year (University Open Source Development for Nonprofits) =======================================================================

The email started with the modest sentence, "An innovative class is seeking community projects for their students learning how to develop web-based applications." I was pretty much hooked from that single sentence.

Four years ago, when I was the Director of the Eastmont Computing Center in East Oakland, I badly wanted to deploy a community-focused, web-based application serving our neighborhood. I didn't have the money, skills, or time to create a solution--here I find a group providing the assistance I needed in 1998.

Randy Groves and Doug Schuler from The Evergreen State College in Olympia, Washington are giving a college course entitled "Community Information Systems." What better way to learn about community information systems than to build one?

"A major part of this program will involve our students (in teams of three to six) working with communities around the world to develop information and communication technology that will enable that community to further some of its aspirations. We're planning to work with eight to 15 communities. We plan to concentrate on communities that may not be receiving adequate attention in relation to information and communication technology."

The Evergren model strikes me a good, concrete example to take to universities in your local community. Maybe some of them will adopt the same approach. Ask them to dedicate class projects to local community information needs. Many universities already offer community focused classes, but may not be doing community focused projects (the University of Massachusetts, Boston, for example-- http://www.cpcs.umb.edu/cmt/).

So Randy and Doug have put out a call for proposals. Community groups are encouraged to fill out an online form to express their interest in participating (http://www.scn.org/edu/tesc-ds/2002-2003/misc/partners-survey.html).

===================================

Universities as Application-Building Resources ===================================

When I ran the Eastmont Computing Center--a community-based agency with a budget of under $500,000--I always got the advice to "partner" with the local university (University of California, Berkeley, in our case). I got great conversation, but little in the way of concrete resources for my agency (though we did jointly launch a regional initiative with university resources).

University partnerships are *hard* in the same way any partnership is hard-- both partners have to get something out of the partnership. Randy and Doug"s model of a successful project makes that partnership process a little easier. Plus, many universities are actively seeking ways to connect with the work going on outside their ivory towers.

With a concrete plan, like the one articulated in the call for proposals, the process of generating a university partnership becomes possible even if you don"t have an existing relationship with the university. So what do you do?

1. Research. Find out if there are courses or departments relevant to community information systems. Library Sciences programs often have such a component. Make a list of relevant professors and administrators.

2. Call your list, Tell them you want to replicate a fantastic model for students doing community work as class projects. Send them call for proposals as an example. Add people to your list as you get referrals.

3. It either worked or didn't. Once you are at the end of your list, you will have either started to engage with someone or you"ll have found out there is not much interest in the concept.

-------------------------

TAKE ACTION

-------------------------

~ Copy Randy and Doug"s call for proposals and send it to your contacts at your local university. They might become inspired and implement a similar class project.

-------------------------

REFERENCES

-------------------------

http://www.scn.org/edu/tesc-ds/2002-2003/misc/partners-survey.html http://grace.evergreen.edu/cis http://grace.evergreen.edu/cis/Projects.html

Large Scale System Development in Open Source

Open-source for nonprofits is a broad field. NPOs can adopt existing open source software (OSS). They can influence open source projects. They can start open source projects.

NPOs often focus on open source that solves needs that are common across industries (Samba for file sharing, Linux for the operating system, etc.). They are just beginning to explore this first stage of adopting software and have little visibility into the potential for starting their own projects.

This is where the potential revolutionary impact of open source for nonprofits comes in. Most NPOs have very unique business processes, data collection, and evaluation needs. However, within nonprofit sectors, these needs can be defined generically. Every fundraising process starts with a donor, proceeds to an ask, and succeeds with a check. Every community technology center program starts with a participant, proceeds to an educational event (class, e-learning, etc.) and succeeds with the accomplishment of an educational objective.

Nonprofits are beginning to learn that automating these business processes leads to higher organizational impact at lower costs. So some folks are going out and building applications to automate these business processes.

Food banks are building applications that manage client intake, reporting to funders, nutrition services, kitchen operations and delivery operations. Most of the time, they end up building these applications in a closed source fashion with the expectation that maybe, “someday” they can sell the resulting application to other organizations. I have yet to see one successful example on this business model, but unsuccessful examples abound.

What if all the food banks pooled their pennies to collaborate on an open source food bank management application? And they have a lot of pennies… three major food banks could easily scrap up $100k apiece for such a project, if they understood the potential.

The only change to their current behavior would be to insist contractors work on the projects using open source software development strategies and that the code be released under an open source license (preferably GPL).

The benefits would be:
Higher levels of functionality at a lower cost than any single organization could achieve.
Organizations without the resources to build their own applications have access to industry best practices embedded into the open source applications.
Applications are updated and extended more regularly because rather than starting from scratch every 15 years with a new application at a high cost, an organization could update their internal application from the open source project every five years at a lower cost.
And many more.

BIO

David Geilhufe has worked in community technology since 1995 when he began teaching Washington DC at-risk youth Internet and programming skills and placing them in full time employment. He latter founded the Eastmont Computing Center, a community technology center serving individuals and organizations in Oakland, CA. As a founding board member of the Community Technology Centers’ Network (CTCNet) he worked to ensure affiliates received useful and direct services from the national office. Currently, David runs Social Source Software, LLC which specifies, designs, and builds complex open-source web applications for nonprofit organizations in the U.S. and abroad.

The original Social Source Software concept (CTSoft)

Welcome to the home page for the CTSoft concept. I need your help to define and articulate a concept that has been developing in my mind over the past year.

In 2000, I left Eastmont Computing Center to become the Senior Product Manager at digiGroups, leading our effort to build online collaboration software for Fortune 50 companies. With $12 million from Accel and other venture capitalists, it became clear that building enterprise quality applications is not rocket science.

At Eastmont we did a lot of begging to get the software we needed. In fact, we shelved a number of online neighborhood organizing projects because we could not find affordable software (we weren't even looking for free software, just affordable).

What if we had the software we needed? What if it met many of our key needs? With an open-source platform delivering web applications with 80% of the functionality we need, we would have embraced it, deployed it and used the software to create outcomes.

This led me to an effort to figure out whether open-source, community technology software development is something that I can make a contribution in. To decide that, I have some questions:

1) Was Eastmont unique, or is this story replicated across the CTCNet membership, the AFCN membership, the Neighborhood Networks Sites, the Department of Education CTC sites & others?

2) Can a critical mass of open source users be created to generate the cash required to continue to build & extend the software platform and applications?

3) What applications are needed? What applications can be funded?

4) If we build it, they will not necessarily come. How do we support the level of deployment, adoption and use that is required to achieve the benefits of open source software communities?

5) Last a personal question: Is there enough interest, traction and commitment to the concept? Is there a team, a community and a shared vision? When is it time to consider quitting my job and join a team and a broader community to make it happen?

.NGO Concept Paper

.NGO
The Nonprofit Web Application Platform


1. EXECUTIVE SUMMARY

1.1. The Problem
Non-governmental organizations (NGOs) face significant barriers to using Internet technologies to improve their ability to fulfill their mission. In a technology environment dominated by Fortune 500 corporations and .COMs, NGOs lack access to technology that is affordable, meets their unique business processes, and evolves as nonprofits adapt their processes to interact with their constituencies using technology.

Without access, NGOs will never discover how to deploy state-of-the-art, mission-focused, Internet technologies. Mission-driven NGO technology is at risk of forever being relegated to being generations behind the for-profit sector, consisting of outdated, obsolete, inefficient tools.

1.2. The Opportunity
In spite of the barriers to mission-driven NGO technology, a number of leading NGOs are building mission-driven web applications today, often forced by limited resources into using inferior technologies originally designed for the needs of corporations with vast armies of technical staff. By bringing these organizations together to create the .NGO platform under an open source development model, the partners can transcend their resource constraints to create state-of-the-art, mission-driven, NGO web applications. Applications built to meet the needs of NGOs.

The Open Source software movement has created a model of software development that can vault to mission-driven NGO technology to standing shoulder-to-shoulder with its for-profit sector counterparts. The open source technology development model -- where anyone can improve technology because it is liberated from the legal constraints of intellectual property, as long as improvements are subsequently contributed to the community for others to improve upon -- represents an unrealized opportunity for the nonprofit sector to develop and disseminate technology that is mission driven. As technology development environments become more accessible, nonprofits can mould technology in their own image.

1.3. The Plan
The .NGO project will bring together organizations that are already funded and building web applications. Through self-selection, a subset of these organizations will be supported in creating a state-of-the-art, open source web application platform common to all participants. Their diverse applications will ride on top of the application platform, much the same way that MS Word rides atop MS Windows.

Compared with autonomous efforts, such a platform reduces total software development costs to all participating organizations, increases the functionality available to end users in each of the applications, and expands the number of organizations capable of using mission driven information technology.

The .NGO initiative has three goals:

• Bring nonprofit leaders currently developing web applications into a forum to explore how open-source application development can improve their current and future applications projects. (Phase One)
• Explore the possibility of standardizing on a single technology platform, allowing the partners to share resources and radically reduce the cost of application development.
• Develop a concrete action plan to enable participating partners to build a joint, open-source platform for their web applications. (Phase Two)

To achieve these goals, .NGO will conduct four national meetings. The first, sponsored by Stanford University and web cast nationally, will present an unbiased assessment of major open source technologies relevant to mission-driven NGO web applications. This essentially provides the menu of technologies that can be chosen to form the core of the .NGO platform.

Two additional regional meetings will facilitate the process of evaluating and agreeing upon a single technology platform.

The last meeting, sponsored by the Alliance for Community Technology/ University of Michigan, will bring together committed participants to develop a concrete work plan to map out the creation of the .NGO platform.

David Geilhufe and Vlad Wielbut will staff the project. A steering committee composed of 12 leaders in community technology will provide governance.

The project requires $50,000 to complete, with in-kind commitments already received from Stanford University and the Alliance for Community Technology. Potential funders are asked to consider contributions of $50,000 or $25,000.

WHAT IS A WEB APPLICATION PLATFORM?
A platform provides the shared building blocks for web applications. Almost every web application needs some of the same functionality- security, permissions, content management, authentication, etc. Rather than reinvent the wheel each time a new application is built, starting from a platform enables faster development times, cheaper projects, and more extensive functionality.

WHY NOT A COMMERCIAL SOLUTION?
Commercial solutions are costly. A Fortune 500 firm make the large investment because they can deploy the software across the entire corporation. Sharing a web application across a network of human rights organizations, for example, would cost tens of thousands of dollars to each organization.