Open Source Software

Definition: Open source software (OSS) is commercial software for which full ownership rights can be obtained simply by agreeing, without any need for immediate third-party verification, to abide by an attached OSS license. Agreeing to an OSS license allows an individual, company, or government entity to replicate, distribute, and run the OSS application as often and as broadly as desired, to obtain its human-readable source code, and, subject to release requirements that vary from license to license, to expand or extend the OSS application. Payment for OSS is indirect, consisting in most cases of agreeing to share value in the form of application fixes and extensions with the community that maintains the application.

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to understand the potential benefits, risks, and limits of applying open source software (OSS) and associated support processes to the construction of large systems and to systems of systems. To ensure compliance with federal regulations requiring selection and use of applicable commercial software over new development, they should understand how and where OSS capabilities apply to systems integration, end-user support, and configurability. They should be aware of how OSS compares to other forms of commercial software in terms of acquisition costs, long-term support, scalability, adaptability, security, and resilience in the face of changing requirements. SEs should be aware in particular of the security properties of OSS at the engineering and process levels, and how those properties compare with other types of commercial and government software. They should be aware of the certification status of major OSS packages, and how certification works in the distributed ownership model of OSS. They should understand how to interact successfully and productively with OSS support communities, which use a barter-based economy in which payments are made in terms of software fixes and application capability extensions instead of fees.

Background

Few topics in the software engineering domain of systems engineering, and in engineering information-intensive enterprises, are more likely to engender stronger reactions than open source software. Such reactions stem mainly from the community-based ownership model of OSS, in which anyone who agrees to follow an associated OSS license receives the same ownership rights as any other user. This dispersal of engineering change authority violates one of the oldest and most deeply held assumptions of software engineering: High-quality, high-reliability, trustworthy software is possible only if that software has been developed using a well-controlled, authority-centered, top-down development process. OSS not only discards the need for a centralized development authority, but it turns the concept upside down by placing control of the development process in the hands of loose collaborations of coders. Because coders are often viewed in software engineering as the participants least likely to understand needs and most likely to violate rules intended to ensure system integrity, quality, maintainability, and security, it is not surprising that a process that relegates change control over to coders would tend to be viewed with distrust.

However, this view is changing. The first reason is the growing realization that just as planned market economies cannot compete with free-market economies at encouraging innovation and efficient use of resources, tightly centralized management of very large software development efforts are more likely to fail than approaches that encourage local innovation and adaptation. OSS encourages such local innovation and moreover makes the human-readable results of local innovation readily available for any desired level of inspection and analysis.

The other reason is pragmatic. OSS use is widespread in both private and government systems and has been for many years [1]. The communication software (TCP/IP) that first made the Internet possible was OSS as were many of the early server systems that provided useful data. Microsoft is one of many examples of commercial companies that make extensive use of open source software to build and expand their product line. Internet Explorer is an example of a notable Microsoft utility that is based heavily on OSS. Essentially all modern Apple products, from Macs to iPods and iPhones, are built on OSS with a thin layer of customized software on top. Google is another industry leader that uses OSS heavily both internally and in its commercial products. Apple and Google are also both good examples of how effective use of OSS can enable more and faster innovation by keeping costly designers focused not on maintaining old code, but on developing entirely new capabilities. Finally, nearly every network appliance and custom hardware box sold in the open market today is built mostly or entirely using OSS. OSS is extremely popular with appliance vendors due to its low cost, easy scalability, flexible adaptation to new environments, broad range of available functions, and field-proven reliability.

Government Interest and Use

On October 16, 2009, the U.S. Department of Defense (DoD) issued an updated policy on the use of open source software (OSS) [2, 3]. The policy emphasizes and explains the legal status of OSS as a form of commercial software, which means that it falls under U.S. law (10 USC 2377), Preference for acquisition of commercial items. Not including assessments of OSS options when examining commercial options for reducing costs and improving quality in DoD systems can inadvertently violate this law. A good example of the seriousness of the commitment of the Executive Branch to assessing, selecting, and using commercial OSS is the White House Developers website [4] which directs software developers to White Houseprojects on GitHub (distributed open source development) [5] and Drupal (open source blogging) websites [6, 7].

Best Practices and Lessons Learned

Read and understand the U.S. DoD web page on free and open source software (FOSS) [8]. The U.S. Department of Defense spent years creating three documents analyzing and elaborating the role of OSS in DoD systems. The site addresses DoD policy toward open source, frequently asked questions about the federal role and legal status of open source, and a survey on the widespread prevalence and importance of OSS to the DoD as early as 2003. The web page is written generically and applies with very little change to other federal departments and agencies. MITRE systems software engineers working with the DoD should in particular make sure they have looked at the October 16, 2009, DoD policy statement at the site.

