Government agencies that want different results from their software procurements recognize that they need to get bids from new vendors to make that happen. A lot of work needs to go into that (market research, dividing up projects differently, simplifying terms & conditions, circulating solicitations more widely, etc.), but three changes stand out above all others for their effectiveness in warding off incompetent vendors while attracting new, well qualified vendors: owning copyright, publishing the software as open source, and issuing smaller contracts. Let’s review each of these in turn.
Own Copyright
Some of the major vendors in the custom software space use government contracts as a source of R&D funding to develop software that they retain ownership of, and then sell to other agencies. They create it as custom software for the first agency, and then license it as “commercial off-the-shelf” (COTS) software to subsequent customers. This is wasteful spending by government, which is left licensing near-identical software that they should have retained ownership over in the first place. An enormous amount of work is required on the part of agencies to support vendors’ development services, and there is no reason whatsoever that the benefit should accrue to the vendor. (Sometimes the private sector should retain copyright for custom software! This is what SBIR funding is for. But if it’s not SBIR-funded, the vendor should not retain any ownership over the rights.)
This predatory contracting model is not something that agencies should participate in. A solicitation that makes crystal clear that copyright will be held by the agency will repel these vendors, while attracting vendors who have no interest in owning these work products.
Publish Software as Open Source
Once the agency owns the software, they should release it under an open source license; or, if it’s a federal agency, it should be released into the public domain or, better, under a Creative Commons Zero license (public domain, but with international applicability). I recently wrote at length about the value of agencies publishing their software as open source, so I won’t belabor this.
Issue Smaller Solicitations
Agencies often turn a monolithic need into a monolithic procurement. “The legislature requires us to stand up a new benefits system” turns into a solicitation to create a new benefits system. This is extraordinarily risky, with vanishingly slim odds of success. There is no vendor that’s able to write software, host software, operate a server farm, run a help desk, run a training program, run a call center, and manage payments, and there are only a literal few who will bid on such a contract (intending to subcontract most or all of the actual work). Issuing solicitations like this guarantees that you’re only going to receive bids from the usual suspects, and ensures that you’ll get the exact same results that you’ve always gotten.
Competent software development vendors don’t want to run your help desk or train your employees—they just want to write software. They’re not going to bid on $100 million projects, because the time and effort required to get a contract like that is enormous, making it too big of a risk to bother with. (Also, for a small vendor, actually getting a contract that big would pose an existential risk to them.)
The solution is to break up the contract into smaller pieces. Have one contract for software development, one for help desk services, one for hosting, etc. Is that more work for the contracting shop? Possibly, certainly the first time they take this approach. But then one failed contract won’t sink your whole effort, you’ll get vendors who are actually good at the thing you’re hiring them for, and you’ll get bids from vendors who aren’t the usual suspects.
There is a laundry list of other things to do differently to attract new vendors (and fend off bad ones), but the the highest-impact ones are the trinity of owning copyright, publishing the software as open source, and issuing smaller contracts. This combination will make a big difference.
I wish they would do this, it would lead to better outcomes.
However this would require the govt to have the capability to own, plan and manage their own software and software development. While the development work would still be outsourced, the product owner would be playing a much more active role in the process. Significant upskilling and a big change of philosophy around the role of government in the economy would be needed before that would be possible. I don’t see that happening, under neoliberalism.
It’s happening now, throughout the United States, at all levels of government. It’s literally my job.
So lovely to hear this perspective. When I was at Excella, we often wished for this sort of thing. It was hard for me to see us get crowded out by behemoths when we had an OSS mentality from the start and were all about iterative & incremental delivery (and would have been content to bid in such a system on the pieces of work that applied to us).
Something is missing here that was previously in the 18F de-risking guide (IIRC) — the idea of buying teams for outcomes rather than buying specific outcomes at all. Would have loved this at Excella because we had a ton of people that were deeply skilled and it could have given us flexibility to provide the right expertise at the right time. However, I get that it’s also very easy for an unscrupulous vendor to take advantage of if government partner isn’t sufficiently on top of things. Is this approach still something you’d recommend today? And if you’ve moved away from that thinking, is it for that sort of reason?
Yup, I recommend that approach highly—I just didn’t name it here because it’s outside of the scope of this thesis. I advocate for the use of a Statement of Objectives (not a Statement of Work) in which the vendor is a partner of the agency, as overseen by an agency product owner, in helping to solve the problem statement in the solicitation and work toward the vision outlined in the solicitation. That for sure requires a government partner is is on top of things—a product owner for whom this is their full-time job, and a qualified technical lead to work with them. The results are much better.