Best Practice:

Investigate “community sourcing” options

“Community sourcing” is a variant of open source that is optimized for the delivery of “enterprise” software technologies (administrative systems, etc.) for public-sector organizations, including government agencies, government operating organizations (e.g., public schools & hospitals), non-governmental organizations, and nonprofits. The community sourcing approach was initially created and supported by The Andrew W. Mellon Foundation, beginning in 2000; currently, a variety of community sourcing projects operate at international scale in multiple public sectors and software markets. Publicly available data[1] from these projects document cost savings ranging from 35%-95%, as compared to the best-feasible proprietary technology alternatives. Private studies confirm these results across several economic sectors, including education, cultural heritage, the arts, and environmental protection. The private data suggest that larger public-sector organizations save more money in total, but that marginal savings tend to be greatest among smaller, less well-resourced organizations.

Best Practice:

There is no “One Best Open Source Organizational Model.”

The viability and long-term success of an open source project are strongly dependent upon a sustaining model that fits the particular open source community. Models such as Apache and Eclipse work particularly well for open-source technologies whose customers are themselves technologists; for instance, programming languages (Perl, Python, Ruby), development environments or frameworks (Eclipse, Rails), content management systems (Drupal, Joomla), and so on. Models such as “community sourcing” are optimized for technologies (financial systems, ERP, other administrative systems) whose primary customers are non-technologists. Such models add protections (e.g., customer-driven checks and balances on project planning and oversight) that help to minimize the “drift” of project priorities away from the interests of the customers who use it. These formal mechanisms are intended to keep the project responsive to its customers—a protection that is arguably unnecessary when the customers are also the developers.

Each model creates its own distinctive sustaining community and culture. For example, both Moodle (www.moodle.org) and Sakai (www.sakaiproject.org) are open-source learning management systems for educational institutions. Moodle uses a “benevolent dictatorship” governance model similar to those in many early OSS projects, and a code-contribution process similar to that of projects such as Drupal (www.drupal.org); Sakai uses community sourcing. Both projects have been successful, and they compete with each other at the margins; however, Moodle has developed a community skewed toward individual contributors and toward larger numbers of smaller installations in K-12 and corporate-training environments, while Sakai has skewed toward institutional contributors and fewer, larger “enterprise” installations in higher education institutions.

Best Practice:

There is no “One Best Licensing Model.”

Much has been written—and much of it mutually contradictory—about whether “free” (e.g., GNU) or “open” (e.g., Apache) licenses are superior. “Free” licenses are particularly valuable when there is significant risk of predatory behavior by commercial firms, such as the reselling of open intellectual property as proprietary without providing benefit back to the project. This makes them particularly valuable for projects comprised of large, diffuse, heterogeneous communities of users that may have difficulty organizing themselves to protect their intellectual property (for example, Linux users). Such communities are the software equivalents of big, diverse cities: they may require the “police protections” provided by a GNU-style license. Conversely, in more homogeneous, cohesive, specialist open source communities, “free” software protections may be redundant. Such communities are the software equivalents of small towns: word will spread throughout town about a misbehaving vendor, and punishment will ensue without the need to involve the law. In such cases, especially if the software in question requires extensive vendor assistance to install, customize, deploy, maintain, and/or enhance, the extra protections provided by “free” licenses may be more-than-offset by the perceived deterrent they create to vendor involvement, or perceived barriers they erect to the mixture of open and proprietary intellectual property by the vendors who are essential to the project’s success. In such situations, the higher degree of interdependence between vendors and customers makes the “open” license as protective as the “free” license, and with fewer costs and risks.

On the subject of risks…much has also been written about whether “free” licenses actually pose any legal threat to participating vendors and their intellectual property, as compared to “open” licenses. Scholars and advocates care deeply about these questions, but from an open-source project participant’s point-of-view, the relevant question is not whether “free” licenses deter vendor involvement in some objective, legal sense; rather, the question is whether vendors perceive them as deterrent (i.e., as “risky”). Such a perception is highly likely to be self-fulfilling, leading a vendor to avoid a project. Many vendors engage effectively with “free” licensed projects, while many other vendors have stated publicly that such licenses are threatening to their intellectual property interests, and have therefore chosen not to engage, or to limit their engagements, with “free” licensed software. Best-practice is to observe vendor behavior with respect to the particular open-source project in which an organization is interested, and determine whether a sufficient number and quality of vendors are willing to provide the organization with effective, attractive choices among vendors for the types of services that the organization requires, given the license(s) under which the project operates. If the vendor situation is suitable, and stable, then the type of license is unlikely to matter—unless the participant plans to contribute its own intellectual property to the project, in which case the organization may wish to conduct a careful risk-assessment of its property and the license in question.