The larger the community supporting OSS, the greater reduction in long-term support costs. This rule-of-thumb is at the heart of how OSS can provide significant cost and capability benefits when building large systems. Notably, it has nothing to do with the ability to modify code per se, and in fact can easily be seriously undermined by a premature project interested in modifying OSS source code. Since OSS support works like a consortium, its cost benefits to individual members are highest when the consortium size is as large as possible. These cost benefits increase even further if the OSS support community is large enough to include world-class experts in specific OSS features, since such members often can resolve difficult problems in a tiny fraction of the time that would be required by more generalized support.

Avoid proliferating OSS licenses. There are already far too many OSS licenses. However tempting it may be for an organization to create its own unique OSS license, each license simply further confuses the developers, lawyers, and project managers who must deal with it and also tends to subdivide the pool of developers available to support such new licenses. Four major license types are typically sufficient:

GNU1 General Public License (GPL): This popular license requires that any new source code made using GPL source code must itself be licensed as GPL; that is, it must be donated back to the OSS community that created the first source code. While this feature makes GPL controversial, it also makes it very good at stabilizing the deep infrastructure of a system or network by removing any profit incentive to change it arbitrarily. The Linux kernel was created in part using a GPL license, and demonstrates another feature of GPL: Standard interface to GPL components can be used without any need for the software that uses it to be GPL.

GNU Lesser General Public License (LGPL): This is a variant of the GPL that allows GPL components to be embedded as "library components" in non-GPL code. It is popular with small companies that like the GPL model but do not want to keep businesses from using or buying their software components.

Berkeley Software Distribution (BSD)/Apache: These forgiving licenses allow companies to "capture" copies of source code and treat those copies and any changes they make to them as proprietary. Apple has made use of this feature of BSD license in creating its current Mac personal computer, iPod, and iPhone product lines. Due to the high cost of individually maintaining large sets of source code, the majority of participants on BSD/Apache licenses continue to support their OSS products under a community model. For systems engineers, BSD and Apache licenses should be viewed as tools for ensuring that small businesses participating in a large system-of-systems effort will have a strong cost incentive to adapt OSS features provided under a BSD or Apache license. For example, the selection of a BSD-like licensing model for the initial release of the Internet communications software (TCP/IP) was instrumental in getting dozens of small and large businesses with unique networks to accept the code and initiate the first working Internet.

No license (government code): This is the legally required status of code developed by government employees. While approximating a BSD or Apache license by allowing anyone to use it, it can cause considerable confusion if a person or company chooses to copyright the entire work "as is" without acknowledging its government origins.

Don't assume that the lawyers involved will understand OSS licenses. Lawyers who are not deeply familiar with software and, more specifically, how it is converted from readable source code into executable machine code will have a very difficult time even reading the GPL license and LGPL licenses, let alone understanding them. BSD and Apache licenses avoid details of software structure and are far easier for lawyers to understand. Often, lawyers favor BSD and Apache for that reason alone: They understand them. This unfortunate state of affairs is slowly improving, but in the case of GPL and LGPL, programmers still often understand the meanings and implications of these licenses far better than the lawyers who are responsible for assessing their implications. SEs should be aware of this possible disconnect and, if possible, point lawyers toward relevant documents such as the Frequently Asked Questions (FAQ) on the DoD FOSS website [3].

Use OSS to stabilize shared infrastructure. Infrastructure here means the software components of a large system or system of systems that establish basic functions such as networking and data sharing. As demonstrated by the history of the most successful of all system-of-system infrastructure projects, the Internet, using OSS to encourage sharing basic capabilities can be a powerful tool for promoting the emergence of more complex and often unanticipated new capabilities on top of that infrastructure. OSS can also help stabilize large systems by removing the profit incentive for companies to change features arbitrarily or lock customers into unique feature sets. Finally, because infrastructure is often the code that is least innovative, using OSS frees up intellectual resources for more innovative new design work.

Use OSS to help focus costly resources on innovation. The end result of factoring out "solved" problems from large systems and moving them into OSS is shown in the pyramid-like structure in Figure 1. The figure's main concept is that by factoring out capabilities that are stable, changing relatively slowly, and well supported by OSS communities, an organization can pull critically needed designers and coders from support roles. They can move them into more innovative positions focused on the most critical needs of the organization, typically making use of many of the prototyping and exploratory features of OSS (see next two entries).

