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 — helping 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:
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.