Federal Source Code Study Series Part 3: Federal Government’s Intersection with OSS
Federal Source Code Study Series Part 3: Federal Government’s Intersection with OSS
By Joseph Castle, PhD, and the Code.gov Team
In part three of our series we take a look at what would be the birth of America’s Code. As the Internet begins to grow so does the need for new software in general and in particular for the federal government. As a government of the people, by the people and for the people we quickly realized that the code being developed should also be of the people, by the people and for the people. Take a look at how the marriage between open source software and government was inevitable.
Consumers of Proprietary Software
When the commercial industry moved to closed source software (CSS) in the post-mainframe-to-PC era, the federal government followed suit. Exceptions occurred in computing offices and laboratories where expertise and program requirements necessitated the ability to create and customize software (e.g., space centers, energy labs).
Centralized IT offices became responsible for developing, modifying, managing, and providing packaged productivity software for workers utilizing desktop computers. Government organizations focused primarily on procuring and implementing standardized solutions or consumer-off-the-shelf (COTS) software.
Towards Using OSS
In the 1990s, the federal government’s reliance on CSS began to change for many reasons. The Internet arrived to server rooms and front-office desktops allowing for real-time communication and file sharing. Server and web technologies became popular; two of the fastest growing Internet products, Linux and Apache, enabled server and application customization that accommodated myriad business needs. By the 2010s, workforce skills evolved to include more advanced computing ability that permitted others outside of IT to provide computing services (i.e., digital services) and products (e.g., websites, applications).
With the maturation and use of OSS as a product for consumption in government organizations, agency instructions and executive-level policy mandated that agencies consider OSS as a viable purchasing and implementation option. Because of this, the perception for OSS evolved, from skepticism about its security, reliability, and general use across the organization to belief in its efficacy as agencies used it to support critical operations.
Digital Delivery
By the mid-2010s, the landscape of government software consisted of a mixed environment of CSS and OSS. As the government brought in additional developers to deliver digital services and products, these developers moved to using OSS to avoid vendor lock-in and high licensing fees, improve the quality of software being built, and support the rush to newer technologies (e.g. mobile, Linux in the data center, cloud management with open tools). This trend occurred outside the U.S. as well with efforts by Canadian, British, Danish, Italian, and South Korean governments who created digital service and technology transformation teams.
Default to Open
According to 18F’s open source policy, “creating in-house digital services and solutions requires flexibility in how we code, with a focus on lowering costs for the American people, while improving their interactions with the U.S. government.”
By the late 2010s, mandates encouraged some federal government software development units to operate in the open. Units in the U.S. General Services Administration’s (GSA) 18F office and the U.S. Department of Energy Lawrence Livermore National Laboratory (LLNL) were just two of many that “default to open.” This meant that all source code was published publicly in an online code sharing platform with any code not available for public release requiring appropriate justification.
Coming Up
The next part of this series shifts to the analysis of each of the organizational factors affecting OSS publication and begins with cultural beliefs.