Figure 1. The I-4 Architecture Pyramid

Encourage use of OSS liaison positions. An OSS liaison is a technically proficient programmer who has been tasked to track, participate in, and make use of a related suite of OSS applications. An experienced OSS liaison both helps make sure that the needs of an organization are understood and sustained by its support community and provides quickly available internal advice on whether and how a combination of OSS capabilities might meet or support an identified system-level need. OSS liaison positions are non-standard in terms of standard software engineering job profiles, but they provide one of the most effective approaches to ensuring that a broad need does not end up being translated inappropriately into a long-term software development project that will at best only replicate features already available through OSS.

Understand the advantages of OSS for exploratory prototyping. For many of the same reasons that OSS makes a powerful exploratory prototyping tool, it also provides a powerful approach to handling the integration problems typical of large and complex systems engineering problems. OSS includes packages and languages designed specifically to help translate between diverse and often unexpected types of data and communication protocols. One of the most important advantages of such translation-supporting OSS tools for large, complex systems is that they can be used to help simulate the inputs and interactions expected by older and out-of-date components of such systems. Because changing such older components is often both very costly and highly risky, the ability to build such "soft" interfaces to older systems while maintaining current protocols and standards in the rest of a system of systems can be very valuable for minimizing overall levels of risk to the project.

Understand the advantages of OSS for systems and systems-of-systems integration. For many of the same reasons that OSS makes a powerful exploratory prototyping tool, it also provides a powerful approach to handling the integration problems typical of large and complex systems engineering problems. OSS includes packages and languages designed specifically to help translate between diverse and often unexpected types of data and communication protocols. One of the most important advantages of such translation-supporting OSS tools for large, complex systems is that they can be used to help simulate the inputs and interactions expected by older and out-of-date components of such systems. Since changing such older components is often both very costly and highly risky, the ability to build such "soft" interfaces to older systems while maintaining current protocols and standards in the rest of a system-of-systems can be very valuable for minimizing overall levels of risk to the project.

Treat OSS licenses like any other proprietary licenses. It would be very unusual for a large federal development project to consider seriously violating the license agreements it has made with large proprietary software companies such as Oracle, IBM, or Microsoft. Yet, ironically, and in part due to widespread misconceptions that OSS means "free" software with no strings attached whatsoever, it is surprisingly common for developers to violate OSS licenses, such as by stripping OSS licenses from source code. This is not just an extremely bad idea from a development quality and long-term support perspective, it is also illegal and unethical and can result in legal action from watchdog groups such as the Free Software Foundation (FSF) [8]. More important, it undermines the consortium-style share-and-contribute model that is where the real cost reduction potential of OSS resides. Systems engineers should do what they can to ensure that on any given project, OSS licenses will be treated with the same degree of respect they would give to any other commercial license.

When building large systems, try to minimize the need for new software. Historically, software projects have used lines-of-code written as a way of gauging schedule progress, which has resulted in a tendency to think that more code is a good thing. However, because every new line of code entails a long-term cost and reliability burden that may endure for decades, the real goal should be the opposite: SEs should always look for ways to reduce the need for new, unique software to an absolute minimum. Code usually will be needed, but it should be relatively small in size, powerful in capabilities, and uniquely specific to the system being created. Common features such as ordinary file access or standard network communications never fall within this category and should always be handled by instead acquiring stable, well-standardized OSS or proprietary software.

Strongly discourage any view of OSS as "free source code" for speeding up internal development. Long-term code support costs always dwarf initial software costs for any type of software. For this reason alone, viewing OSS as "free" source code to speed up short-term development goals is a short-sighted and frankly dangerous perspective. A good analogy is this: If your organization was offered all of the source code for Microsoft Windows without charge, but with the stipulation that you would have to fix all bugs and make all enhancements yourself from then on, would you accept the offer? Large OSS packages are at least as complex as Windows, so casually adopting such source code into small internal projects creates the support-cost equivalent of a very large and fast-ticking time bomb. A useful three-step rule of thumb is this: Try executables first, community support second, and new code last:

Always try using the executable version of the OSS first. OSS tends to be more configurable than alternatives, so the first step is to consult with experts to see if an OSS application can be configured to meet a need simply by downloading the "standard release" binary form of the OSS. (For security reasons, you may still want to download and compile the source code locally.)