Best Practice:

Ownership also matters; sometimes, it matters even more than the licensing model.

An (approved) open-source license guarantees legal use in perpetuity of the software being licensed; however, it does not guarantee that a licensee can achieve or sustain effective use. The owner of the intellectual property has the right to change the terms of the licensing going forward, and even to sell the intellectual property involved. Under an approved open source license, any new restrictions by an owner cannot be made retroactive, so the participant cannot be denied access to the code delivered prior to the change; however, it can be comparatively easy for an owner to make subsequent changes to the evolving code-base that will render the earlier code obsolete or effectively unusable. Coordinated community action (e.g., continuing to develop the “original” code-base independently) may prevent this strategy from succeeding, but coordinated community action is not always a feasible response.

Best-practice is for governments considering open-source software to inspect carefully the ownership terms of the software, and assess the risks that the ownership model creates. From the perspective of risk-mitigation, projects owned by viable nonprofit organizations created specifically to own and govern the intellectual property (e.g., the Mozilla Foundation, the Eclipse Foundation, the Kuali Foundation) present the lowest risks of loss-of-access. OSS projects which are owned by a single individual or for-profit firm present the highest risks. (This risk should not be confused with the risk of failure of the project, which is another, separate matter.) Size of the owning organization may or may not matter: acquisition of a (small) firm usually implies transfer of ownership (except in cases where antitrust is an issue), but large firms can sell intellectual property, too. Nonprofits having the mission to govern and protect a corpus of intellectual property are far less likely to sell that corpus than is any for-profit firm—but nonprofits whose mission has nothing to do with conserving a particular piece of software are inherently neither more nor less likely to sell than any other type of organization.

It should be noted that actual cases of bad outcomes from the sale of open source intellectual property are difficult to find and document, especially in high-visibility open source projects. However, while the probability of harm may be low, the magnitude of harm is potentially large. The highest-risk project types—single-owner, single-vendor, commercial OSS projects—are seldom highly visible or widely successful (a lack of success which may, in turn, reflect awareness of the risks among prospective users). This makes them less-attractive targets for purchase, but does not reduce the size or scope of potential damage to their users if a purchase does take place.

Perhaps the most widely discussed, concrete example of this problem is counter-factual: it concerns the open-source software Zimbra, a competitor to Microsoft Exchange Server that was developed by a commercial OSS firm and later sold to Yahoo!. During the period when Microsoft was attempting to acquire Yahoo!, industry sources speculated that Microsoft would “kill” Zimbra upon obtaining ownership of its intellectual property, using positive and/or negative incentives to force Zimbra users out of the software and (presumably) into Microsoft’s proprietary product. For many users, this would have been an expensive, organizationally wrenching transformation. Because the Yahoo!-Microsoft merger never took place, the discussion remains speculative, but it suggests the potential seriousness of the problem.

’ Best Practice:’

When assessing the viability/sustainability (risk of failure) of an open source project, a wide range of metrics are available, from simple counts of installations or code-committers, to formal scores such as the Business Readiness Rating (cite needed). No single metric has achieved authoritative status: best-practice is to collect as many measures as are available, and look for consistently high viability estimates across them all.

It is particularly important that an organization do more than simply count installations or contributors. The quality of installation data varies widely across projects, as do the types of contributors. A project having millions of installations and thousands of code-committers worldwide may be extremely vulnerable, if none of them is seriously committed to the continuation of the project.[2] Conversely, a project with only a half-dozen installations may be rock-solid, if those installations are large organizations having extensive resources, whose daily operations absolutely depend upon the continued viability of the software in question, and who have no easy, quick, and inexpensive way to replace it. These are extreme examples, and actually quite easy to assess. More-challenging cases include projects that are presently small, but whose size and levels of commitment are trending upward—or larger projects whose memberships are static or declining. In such cases, it is wise to supplement quantitative analysis of the project with qualitative investigation, by talking with a sampling of participants to get a sense of the community’s self-understanding. Interviewing organizations similar to one’s own can be particularly valuable.

