Since the first edition of this book came out in 2005, I've worked with various U.S. government agencies (federal, state, and municipal) to help them develop and participate in 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 have my sympathy — I 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, after all.
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 another exposed surface 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, and this need can sometimes be in tension with overall project health. The need for good publicity is, in a way, 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, government workers want to make sure that in the few moments when people are paying attention they see something good. This is understandable, but it can cause certain actions to be delayed — or, in some cases, done 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 or even 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 idiosyncrasies mentioned above. Much of that advice is also applicable to non-governmental organizations, and is already present elsewhere in this chapter, so below I'll simply list the sections that I think are most important for a government agency:
In addition to the above sections in this book, there are many excellent online resources about open source in government. I won't even try to include a complete list, as there is too much and it changes too quickly. Here are a few sites that are likely to remain good starting points for some time to come, especially for government agencies in the United States and in countries with procurement and civil service systems similar to those of the U.S.
https://18f.gsa.gov/ is a digital services agency within the United States federal government, created in 2014 to bring modern software development practices to government work. 18F serves as a technology consultancy to other agencies, and builds its deliverables out in the open as open source software. Along the way, 18F has generated useful guidelines and observations that anyone trying to run an open source software project within government can benefit from.
http://www.dwheeler.com/, the home site of Dr. David A. Wheeler, is a fantastic trove that includes, among many other open-source-related things, tons of information about how to use U.S. government procurement regulations to support open source development.
http://ben.balter.com/2015/11/23/why-open-source/ is a terrific post to mine for arguments, if you are advocating for open source development within a government agency. Many of Ben Balter's other writings are worth looking at too.
Finally, there is one issue in particular that I have encountered over and over again in government-initiated open source projects. It is so common, and so potentially damaging to a project, that I have given it its own subsection below.
In the section called “Be Open From Day One”, I explained why it's best for an open source project to be run in the open from the very beginning. That advice, particularly the section called “Waiting Just Creates an Exposure Event”, is especially applicable to 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 hover over everything by the time they're ready to open up hitherto closed code. How can they ever know they've got it all cleaned up? One can never be totally sure some hawk-eyed hacker out there won't spot something embarrassing after the publication. This worry is an energy drain: it causes the team 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 for starting out closed, at least in theory, and they have even more to lose.