Eight reasons why government contractors should embrace open source software
Government contractors have traditionally been slow to embrace open source software. There’s a handful of reasons why that’s the case, but it doesn’t have to be that way. Here’s why government contractors are embracing open source with increasing frequency:
1. Industry-standard best practices
You’d be hard-pressed to find a startup worth its angel investment today that isn’t built on open source software. Heck, even enterprise giants like Microsoft and Adobe are embracing opens source workflows. As agencies are increasingly looking to shed the outdated IT stereotype and embrace modern software development practices, offering open source solutions serves as a proxy for the express lane to industry standard best practices.
Even a casual observer of the industry can see the direction things are heading. Government contractors that have a history of participating in the open source community and who brag about their open source prowess in responding to government RFPs can gain a unique first-mover advantage and would be uniquely attractive to government agencies.
2. The easy problems have already been solved
As we say in open source software, the easy problems have already been solved. How to get information in and out of a database, how to stand up a blog, or how to convert tabular data between formats are all problems for which well-established open source solutions already exist. Why waste time reinventing the wheel when a better one already exists?
In the government space, the decision becomes even more clear. The types of challenges government agencies face are not unique to the particular agency. A press release is a press release. A FOIA request is a FOIA request. And unlike say, Coke and Pepsi, where one’s advantage affects the other’s bottom line, when the Department of Commerce open sources a Drupal module, the Department of Energy benefits because they don’t have to make the same upfront investment, taxpayers benefit because their tax dollars go further, and the Department of Commerce, by splitting subsequent development costs across agencies, will likely be better off in the long run, as others contribute improvements to the shared code.
In an environment where agencies are receiving increasing pressure to do more with less, government contractors that embrace open source can deliver agencies the same solution, for a fraction of the cost they would otherwise, extracting larger profit margins, or passing the cost savings on to taxpayers.
3. Free advertising
Government contractors are often contractually prohibited from disclosing the nature of their work performed under government contract. That’s why contractor’s sites are notably silent on portfolios or long lists of satisfied clients. Open sourcing work performed under a contract makes that project’s history a matter of public record. Any member of the public can browse the project’s commit history, and depending on the specifics of the contract, the contractor may then be able to talk freely about their efforts.
Open source provides government contractors with the ability to build a portfolio of past performance, whereby members of the community can evaluate the quality of the work and better understand how the firm approaches software development without the need to write a single line of procurement legalese.
4. Attract and evaluate talent
Potential customers aren’t the only ones that can benefit from the software being public. Being an active member of the open source community allows the government contractor to become a known quantity, and to establish a reputation as a firm that supports open source software. You can’t buy goodwill like that.
As the contractor seeks to attract talent, by the time they step foot in the career fair, or post the job posting to their site, the most passionate, talented developers in the space already know who they are, already see how they work, and already want to work for them.
Better still, because open source is collaborative, there’s a good chance you’ve already had an opportunity to evaluate the applicant. What better way to evaluate how the applicant would contribute to your organization’s software, than to be able to evaluate them as they contribute to your organization’s software over the lifecycle of an open source project? At GitHub, for example, we’re already familiar with many of the developers we hire, well before a résumé ever changes hands.
Open source provide government contractors with a platform to establish a brand among the industry’s most committed developers, to attract that same talent, and to evaluate how they’d work, all without spending a single dollar on recruitment.
5. Guaranteed maintenance
There are two big buckets of IT contracts: software development, and operations and maintenance. Traditional software development contracts are often a large, firm-fixed price, agreed upon up front, but once the software is delivered, the revenue stream may dry up depending on whether the agency chooses to invest further in the project by building out additional features.
With open source, there’s always a built-in maintenance component. Once open sourced, agencies will require someone with the technical know-how to foster a community around the code, evaluate proposed changes, and answer questions in the support forums, rather than let the project dry up and die on the vine. Whereas an agency may choose not to develop new features, once in the hands of the community, there’s a high probability it will be improved upon for a particular use case or that bugs will surface. Most agencies don’t have that expertise in-house, and are increasingly turning to industry partners to maintain the day-to-day operations of the project.
Rather than being a one-off engagement, open source provides government contractors to establish long-term maintenance and engagement contracts, and to advise the agency on open-source best practices throughout the lifecycle of the project.
6. Day-to-day visibility
A lot of the overhead inherent in government contracting comes from shuttling information — be it code, bug reports, or mock ups — back and forth between agency and contractor. Each side has their own project management process, which may range from Excel spreadsheets and email to Gantt charts and dedicated project management tools.
Open source eliminates that overhead by facilitating the free-flow of information. Found a bug? Submit an issue describing what you see. Want to know the status of a particular feature? Subscribe to the pull request. All of a sudden the agency has day-to-day visibility into the project’s status, and does so at no additional cost to the contractor. In fact, project managers are often freed from serving as an interface to the client, and can concentrate on higher-level tasks like delivering the best software possible.
By unshackling project information from costly corporate channels, open source streamlines interactions between agency and contractor, ensuring project status is communicated cleanly, efficiently, and without the need for duplication of efforts.
7. Internal efficiency
Open source software is developed by teams rarely in the same place at the same time, rarely working on the same thing at the same time, rarely with fully aligned interests, and despite this complexity, consistently delivers higher quality software than its purpose-built and proprietary counterparts. It’s the story of Wikipedia versus Encyclopedia Britannica.
Adopting open-source workflows, even if the code itself is never made public, can be a force multiplier for teams, allowing them to shed bureaucratic cruft and adopt leaner, more agile workflows. While it’s certainly possible to publish code developed under a waterfall approach, the decentralized nature of open source, absent a centralized planning authority, almost necessitates iterative development.
Whether shared with the development team, the agency, or with the public, open source workflows allow government contractors to adopt best-of-breed development practices, and to streamline their own internal communication practices.
8. Better code
Open source is not just a workflow and a philosophy, but also a development style. When you write code you know is going to be shared with others, you’re less likely to hard-wire custom functionality, or hardcode deployment-specific considerations. As a result, you get abstracted, modular code that can be repurposed, redeployed, and more-easily upgraded in part, rather than in whole.
You also gain the benefit of more mature code. Many contracts may call for the same challenge to be solved. Rather than writing a custom XML library for each project, open source allows you to reduce duplication of efforts internally, by allowing you to adopt an existing library, or to start your own shared library. More eyes, more time, and more use cases, means more stringently field-tested and proven code for both projects on day one.
Assuming you engage in more than one project over the lifetime of the contracting firm, open source forces government contractors to write better, more modular, less fragile code that can be shared between components.
Get involved today
Open source has traditionally gotten a bad rap as being a fringe effort, being buggy, or being hard to break into. All three of those assumptions have changed dramatically in the past years, especially in government, as we see open source increasingly used in place of traditional, “enterprise-grade” solutions with positive results.
If you haven’t recently, take a closer look at open source. I think you’ll be surprised. Find something small — a bug in the software that powers your site, a shared library used internally, or a tool used to facilitate your own workflows — and open source it. Government contractors may be stereotypically hesitant to embrace the latest industry trend, but open source is neither risky, nor a passing fad. Open source is here to stay.
As young firms begin to bring their open source experience to the marketplace, the only questions is whether existing government contracting firms will finally get ahead of, or continue to lag behind the technology adoption curve.
If you enjoyed this post, you might also enjoy:
- Why open source
- 19 reasons why technologists don't want to work at your government agency
- Five best practices in open source: external engagement
- Twelve tips for growing communities around your open source project
- How to make a product great
- 15 rules for communicating at GitHub
- Everything a government attorney needs to know about open source software licensing
- The difference between 18F and USDS
- Four characteristics of modern collaboration tools
- The three biggest challenges in government IT
- A White House open source policy written by a geek
Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →
This page is open source. Please help improve it.
Edit