Pity Francis M. Wilhoit.

You’ve got to feel for Francis M. Wilhoit. Born in 1920, the Harvard-trained political scientist spent his entire career in academia, working as a professor at Iowa’s Drake University. He was published on subjects such as nationalism, equality in freedom, and the impact of populism on Black residents of Georgia. The topic that really motivated him was his opposition to racism. His PhD thesis was about the politics of Massive Resistance, which was published as a book in 1973. While he was no Mearsheimer, Walt, Huntington or Waltz, his career was one to be proud of. He died in 2010.

Despite all of this, what Wilhoit is most remembered for is this one, brief quote:

Conservatism consists of exactly one proposition, to wit:

There must be in-groups whom the law protects but does not bind, alongside out-groups whom the law binds but does not protect.

It was an astute observation, though a sensible observation for somebody who had spent so long studying populism and racism in U.S. politics.

Unfortunately for Francis M. Wilhoit, this remark was in fact written by one Frank Wilhoit—no relation—on a comment posted to Crooked Timber in 2018, eight years after Francis M. Wilhoit’s death. The name is an absolute coincidence.

Frank Wilhoit is a 63-year-old classical music composer who lives in Ohio. In an interview with Slate this past June, he expressed horror at his quote being often attributed to Francis M. Wilhoit, not because he feels he’s owed some credit, but because he regards it as unfair to the deceased political scientist. He told his interviewer:

I had absolutely no right to create that kind of confusion, to pose that kind of insoluble problem for the custodians of his legacy. They will be playing whack-a-mole with that misattribution for all future time.

It’s clear in the interview that Frank Wilhoit is a thoughtful, erudite guy. But, again, he is not a political scientist, so it remains impressive that he managed to write a comment on a blog that has, in reputation, accidentally eclipsed the reputation of Francis M. Wilhoit. It’s like some baseball fan named Tony Peña being randomly selected from among the attendees at Fenway Park during the seventh-inning stretch, to come onto the field to try to hit a few balls pitched by Roger Clemens…and hitting a 510-foot homer. For decades after, people would understandably assume that it was the “real” Tony Peña who did it.

Perhaps it’s for the best that Francis M. Wilhoit didn’t live long enough to see a homonymous composer receive vastly more recognition for a blog comment than he did for his life’s work.

Car buyback offers are bad CX.

A few years ago, my wife and bought a new car: a Chevy Bolt EV. About a year later, the dealership began a drumbeat of emails, phone calls, letters, and postcards, each communication proposing that we sell our car back to them for a different dollar value each time. The acute shortage of both new and used cars led to inflated values, and the dealership presumably wanted to make the most of this. But these proposals mostly annoyed us, because they were offering to make our lives worse.

We hadn’t bought a car because it seemed fun or interesting, but, like most people, we did so because we needed a car. When the dealership proposed that they buy back our car, they were proposing to create a problem for us: the problem of not having a car. Given the very shortage of new and used cars, we had no interest in trading our car for money. After all, it was just a year prior that we’d traded money for our car! We need a car. Not having a car is not an attractive offer.

I actually answered the phone for one of these promotional calls, and was able to tell the dealer why their offer held no allure. I explained that we would entertain an offer to exchange our car for a newer EV. Instead of telling us that they’d pay us $X for our 2019 Bolt, we’d rather they propose that we trade our 2019 Bolt for an e.g. 2023 Bolt for a cost of $Y. This did not compute, apparently, because over a year later, we continue to receive a buyback offer every couple of months, none proposing anything beyond us no longer having a car.

I guess this works, or else they wouldn’t do it, but it seems like it would work a lot better if their proposal wasn’t to create a problem for people, but instead to at least propose a problem and a solution, all in one go.

Apple Card account verification considered harmful.

My wife was startled awake from her nap by her iPhone’s ring. She answered, groggily. The caller informed her that they were calling from Apple, and needed to verify her account. This made a sort of sense, because just the day prior, she’d communicated with customer support about a problem with our new, Apple-branded credit card. The caller said they’d be sending her a text message, and could she please read the verification number? The text message arrived immediately, and my wife dutifully read off the six-digit number. The caller thanked her and hung up.

