The Truth About Open Source in the Social Sector

The High Cost of "Free" Software - Summary

[Note - To read the full version of this article, click here.]

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 the like) 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:
     1) Reflect the unique needs of the social sector rather than technologists
     2) 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 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
  • Inability to upgrade

    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 our experience, many executive directors and other social sector practitioners often are not aware of the trade-offs in these customized OSS projects.  That is, they think 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 becomes limiting.  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 "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 [i.e. 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 the customization work.  In practice, this often means that there is only one developer on earth 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 Reinforces "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 identified a few important requirements for open source software to succeed in the social sector.

    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 usually not enough

    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 application code.  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. Rather than feel grateful towards us, they felt stuck with a difficult IT burden that was not easily manageable.

    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 scenario.  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 upgrades
    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 ability for future developers to make smooth, automated upgrades of the core system from one version to another.