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.
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.