As she finished waking up, she realized this seemed strange, on a few levels.

It’s not just strange: it’s a well known scam.

I’m going to give away the ending here. It wasn’t a scam. This was a legitimate call, legitimately representing Apple.

Here’s how this scam works. The criminal selects a target, from a list of known customers thanks to a prior data breach of First Bank of New York (to invent an example). He tees up First Bank of New York’s “reset your password” functionality, which is designed to help out customers who have gotten locked out of their accounts. It will send a text message to their phone number of record, which they can type into the website to verify their identity, and then select a new password. He then calls the target, claiming to be with First Bank of New York, but could they please verify their identity? And he clicks that “Submit” button on First Bank of New York’s “reset your password page,” triggering a text message to his target. The target dutifully reads off the number, the criminal types it in, and, boom, he has access to the target’s bank account.

This, obviously, was what happened here. I set to work immediately, examining her call log and the text message, to figure out who was stealing what from us, to try to act before they could.

GS authentication code: 524886. Contact your GS team if code was not requested. Txt STOP to end or txt HELP
The text message from Apple, along with me trying and failing to tease more information out of the service.

Within a couple of minutes, I realized that the one and only thing that could be relied on here was the text message. The scam would only work with a text message actually triggered by a real service. Apple doesn’t confirm identities with text messages, but instead with an OS-level service. So it couldn’t be Apple.

I had two clues to go on: the short code (87175) and “GS.” Friends immediately helped me brainstorm what “GS” could be, and one suggestion (Goldman Sachs) seemed plausible, since LexisNexis’ identity verification service uses that short code, and that was a sensible vendor relationship.

The Apple Card is with Goldman Sachs. Somebody was stealing our credit card! I immediately locked our cards, which is a trivial setting on iOS, and my wife called the Apple Card’s support number to report the fraud.

That was when the employee at the support number—an apparent Goldman Sachs employee—provided some surprising information: the call had been legitimate. Goldman Sachs, in Apple’s name, had used a classic identity-theft ruse.

My wife asked what the purpose of the phone call was and she was told that it was to verify her identity. …What? They’d done that just a month prior, when we opened the account. And their text message went to the very phone number that they were calling! The text message added nothing! The message itself, from “GS,” while the phone call claims to be from Apple, is further confusing. The call did absolutely nothing to verify my wife’s identity, nor could it possibly have done so, as designed.

Screenshot of an Apple ID verification code.
This is what Apple’s legitimate verification code service looks like.

Apple and Goldman Sachs are teaching customers that it’s not just OK, but actually necessary to read verification codes out to strangers who call on the phone.

I’m appalled. Obviously, Apple knows better than to employ a pattern common to fraud (I’m aware of no other aspect in their business where they’d allow something like this), but Goldman Sachs should know better, too. I’ve had an American Express for many years, and every interaction I’ve ever had with them including several cases of fraud, was handled flawlessly. Their security practices are top-notch. I’d assumed that was industry standard, but clearly I was wrong. I’d assumed that Apple’s involvement with the Apple Card would lead to extraordinary security practices, but clearly I was wrong about that, too.

I’d intended to switch from American Express to the Apple Card over the next few months, but now that doesn’t seem like a good idea.

Procurement smells.

Major government software procurements fail at a high rate. There are a lot of methods of reducing the odds of failure, but how do you know if that’s necessary?

Developers talk about “code smells”—small things that are off in ways that indicate that there may be larger problems. So, too, are there procurement smells—the little tells in requests for proposals and associated materials that vendors use to know if this is a project they want to have anything to do with. We can use similar procurement smells to determine if a project has any real chance of success, or if it will join the ranks of the supermajority of major procurement that don’t pan out.

