فصل 9. Governments and Open Source
قبلی		بعدی

فصل 9. 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 فصل 2, Getting Started, I explained why it's best for an open source project to be run in the open from the very beginning. That advice, particularly بخشی بنام “Waiting Just Creates an Exposure Event” , 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.

قبلی		بعدی
Forks	خانه	Review Your RFI, RFP and Contract Language