It's Not Magic, It's Reusability

Why governments are embracing reusable software, and why your team should too.

US federal agencies do periodic reviews of how they buy and build software. One consistent finding: an addiction to over-customization has left America poorer, more vulnerable, and far behind its potential. The legacy approach has resulted in bloated software that costs too much, is difficult to improve, and that's notorious for vendor lock-in.

The solution? Embracing reusability, where vendors thoughtfully blend commercial development and open-source components and then leave governments with free-and-clear ownership of their codebase.

While some customization is often required to meet the requirements that actually matter, there are three reasons why reusability should always be the primary goal: 

1. It means more security, not less

There’s a pervasive myth that closed software is secure software. The underlying logic is that keeping codebases locked down limits how much bad actors can inspect and exploit them. Or at least that’s what those selling you closed software would prefer you to believe. 

One party that disagrees? The most security-conscious part of the federal government. When the Defense Innovation Board was tasked with revisiting how the Department of Defense procures software, it came to a simple conclusion: commission fewer projects from scratch. 

While it made exceptions for eg. software specially designed to run natively on military hardware, it drew a bright line for the rest: “Where [procurement] processes are not amenable to this approach, the Department should modify its processes, not the software.”

The key thing about reusable software is that you don't need to wait for your project to be targeted by bad actors to learn how vulnerable it truly is. Instead you get to leverage learnings from every test and attack on its shared foundations. The DIB found that reusable alternatives are "more likely to be optimized for efficiency" and have "a higher likelihood of being secure to common cyberattacks..." This natural feedback loop is critical, and can’t happen in a walled garden. 

What else did the DIB recommend in their review findings?

They also came up with 10 Commandments for procuring software, one of which was that software "should also include source code as a deliverable". You can read their full 2020 reports here. We'll cover these more—along with rhyming findings from other state and federal departmental reviews—in other coming guides.

2. It’s always more budget-friendly

Reinventing the wheel is expensive, in more ways than one. 

The classic waterfall approach to procurement inevitably leads to brimming pools of well-meaning requirements. And legacy vendors of course do little to discourage this. The more complex and over-designed your software, the fatter their fees and the more dependent you are on them for long-term support. They’ll encourage every bell and whistle, hearing their register ring with each addition. 

The natural result? Delays, cost overruns, interoperability issues, and codebases that you don’t own and/or can’t easily adjust to meet future needs. 

The alternative? Buying software that already exists, lightly tailoring it to your real needs (as determined by talking to your users), and insisting on a copy of the codebase. This way you aren’t vendor-locked, you benefit from all external improvements made to the core components, and you retain ownership over everything you need for future flexibility.

How exactly does this approach guarantee cheaper pricing?

When we build software for your eg. agency or school board, we give you the code. But we keep a copy too, and then resell a version to the next agency or school board. Each of you will likely have unique components, but built atop a shared foundation. This means we can sell each copy—including the first one—at a substantially lower rate. It also means that all improvements made for each buyer flow back to all buyers.

3. Investing into reusability powers an innovation flywheel 

Builders of popular commercial software—along with the open-source community—would love to cater more to government needs. Any personal gains aside, they’re taxpayers too and want public spending to result in products that work and get better over time. 

When government software implementations are locked up in private codebases, this closes the window to those who want to help. It also reinforces the status quo in which legacy vendors feel little pressure to modernize their approach.

In contrast, when a government invests into reusable software, this educates outside industries on how they can help. They can then begin adding, expanding, and retooling software for more public use cases. This is the same fundamental strategy that's made Silicon Valley what it is, and why it's a place where new startups can compete almost immediately.

What are some examples of this working in the private sector?

When Microsoft created DOS for IBM, it added a crucial clause to its contract: it retained the right to license DOS to other hardware makers too. Had this not been the case, we wouldn't have seen the same explosion of competition that both drove PC costs down and enhanced what DOS could do for all users.

There was also a landmark case where Oracle argued that Google had violated its intellectual property by copying code from its Java APIs. The Supreme Court ruled that this was fair use, and that the copying was acceptable because it "allow[ed] programmers to bring their skills to a new smartphone computing environment". Expanding who could work on Java let it become a more useful, more valuable, and more secure framework.