Defaulting to open is one of the plays in the federal CIO’s digital service handbook. These days, using open source software libraries within your government tech project is the default, as open source libraries power much of modern technology. But what about making open source software as well? Fortunately, more and more government teams are deciding to build, publish, and maintain their websites, applications, or systems as publicly accessible code under open source licenses.
In addition to federal policy that encourages it, there are great reasons to make your software open source. You might want to encourage public engagement with the project, such as giving folks a process for reporting and even fixing bugs, or enabling them to contribute enhancements to the code library. You might simply believe it’s the right thing to do from the tax-payer’s perspective: the public is paying for the tech, so the public (and other government teams) should have access to and be able to reuse the tech at no additional cost.
In my experience, there’s an even more basic, operational reason making your project open source: it helps your government tech team be more productive, and is therefore better for the project’s bottom line.
Incentivize Better Coding Practices
This is a generalization, but it’s probably not a surprise: developers I know (including myself!) will typically spend more time on code readability, organization, and overall quality when they know other people are going to look at it – and especially if others will try to use or reuse the code. Of course, there is plenty of bad open source code out there, but you can use open source principles to encourage or even prioritize practices that will increase code quality. For example, when a developer does need to take a shortcut or perhaps make a confusing coding decision, building in public may incentivize them to document their reasoning in the code or in the commit message (the message explaining the change in the code’s version history).
More readable, documented, and better organized code means it’s easier and faster not just for strangers to the project to understand, but also new and existing team members.
Enable More Competitive and Better Equipped Vendor Teams
When your project is open source, vendors who want to bid on the contract to maintain or enhance it can see what they’re bidding on. This means the bid is actually competitive: the original vendor can’t argue that they’re the only ones who know the code, or worse, that they own the code (note: your contract should stipulate that the government owns the IP, not the vendor, even if the code is not open source!). New potential vendors can view the code and craft their bid based on reality instead of guesswork.
Then, when a vendor wins the contract and comes onboard, they’ve had the opportunity to staff their teams appropriately and already become familiar with the project, tech stack, coding styles, etc. – all leading to faster onboarding and greater productivity.
Onboard New Team Members Faster
Regardless of the vendor vs full time employee makeup of your team, open source projects can support faster onboarding of new team members. This isn’t just about the increased readability and code quality discussed earlier. Individuals can start reading the code in their web browser (assuming the code is hosted on a web platform such as Github or GitLab) as soon as they join, instead of having to wait what is often many weeks in government to get their new laptop or credentials.
Don’t worry: Having access to the code is not the same as having access to sensitive data or production systems. While a new team member won’t be able to access those things until their accounts and computing environment are set up, using that lead time to read the code, learn the team’s coding style and conventions, and understand the architecture and past decisions means they can hit the ground running when they do finally get set up.
Empower Teams Dependent on Your Tech
Open source software projects not only help your team be more productive, but they can help other teams in your agency be more productive too.
Let’s say you have a team that builds a mapping library that other teams at your agency use to embed maps on their websites. If one of those teams wants to add a new color to the map’s color palette, they can make a feature request asking your team, the maintaining team, to add it. If your team doesn’t have bandwidth to add it anytime soon but the requesting team has some additional capacity, then the requesting team could fork (copy) the source code, make the change themselves, and use it immediately, and even submit that code change as a contribution back to the project’s main codebase.
The maintaining team then only has to review the code, make sure it passes automated tests and conforms to the project’s coding style, and then can accept and deploy the change. After that, any team using the mapping library can use that new color.
This depends on the project having a documented process for making feature requests or bug reports and contributing code to the project – common documents in open source projects. Once you have this process established for your project and your project’s users, you can empower your users to solve their own problems and not be blocked by your team’s bandwidth, within governance constraints set by you. This is better for those teams, and it can make your team’s project better over time through quality contributions and being in close communication with your project’s users.
Shelby Switzer is a Fellow at the Beeck Center for Social Impact and Innovation at Georgetown University, helping governments build/buy software collaboratively through Beeck’s Intergovernmental Software Collaborative. Their career in civic technology spans a decade and includes volunteering with Code for America brigades across the country, contributing to open source and open standards projects, working at tech companies serving governments and community organizations, and leading various technology projects at the US Digital Service. They write regularly on civic technology and digital public infrastructure on their blog, Civic Unrest.
Leave a Reply
You must be logged in to post a comment.