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
Tuesday, October 1, 2002
Unlocking the Potential of Open-Source
Thursday, August 1, 2002
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/
Monday, July 1, 2002
Social Source Newsletter v1#1
July 2002 v1 #1
=================================
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
=================================
=================================
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).
-------------------------------
-------------------------------
~ 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/
Saturday, April 13, 2002
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.
Wednesday, February 6, 2002
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?