It works like this: Review the list of statements below, and tally one point for each statement that describes the project in question. Cumulatively tally similar statements, so that e.g. a 1,000 page RFP would be awarded a point for being 100 pages, a point for being 500 pages, and a point for being 1,000 pages.

  • The RFP is longer than 50 pages
  • The RFP is longer than 100 pages
  • The RFP is longer than 500 pages
  • The RFP includes 10 requirements
  • The RFP includes 50 requirements
  • The RFP includes 100 requirements
  • The contract is for both technical services and non-technical services (e.g., both building software and running a help desk)
  • The contract is for customized COTS
  • The contract is for more than $10 million
  • The contract is for more than $50 million
  • The contract is for more than $100 million
  • The contracting officer insists on “one throat to choke”
  • The agency has no intent or capacity to inspect the vendor’s code
  • The RFP says nothing about user research
  • The contract is fixed price
  • Work is to be delivered to government only at the conclusion of the performance period
  • The period of performance exceeds three years
  • The vendor will own the resulting software

OK, now score your project!

0 points: This could work
1 point: This is not impossible
2 points: You’re going to have a bad time
3 points: Get out while the gettin’s good
4+ points: Abandon hope, all ye who enter here

(To learn how to avoid these problems from happening in the first place, see 18F’s De-Risking Guide, particularly “Budgeting and overseeing tech projects.”)

Have any additions to propose? Comment here, email me, or reach me on Twitter

The disconnect between software development and government contracting.

There’s a big disconnect between modern software development practices and government contracting. It can seem intractable, but there is a solution.

It’s the job of contracting officers to get government the best value for their money. That means being sure that they’ll get precisely what they need, within budget and on time. Normally, the best way to do this for a “firm, fixed price”: buying X gizmos that meet Y spec for $Z.

Firm fixed price (FFP) is by far the preferred method of procuring stuff. And for good cause! Contracting officers are taught that nearly any other contract type (i.e., labor-hour, cost reimbursement, or time and materials) is more risky. And that’s generally true.

That’s what has led us, for decades, down this path of wildly over-specified software RFPs. FFP for complex software means you need to have hundreds of pages of specs, because you’ve got to specify exactly what you’re getting for your money. That’s seen as safe.

In the meantime, software developers gave up that kind of software development and moved to Agile. We know that if you define all that stuff up front, you’re sunk. You’ll build something bad that the users hate, but that sure does meet the spec.

This has left a fundamental disconnect between contracting practices (specifying everything is safest) and software development practices (specifying everything is dangerous).

The solution to this is the obvious one: contracting officers need to stop using FFP for software development. There is literally nothing you can FFP for Agile software development. (See my article about doomed efforts to FFP story points.)

The way I’ve sold this to contracting officers is with this point: When buying custom software, you’re not buying a product. You’re buying a service, the service of developers building software, with features as prioritized by a government product owner.

To many contracting officers, this is nonsense. But to the right contracting officers, they get it. They see how Agile + a time & materials contract allows for extremely close oversight, tight control, and severability for non-performance. It’s safer than FFP.

There’s no way around the disconnect between contracting officers wanting FFP contracts and how software is actually created in the 21st century. The solution is to tackle the problem head on, to educate contracting officers, and let the solicitation & contract reflect the work.

To learn more about this, I recommend “Use time and material contract types for custom Agile software development services” in 18F’s “Federal Field Guide.”

Never contract for story points.

When contracting for Agile software development services, sometimes contracting officers make “story points” the thing that they’re buying. This is an enormous mistake, on a couple of levels, and nobody should ever do it.

Let’s talk about why.

First, let’s define “story points.” Agile development teams need to figure out what they’re going to work on at the start of every ~two-week sprint. Working with the product owner, they need to identify a bunch of user stories that will take as close as possible to two weeks.

One way to figure this out is for the team to figure out how many “story points” to assign to each story — basically, how much work it will be to get it done. That number might be labor hours, or it might represent how complex or uncertain the work is. There are all kinds of ways to come up with story points. Story points are a rough number, sometimes picking from a number in the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) to make that clear.

The team might have learned that they have the capacity for e.g. 300 story points in a sprint, so they’ll pull in a total of about 300 story points of work. The team decides these numbers. They are only for the purpose of estimating how much they can do in a single sprint.

Contracting officers hate time and materials contracts. They want to contract for a firm, fixed price (FFP). When procuring Agile development services, they desperately look for something, anything, to FFP. (Hint: There is nothing.) So they sometimes settle on story points as a thing that they’ll buy for a fixed price per point.

