Fighting Forks

This is the ignite presentation I gave for the Mil-OSS WG2 conference today. It’s a tremendous group of sandal-shod revolutionaries who want to bring open source and the US Department of Defense together. You can sign up for the mailing list here. If you use your imagination and insert a lot of stumbling, fumbling, and false starts to this, you’ll have a pretty good idea of how it went. You can find the full presentation here. [Update: Josh posted a video of my presentation, so you don’t have to imagine it.]

Licenses keep software open.

Open source software depends on its licenses. They are the architecture that keep the communities together. To steal a line from Michael Tiemann: they’re the one thing that stays the same so that everything else can be different. Licenses work very well in the private sector, because everyone is playing by the same rules. They don’t work so well in the public sector.

Our process keeps software closed.

The licenses are fine, but because the simple bargain of the licenses is buried under multiple layers of contracting, bureaucracy and secrecy, they don’t work as well as we’d like. You may have a great project you want to release. You might have an amazing patch to an existing project. You may want to use free software on your program. Whatever the case, you often have a long journey in front of you. It’s nobody’s fault, it’s just how the world works right now. The result: software that should be free disappears into government programs, never to be seen again. So how does this happen?

Tivo-ization.

I know this will come as a shock, but there are programs out there that use free code and don’t abide by the rules. Or maybe the abide by the rules, but have gamed the licenses to their advantage. That doesn’t make them evil, but it does make our lives more difficult. It’s a real problem — the Tivo clauses in GPLv3 specifically address this. It’s common for a program to take free code and lock it up in a black box. Whether it’s on a plane, or in a tank, or in a financial ERP system, we’ll never see that code again.

Secret open source.

Integrators and government programs are, at their core, about risk management. The last thing they want to deal with is something complicated or unusual. Open source is, for them, complicated and unusual. There’s a strong incentive for the lowly engineer who happened to use that Python library or that Linux kernel to hide it. Dan Risacher (godfather of the DOD open source memo) has a great story about the developer who deleted all the copyrights in his source, rather than be subjected to his company’s lawyers.

Tweakers.

This is a behavior that’s not specific to government. Our lowly contractor  improves a piece of software, but considers his contribution too insignificant to contribute upstream. SHAME ON YOU, lowly contractor. For all you know, a hundred other engineers want to fix that same problem, but can’t find the time. You can solve their problem, and you’re choosing to keep it all to yourself. Selfish!

Government is government.

Here’s a structural problem: when the government gives code to the government, like when agencies share code, the distribution clause of the GPL isn’t triggered. This is great for contracting officers, this is terrible for the community. The government can tweak code and it’s not obligated to contribute that code back upstream. This means redundant effort, wasted time, and runs against that architecture, the rules that make our community work.

Government Forges.

We’re going to talk a lot about forge.mil at this conference. I can feel it. Love it or hate it, forge.mil, forge.gov, and all the other government code repositories are here to stay. They’re useful for specific tasks, like encouraging sharing in classified environments. But by their nature, they encourage code to stay in one place. We have to make extraordinary efforts to get code out of the forges and into the public repositories. You need the will and the means, otherwise that code is lost forever.

Security.

Which brings me to security. No matter how well-constructed your license is, it’s trumped by national security. Here, I’m talking about classified use of open source code, but don’t forget ITAR restrictions, which can put your contracting officers in the awkward position of having to fulfill the terms of the GPL and simultaneously not violate the State Department’s export controls.

What can we do?

So we’re beset on all sides. At every stage of the process, from IRADs to distribution, there are barriers to the productive sharing of open source code. The situation has felt hopeless for a long time. I’m here to tell you: it’s not hopeless. We have the power to change how this system works. And we don’t need Congress, we don’t need a memo from the DOD CIO. We can do this all by ourselves.

What do we want from the process?

The point here is not to hack the system. The point is to create a useful community of developers in the DOD. Overcome the regulations, the laws, and the stovepipes. Useful communities, Etienne Wenger tells us, have certain characteristics. Fortunately, these characteristics align nicely with the problems I’ve just described.

Design for Evolution.

We can include language in contracts that ensures the open source software is contributed upstream. It really is that easy. If more PMOs required upstream contribution as part of the contracting process, they could reduce program risk, mitigate vendor lock-in, and make it significantly easier to abide by the spirit of the open source licenses.

Invite different levels of participation.

Dave Wheeler and Dan Risacher are our founding fathers. They’ve been through the law, the FARs, the DFAR, They know this stuff better than anyone. We all need to be as good as they are. We need to make it simple for people to contribute. So, we need to make all these issues easily understood. That’s why I’ve created this flowchart. It’s not the final word, and it hasn’t been anywhere near a lawyer, but this flowchart walks you through all the issues you’ll encounter when you’re trying to release software from inside a government program. Patches welcome.

Develop public and private spaces.

Let’s agree here: forges are for secret squirrel stuff. Everything else should be public. There’s a dangerous trend I’ve noticed — that forges are being treated as de facto “approved product lists.” This is terrible. Think of Red Hat’s Fedora model: forges should be where we experiment, where we play, where we tinker. From the forges comes software that we can use on programs. Keeping the forges away from the APLs frees up the forges, gives them less scrutiny, makes programs less protective of the code that they hold.

Open a dialogue.

We all need to be talking about this stuff. The PMs and the COs and the PEOs and the oversight committees won’t come to open source by themselves. They need to be made aware of all the advantages, and all the barriers, before we see structural change.

Focus on value.

As a community, we spend a lot of time talking about what should happen, what structural changes need to be put in place, and so on. I say we stop now. Clay Johnson, when he was kicking off the CrisisCamp for Haiti, said: “Democracy is the enemy of useful work.” What he meant was that consensus through talking and bargaining is a waste of the community’s time. Just get out there and release your code. If we demonstrate the value of our community, and show through useful work that we can change how things work in government, the change will follow behind us. We can’t wait for someone to fix this for us. We have to do it ourselves.

Combine familiarity with excitement.

For a developer, nothing is more important than their tools. There’s a tendency in our industry to solve every problem with a process, and every process needs a tool. Too often, we content ourselves with tools that someone else wrote. They’re outdated or insufficient. Don’t stand for that. Go build your own tools, bring in the best practices from the public open source community and use them. The forges need to serve the developers, not the other way around. Familiar tools will broaden our community, and make us much better developers.

Create a rythym.

We need to stay vocal. We need to be a thorn in our contracting officer’s side. We need to be the problem children. We also need to hold up our achievements. Too many of us toil in the dark. Start a blog, start a meetup, talk about the great things we’re doing. Help each other out. We need to create a cadence to this movement, and that cadence is what will make us larger and stronger.

Do these three things.

So this was a lot. I think I can distill all of this into three tasks:

• Understand the contribution process. Review the flowchart, talk with your lawyers. Make sure people know they can come to you with questions. We have your back.
• Shout success from the highest rooftop. We’re doing something revolutionary, and we need to be vocal. Congratulate each other publicly. Tell your PM you saved him a million dollars. Tell your CO that releasing the code brought in five new features.
• Find one thing you can set free. If everyone in this room found one piece of government code to set free, to submit upstream, we’d not only have more code to work with, we’d have one hundred open source contribution experts working in the DOD.

Thanks.