Next, try submitting non-sensitive changes to the supporting community. If some feature of an OSS application absolutely must be changed or extended to the source code level, to try to express the changes needed in a way that can be submitted directly to the community that is supporting the application. This approach not only reduces the need for long-term support of the source code, but it can also help build a stronger relationship with the supporting community.

As a last resort only, develop your own modules. In the rare cases where code changes absolutely cannot be made public, look for ways to develop independent modules. If at all possible, avoid any inclusion of OSS source in such modules. Every line of OSS source code included in a new module must be checked and updated whenever the original OSS is updated and can also needlessly complicate the legal status of the module.

Avoid overly casual release of government code as OSS. Government projects responsible for non-sensitive government off-the-shelf (GOTS) products often find the community support features of OSS highly attractive and wonder whether they can simply release their GOTS products under OSS licenses to take advantages of the lower costs, faster bug fixes, and improved long-term support seen in some OSS projects. The answer to this question is easy: No. The valuable properties of OSS support emerge from having a community of people already interested in the product, and the valuable modularity and flexibility of OSS emerges from it having been developed over a period of years by such a community. Simply making GOTS products OSS by changing their license and posting them on a website exposes all of their flaws to any interested hackers, without necessarily attracting the interest of supporters who will in any case almost certainly be mostly baffled by the unfamiliar source code. A better approach to replacing GOTS applications is to look for configurations of existing OSS tools that could be used to approximate the GOTS features. Then try to start building a new community around that configuration to build it up into a full-featured analog or extension of the original GOTS tool.

Encourage a realistic understanding of security in all commercial software. If software is sold or released in the form of binary code, its security situation in the modern world is no different from software that has been released in the form of human-readable source code. The reason is that modern hacking tools work directly against the binary forms of software to attempt to crack it, making the binary form in some ways preferable over the human-readable form that would be hugely slower to analyze. Thus the commonly expressed fear that OSS cannot be made secure because "the source code is available" is just nonsense.

The opposing argument that OSS is always more secure because "thousands of eyes" are looking at it is also faulty for a simple reason: Just because source code is posted on a website doesn't mean anyone is looking at it at all. Proprietary software may also be touted as more secure because it has been "certified" in one way or another. Unfortunately, because no software certification process in existence has ever been demonstrated in a scientifically assessed field study to produce software that is measurably more secure or reliable than uncertified software, it is not clear that such certifications mean anything beyond that the companies involved were able to afford the high cost of such certifications. Certifications are applied inconsistently, with federal desktops typically running systems and applications that have never been certified or that were certified so long ago that the certifications no longer apply. OSS is sometimes assumed to be non-secure because "anyone can insert a change" into the code. Though it is true that anyone can make a change they like to their own copy of OSS source code, the actuality is that large, active OSS projects such as Linux have closely guarded and highly automated code control processes that only allow code to enter into the main build process after it has been scrutinized literally by some of the world's top experts on operating system kernels—a level of verification that would put most proprietary code control and review processes to shame.

Conversely, many proprietary processes that keep source code secluded are riddled at multiple levels with opportunities for people to insert changes that could gravely damage the security of such systems. The bottom line is this: Security is a process that is best assessed based on the actual details of each case; whether it was developed using proprietary or OSS community methods changes the issues that must be examined. Proprietary methods have the advantage of bringing more money to bear, whereas community methods are more visible to more users. When active and global in scope, OSS can also bring to bear experts who are far more likely to spot infiltration attempts.

Software certifications: Look for them, support getting them, but never rely on them. As noted above, there is no scientific evidence that software certifications make any difference in the field-level reliability or security of software. They are nonetheless required in many cases. For OSS, companies such as IBM have helped provide certifications. SEs therefore should look for certifications of relevant OSS in case they are available and see how they compare to proprietary equivalents. It is also possible for interested projects to help OSS groups get certifications, such as through the small proprietary companies that often handle the business side of the use of a particular OSS component. Finally, regardless of whether a commercial software component is OSS or not and certified or not, the overall security of a networked software system should never be assumed to be proven; multiple layers of security are an absolute necessity.

1 GNU (GNU's Not UNIX) is a UNIX-like operating system developed by the free software movement starting in 1984. In 1992, the almost-complete GNU system was combined with the Linux kernel, producing the GNU/Linux system. The GNU project developed many of the core programs in GNU, but it also included available free software such as the X Window System and TeX.

MITRE intends to maintain a website that is fully accessible to all individuals. If you are unable to search or apply for jobs and would like to request a reasonable accommodation for any part of MITRE’s employment process, please contact MITRE’s Recruiting Help Line at 703-983-8226 or email at recruitinghelp@mitre.org