Section Three: Using Open Source Software

A modern software system is made up of various smaller software components, and each of these components can be either custom built, or reused from existing open source projects. A report from Synopsys shows that the majority of software in use today is open source, and much of that is at this component level—building blocks of open source software stitched together to create systems and applications. From basic open source software (OSS) components like code compilers (such as gcc), to entire user-facing systems like WordPress, reusable OSS spans a wide range of sizes and use cases.

Most OSS comes in these smaller components, sometimes called “packages” or “libraries.” These open source packages are used in virtually all software built, as reported in the same Synopsys study. They handle small tasks that systems everywhere need to handle, and do it in a simple, vetted, reusable way. For example, many software systems reuse open source packages to make data requests across the internet, or to encrypt and decrypt data. These packages allow software engineers to save time by building on the existing work of others.

When using smaller open source packages, software engineers use a “package manager” to search for OSS packages that meet their needs, download those packages, and link them into their own code. Package managers also manage updates and version control. Advanced package managers also work to maintain the security and availability of the packages available on their platform. This is less involved than forking and modifying a project, but more technical than simply installing an application such as Firefox.

In many cases, OSS is a whole system, such as in the case of WordPress or Firefox. These systems can be wholly reused to fulfill the needs of your organization. For example, open source systems can be used for content management or client relationship management. These complete, open source applications are built to be used by non-technical consumers, and include simple instructions for installation and usage. These systems are proven—they are stable and reliable—and can be customized to fit a variety of needs. For example, the White House has been operating its main whitehouse.gov website on WordPress since December 2017, demonstrating the stability, security, and reliability of an open source solution.

Regardless of whether your organization is looking to use smaller packages or complete open source applications or systems, there are a number of considerations to make when using existing open source software. Below, we’ll explore these considerations.

Finding open source software that meets a specific government need can be difficult. Unlike proprietary licensed software, open source tools rarely have a sales team marketing their brand. However, there are ways you can search for open source tools to fit your needs and make the discovery process easier including:

• Search for generic applications based on their main function. For example, if you are looking for a software system that you can use to track applicants as they move through an approval process for a housing permit, you can look for a more generic open source permit processing system that fits your needs. On a smaller scale, if you need a component for your larger system to send emails and text reminders to the public, then you could look for an open source notification system.
• Look for open source solutions used or produced by other similar government entities. If you want a system to manage searches for business records, chances are high that another agency or municipality has done the same thing using OSS. Reach out to these peers via user forums, developer communities on GitHub and Stack Exchange, LinkedIn groups, and other networking opportunities and tell them what you need. They may make suggestions, right down to giving you modifications that work for your particular situation. Networking and information sharing are particularly useful since you can partner with these users to contribute back to the original open source software—especially if you add helpful features.
• Look at how other governments are leveraging open source software for their services and operation, and learn about what you can adapt in your own work. Many other offices and municipalities have already started moving to open source solutions for a wide variety of needs in their government, and can provide insights into what has worked for them. Examine what they use to get a sense of what you can take and reuse for your own needs. You may find some good ideas just by looking at what exists, rather than finding something to fit a predetermined need.

Licenses provide safety for you as a consumer to use the software, as long as you abide by the license terms. When using externally developed open source software, you must follow the author’s license agreement. As a consumer of the open source software, you are legally required to follow the license of software you use. These licenses spell out the terms of use, including how you are able to use, copy, or modify the code; whether you must attribute your usage of the software; whether your software must use the same license if you use their software as a component; and other types of requirements. The license effectively describes the terms of use for the open source code. Open source projects do not charge to use the software itself, and payment should never be a part of an open source license. OSS licenses are not agreements you make and sign with the authors. Instead, they allow the author to proactively give permission to the software for a wide variety of uses. While the authors still carry the copyright (which we cover later in this report), the license proactively allows anyone to use the software.

If the authors of OSS do not provide an open source license, do not use that software. The ambiguity of it introduces too many risks, and it’s safer to find an alternative with a license that fulfills the same function. If you find something you want to use that does not have a license, you may ask the authors for a license to their software, but it’s up to them how they proceed.

Assessing Non-License Costs

