Governments and Open Source
24 March 2013: If you're reading this note, then
you've encountered this chapter while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
NOTES: poss2: mil-oss, Gunnar's timeline, procurement
& the question of where expertise should reside; how to write a
contract; liability; ownership; where to host; use vs creation; be
open source from day one. Mention ORM, CfA, CivComs. What other
orgs? Open source policies, open data policies.
This chapter is mainly about government agencies producing new
open source software, and participating in existing open source
projects; I'll also look at government usage of open source software,
to the extent that it overlaps with those main topics.
Since the first edition of this book in 2005, I've worked with
various U.S. government agencies, at the federal, state, and municipal
levels, to help them release open source software. I've also been
lucky enough to observe, and in a few cases work with, some government
agencies outside the U.S. These experiences have convinced me of one
thing: government is different. If you work at a government agency
and the material in this book so far has made you shake your head and
think "Sure, but it'll never work here", you don't have to convince
me — I already know what you mean. Governments differ
from individuals and from private-sector organizations in some
fundamental ways:
Governments often aren't trying to retain technical
expertise in-house (that's what contractors are for).
Governments have labyrinthine and in certain ways
inflexible procurement and employment policies. These policies can
make it difficult for a government agency to be nimbly responsive in
an open source development community.
Government agencies tend to be unusually risk-averse.
Somewhere at the top there's an elected official who, reasonably,
sees an open source project as just one more surface area for
opponents to attack. After all, when development happens in public,
the inevitable false starts and wrong turns are also public; if
development were internal, no one else would know about it when
those things happen.
Government officials hunger for well-timed and
well-controlled publicity events. This has certain benefits, but it
can sometimes come at the expense of overall project health.
This need for publicity is the complement of being risk-averse:
elected officials and those who work for them understand that most
people aren't paying much attention most of the
time — therefore, those who work in government want
to ensure that in the few moments when people
are paying attention, they see something
good. This is understandable, but it can cause them to delay
certain actions — or, in some cases, do them too
soon — based on external publicity implications
rather than on what's best for the project technically and
socially.
There are good reasons for all of these things; they've been
true for decades if not centuries, and they're not going to change.
So if you're a government agency and you want to start a successful
open source project, certain adjustments will be necessary to
compensate for the structural idiosyncracies above. The advice that
follows is most applicable to the U.S. and countries with similar
systems of government and civil service.
Being Open Source From Day One is Especially Important for Government Projects
In in , I
explained why it's best for an open source project to be run in the
open from the very beginning. That advice, particularly , is if anything even more true for
government code.
Government projects have greater potential to be harmed by a
needless exposure event than private-sector projects have. Elected
officials and those who work for them are understandably sensitive to
negative public comments. Thus even for the most conscientious team,
a worrying cloud of uncertainty will surround everything by the time
you're ready to open up hitherto closed code. How can you ever know
you've got it all cleaned up? You do your best, but you can never be
totally sure some hawk-eyed hacker out there won't spot something
embarrassing after the release. The team worries, and worry is an
energy drain: it causes them to spend time chasing down ghosts, and at
the same time can cause them to unconsciously avoid steps that might
risk revealing real problems.
This concern doesn't only apply to government software, of
course. But in the private sector, businesses sometimes have
competitive reasons to stay behind the curtain until their first
release, even if they intend for the project to be open source in the
long run. Government projects should not have that motivation to
start out closed, at least in theory, and they have even more to
lose.
Review Your RFI, RFP and Contract Language
(poss2: make sure you own copyrights (ref ch10). There are some
good examples out there of RFI/RFP language; what about contracts?
Also, look at how RFP-EZ project is doing.)
Get the Lawyers Involved Very Early or Very Late
tbd
Dispel Myths Within Your Organization
(poss2: note that government agencies are targets of heavy sales
attention from vendors of proprietary services. Myths you'll need to
dispel: insecure; no support; OSS is cheaper; if it's open that means
anyone can change our code; if it's open that means we'll have to
spend a lot of resources interacting with outside developers; if it's
open then we'll have to release all our other stuff as open source
too; developers will devote attention to this just because we released
it; other cities will pick this up and use it right away. Note that
many of these could/should be referenced from other places, like
chapter 5.)
Foster Pools of Expertise in Multiple Places
(poss2: foster concentrations of expertise in the software
outside the contractor who is writing it. This is not because you
don't want to use them for future maintenance; it's so that you'll
have a better bargaining position and not be locked in. Ref
hackathons section, licensing section.
Decouple Publicity Events from Project Progress
poss2: tbd
Establish Contact Early with Relevant External Communities
poss2: pre-announce; ask for help not admiration; use contracts
(e.g., security audits) to establish bona fides, etc
Have a Plan to Handle Negative Reactions
poss2: anticipate reactions re licensing, code, APIs,
documentation, choice of hosting platform, etc. Don't let them catch
you by surprise.
The Open Government / Open Data Community
poss2: there's a community of people now who talk to each other,
read and write for overlapping publications, go to conferences, etc.
You don't need to do anything special to find them, but be aware that
reactions can balloon in there and then take you by surprise.