The first problem with contracting for story points is that story points are imaginary. They are a tool used by the development team for the development team. They are sometimes externally indefensible, which is fine, as long as they work for the team!

The second problem with contracting for story points is that they are, basically, a fictional currency with a value invented by the vendor. You might as well be buying 1,200 flibberdigibbets, or 1.6 million dinglehoppers. The value means nothing, can change at any time, and cannot possibly be fixed within a contract. (If you’re thinking “you could fix them at one labor hour per story point,” then, congratulations, you have invented labor hour contracts, which is precisely what contracting officers are trying to avoid by using FFP contracts.)

In short, if a contracting officer knows anything about about a vendor’s story points, something has gone terrifically wrong.

For more about the proper methods of procuring and overseeing Agile development services, see “Oversee Agile projects by measuring end user outcomes instead of requiring project teams to perform tasks by specific dates,” in 18F’s Federal Field Guide.

Reduce bids by reducing uncertainty.

When government agencies procure custom software, the price tag is often driven up because the agencies are unwilling or unable to reduce the complexity prior to beginning the acquisition process. The complexity and associated uncertainty is obvious to vendors, so when asked to provide a firm fixed price bid, they’re going to price it for the worst-case scenario, to avoid losing their shirt.

If agencies would allocate the resources to simplify and de-risk the work prior to publishing a solicitation, they’d receive substantially lower quotes from vendors, who would no longer be required to price in uncertainty.

Let’s use a metaphor here.

Imagine that I find that my finished basement has a wall that is wet and has a black substance growing on it. So I ask a half-dozen contractors for fixed-price bids to fix the problem. Those contractors have to assume a worst-case scenario: the basement wall is collapsing, and has cracked enough to admit water, which has resulted in black mold (Stachybotrys chartarum). That’s going to require demolishing the interior wall (subcontracting for mold remediation), digging out many cubic meters of earth, jacking up the house, tearing down the old wall, pouring a new wall, re-framing the interior wall, putting on new drywall, and painting. That’s going to cost tens of thousands of dollars.

But imagine that, instead, I do a little homework first. I take a sample of the black substance and pay a lab $50 to test it, and they tell me it’s just mildew. Then I tear off the wet drywall and find there’s a white PVC pipe that has a slow drip coming from a connector. Now I know that I really need two things: a plumber to cut out the connector and put in a new one (that’s an hour’s work), and a contractor to replace the ruined sheet of drywall and repaint (that’s maybe two hours of work). Now I can ask a plumber and a contractor for bids, and those bids are going to be way cheaper, since I’ve eliminated nearly all of the uncertainty associated with the work. And I know enough about the problem to have an intelligent discussion with a contractor about their proposal. Instead of $30,000, the bids will total maybe $400.

Agencies generally lack the knowledge about how to do that homework. They don’t employ people who understand software development; or, if they do, those people are not consulted prior to starting a procurement. The contracting officers don’t know about software development, and the software developers don’t know about contracting. Those two experts sure wouldn’t be expected to work together, or even know each other. So agencies pay wall-rebuilding rates for pipe-repair work.

Government agencies at all levels could better control spending, improve their budgeting processes, and take charge of their technology-intermediated service delivery, if they would simply allocate the resources to understand what they need to procure.

Government should procure custom software as open source.

Government software becomes vastly better when it’s procured as open source.

Normally, government buys closed-source custom software. Government never looks at the source code. The public can’t inspect it. Is it any good? No, it is not. There is no incentive to make it good. In fact, there’s a perverse incentive: hard to maintain means they keep the contract.

It’s not literally impossible to have bad code and good software, but let us agree that these things generally do not go hand in hand. Everything works a lot better if the vendors are producing great code.

Declaring right up in the RFP that all work will be public domain, developed in an open code repository, has a lot of great effects. The first is that vendors that write garbage code will self-select out of the running. They just won’t bid. You’re left with competent teams.

