The Truth About Open Source in the Social Sector: Lessons from the Trenches

By Nick Gleason

Open Source Software (OSS) is one of the hottest trends in social sector technology. With rhetoric at a fever pitch, social sector managers and executives who are evaluating technology options need to clearly assess how the open source trend meets their needs. This article explores some of the key issues, challenges and solutions in bringing enterprise OSS (in particular OSS that helps manage web content, contacts, donations, ecommerce, emails, and so forth) to social sector organizations. In particular, I argue that OSS has not yet come close to realizing its potential in the social sector and that ultimately the best OSS solutions will reflect the unique needs of the social sector rather than technologists, and combine the best aspects of traditional and open source software.

What's Unique About the Social Sector?

Open source successes like Linux, Apache, and others have succeeded most dramatically in well-resourced private sector (corporate or start up) technology environments. These OSS tools are typically "tools for technologists" - created by technologists for technologists as a way to simplify corporate computing challenges. These private sector users frequently have both extensive resources and a compelling return on their OSS investment because they can replace existing expensive software from Microsoft and others. In contrast, most social sector organizations have very limited financial and technical resources and don't have a cost savings opportunity to replace expensive existing infrastructure (like Microsoft NT with an OSS solution). Moreover, these social sector practitioners are frequently stuck with many of the problems associated with traditional custom software such as high total-cost-of-ownership, vendor lock in, extensive consulting, high switching costs, and lack of upgradeability.

Open Source Software Projects Are Customization Projects

A critical issue for social sector managers to understand when considering OSS is that projects based on OSS are usually customized technology development projects. That is, the consultant implementing the OSS typically downloads open source programming code and components from the Internet and conducts custom programming and configuration to craft a final deliverable.

In my experience, many executive directors and other social sector practitioners often don't appreciate the trade-offs in these customized OSS projects. That is, they think that they are getting a traditional, packaged software product like Microsoft Office that is easy to use, maintain, patch and upgrade. In reality, they often receive customized code that is unique, poorly documented or supported, and difficult to maintain or upgrade.

When Free Isn't Free - Custom IT Implementations Increase Cost

Many social sector practitioners view open source software - incorrectly - as free. In fact, because OSS projects are custom technology implementations, they actually have a high "total cost of ownership" (TCO). TCO refers to the cost of the initial implementation project as well as the cost to learn, use, support, enhance, fix, and upgrade the software over time. The TCO of customized IT implementations - including customized OSS projects - often drives costs much higher than traditional software in the social sector.

Whereas private sector users often have plentiful technology resources and a good business case for using OSS, in the social sector, the issues are different. Without large budgets or IT staffs, the cost of managing complex or customized software can quickly outweigh the benefits. And, without large corporate IT costs that can easily be reduced by substituting OSS, one of the central rationales for OSS becomes irrelevant for most social sector organizations. As a result, many social sector organizations purchasing "free" OSS actually pay much more in TCO.

Custom Projects Increase Vendor "Lock-In"

Vendor "lock-in" is a common characteristic of software implementations and refers to an over-dependence on a particular vendor (e.g. Microsoft) who can charge high prices and in effect hold clients hostage. In contrast, OSS has been viewed as an alternative that lessens vendor lock in.

However, this conventional wisdom is increasingly being questioned by the OSS movement's own evangelists. According to Internetnews.com, at a recent LinuxWorld presentation Jim Zemlin, the Executive Director of the Free Standards Group argued that open source is as vulnerable to fragmentation and lock-in as traditional software. "You can get just as locked into an open source implementation of something as you can a proprietary version," he explained and went on to add that "There is a real fundamental paradox that I think the open source movement and end users need to solve and that's the paradox of throats to choke [ie. having an accountable vendor] versus vendor lock-in. That paradox is that the throat you are choking is the vendor who is locking you in."

In the social sector, similar OSS dynamics increase vendor lock-in by making clients dependent on the consultant that did their customization work. In practice, this may mean that there is only one individual developer who is familiar with the details and nuances of how a particular organization's OSS implementation was customized within thousands of lines of code.

Custom Projects Are Difficult To Upgrade

One of the great values of good software is the ability to upgrade it easily to add features and fix bugs. Unfortunately, one of the downsides of customized OSS implementations is that once the customizations have been made, the system cannot easily be upgraded in the future without over-writing all the previous customizations.

Traditional OSS Leads To "Silos"

Traditional OSS implementations in the social sector often re-enforce fragmented technology "silos" in which separate systems (such as a content management system, a database, an event manager, a document system, an e-newsletter system, and so forth) are used in isolation from one another.

This happens because OSS is typically created as a stand-alone system or silo (e.g. a content management system or an event system, or a contact database) rather than as an integrated whole. This silo dynamic limits the ability to develop a truly cost effective system that crosses organizational and system boundaries.

The problem can become worse when custom integration is done to connect the stand-alone systems (e.g. connecting your database to your web site content management system). As mentioned above, this custom integration often results in high TCO, vendor "lock in," and an expensive learning curve for anyone new who is trying to upgrade or improve the custom integrated system in the future. As a result, these silo systems can trap an organization on a code island that ultimately increases costs, increases vendor lock in, and defeats upgradeability.

Lessons Learned

For OSS to reach its potential in the social sector, it must both reflect the unique characteristics and needs of the sector. After years of working on open source implementations in a variety of contexts, I have learned a few important lessons for open source success.

Lesson #1 - OSS in the social sector should be very easy to use.

Since social sector organizations do not have large budgets for technology, training, and support, software must be easy to use for clients and end users (not just for technology professionals).

Lesson #2 - Total cost of ownership for OSS in the social sector should be low.

Since social sector organizations do not have large budgets, the software must have a low TCO, not just an affordable initial implementation cost.

Lesson #3 - OSS in the social sector should be easy to upgrade and maintain.

Since social sector organizations do not have large budgets, the software must be well managed in terms of how easy it is to upgrade, customize, and integrate.

Lesson #4 - Providing clients with source code is not always helpful

One of the rudest awakenings for me in participating in many open source technology projects over the years was that our clients didn't always appreciate the access that we gave them to the code as much as we thought they should. We thought it was virtuous and cool to allow clients to have full control and access to the source code of their applications. What we discovered was that over time many of these clients found it a burden to manage a large customized software system.

Where Do We Go From Here?

As an advocate of both the innovation and accessibility of open source software, and the stability and upgradeability of traditional software, it's not surprising that I view the ideal future as a combination of these two approaches. Here are some concrete suggestions for social sector managers to help create this ideal world. When evaluating software, make sure to ask technology providers or consultants that you work with to:

1. Provide open APIs and Open Standards.
APIs and Open Standards allow a core system to be maintained and smoothly upgraded even while customizations and integrations are conducted. This is easier said than done but nevertheless, this is an important long term goal.

2. Provide a clear plan for future upgradeability.
This is a question that is rarely asked by social sector decision makers and yet it has a tremendous impact on long term cost.

3. Provide a way to make any and all customizations "safe."
Customizing safely means that customizations done to OSS (including visual design work) should not compromise the smooth upgradeable of the core system from one version to another.

Nick Gleason is the Chief Executive Officer of CitySoft, Inc. and has worked as an activist, non-profit manager, and technologist for the last 20 years. A longer version of this article is available on the CitySoft website.