Promoting Open Source Procurement in Government
After publication I was sent this PDF about open source procurement in the Netherlands that was worth sharing.
How Can Government Responsibly Procure Free Software?
Free software is “free” in two senses: it is distributed free of charge, and can be freely used and shared because it is unencumbered by onerous and restrictive licenses. This software model has been refined over the past twenty-five years, and its use has become mainstream.
In 2008, leading IT industry analyst Gartner Research announced that “Eighty-five percent of companies are already using open source software, with most of the remaining 15 percent expecting to do so within the next year.” Amazon lists 90 thousand books when searching for “open source”, and there are many more publications available electronically.
In this age of the Internet and mature, enterprise-ready, open-source projects, commercial off-the-shelf software is an outdated concept. There is no longer a need for either the boxed software or the shelf it sat on. This article offers an introduction to this model of software development and distribution, and offers procurement professionals guidelines for approaching and understanding free and open-source tools.
What is Free / Open-Source Software?
Free software is distinguished by its licensing and by its transparency: it can be freely distributed and modified because its source code is made available. In contrast to the opaque workings of proprietary software, free software is developed in public, and is freely available for inspection, evaluation, and modification.
There are subtle licensing and philosophical differences between “free software” as defined and promoted by the Free Software Foundation (FSF) and the broad world of “open source” software. Our focus will be on Free Open Source Software (FOSS), but most of the points will also be relevant to Open Source Software (OSS) as well.
The “free” aspect of FOSS has been seen as problematic, inasmuch as things that are free are often seen as being without value. However there are many assessments of the value of FOSS products which clearly show that this is not the case. According to Ohloh.net, for example, the OpenOffice.org office suite would cost almost USD $150 million to develop from scratch, but it can downloaded for free, and offers a near drop-in replacement for Microsoft Office. In addition, it can then be distributed, modified, and improved just like other FOSS software.
Given that the current economic challenges mean everyone is trying to do more with less, paying for a license is often an unnecessary expense. And proprietary, closed-source software has far more costs than most government agencies realize. When you hire consultants to deploy and manage closed source products, there is no added value or opportunity to participate in a community of innovation. Investment in FOSS projects, on the other hand, benefits the entire sphere of FOSS users and developers. Open source tools free you from dependency on the sustainability, competence, and good will of third-party software vendors because there is a community of technical expertise that can be mobilized, commercially or not, to troubleshoot and improve FOSS systems.
Open source software reduces up-front implementation costs by eliminating license fees, but more importantly it can help protect against single-vendor lock-in. Vendor lock-in is a problem because companies it increases the cost for the deliverables. Lock-in is also a problem in terms of future-proofing your data or applications: if a company is bought out, goes out of business, or simply discontinues a product line, you may not be able to get support for your software. Software producers benefit by lock-in because they have an effective monopoly on their customers; this means they have little or no incentive to make better products, or to make their products interact well with other tools.
On a technical level, FOSS tools benefit from open, distributed. community-driven development. Many FOSS projects enjoy the attention of hundreds or thousands of developers, and tens or hundreds of thousands of engaged users. Such projects have demonstrated very rapid cycles of continuous quality improvement. Moreover, they are directly and actively responsive to the needs of their users. Many organizations have chosen to implement mature open source projects because they allow for the fast delivery of a well -tested product. In developing the Canadian Museum for Human Rights website within just six weeks, for instance, Mark Stephenson of RealDecoy said, “the Drupal framework really saved us a lot of time.”
Despite its strong technical reputation and very widespread use, there remains a great deal of uncertainty about free software. Many of the concerns are unfounded, and based on limited knowledge of the FOSS community. For instance, the following are all true of FOSS software:
- there is a great deal of commercial support available;
- you have a wide choice of vendors (unlike many proprietary applications);
- it is almost always more secure than closed-source code and on par or better than proprietary software, because the user/developer community is constantly evaluating and improving it;
- industry has built and extended FOSS applications for real world enterprise environments;
- active communities allow users to learn from each other and encourage innovation
Government and FOSS: Shared Values
Free software is presently being used by most if not all government departments. There is no central listing of software used by the Government of Canada. A short survey conducted by OpenConcept revealed that openconcept.ca/blog/mgifford/canadian_government_uses_plenty_of_open_source_software. FOSS is already being used extensively from the Canadian Revenue Agency (CRA) to the Canadian Space Agency (CSA).
In many ways FOSS software is a natural match for government. Both software projects and government departments are mission-based and depend on finding a cost-effective manner to deliver services. Government financing comes largely through its citizens and anything that is produced is ultimately there to benefit the community. Likewise software projects are responsible to their community of users.
Jeff Braybrook, Deputy Chief Technology Officer for Canada, spoke in February about the Treasury Board's adoption of MediaWiki for GCPedia. In his summary government and FOSS communities are natural allies as they share common values. Both communities: i) encourage participation, and having a platform to perform, to contribute and to interact with others; ii) promote co-operation and collaboration which is critical for any successful federal government or open source project; and iii) depend upon and are improved by agreed upon standards that allow for innovation./p>
To be innovative you need to encourage creativity, collaboration and provide inspiration for those working on common problems. Innovation is largely about combining old tools in new and creative ways. FOSS allows you to do this by not limiting how one can learn from and extend the tool and by encouraging the technology to be shared with others. Governmental use of FOSS tools thus provides a ready opportunity to both fulfill internal technical requirements while at the same time fostering and disseminating innovation.
FOSS Procurement Internationally
Earlier this year the UK, the IT in the Government initiative of the Cabinet Office put forward a very progressive procurement position calling for more use of open source, open standards and re-use within government. They were looking for solutions that provided the best value for money and also encouraged share and re-use of what the taxpayer has already purchased. The initiative was designed to encourage innovation and this precedent will not only benefit governments within the UK, but also around the world.
In the USA, the Department of Defense is a big advocate of this software model. Recently they launched Forge.mil which is hosting the military's open source projects. In their study they determined that using open source projects increases flexibility, produces greater interoperability, and reduces IT costs. The National Defense Authorization Act “has explicitly articulated a preference for open source software.”
There is a strong effort to even further entrench open source within the USA government. Especially since the election of Barack Obama. Large open source companies are banding together to lobby for change. Critical websites like Recovery.gov have been built using the Drupal CMS, and others are coming online using other open source tools.
FOSS Procurement in Canada
It is a misconception that FOSS isn't being used in the public sector in Canada. The Treasury Board's Federated Architecture Program has quite a wealth of information on OSS. Though it was largely written in 2003-2005 and so needs to be updated, it is nonetheless an example of a central department pursuing a path for OSS procurement within the Government of Canada. Industry Canada maintains an OSS Solutions and Support Providers page, and Public Works and Government Services Canada (PWGSC) has created a Software Acquisition Reference Centre (SARC) that has a section for OSS. Neither of these is an endorsement of the companies listed, but reflects a general need for government departments to know where to consider their options.
PWGSC put forward an Request for Information (RFI) earlier this year in an attempt to get clarity on how the federal government should approach this issue. There should be a good summary from all of the input that was submitted, however the question was much too general. The RFI was for “Not for Charge Software” which included both OSS & FOSS licenses but also careware, trialware, shareware and adware. This very broad set of licenses has very little in common other than that there is no upfront financial cost. It should be stressed that openness and collaboration are distinctively characteristic of OSS and FOSS projects.
There are strong precedents for the use of FOSS, clear indications of value for total cost of ownership, and plenty of evidence that OSS can deliver enterprise-class results. But how does a procurement officer evaluate software in this new paradigm? In many cases the procurement officer may not have a software background so will not be able to technically compare two similar solutions. Having a richer understanding of the software industry will help, but there are a number of steps that can be taken to improve best practices. The following is an incomplete list of items to consider:
- Evaluate the size of the community of users & developers and look at relevant trends of comparable software (with so many options available, make sure you have a critical mass). Google allows you to do a simple comparison with the trends search.
- Check that there are users within your sector (it's worth checking if there are any communities of government sites). Drupal's founder Dries' blog has a focus for government and there's also two Drupal Groups available (for municipalities and national/provincial departments)
- In evaluating software ensure that you are aware of the niche areas that the software is written for (MediaWiki is a great wiki platform if you want to emulate Wikipedia)
- Most popular OSS projects are transparent about their processes for code review and also security evaluations. It's good to know what the release schedule is and also that there is an upgrade path available for users. All software needs to get upgraded at some point, so best to have a plan.
- Is there a strong user community that is contributing back to the projects (either in bug reports, feature enhancements or even providing use cases?). Are there regular conferences, or even local meet-ups.
- Are there a number of companies who work with the software who you can engage if required? Local companies and large multi-nationals are all using OSS, so it is important to consider where you want your money to go.
- Is there a clear software license under which you know what obligations there are for your work? If work is all developed under the same license it will make it easier if questions around intellectual property issues do arise. Any software downloaded directly from Drupal.org is under the GPL free software license.
- Particularly in Canada it is useful to assess if there is language support in both official languages. With most software projects, the developer documentation is usually written in English, however it is critical that the user/admin components can be available in French as well.
- Software maturity is important for consideration. It is easy to start a software project, but much harder to sustain it and build a strong user base around it.
- Documentation is important issue to evaluate with any software. Both inline and user documentation should be considered (With any reasonably large OSS project you'll find that there are books are available)
- How user friendly is the product and how much training is required?
- Is there a clear definition of what needs the software is expected to fulfill? How well does the software being evaluate meet these requirements? The Commons Group has developed a software needs worksheet to help.
The software procurement landscape has become more complicated. It is critical that public sector managers be able to evaluate the richer set of options that are now available. Resources are available to help educate and guide staff in making informed decisions about the pros and cons associated with different choices. There are also a number of frameworks, like the one defined by the Commons Group above, which can be used to plot the needs of the organization to learn about how to make better use of software within your organization. Requirements gathering takes time and money to do properly, but it is much better than once again purchasing something that doesn't meet the needs of users and that is incapable of being modified to do so.
Open source solutions offer robust performance and technical excellence, but perhaps more importantly they offer independence and flexibility. And importantly for the public sector, money spent implementing FOSS projects is an investment in the common good because improvements and testing for one can be contributed to improve these tools for all.
About The Author
Mike Gifford is the founder of OpenConcept Consulting Inc, which he started in 1999. Since then, he has been particularly active in developing and extending open source content management systems to allow people to get closer to their content. Before starting OpenConcept, Mike had worked for a number of national NGOs including Oxfam Canada and Friends of the Earth.