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/