Generally speaking, institution-wide commitments (e.g., formal adoption, with budgetary support, by an entire organization or organizational unit) are much harder to make than individual commitments (e.g., informal adoption of a project by a single individual, without explicit organizational approval/support). Institutional commitments also tend to be better-resourced for long-term viability, and tend to be harder to break. This makes institution-level commitments a better indicator of project viability, on average, than individual-level commitments.

Best Practice:

Open source projects that are not formally “cloud-capable” may still present opportunities to realize savings comparable to those of software-as-a-service (SaaS) offerings, under a variety of circumstances. For example, a consortium of higher education institutions in the Appalachian College Association banded together to create a single, hosted image of the Sakai learning management system. Sakai was not designed for SaaS delivery at the time, but by foregoing certain features (e.g., by creating a single, aggregate brand for all of the colleges, so that they could share a single software image) and creating workarounds for others (e.g., using the existing permissions systems, coupled with contractual agreements among the campuses, to manage the co-tenancy of faculty and students from different institutions), the campuses were able to achieve the highest reported marginal savings-rate of any institutions using Sakai—by some estimates, more than 90% savings over individualized installations. ’ Pain Point:’

Governments and their procurement specialists may attempt to treat open source software as simply an alternative product-type to existing, proprietary software. Such treatment can lead to serious misjudgments regarding the efficacy, affordability, and availability of open source alternatives. ’ Best-practice 1:’

Treat open source as a different business model, and procure it appropriately.

The two models—proprietary and open source—are incommensurable in many ways. For example, because open source vendors do not own the intellectual property in the software they sell, they cannot charge monopoly prices for it.[3] As a result, open source vendors tend to work on a fee-for-service basis. Most lack the marketing resources required to perform elaborate, speculative “demos” or to respond to multi-hundred-page RFPs. Simply changing the “IP section” of a procurement document to permit open licensing may not be sufficient to allow open source projects and their vendors to compete effectively—or even to respond to an RFP.

In fact, inability to respond to RFPs designed for proprietary software, due to one or another provision that assumes a proprietary rather than an open source business model, is one of the most common complaints among open-source-specific vendors. Conversely, when an RFP focuses on the potential benefits of open source, it is just as difficult for proprietary offerings to compete. There are, as yet, no best-practices for allowing open source and proprietary offerings to compete on a truly level playing field.—and because the differences in the offerings are fundamental, it is not obvious that any such “fair fight” is even possible. Consequently, the organization should reach a decision first on the strategic question of open v. proprietary, and only then should it design/select a procurement process.

Organizations deciding to procure open source should begin by reviewing their RFP process carefully. Today’s conventional software RFPs are designed to mitigate the most serious risks to an organization that can arise from procuring proprietary software that it does not own, cannot inspect (internally), and cannot modify without permission. For such a situation, it is imperative that the procuring organization identify beforehand all functions and tasks (requirements) that the software must perform, and obtain contractual commitments from the vendor that the software will perform those functions and tasks. Because the procuring organization can neither inspect nor modify the software without permission, it is also entirely rational for the organization to insist upon elaborate “demos” of the product, at vendor expense, to assess beforehand the credibility of the vendor’s contractual claims. Similarly, because proprietary software packages are often de facto monopolies, it makes sense for government procurement experts to perform exhaustive due-diligence regarding a vendor’s competencies—because one cannot fire the vendor without also “firing the software.”

By comparison, an organization procuring open source software has full access to the software at all times—before, during, and after procurement. Because the software is available for inspection, and even for trial modification, much of the risk-mitigation function of an RFP becomes unnecessary. In particular, the endless, committee-driven enumeration of “requirements” that can fill hundreds of pages in an RFP is transformed from an essential protection into an expensive boondoggle. The organization can save most of that effort and instead allocate more effort toward pre-determining its desired strategic direction (e.g., open v. proprietary), picking an open-source product that aligns with its priorities, and determining (roughly) what changes may need to be made to the software in order to accommodate organizational practices. Once those high-level considerations have been addressed, the organization can create a competitive bidding process and procure using a substantially streamlined RFP—saving time and money for both the organization and its prospective vendors. Moreover, because an organization can fire a vendor without firing the software, due-diligence on vendor competence can focus more strategically, and less exhaustively, at a considerable savings in time and effort without any reduction in safety.