The second benefit is that those vendors that do bid will put their best people on that work. The vendors will want their work to look good. Anybody can look at their output, now and forever, including potential clients and potential hires. That’s unusual!

The third benefit is that the best developers will want to work on these projects at these vendors. A rare opportunity for their work to be seen by the public! By future employers! By their peers! Normally they toil in obscurity, but not on an open source project.

The fourth benefit is that it will be vastly easier to switch vendors (if need be), or hire new vendors to build onto this code base. Because it’s all public! They’ll know exactly what they’re getting into. That’s important because uncertainty is reflected in higher bids.

When everybody is working in the open, everybody’s interests are aligned: government, vendors, the vendor teams, and the public. When procuring closed source software, nobody’s interests are aligned. Government needs to stop doing that.

Vote ”yes“ on VA’s redistricting constitutional amendment.

Gerrymandering persists because it’s the rational choice for elected officials.

The way electoral districts are drawn in most of the U.S. is that state legislators decide what they want their districts to look like. The majority party that controls the legislature draws their own districts to allow them to cruise to reelection, using fancy redistricting software with household-level party membership data. And then they draw the minority party’s districts to make their lives difficult, such as by pitting incumbents against each other, lumping together unrelated communities, and making sprawling districts that are difficult to travel. This might sound complex, but the redistricting software makes it easy.

In short, legislators draw their own districts, ensuring their reelection. And why wouldn’t they, given the choice? It’d be completely irrational to do otherwise.

An illustration of how district lines can be drawn to allow a 60% "blue" / 40% "red" area to be divided into five districts allowing total control by either "red" or "blue."

Legislators generally get to do this once each decade, right after the decennial census determines how many people live where. The census is in 2000, 2010, 2020, etc., so redistricting is in 2001, 2011, 2021, etc.

Democrats and Republicans both gerrymander. It’s not an affliction of partisanship, it’s an affliction of power. Every time, the majority party defends their gerrymandering as mere redistricting, and the minority party decries the evils of gerrymandering and promises they’ll get rid of it when they’re in charge. This has gone back and forth for many decades.

Gerrymandering has lots of terrible effects. Especially the very premise: that legislators choose their constituents, instead of vice versa. There’s the effect on voters who are of the opposite party as their representatives, knowing that their votes will have no effect. Perhaps most important, there’s the resulting extremism. When the general election isn’t competitive, then the competition happens in the primaries. This results in the nomination of candidates who have no incentive to appeal to the opposing party, who get the nomination on the basis of promising to give no quarter to their opponents. This creates a spiral of extremism, and eliminates the possibility of bipartisan cooperation within the legislature.

In much of the U.S., there’s nothing that you and I can do about gerrymandering, because that requires a constitutional amendment…which legislatures must approve of. (Except in Delaware — they don’t bother with voter approval.) The majority party is quite happy with how redistricting is working for them, so they don’t pass those constitutional amendments. There’s nothing the public can do about it. (You might be thinking “well, people could vote them out of office.” No, they couldn’t. That’s the underlying problem here.)

So we’re stuck with gerrymandered districts.

* * *

In Virginia, right now, we have a chance to fix this, thanks to an extraordinary coincidence of timing.

Advocates for redistricting reform got to work a decade ago to get a constitutional amendment in place by 2021. With Republicans firmly in control of the General Assembly, it was easy to persuade Democrats in the legislature to get behind the cause. In fact, Democrats were so eager to support it that there was real danger that the movement would be perceived as a partisan one, so organizers had to go to considerable pains to avoid that.

In the 2019 session, the Virginia Senate was on the knife’s edge of control between Democrats and Republicans. Demographic changes in Virginia over the past decade had reached the point where Democrats had made big gains a few months prior, and Republicans were deeply concerned that they could find themselves a minority party by 2021. So the General Assembly was able to pass the legislation to amend the constitution to reform the redistricting process, by an 85-13 margin. Democrats supported it overwhelmingly. Sure, they watered it down, moving from nonpartisan redistricting to bipartisan redistricting, but it passed. But passing it once wasn’t enough — by law, they needed to pass the same amendment again the next year, after an intervening General Assembly election.

