Inability to upgrade
For the promise of OSS to be realized in the social sector, OSS systems must reflect the unique characteristics and needs of the sector, such as ease of use for non-technical users and low total-cost-of-ownership for organizations with small budgets.
How Open Source Projects Work In The Social Sector
In order to effectively evaluate OSS, it’s helpful to know how open source projects are typically done in the social sector. Although details vary from project to project, the basic steps of many OSS implementations are as follows - a developer, agency, consultant, or other professional service provider:
1. Documents the client’s requirements
2. Downloads various open source software packages, modules, or raw code from the Internet, and
3. Customizes and packages OSS code to create a system that meets the client’s needs.
The project requirements vary but frequently include areas like content management, a contact or member database, event registration, an email "blast" module, reporting, and other functions that many organizations need to manage. In addition, these projects may address questions of support, hosting, maintenance, and (sometimes) upgrade options.
Said another way, OSS projects in the social sector tend to work on a decentralized model. That is, the way the original code is created is often decentralized with contributions by many disparate developers. And, the way that the code gets to social sector organizations is further decentralized in that local consultants subsequently customize OSS code for their clients. This decentralized model can work well and there are many examples of its success. But, the decentralized model of OSS deployment is different from some other projects and products that fly the OSS banner (e.g. Linux, Firefox, and MySQL). The key for social sector practitioners is to understand which model of OSS deployment they are buying into and what is required to make it successful.
Open Source Software Projects Are Customization Projects
Because OSS usage in the social sector tends to work on a decentralized model, the critical issue for social sector practitioners to understand when implementing OSS is that these projects are customized technology development projects. That is, the consultant implementing the OSS is doing custom programming and configuration to put together the various pieces and provide the client with the 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. And, whereas they often think that they are contributing to the development of a traditional software product (except that it's free) with their technology investment, the truth is that they are mostly purchasing customizations of technical components that they will have to maintain at considerable expense.
Winners And Losers
For a social sector executive making technology decisions in the open source era, it is important to understand who wins and who loses as OSS ripples across the technology industry. Or, as was famously said in another context, "follow the money."
Simply put, OSS projects tend to shift:
1) Fees away from traditional software companies and towards technical consultants and
2) Costs away from the beginning of the software life cycle and towards the end.
As a result, proprietary software companies with high software prices will lose. And technical consultants who can claim some of that margin while offering clients competitive prices will win. When it comes to implementing enterprise OSS in social sector organizations (e.g. content management, contact / member management, fundraising tracking, email newsletters and the like), it should not be a surprise that OSS technologists are enthusiastic while traditional software companies downplay the changes.
For the social sector decision-maker in this environment, the challenge is to see through the fog of jargon, buzzwords, winners, and losers to make well-informed, long term decisions. To that end, we have described below several hidden costs in OSS and suggested ways that social sector organizations and technologists can make the most of both OSS and traditional software approaches.
When Free Isn’t Free - Custom Software Implementations Increase Cost
Many social sector practitioners view open source software – incorrectly – as free. Because OSS projects are in fact custom technology implementations, they 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 OSS implementations often drives costs much higher than traditional software in the social sector.
In the corporate and IT sectors, this challenge is easily managed because the organizations are well resourced and technically staffed. Moreover, for large organizations, the cost savings of implementing an OSS system like Linux can far outweigh the total costs of ownership since they can often displace a more expensive solution like Microsoft’s. As a result, in the corporate context OSS is associated with a low TCO.
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. At the same time, with the number of low cost software providers growing rapidly, the TCO of traditional software is dropping dramatically.
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 the corporate sector, the use of OSS (e.g. Linux) can significantly reduce the reliance on a traditional software maker. The conventional wisdom has been that this switch reduces vendor lock-in because once corporate technologists have been freed from Microsoft, they will have more choices and lower costs with their vendor relationships.
However, this conventional wisdom has been questioned by the OSS movement's own leaders and 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 extremely 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. So, even another consultant who is familiar with the underlying technologies will have to learn the customizations from scratch. As a result, dependence on a vendor (in this case a consultant rather than a software company) often increases dramatically.
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. Anyone who has used Microsoft Word over the years has experienced this value. Unfortunately, one of the downsides of customized OSS implementations is that future upgradeability is often undermined by the customizations themselves. This is actually just the flip-side of one of the great values of OSS – its openness, flexibility, and decentralization. Because the code is accessible, technologists can work directly in the system code to make custom changes for clients.
The problem is that once the customizations have been made, future upgradeability is often compromised. That is, when a new version of the OSS comes out with new fixes and features, it usually can’t be applied cleanly without over-writing all the previous customizations.
As with previous examples, well resourced corporations and start-ups can easily manage upgradeability in their implementations. However, in the social sector where funding and technical resources can be scarce, customized implementations that compromise upgradeability often have the unintended consequence of raising the total cost of system ownership and actually limiting access to upgrades and improvements relative to more traditional software.
Traditional OSS Reinforces "Silos"
Traditional OSS implementations in the social sector often reinforce fragmented technology "silos" in which separate components (such as a content management system, a database, an event manager, a document system, and so forth) are used in isolation from one another. Like the upgradeability example above, this “silo” phenomenon is a byproduct of some of the great strengths of OSS – that OSS is easily available and that OSS evolve organically as many different developers solve many different problems. But, when these isolated components are adopted by an organization that is trying to solve multiple systems problems, this organic approach frequently limits the ability to develop a truly efficient and cost effective system that crosses organizational and system boundaries.
The silo problem becomes even worse when custom integration is done to connect the disparate components (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 a steep and expensive learning curve for anyone new who is trying to upgrade or improve the system (or any of its components) in the future.
As with previous challenges, these problems are manageable for well resourced corporations with a consistent and highly skilled technology team that can manage and document the integration between customized silos. 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.
Lessons Learned
Despite all these challenges, the open source approach has a bright future in the social sector. However, for OSS to reach its potential, it must both reflect the unique characteristics and needs of the social sector. As technologists and social sector managers, we cannot assume that the success stories of corporate computing will translate smoothly to the social 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. And, we have evolved towards an approach in our own work of combining the successes of both open source (easy access to code, flexibility, low cost, and a community of contributors) and traditional software (upgradeability, ease of use, low TCO) in our approach to social sector client.
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 and consultants).
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. 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.
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 software 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 your technology providers or consultants that you work with to:
1. Provide open APIs and Open Standards
This is easier said than done because:
- most social sector managers don’t have a clear sense of what this means,
- some providers don’t want to open any aspect of their systems for free, and
- other providers either can’t or don’t have the time and resources to create sophisticated APIs.
Nevertheless, this is an important long-term goal, both to make sure that your system can be easily upgraded and to enable data to travel more easily between systems.
2. Provide a clear plan for future upgrades
This is a question that is rarely asked by social sector decision makers that has a tremendous impact on long term cost. One reason that OSS consultants often don’t plan for future upgrades is because this is rarely requested by their clients. When asking this question make sure to determine whether upgrades will be automated or will require a lot of hands on consulting work.
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 to smoothly and quickly upgrade the core system from one version to another. If your provider doesn’t have a clear strategy for this issue, then you are likely to be left alone on a "code island" without an easy way to manage your system long term.
Finally, for other OSS providers and advocates, I would suggest more openness to hybrid models and to some centralization (of code, standards, versions, etc.) that may help OSS avoid fragmentation and deliver more valuable contributions to the social sector.