Section Four: Managing the Details

As you and your organization start introducing more open source software (OSS) and practices into your infrastructure, you may run into some recurring issues. For this reason—rather than encountering the same challenges every time you embark on a new project, you may want to build an infrastructure that allows for all projects to easily be made open source. Here, we’ve outlined some of the details that should be kept in mind when moving your organization into a more holistic open source strategy.

Policies should encourage and support the broader usage of open source tools within your organization. This may require getting executive buy-in and creating teams to explore how open source will benefit your organization. Once you have buy-in, clearly articulate that projects and teams are allowed to use open source software, and provide clarity on how open source use may interact with other policies. Give teams that want to use open source the permissions they need to do so, and simplify the processes to let them focus on finding and matching software to the needs of their users.

Create organization-wide policy to reduce the barrier to entry for adopting open source practices. Use policy to standardize processes, clarify risk interpretation, set expectations for open sourcing tools, and provide repeatable procedures for projects just getting started. You can find examples of good open source policies in GSA’s Open Source Policy and CFPB’s policy, and supporting details on Code.gov.

Open source policy is a great way to encourage and enforce the adoption of open source principles. U.S. Federal policy M-16-21 set the bar for federal agencies to support and use OSS. Since it was released, nearly 7,000 individual federal source code repositories were made available to the public on code.gov. M-16-21 requires that agencies “release at least 20 percent of new custom-developed code as Open Source Software,” which has encouraged the creation of open source programs across the government.

Establishing a Licensing Policy

Use policy to clarify the interpretation of open source licenses and provide legal consistency of the risks and benefits of open source. This can minimize the misplaced concerns around legality that many hold around open source software. Consistent interpretation is a huge benefit, as one of the larger hurdles with organization-wide use of open source is the variable interpretations of open source licenses. As previously mentioned, these licenses range from straightforward to complex, and the interpretations can vary depending on the technical proficiency and risk attitude of the legal counsel involved. Creating a consistent interpretation of open source licenses will smooth its use and access across the board.

For example, creating policy that outlines pre-approved software licenses can alleviate the burden of repeatedly seeking approvals. There are a set of commonly-used licenses available from the Open Source Initiative, such as the MIT license or the Mozilla Public License. Licenses vary in how they handle attribution, license reciprocity, and other factors. Opensource.com discusses some key differences in licenses in this blog post. It is highly likely that any open source software that you are looking to use leverages one of the licenses from the Open Source Initiative. Consider creating a policy that pre-approves certain licenses so that any software with those licenses can be used in your organization without requiring a license review.

When building OSS, it’s important to make correct decisions on the licenses, copyright, and general ownership of the software. There are many factors that play into this, including your jurisdiction’s copyright laws. For example, in some jurisdictions the government cannot hold any copyright, while in others the government reserves all ownership. By collaborating closely with agency or organization legal teams, communicating clearly to community members, and using existing licenses, you can navigate this more challenging terrain and develop a plan that meets your needs. Here, we outline some considerations and common strategies. We also recommend reading GitHub’s simple guide to the legal aspects of open source. However, the best practice is to involve legal support from within your organization from inception, and task them with figuring out how to make this work positively. Attorney and open source developer Ben Balter provides a guide for government attorneys on open source licensing that is worth the read.

Software written for government purposes and paid for by the government, should always belong to the government—not to vendors or contractors. This is true regardless of whether the software is open or closed. With open software in particular, open sourcing the software does not eliminate the government retaining copyright of the software it wrote and financed. When procuring services with vendors, ownership and copyright for custom-written software should be clearly outlined in contract documents with a caveat that it belongs to the government. If your jurisdiction cannot hold ownership, then the software should be placed in the public domain. By owning the copyright, you ensure that you control the ability to open source the software, rather than leaving it in the hands of vendors.

OSS may have contributors who are not contracted vendors. This is, after all, one of the great benefits of open sourcing your software. These contributors might be other offices within the same government, public servants from different municipalities, companies or nonprofit organizations, academics, or constituents. To protect your organization’s interests and the interests of the open source project, you should clearly articulate to contributors how the licensing and copyright of their contributions will work. There are many ways to do this, and varying industry opinions on the right path to take. One prevailing option is to allow contributors to retain copyright of their contributions, but stipulate that their contributions fall under your license, meaning that any contributors to your project extend an unlimited license to use their code. Alternatively, if you perform a code review of their software, you may be able to argue that by performing the review, the software is released under the appropriate license, as the Department of Defense has argued. Work with your legal team to determine the right type of guidance to provide.

