Tens of millions of Americans have lost their jobs this year. Overall, over 35 million people have made unemployment benefit claims since the crisis began. State unemployment systems are crumbling under the load, and they’re desperate to modernize.
The CARES Act, passed March 27th, expands benefits for those who lost work due to the pandemic, notably $600 per week atop state-provided unemployment insurance (UI). It has an expanded scope, too — even people who were self-employed or worked in the gig economy can apply for Pandemic Unemployment Assistance (PUA) to receive that $600 per week. (At this writing, that funding expired a week ago, and Congress is wrangling over what to do.)
States’ legacy UI systems have struggled to keep up with the volume of applications, and are too inflexible to accommodate the changes in criteria.
At U.S. Digital Response, we spent April, May, June, and July volunteering at several state labor agencies, helping to patch struggling unemployment insurance systems. We’ve helped scale websites, troubleshoot call center volume spikes, and implement new web forms for PUA applications. As state labor agencies implement programs, they’ve also started revisiting their modernization plan, and in some cases, have asked us for advice and recommendations.
We’ve seen systems from all of the vendors in this space, from big firms like IBM, Deloitte, and Tata, to smaller firms like Fast Enterprises and Geographic Solutions. No matter what vendor states work with, we advise states to make sure they include an open source clause in their software development contracts. Here’s why.
* * *
State government requires custom software to operate. Unemployment insurance, Medicaid, DMVs, child welfare, SNAP, and all core government infrastructure depends on custom software bought by states at a large expense. Most of the software is overpriced and bad, but there is an easy way to improve this situation: open source software.
When it comes to important state infrastructure, top government software vendors use a double-dip business model. First, they charge us to build the software, then they charge us to use it. Nobody would pay to build a house and then pay to rent that house, so we shouldn’t do this with important state infrastructure. Vendors often claim that states are merely licensing software they’ve already built (“Commercial Off-The-Shelf,” aka “COTS”). This is often untrue. Instead, the software they’ve already built is custom for another state and will require large changes to work in a new state. These changes will be done at our collective expense, but with the resulting software owned by the vendor. In this scenario, we’re paying for a house to be rehabbed before we start to pay rent on it. This is absurd.
When paying a vendor to build custom software, vendors should be paid for their time, not for their time and for a license for the resulting software. The contract should reflect that, giving the agency ownership over the software. But it’s best to go a step further than that and place the software in the public domain, making it open source. Publishing government software as open source has many benefits with no drawbacks.
First and foremost, open source helps to prevent “lock-in,” in which a vendor tries to make it impractical or impossible for a client to ever switch to a competitor. When the source code is available for open replication, the vendor can’t use it as a weapon of monopoly. For future projects, vendors can inspect the existing source code prior to bidding, reducing uncertainty, and lowering the cost of the bids. This also reduces the switching costs associated with a system, which is important for government to be able to participate in a competitive marketplace.
Open source is also a crucial prerequisite for building secure software. Source code should never contain any secrets, like passwords, but it’s common for developers to have a casual attitude about this when the source code is closed. This is a mistake. Software can be decompiled — those secrets can be extracted. Source code can be leaked, as Edward Snowden demonstrated. And in many states, works of government are inherently in the public domain, which may include the source code that was thought to be secret. The Department of Defense maintains the excellent Open Source Software FAQ, and their answer to “Doesn’t hiding source code automatically make software more secure?” is summed up with the first sentence: “No.” Software projects should be open source from day one to avoid these problems.
Finally, the work done by developers will be enormously improved if it’s open source. Requiring all development to be performed on a social coding website like GitHub (think Facebook but for software developers) completely changes the incentive structure. Developers who work on closed source software generally work away by themselves — other than their immediate coworkers, nobody is ever likely to see their work. Government agencies rarely have anybody on staff who is capable of reviewing vendors’ source code to know if the work is any good, so they’re not inspecting their purchases. These are circumstances that provide developers with little reason to perform their best work. But if the RFP declares that the work will be open source, all of this changes. Vendors won’t want to respond if they know that their work is low-quality. Those who do respond will want to put their best team on the project. Those team members know that their work is being watched by friends and colleagues—and will be available for inspection by future employers forever—so their work is correspondingly high-quality. Open source gets the best work out of the best team at the best vendor.
How does an agency publish their procured software as open source? Simply, with a data rights clause:
Data Rights and Ownership of Deliverables — The Agency intends that all software and documentation delivered by the Contractor will be owned by the Agency and committed to the public domain. This software and documentation includes, but is not limited to, data, documents, graphics, code, plans, reports, schedules, schemas, metadata, architecture designs, and the like; all new open source software created by the Contractor and forks or branches of current open source software where the Contractor has made a modification; and all new tooling, scripting configuration management, infrastructure as code, or any other final changes or edits to successfully deploy or operate the software.
To the extent that the Contractor seeks to incorporate in the software delivered under this task order any software that was not first produced in the performance of this task order, the Agency encourages the Contractor to incorporate either software that is in the public domain or free and open source software that qualifies under the Open Source Definition promulgated by the Open Source Initiative. In any event, the Contractor must promptly disclose to the Agency in writing and list in the documentation, any software incorporated in the delivered software that is subject to a license.
If software delivered by the Contractor incorporates software that is subject to an open source license that provides implementation guidance, then the Contractor must ensure compliance with that guidance. If software delivered by the Contractor incorporates software that is subject to an open source license that does not provide implementation guidance, then the Contractor must attach or include the terms of the license within the work itself, such as in code comments at the beginning of a file, or in a license file within a software repository.
In addition, the Contractor must obtain written permission from the Agency before incorporating into the delivered software any software that is subject to a license that does not qualify under the Open Source Definition promulgated by the Open Source Initiative. If the Agency grants such written permission, then the Contractor’s rights to use that software must be promptly assigned to the Agency.
This can be dropped into an RFP or a contract as-is.
* * *
It’s trivial to commit to open source within an RFP, and the benefits are enormous. It reduces switching costs, improves security, and provides vendors with an incentive to do their best work. When states are procuring custom software, they should default to open source.
If you have questions about your unemployment insurance modernization process or need another set of eyes on your RFP, U.S. Digital Response is here to help.