Before that could happen, though, something remarkable happened. Last November, Democrats flipped the House and the Senate, taking control of both chambers. Those new legislators were seated this year. And then the constitutional amendment came up for its second vote. By something had happened in the interim: Democrats were no longer so enthusiastic.

The same Democrats who cheerfully voted for the bill a year prior now had “concerns.” They wanted to “tweak” the legislation and perhaps delay when it would take effect, proposing substitute legislation.

But here’s the crucial fact about that substitute legislation: those changes would have reset the clock. That is, it wouldn’t have been the second time that the legislature had voted on this amendment, but the first time they had voted on a new amendment, requiring a pause of two years (so there could be an intervening legislative election) before the legislature could have the second vote. If it passed in 2023, and then voters backed it that November, that amendment would happen years too late for the 2021 redistricting, and have no effect at all until 2031.

Whatever the legitimacy of these newfound concerns, these Democratic legislators well knew that there were only two options: pass the amendment as it was, or vote against the amendment so they could gerrymander next year. There was no third option.

When forced to vote on the very bill they’d passed the prior year, what was the outcome? Well, every House Republican voted for the amendment, and nearly every House Democrat voted against it. Just nine House Democrats joined with Republicans in supporting it. (The Senate, on other hand, passed it 38-2, with two Democrats dissenting.)

Here are the 23 legislators who voted for the bill in 2019, and then voted against it this year:

  • Hala Ayala (D-51)
  • Betsy Carr (D-69)
  • Jennifer Carroll Foy (D-2)
  • Lee J. Carter (D-50)
  • Karrie Delaney (D-67)
  • Eileen Filler-Corn (D-41)
  • Wendy W. Gooditis (D-10)
  • Elizabeth Guzman (D-31)
  • Charniele Herring (D-46)
  • Patrick Hope (D-47)
  • Chris Hurst (D-12)
  • Mark Keam (D-35)
  • Kaye Kory (D-38)
  • Paul Krizek (D-44)
  • Mark Levine (D-45)
  • Kathleen Murphy (D-34)
  • David Reid (D-32)
  • Danica A. Roem (D-13)
  • Mark Sickles (D-43)
  • Marcus Simon (D-53)
  • Rip Sullivan (D-48)
  • Kathy Tran (D-42)
  • Vivian Watts (D-39)

(Of course, thanks to the intervening election, some legislators who voted for it in 2019 were gone by 2020, and some legislators were new in 2020. That’s the purpose of requiring an election between the first and second votes.)

When these Democrats were in the minority, they were all for redistricting reform. But now that they’re in the majority, one year later, now they’re against it.

As St. Augustine prayed, “Grant me chastity and self-control…but not yet.”

* * *

Gerrymandering persists because it’s the rational choice for elected officials.

Are legislators being hypocritical in voting for a bill and then voting against it? Yes. Are they behaving rationally? Absolutely. Left to their own devices, legislators will never vote to restrict their own power, only others’ power.

In 2007, then-House Minority Leader Ward Armstrong came to Charlottesville to speak at a public event that I held on redistricting. I asked him, before an audience of fifty or so Democrats, whether he supported redistricting reform. He delivered some relatively impassioned remarks about the importance of redistricting reform, about how we’ve got to get rid of gerrymandering. Then I asked him whether he’d still support that if Democrats controlled the legislature. He didn’t even pause before saying that, no, then he’d be against any kind of reform.

Extraordinarily, Virginia managed to get redistricting reform on the ballot, through an amazing coincidence of timing and, again, hard work by a small, dedicated group who pushed this for years.

Could we do better than bipartisan redistricting? Absolutely. Is bipartisan redistricting better than partisan redistricting? Absolutely. Should we let the perfect be the enemy of the good? Absolutely not.

Let’s make bipartisan redistricting a stop on the way to nonpartisan redistricting. Let’s move past the harms of gerrymandering, the extremism that comes of packed districts, the constant back and forth of each party punishing the other after they claw their way back from redistricting oblivion.

Let’s vote to pass amendment #1, making bipartisan redistricting the law of the land.

Make sure your UI modernization plan includes an open source clause.

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.