The government-vendor ecosystem is a vital one that ensures a constant availability of up-to-date knowledge and talent in a flexible format to the government. Historically, this ecosystem has operated outside the open source world, using proprietary software or restricting ownership and usage of software. The move to an open source paradigm will likely require changes to existing business models, and as such, the vendor community may resist any changes in the status quo. However, vendors can adopt open source practices in a way that will support expanded business. Large tech providers, like IBM, have invested in OSS as a way to break into new markets, offer value-added services and absorb highly-skilled developer communities, proving that companies can still profit from open source development.

While some vendors will adopt open source business models, others will be resistant and hold onto proprietary software as a means of sustaining business. As you start including open source in your procurement plans, take care to build in protections and pay attention to details when commissioning software development. Ensure that any contracts include explicit language stating that all software used for the solution, whether newly written or reused, will be open source. Also make it known that proprietary, closed-source software will not be used for the solution. While this may seem redundant, it protects against vendors who may use loopholes to lock you into their platform. Ensure that the government owns the software that it pays for, and if possible, build into the contract which open source license the software will use. Build on existing precedent, adopting language used from previous open source procurements in your or other jurisdictions. While many of these steps may seem defensive, it will help protect you and your organization and make the move towards open source faster and more securely.

Whether you are building a new system in the open or reusing existing open source solutions, you will still be operating a system that likely collects data or works in tandem with other systems or applications. This interoperability is crucial to creating an effective software ecosystem that supports your business needs. There are a few things you can keep in mind that support interoperability:

• Bring knowledgeable people to the table to discuss interoperability between various systems. If your operations depend on legacy systems, ensure that someone who manages those systems is present for discussions. They should be able to speak to the integration capabilities and limitations of the legacy system. This simple act of bringing the right people together, when done early on, can help drastically with reducing any integration and interoperability pains. A good rule of thumb is to not assume anything about legacy or new systems unless you have first-hand knowledge.
• Follow common data standards when recording data. If you examine data, chances are high that at least one (if not several) data schema standards already exist in your organization. These standards help make the collection and sharing of data more consistent across various organizations. Using one or more popular data standards ensures that you’re taking advantage of the hard work that went into creating them, saving you from the trouble of having to come up with the data schemas on your own. Many organizations create and manage data standards, such as schema.org.
• Use systems that provide open interfaces (or, build open interfaces into your systems) to facilitate the transfer of data. These open interfaces, or APIs, allow other systems and software developers to integrate with your solutions. Open interfaces should be well documented. Wherever possible, use common standard interfaces for standard data or operations, so that other systems know what to expect and can integrate even more seamlessly.

Using OSS puts your organization much closer to the source code of the technology you’re using than you may have ever been before. Many governments and organizations almost exclusively use customized proprietary software, and remain unfamiliar with application source code. This is in part because many organizations don’t have the in-house technical talent or expertise needed to modify or make changes to such code. This is fairly normal, and is why the government-vendor ecosystem is so important. Our recommendation is to bring in talent who will support the usage of open source tools, while helping to build a more modern, digital organization.

The following roles are central to any software product development team, and will enable your organization to move towards an open source development paradigm with confidence:

• Product managers are broad experts, serving as the connecting point of business needs, technology, and user experience. Product management, not to be confused with program or project management, is a rare discipline in government. Product managers set the vision and mission of products and services, and drive the organization towards the successful implementation and delivery of those products. Bring in a product manager first—someone who has experience building modern live digital products.
• Designers and researchers are critical to ensuring that the solutions being built solve real problems in ways that will result in tangible outcomes. Designers and researchers can take many forms, from interface design to service design. Choose what you need based on your context and recommendations from your product manager.
• Software engineers are the backbone of software development. Many organizations and government agencies employ software engineers, but they often work in roles that are removed from decision-making. Consider hiring senior software engineers who can write and review code and who manage technology teams and projects. Avoid various software engineering substitutes, such as enterprise architects, as a senior software engineer should be able to fill these roles.

It may seem like a tall order to bring in the talent required to manage OSS, but ideally this talent can be used elsewhere in modern organizations that build and offer services to the public. You won’t need to hire swaths of talent, instead, hire enough in-house talent such that any tech-related departments or projects can make use of it. There is no substitute for in-house expertise.