Of course, it is still entirely reasonable for a procuring organization to determine whether the software and vendor will accomplish what is needed cost-effectively, and some risk of impossibility or ineffectiveness remains even when one is free to modify the software as-needed. The open source industry is working to innovate solutions to these remaining procurement risks, in ways that reduce the costs and other burdens of procurement on both vendor and customer. One example of such innovation is the “demo-to-own” approach.[4] In this model, a vendor provides, for a fee, a dedicated copy of the software (sometimes hosted, sometimes on an “appliance” server), along with the technical support required to assist the prospective customer in evaluating the software. The fee is typically a small fraction of the full cost of installation, and covers only a commensurate amount of assistance—enough to allow the customer to establish that the software will do the job, to allow the customer and vendor to estimate together the scope and cost of work for a “production” installation, and to give the customer firsthand experience with the vendor’s competence (fulfilling due-diligence). The prospective customer loads its own data into the copy, configures it as desired, and evaluates the software as it might a ‘demo’ of a proprietary system—except that the evaluation can be as exhaustive as the organization wishes, occurs under the organization’s full control, and can be conducted and completed before the organization decides whether to move to a full (“production”) installation. Moreover, if the organization decides to go ahead with procurement, all of the configuration changes made to the demo system are preserved and can be copied into the “production” version—saving funds that would otherwise be lost to redundant configuration. Because the software is open source, these savings can be realized even if the organization then decides to award the work on the production phase to a different vendor.

Best Practice 2:

Engage the organization in the decision to procure open source at the executive level, not (only) the IT unit level.

Because it represents a different business model, open source presents different strategic opportunities to a government organization than does proprietary software. Opportunities abound for ancillary collaborations that can save additional funds, improve organizational readiness and/or capacity, improve (e.g.) staff development and productivity, increase the prevalence of best-practices within an organization, empower clients, and deliver other monetary and non-monetary benefits. Many public-sector organizations report that these benefits greatly outweigh even the direct cost savings involved. Moreover, open source can redistribute resources away from IT and (ideally) toward the organization’s core mission.

If the business case for open source is analyzed and reviewed only at the level of the IT unit, some or all of these potential wins may be obscured. The IT unit may not recognize all of the potential benefits (and costs) accruing to other parts of the organization, or may discount them in favor of its own benefits and costs. The unit may be reluctant to embrace cost savings that reduce IT staffing or budgets, even to the benefit of other parts of the organization. The unit’s leader may not be a strategic thinker, or may lack the business-analytical expertise necessary to conduct a satisfactory evaluation. Finally, in the worst case, the IT unit may have emotional or financial attachments to proprietary offerings. Many large, proprietary vendors sponsor lavish conferences in attractive locales, and/or provide a variety of other loyalty inducements targeted directly at IT professionals. In a world where staff “perks” have largely been erased by waves of budget cuts, these loyalty inducements can distort decision making, to the detriment of the organization as a whole. It is recommended that the business case for open-source be reviewed by at least the CFO and COO, and preferably the CEO as well, to ensure that the analysis is conducted holistically, strategically, and fairly.

Note that this recommendation protects against bad decisions in favor of open source as well. Governments can and do adopt open source for the wrong reasons. Often, the culprit is a well-intentioned IT professional having a personal passion for open source, and lacking the business acumen or strategic perspective needed to fully appreciate the hidden costs of his or her advocacy. In such cases, the perpetrator is often half-right: the open source product in question would be a better fit than a proprietary alternative. However, the correct decision would have been not to procure any new system, but instead to work with one or more existing systems to improve their reach or effectiveness. A holistic, strategic, executive-level review of an open sourcing decision can also help to pinpoint situations where not procuring new software is in fact the optimal procurement strategy.

FOOTNOTES

[1] See, e.g., http://www.insidehighered.com/news/2009/07/06/kuali, which documents savings of 92-95% by one organization, and savings of “millions of dollars” (an implied 90%) by another. See also http://www.rsmart.com/savings, for one vendor’s published pricing, indicating 35-53% savings.

2 cf. the abrupt collapse of Mambo and the creation of Joomla– http://en.wikipedia.org/wiki/Joomla

3 The exception is “commercial OSS,” where a single vendor may be a de facto monopolist by virtue of being the only entity able to provide services for the product.

4 See, e.g., the rSmart “Kualifier:” http://www.rsmart.com/files/rsmart/rSmartKualifier.pdf