"The federal government neither prevents nor encourages open source adoption...but effective exploitation will require clear and well-communicated policy and proactive education - Government needs to seize OSS opportunities through clear and well-communicated policies and by being proactive without being provocative. There are numerous examples of effective use of OSS within the public sector today but lack of clear OSS policy is creating fear, uncertainty and doubt about its legitimacy preventing optimal exploitation."
Open Source Software in Canada (2003)
After a slow beginning in the late 1990s, Free/Libre and Open Source Software (F/LOSS) has been constantly growing in importance and expanding in many software architectures all over the world. This impressive growth has been supported by the numerous successes, the high-quality reputation of F/LOSS-based systems and, of course, by the expectation of cost savings.
In 2003, Defence Research & Development Canada (DRDC) initiated a special study to determine the role of F/LOSS in our information system architectures. This study was later expanded to the whole Government of Canada (GoC). This article summarizes some key findings based on the original DRDC report published in 2004. It includes a general introduction to F/LOSS followed by some guidelines in assessing the usefulness of F/LOSS in GoC project contexts.
F/LOSS Advantages and Associated Challenges
Over the years, many very useful software products have been distributed under the various open source licenses. Moreover, F/LOSS also evolved in a very efficient development process. By its simplicity and efficiency, the F/LOSS development model has repeatedly demonstrated many benefits, including:
- huge diversity of software
- high flexibility and scalability of software solutions through source code editing
- high reliability and security through source code review and validation
- one-order of magnitude faster release rate than equivalent commercial off the shelf (COTS) software
- rapid development of custom solutions to meet specific requirements through code reuse and extension
- lifetime extension of F/LOSS-based systems through source code upgrades
- high degree of compliance with open standards leading to more interoperability between information systems
- leaner and meaner systems compared to COTS equivalents that often suffer from marketing feature bloat
The strategic rationale for migrating to F/LOSS is typically related to three main factors: i)the expectation of direct cost savings; ii) the reduction of economic loss at the national level caused by commercial software imports; and iii) the hope to better develop national IT (Information Technology) expertise by means of access to source code (and development of original components).
When the original DRDC report was prepared, the following criticisms about OSS were still found in the technical literature: i) version control may be more complex; ii) system maintainability requires more local resources; iii) higher technical skill is needed from system administrators; and iv) F/LOSS may offer less integration within an application suite and less user-friendliness. But these challenges has been addressed to a large extend in the last 5 years and may be seen as debatable now.
F/LOSS Adoption Around the World
During the past two decades, the software market has been dominated by COTS products. However, the intrinsic limitations of COTS software such as closed source code, lock-in effect, expensive upgrades, and security weaknesses have emerged over time, leading to the development of a parallel economy based on F/LOSS.
The good reputation of F/LOSS has attracted the attention of many governments around the world. The leading countries, migrating to F/LOSS in 2003/04, were the United Kingdom, Germany and France. Canada appeared to be behind these countries in F/LOSS adoption. The lack of clear business cases and the underestimation of the strategic value of F/LOSS partly explain this situation.
In 2004, the GoC endorsed a pro-active position on F/LOSS to ensure that GoC staff are aware of the options available and that no barriers to procurement remain. For comparison purposes, the Center for Strategic and International Studies publishes periodically an overview of F/LOSS policies around the world.
F/LOSS in the United States
F/LOSS originated largely in the United States and remains a very strong movement with many large American corporations and some government initiatives. However, adopting a strong F/LOSS policy may be problematic for the American government since the proprietary software industry strongly supports the US economy.
While a plethora of reports discuss the growth of F/LOSS in the US economy, a large portion of this information is incomplete and/or biased, written to support a specific perspective. Almost unanimously, however, it is recognized that F/LOSS is expanding rapidly in most IT infrastructures. The well-known Linux operating system and Apache web server are the most often cited because of their recognized maturity and their technical qualities compared to their commercial equivalents.
Government sponsoring of F/LOSS is becoming more common. Security Enhanced Linux (SELinux) can be downloaded directly from the National Security Agency (NSA) web page. In geomatics, the National Technology Alliance (NTA) sponsored the Open Source Prototype Research project which had a significant impact on geospatial information organizations in the US government, including the Department of Defense (DoD). More recently, a mission-critical development with F/LOSS has been reported in IEEE Software and describes how F/LOSS has been used very efficiently in the NASA JPL project.
The software business was estimated to be $70B (US) in 2004 and so it is not surprising to see a vigorous reaction from COTS editors against F/LOSS. [Editor's Note: The Critical Infrastructure Protection Program, the source of the cited report, has updated reports available.]
F/LOSS in Canada
In June 2004, the Government of Canada announced a new position on F/LOSS. It is based on a balanced approach to ensure that governmental policies and guidelines do not bias one software business model over another, such as F/LOSS vs. COTS vs. custom development. Some government departments will address a series of next steps to support the national policy on F/LOSS including: i) to review federal procurement practices to ensure a level playing field; ii) to provide advice on software quality and security best practices; iii) to develop a strategy for property rights, patent protection and technology transfer; and iv) to provide advice on licensing and other legal issues.
At the time that this report was being written, the use of F/LOSS in Canada was mostly in software development and in the back-office environment such as servers and network management. Analysts often describe this phenomenon as the horizontal market penetration of F/LOSS. Most analysts consider that vertical penetration of F/LOSS, through the multiple layers in a specific application domain, is required to support a more widespread penetration of F/LOSS technology.
F/LOSS and Software Security
When software is created, it has a level of quality that depends directly on the programmer's competence, experience and professional methodology. To increase the reliability and security of code, it is essential to use some complementary mechanisms such as peer review, testing, quality audits, and beta versioning. F/LOSS and proprietary software rely essentially on the same processes during development. However, after the first public release, F/LOSS offers the very significant advantage of keeping access to source code. This encourages more peer reviews, testing, and quality audits by a much larger community of users/developers than what would be possible with proprietary code. For closed source software, flaws and code defects are often discovered by subversive exploits which can lead to some destabilization in corporations that rely on such COTS packages. In short, F/LOSS is not intrinsically more secure than COTS software, but the openness of source code makes security enforcement more ubiquitous and less disruptive.
The dilemma on security through obscurity vs. openness was the subject of a heated debate in the cryptographic community in the 1980's. The final decision was to make the cryptographic algorithms generally available so as to provide for security assessment and validation by the widest scientific community possible. Whitfield Diffie, the inventor of public key cryptography, and now chief security officer at Sun Microsystems, has repeatedly said that "openness is essential for trust" in software as it was for cryptographic protocols twenty years ago.
Other security advantages for F/LOSS include:
- since they are smaller, open source systems are expected to provide fewer opportunities for exploits
- source code can be enriched with assertions and complementary safety checks
- increased code diversity in the software ecosystem could reduce the speed and the proliferation of cyber attacks
F/LOSS does have some increased risks to manage. It is often perceived as a return to more reliance on internal resources for system development and maintenance. For security enforcement, high-quality expertise is scarce and may often have to be developed to adequately cope with the increased responsibilities that F/LOSS-based systems will require.
At any rate, neither COTS nor custom software are immune to malicious or programming defects that result in information system vulnerabilities. F/LOSS proponents consider these threats to be exaggerated. As noted in the full report, advantages and disadvantages can only be balanced in a specific project context.
Guiding Principles for GoC
While very attractive in general, F/LOSS must be evaluated in the context of each project on a case-by-case basis in order to determine if the advantages outweigh the disadvantages in practice. In the case of GoC, special attention must be paid to the protection of classified technologies, the protection of intellectual property, and the selection of a license suitable for the specific activity. Some preliminary guidelines are available in Parts III & IV of the full report.
Adoption of F/LOSS development methods can have fundamental and far-reaching consequences on engineering practices, especially if the objective is to contribute actively to an open source project. It is recommended that experience be gained with F/LOSS as a passive user first, then to become progressively more involved by reporting bugs, suggesting new features, and modifying existing code before engaging in active development within a collaborative project. GoC should consider F/LOSS solutions alongside proprietary ones in IT procurements, especially in large development contracts such as Technology Demonstration Projects (TDPs). According to Industry Canada, contracts are awarded on a value-for-money basis and no Public Works Government Services Canada (PWGSC) rules restrict F/LOSS uses in federal government contracting and no Treasury Board rules restrict F/LOSS use in our internal programs. The Canadian position on F/LOSS confirms that no barriers to procurement should be maintained.
The process to evaluate F/LOSS or COTS software is essentially the same and a side-by-side comparison remains the best approach to identify the pros and cons of each option. The evaluation process can vary in duration and in technical depth depending on the application context and the project requirements.
It is to be noted that most COTS packages are designed for a very broad client spectrum and typically include diversity of functionalities and potential configurations. On the other hand, F/LOSS tends to be more specialized since it is often designed to meet the requirements of a specific user community. A direct comparison of both types of software against a well-defined application context is recommended to determine the best option. In short, the main evaluation steps include:
- understand the requirements and the application context
- prioritize the selection criteria
- identify COTS and F/LOSS candidates
- compare the best candidate options
- analyze the best products in depth for performance, security audit, cost
- seek approval from local management and from the project client
- document lessons learned
At this time, it does not seem appropriate for GoC to select one license model and to impose it on all projects. It seems preferable to identify the most suitable license model in the context of each project, including due consideration of:
- intellectual property (IP) protection
- national and international partnership constraints
- client preferences
Recommended Evaluation Steps
The following six steps are recommended for GoC procurement policies.
Step #1: define the application context
- clarify objectives and client expectations
- document project constraints such as classification level, partners' demands, compatibility with development/execution environment, compatibility with legacy systems and existing information formats, and mandatory standards to comply to
- prioritize evaluation criteria to compare software including functionality, cost, required support/maintenance, reliability, security, performance, flexibility, scalability, user-friendliness, legal/license issues and other issues specific to the applications
- estimate internal (and external) resources available to the project such as money, time and technical expertise
- seek support from an experienced colleague that would mentor the evaluation process and help in avoiding pitfalls
Step #2: identify candidates
- perform search on the Internet
- gather technical reviews and product comparisons
Step #3: compare the best 3-4 options side by side
- consult existing internal lists of reliable F/LOSS such as the Generally Recognized As Safe (GRAS), Generally Recognized As Mature (GRAM), and IDA (Interchange of Data between Administrations)
- read/assess technical product reviews while remaining vigilant concerning excessively biased evaluations
- consider compatibility of the software with existing libraries and your development and execution environments
- assess maturity and technical risk through download counts and other popularity measures, product longevity, and market penetration
- summarize your findings in a spreadsheet that includes your criteria as prioritized
Step #4: if appropriate, perform an in-depth code analysis
- if time permits, download evaluation versions to confirm performance, compatibility, and user-friendliness clarify details with suppliers/developers
- evaluate licenses and seek advice from your local Business Development Service (BDS) for IP protection
- if appropriate, perform detailed code analysis with software analysis tools to detect flaws and other types of defects
- if appropriate, evaluate the feasibility of adding new functions
Step #5: seek approval from client and local management
- even if software packages are used unchanged with no code development, it is recommended to inform your local management, and possibly the project client, of the use of F/LOSS
- if F/LOSS is used to build a research prototype involving substantial code development, seek approval from your local management and project client
- if a GoC development is considered for distribution in one of the F/LOSS networks, estimate the additional effort required to clean up the code, to improve the documentation and to support the community in a timely fashion once released
- if a GoC development project is to be carried out in a collaborative open source paradigm, it could be necessary to build a comprehensive business case to justify this approach
Step #6: document lessons learned
- summarize lessons learned from your evaluation in a brief tech note to share your experience with GoC communities
- keep track of F/LOSS usage and changes made through a rigorous software revision control throughout the development process where the revision control data must remain available to the Crown after the development has finished
F/LOSS offers a credible alternative to commercial software. However, it is not a panacea. GoC could benefit from improved diversity in software supplies, augmented security by source code auditing and enhancement, and higher compliance with open standards that contribute to system interoperability.
Specific actions are proposed to increase awareness/use in GoC: i) promote F/LOSS by means of publications and workshops; ii) consider F/LOSS in contractual work; iii) and support GoC departments in assessing this emerging technology.
This article is based on the report with the same name, published for unlimited distribution as DRDC ECR 2004-232 in December, 2004. A copy of the full report is available online. Readers are encouraged to submit comments.