In the material below, we discuss some unintended consequences that occur as OSS approaches that have succeeded in well financed corporate environments are applied to the social sector.  For instance, a primary challenge is that custom OSS implementations frequently leave clients trapped on a "Code Island" that has characteristics similar to traditional software implementations that use proprietary compiled, client-server, or ASP software.

In addition to pointing out some challenges, we also discuss what we and others are doing to help realize the promise of OSS in the social sector - an approach we call Managed Open Source.  Managed Open Source reflects the unique needs of the social sector by providing software that is both accessible and well managed.

Challenge #1 - Social sector organizations have fewer resources than corporations

Open source successes like Linux and Apache have succeeded most dramatically in corporate technology environments.  In these situations, the primary users are typically technologists and the clients have the expertise and financial resources to manage and support the implementations over time.

In contrast, most social sector organizations have neither the financial resources nor technology staff to smoothly implement and look after enterprise software systems.  As a result of these differences, social sector organizations attempting to implement and support OSS have frequently experienced many of the traditional software problems faced by smaller organizations – lack of expertise, vendor lock in, higher total-cost-of-ownership, and higher switching costs.

For the promise of OSS to be realized in the social sector, the systems must reflect the unique characteristics of the sector such as ease of use for non-technical users and low total-cost-of-ownership for organizations with small budgets.

Challenge #2 - Most OSS implementations are actually custom projects

The traditional open source project in the social sector is conducted by a developer, agency, consultant, or other professional service provider who downloads an open source software package from the web and then customizes it for a client’s particular need.

The problem is that by paying a developer to customize an OSS package, the social sector organization is actually purchasing a custom software project without being aware of the trade-offs or consequences, some of which are described below.

Challenge #3 - Custom software implementations increase cost

Custom software implementations have a high “total cost of ownership” (TCO).  TCO refers to the cost of the initial project as well as the cost to use, maintain, support, enhance, and fix the software over time.  These costs can be very high and are frequently higher with custom implementations.

In the corporate and IT sectors, this challenge is easily managed because the clients are well resourced and technical.  Moreover, for large organizations, the cost savings of implementing a system like Linux can far outweigh the total costs of ownership.

In the social sector, the issues are different.  Most social sector organizations have neither large budgets nor IT staffs to provide continuity in managing complex or customized software.  And, they frequently don’t have large existing IT costs that can easily be reduced through something like a Linux implementation.  As a result, many social sector organizations get “free” software but actually pay much more in TCO for:

  • Technologists who know how to implement that software
  • Technologists who know the underlying technology languages
  • Technologists who know the specific customizations implemented for a particular client.
  • Technologists who can manage the technical environment (e.g. servers and operating systems)
  • Consultants who know how to use the system and can train and support staff over time

In most contexts, OSS is associated with a lower TCO.  But, in the social sector, the result is frequently the opposite. 

Challenge #4 – Custom software implementations 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 hold clients hostage.

In the corporate sector, the use of OSS can significantly reduce this reliance on a particular software vendor.  Moreover, corporate and technical users of OSS have the resources and skills to manage vendor lock in related to the custom uses of OSS.

In the social sector, the use of OSS often increases “vendor lock in” by making the client extremely dependent on the consultant that did the initial customizations.  In practice, this often means that there is only one person on earth who is familiar with how a particular organizations software was customized within hundreds of thousands of lines of code.  So, although dependence on an expensive software platform is lessened, dependence on a particular implementations consultant is often increased dramatically.

Challenge #5 – Custom projects are difficult to upgrade

One of the great values of good software is its ability to easily upgrade over time to add features and fix bugs.  Anyone who has used Microsoft Word over the years recognizes this value.  Unfortunately, one of the few downsides of OSS implementations is that future upgradeability is often sacrificed by customizations that are made to an OSS system for a client.  Said another way, one of the great advantages of OSS for consultants and developers is its flexibility - the ability to work directly in the system code to make custom changes for clients on an as needed basis. 

The down side of this flexibility is that once the customizations have been made, future upgradeability is compromised.  That is, when a new version of the OSS comes out with new fixes and features, it can’t be applied cleanly without over-writing all the previous customizations.  As mentioned above, this kind of customization can be managed by large organizations with strong technical resources.  However, in the social sector where funding and technical resources can be scarce, customized implementations that compromise upgradeability often have the unintended consequent of raising the total cost of system ownership.

Challenge #6 – Traditional OSS leads to a “silo” approach to systems

Traditional OSS implementations in the social sector often re-enforce fragmented technology “silos” in which separate components (such as a CMS, a database, an event manager, a document system, and so forth) are used for different organizational functions in isolation from one another.  This “silo” phenomenon is a byproduct of one of the great successes of OSS – that systems evolve organically as many different developers solve many different problems.  But, when these isolated components are applied by an organization that is trying to solve multiple problems, the challenge is how to develop a truly coordinated system that crosses organizational and system boundaries. 

The silo problem becomes even worse when custom integration is done to connect the different components (e.g. connecting your database to your CMS). Custom integration often results in vendor “lock in” or a steep and expensive learning curve for anyone new who is trying to upgrade or improve the system (or any of its components) over time. 

As with previous challenges, these problems are manageable for corporations and other large organizations with a well resourced, consistent, and highly skilled technology team that can manage and document these customized systems.  However, in the social sector most organizations do not have the necessary resources.  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.

The Solution - the emergence of Managed Open Source

Far from being critical of others, we have struggled with issues described above with our own clients many times.  In the past, by customizing our software to meet every and any client need, we accidentally enabled many clients to drive up their costs, become over-dependent on a few people, and learn the hard way about the trade-offs inherent in managing software.

As a result, we learned several lessons which have led us to creating an approach which combines the value of traditional open source with the specific needs of the social sectors.  We call this approach Managed Open Source and we think that other leading edge providers will be moving in this direction as well.

Lesson #1 - Open Source Software in the social sector should be very easy to use.

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

Lesson #2 – Total cost of ownership for open source software in the social sector should be affordable.

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 - Open Source Software in the social sector should be well managed.

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.  These are the key areas where poorly customized implementations come back to haunt clients in the form of extra costs to fix, undo, or improve on the initial implementation.

Unlike much open source software in the sector, Managed Open Source has spent a great deal of time simplifying the:

  • user experience for non-technical users
  • ability to have multiple modules without any customization
  • ability to customize and integrate intelligently so as to maintain upgradeability
  • upgradeability of the system so that upgrades and patch can be easily applied