Get the highlights in your inbox every week.
Consumer Financial Protection Bureau on open source and "growing the pie" | Opensource.com
Consumer Financial Protection Bureau on open source and "growing the pie"
The Consumer Financial Protection Bureau (CFPB) recently announced one of the most progressive open source policies in the US government. They reiterated the current OMB and DOD guidance by making open source commercial software, but they also went one step further: code they write is open by default. I am totally impressed.
CFPB CIO Chris Willey and his acting deputy Matthew Burton (of "Spook Developer Speaks...!" fame) did a wonderfully thorough interview with Alex Howard a couple days ago, in which Alex teased out some interesting undercurrents to CFPB's policy that deserve special attention. First, Burton:
By having developers and designers in-house, we can constantly be addressing things as they come up. In some cases, before the businesses even know it's a problem. By doing that, we're constantly staying ahead of the curve instead of always reacting to problems that we're facing.
This is an important aspect to the "in-sourcing" debate, and I'm afraid that it gets lost. Often, we frame the issue as a simple cost-cutting measure, but the effects of outsourcing go much deeper. The acquisition overhead that outsourcing requires creates friction and expense. Often, there is so much friction that it's easier and cheaper to do nothing. This discourages innovation and new behavior.
On the other hand, if the agency has the resources already available--developers, designers, etc--it becomes easier to experiment. In other words, innovation doesn't come from contract vehicles. If we want innovation, we need an agency staff that's capable of innovating.
Burton again, on what code they've released:
Obviously, [transit subsidy paperwork] should just be a web form that you type into, that will auto fill any detail it knows about you. You press submit and it goes into the database, which goes directly to the DOT [Department of Transportation]. So that's what we made. We demoed that for DOT and they really like it. USAID is also into it. It's encouraging to see that something really simple could prove really useful for other agencies.
Two points to highlight here: this is a culture of sharing. You share your work because sharing makes your work better. That's an attitude and a precondition to getting the most from open source. There are all kinds of questions to answer about procurement, ethics, and regulation, but having an "open by default" attitude is what ultimately makes you successful.
Second, it would be far more difficult to work together with these agencies if the software was built under contract. You'd have IP issues, and the contractor who wrote the software would be unlikely to entertain this sharing nonsense unless they could make money on it. Because the software was written by the government, it's a lot easier to share. That's not a good or bad thing, just an interesting side effect of having competent developers and designers on government staff.
We can't say, "We're not going to use a large share of the software that's available to us." That's just not an option. We have to say, "Yes, we will consider this as a commercial good, just like any other piece of proprietary software."
Willey says that their lack of resources is what compels them to use open source. That passage reminds me of these choice words from former Secretary of Defense Robert Gates:
If the DoD can’t figure out a way to defend the United States on a budget of more than half a trillion dollars a year, then our problems are much bigger than anything that can be cured by buying a few more ships and planes.
That makes me think the demand for more a broader pool of effective solutions is more acute than Willey allows.
Back to Burton:
We actually want to create a community of peer reviewers of code within the federal government. As we talk to agencies, we want people to actually use the stuff we build. We want them to contribute to it. We actually want them to be a community. As each agency contributes things, the other agencies can actually review that code and help each other from that perspective as well. It's actually fairly hard.
As we build more projects, it's going to put a little bit of a strain on our IT security team, doing an extra level of scrutiny to make sure that the code going out is safe. But the only way to get there is to grow that pie. And I think by talking with other agencies, we'll be able to do that.
This. A thousand times, this. "Growing the pie." I like that. The commercial world already uses open source to address complex technical problems (viz. Google, Facebook, Twitter, etc.), and it's the best way to address similar problems in government. Grow the pie.