OSS is free. This means that there are no costs to license or use the software code itself. However, there can still be costs associated with using OSS. These costs could include application or web hosting or personnel costs if your staff lacks the skills to customize and support the software. As one of our interviewees told us, “Open source is free as in puppies, not as in beer,” meaning that while you don’t have to pay for the OSS, there may still be costs for its hosting and maintenance.

When using OSS applications that need to be hosted on a server, such as WordPress, you still need server infrastructure on which the software will run. These servers can range from extremely simple to highly sophisticated, depending on the needs of your organization. In addition, you will need storage for corresponding data and databases. Servers and storage infrastructure come at a cost, albeit often a fairly cheap cost if you tap cloud services.

Even though you’re using software built by someone else, you may still need to hire people to customize or update the software to fit your specific need. For example, you may need software developers to copy the software used by one jurisdiction and change it to match the language and function of your own. In some cases, the software will have simple mechanisms for customization or updating such that you won’t need technical talent.

Even though you’re using software built by someone else, you may still need to hire people to customize or update the software to fit your specific need.

While there are some costs, they are negligible compared to the extensive costs associated with licensing closed-source, proprietary software products. The infrastructure costs can be simplified to merely what is needed for your system, and these infrastructure costs tend to decrease over time. Likewise, the costs of bringing in technical talent ensures that the lessons from performing this work stays within your organization.

Software that you bring into your organization should be well-documented. Good documentation accounts for multiple audiences. It should contain simple documentation for non-technical people to understand what it does, even if the software itself is highly technical in nature. The documentation should also explain how to use the software, with guides for integrating the software in your organization and rolling it out to users. More technical documentation, such as technical guides for integrations or explanations of the code itself, are also helpful when using open source components or systems, and especially if you plan on modifying the code itself for your context.

OSS that you use should be actively updated, with developers continually iterating the application, applying security patches and releasing new features. If software hasn’t been updated in years or even months, it’s likely that it will not receive attention when there are needed updates, such as security fixes. Instead, look for active communities and maintainers that regularly add features, fix security issues and bugs, and generally update the software.

Where possible, look for open source projects that are supported and maintained by established organizations. These organizations tend to have more official practices for maintaining open source projects, and can provide much more consistent support and community management. These maintainers should enforce good community management practices, such as reviewing code being submitted and actively informing the community of developments. Examples of organizations that manage large amounts of open source software include Apache, The Linux Foundation, Red Hat, Mozilla, and 18F.

It’s likely that you might find an open source project that mostly matches your needs but is missing one or two features, or has extra features you don’t need. This is very normal, and showcases the strength of open source. If you need additional features, you can add them, and submit those changes back to the original project as a contributor so that others can take advantage of your work. If you don’t have access to technical talent, you can start a conversation about your needs with that project’s community.

Lastly, open source projects should clearly outline the various restrictions, requirements, and processes they follow. The open source license should be simple to find and clearly understood. Contributor guidelines and other policies on contributions should also be simple to find and understand. When these documents are clear and available, it protects you as a user from license risks, and creates a joint understanding of how you can engage with the project.

Once you’ve found an open source tool that you want to use—whether it’s a component, or a full application—you’ll have to work to bring it into your organization. The project’s documentation should be clear enough to make this process simple. Depending on the type of software, how much it matches your needs, and the size and complexity of the software, there are a variety of ways to bring these open source tools into your organization.

In some cases, OSS is specifically built to be extremely simple to use. For example, desktop applications like Firefox or OpenOffice allow people to simply download and install them, as you might do with any other application. Open source applications are no different from closed-source applications in this case, and are typically easy to install and get up and running. The difference: these open source applications allow for extensive configuration without having to modify any of the source code itself.

For software that needs some amount of modification of source code (as opposed to simpler configuration), you will likely create a copy (or a “fork”) of the source code for your own organization to use. You can update and change this fork as you see fit, as long as it is in accordance with the license. For example, the U.S. Forms System was forked by the City of Austin so that they could make their own modifications to it and maintain it as they needed. The City of Austin started from the code provided by the U.S. Forms System, and modified it to meet their particular needs. If, like the City of Austin did, you make changes you want to contribute, you would need to submit the changes to the maintainer for approval.