Applying Open Source Principles to Government

Open Voices, Issue 3
opensource.com

Copyright

Copyright © 2013 Red Hat, Inc. All written content licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Introduction

Governments are increasingly embracing openness through policy and practice. In recent years, that means adopting and releasing new technologies—from open data bus schedules to websites built using open source tools. Some governments are even building and cultivating open source communities of their own. With unprecedented government interest in open source, we wonder: “Why would open source be of special interest to government?”, “What is the role of government in open source communities?”, and, perhaps most important, “How is open source transforming governments and their interactions with citizens?”

At opensource.com, we look at the intersection of open source and government, with a special focus on the ways government can cultivate open source communities. We document the way that open source principles—participation, transparency, collaboration, sharing, meritocracy, community, and rapid prototyping—have enormous value beyond the technology sector. Citizen movements around open voting, the Freedom of Information Act (FOIA) request tracking, and even crowdsourced legislation, represent a growing trend of open source principles within government.

We’ve been able to build a community that highlights the best—and sometimes worst—of those principles. Inside you’ll find a sampling of stories we collected in the first two years of opensource.com. They illustrate the impact of open source on government and vice versa.

There is still a long journey left before we reach truly open government everywhere around the world. We hope you continue on that journey, and that you’ll share your story with us.

Open Government, What is it Really?

Pia Waugh, Adviser to Senator Kate Lundy (originally published November 2011)

Below are my notes from the talk I gave at OSDC (Open Source Developers Conference) 2011 on open government, where I tried to go into some of the practicalities of open government implementation and projects. I had a great response from the packed room, so thanks everyone for attending (and for encouraging me to blog).

The changing relationship between citizens and government

Most citizens have a very limited relationship to government. We tend to see government as an amorphous body that removes our garbage, provides our hospital and local school, and makes us pay taxes. Politicians tend to get a pretty bad rap, and are assumed to be simultaneously stupid and extremely strategic.

But “government” in Australia is a large and complex entity run by a democratic Parliament, this makes it a tool of the people, an entity accountable to its citizens.

The proliferation of and now mainstream usage of the Internet, brings citizens closer to governments than ever. It also makes governments more accountable and transparent (whether intentionally or not). So the government is now more a tool of the citizen, and as such we need, as citizens, to engage with governments.

As citizens we are more empowered than ever. We can research, make public comment, self-organise into clusters of interest and advocacy, cross check facts, hold people to their word, develop new ways to do things and much more. The line has blurred between governments and citizens. Indeed, we are starting to even properly accept the idea that people who work in government are, themselves, citizens.

Citizens have much to contribute to government policy, implementation and vision, and governments are just starting to understand and engage with that opportunity.

Gov 2.0 is about using the new technologies at our disposal, primarily the Internet, to co-design the next era of democracy in collaboration with citizens. It is about a more transparent, accountable, engaged, participatory and responsive government approach to serving the needs of citizens.

Open Government and Gov 2.0 are often used interchangeably, but “open government” has been used for many years, usually to relate to things like Freedom of Information (FoI) laws and transparency in legislative processes, whereas Gov 2.0 is more specifically looking at how we can use modern technologies and communications to make government more open, engaged with, relevant to and ultimately co-created with citizens.

“There’s a clear vision from the top, not only in the US and the UK, but in many other countries, that now is the time for government to reinvent itself, to take the old idea of government “for the people, by the people, and of the people” to a new level.”—Tim O’Reilly

In Australia we have a strong, highly skilled and completely awesome Gov 2.0 community. These are people who work in, for or with government to implement Gov 2.0. This community has people who are into software/web development, user experience, accessibility, open data, mobile development, public engagement and much more.

It is a community driven by the ideals of open government, and a really inspiring and exciting community to be involved in. I highly recommend to any of you interested in following or getting involved in Gov 2.0 to check out the following:

The Gov 2.0 Google Group mailing list

GovCamp’s–a great opportunity for Gov 2.0 practitioners to get together, share knowledge, and find ways to collaborate. They are starting to run all around Australia after I ran the first one in October. The next one is this weekend in Sydney (BarCampNSW).

Follow the #gov2au hashtag on Twitter, and some notable Twitter users in this space are @CraigThomler, @trib, @chieftech, @davidjeade, @gov2qld, @sherro58 & @lisa_cornish from AGIMO, @FCTweedie & @OAICgov from OAIC, and many more including me @piawaugh. I’ve got a far more complete Gov 2.0 list on Twitter that I’m continually adding to that may be useful.

There is a Gov 2.0 Ning group and OzLoop Ning. Craig Thomler also runs a good blog worth subscribing to. Craig and Kate Carruthers put together a website on Gov 2.0 and the Centre for Policy Development did a great collection of essays by people in the community on Gov 2.0 in 2009 which is available online.

What is Gov 2.0

Most elements of what we call Gov 2.0 can be boiled down to three concepts:

1. Open data

2. Citizen centric services

3. Public engagement

Open data

Open data is about taking the vast majority of government datasets and information which doesn’t have privacy or security issues, and putting it all online in the most useful way possible. In a practical sense, for data to be most useful (both to the public but equally important for other parts of governments to be able to leverage the data), it needs to have permissive copyright (such as Creative Commons BY), be machine readable, time stamped, subscribable, available in an openly documented format (open standard), have useful metadata and wherever possible have good geospatial information available.

This last point about geospatial information is vital for making data interactive and personalised to a citizen’s needs, as it helps aggregate and map information relevant to where a citizen is.

Achieving open data is a difficult process. There are three key steps to take, each with its own challenges:

1. Just get it online. This stage is where an organisation just tries to get online whatever they can. It often means the licensing is not entirely clear or permissive, the data format is whatever the organisation uses (which may or may not be useful to others), the data may be slightly out of date and it often isn’t clear who the contact for the data set is making followup hard. This stage is however, extremely important to encourage as it is where every organisation must begin and build upon. It is also important because to achieve quality open data, major changes often need to be made to systems, workflows, technologies and organisational culture. Access to imperfect data in the short term is far better than waiting for perfection.

2. High quality data. This is the stage where issues around quality publishing of data have been teased out, and an organisation can start to publish quality data. It is hopefully the point at which the systems, culture, workflows and technologies used within the organisation all facilitates open data publishing, whilst also facilitating appropriate settings for secure data (such as sensitive privacy or security information). This stage takes a lot of work to achieve, but also means a far lower cost of publishing data, which helps amongst other things, keep the cost of FoI compliance down.

3. Collaborative data. This final stage of open data is where an organisation can figure out ways to integrate and verify input from the public to data sets to improve them, to capture historical and cultural context and to keep information up to date. This is also a challenging step but where government departments and agencies can engage the public collaboratively, we will see better data sets and greater innovation.

There are examples of each of these stages, but it is important to remember that they are stages, not static. Some good examples of open data initiatives in Australia include:

data.gov.au, the Office of Spatial Data Management, the BoM climate data, the Living Atlas of Australia, Mapping our ANZACs13, the Powerhouse museum online collection database and the GovHack initiative

It is also important to consider the broad ramifications of open data. One can think of many positive case studies for open data. Examples of transparency or innovation or a strong public record. But there can be unforeseen negative consequences. For example, I heard of a case where the mapping of the ocean above Australia was made public, and within a very short period of time a particular species of fish was driven almost to extinction by fishers who used the data to plan their fishing season.

This is not a reason to not pursue open data, but rather a reminder to always consider things critically and thoughtfully.

Data visualisation

Nowadays I can’t overemphasise the importance of data visualisation. As a technical person I was quite cynical in the value of data visualisation. It seemed a waste of time when you can just read the data. But using data visualisation tools effectively can create two core benefits:

Informed public narrative. Most people are really busy. Busy with their jobs, their personal lives, their hobbies. So expecting them to take time to really understand complex issues is not only unrealistic, it is unreasonable. Presenting information visually is a great way to lower the barrier to understanding and then engaging in an informed public debate. People will understand in seconds the information from a well constructed visualisation, but to glean the same information from papers and spreadsheets takes a lot longer.

Policy development & load testing. Interactive data visualisation tools such as SpatialKey, Tableau or one of the many great FOSS (free and open source software) tools available create a new way to engage with and glean new knowledge from data. By being able to pull together many different data sets into a single space, one can then explore, test and experiment with policy ideas to determine the effectiveness of a policy to meet its goals.

Citizen centric services

Citizen centric services is about putting the user experience first to create a personalised and unique experience for citizens. It is better for citizens as it makes their experience better and more seamless, and it is better for government who can more effectively serve the needs of citizens. Citizen centric services requires good data and metadata, especially good geospatial data as location information is an extremely effective way to personalise government services, information and projects for citizens.

Constant feedback loops that engage the input and ideas from citizens are extremely important to establish effective citizen centric services, and to ensure the iterative improvements over time to keep services relevant and responsive to the changing needs of the population.

Some examples of citizen centric services include: Australia.gov.au, MyRegion, MyChild, MySchool21 and there are some good community examples including OpenAustralia, GotGasto, and Know Where You Live.

Public engagement

Effective, constructive, and collaborative public engagement greatly improves the capacity of government to build the knowledge and experience of citizens into policy and projects. Public engagement strategies work best when they are underpinned by strong community development, a clear and collaboratively developed goal, a genuine interest in the inputs of others, and a process that is as low a barrier to entry to engage in as possible.

Basically we are moving towards an era of democratic and governmental co-design.

There are some great examples of public engagement out there, including our Public Sphere consultations, the Queensland Police use of Facebook throughout the natural disasters a year ago (which showed how social media is great for timely updates, but also for managing misinformation quickly and crowdsourcing to help most effectively deploy resources in disaster management), the Census 2011 social media strategy, the growing number of public consultations on government policy and strategy such as from the Gov 2.0 Taskforce and much more. The need for public engagement has also been pushed in several recent policy agendas. The GovHack events last year were also great as they showed how effective engagement with the general public can result in highly innovative and rapidly developed new applications and knowledge when open data is made available and when usage of that data is encouraged.

FOSS and government

FOSS has provided a natural fit for a lot of open government initiatives, due to the widespread use of open standards, the ability to rapidly deploy, the large developer and support communities around mature FOSS projects such as Drupal and WordPress, the competitive and thus reliably sustainable nature of commercial support around mature FOSS projects, and, most relevantly, the cross over of values and practices between open government and FOSS.

In January 2011 AGIMO released the Australian Government Open Source Software Policy which has three principles:

Principle 1: Australian Government ICT procurement processes must actively and fairly consider all types of available software.

Principle 2: Suppliers must consider all types of available software when dealing with Australian Government agencies.

Principle 3: 3. Australian Government agencies will actively participate in open source software communities and contribute back where appropriate.

The third principle in particular represents a fundamental shift in how government sees and engages with FOSS, technology and the community. It is very exciting! It clearly demonstrates the value of collaboration so prevalent in the open government agenda.

In July 2011, after six months consultation, AGIMO also released the Australian Government Open Source Software Guide V2, a really useful document for departments and agencies to help them comply to the policy directive where they must consider open source in their procurement processes.

Both the Open Source Policy and the Guide are available along with other information.

Open government policies

The open government or Gov 2.0 agenda is nicely encapsulated in the two major policy documents, Ahead of the Game and the Gov 2.0 Taskforce Report. These two reports form the blueprint of Gov 2.0 for the Australian public service.

It is also worth looking at the Office of the Information Commissioner paper Principles of Open Public Sector Information and other resources, the Attorney General’s Principles of IP (which explicitly encourages Creative Commons), and the various useful web policies provided by AGIMO including the Gov 2.0 Primer.

Conclusion

Open government and Gov 2.0 both represent an ideal.

They represent a goal for us to be continually aiming for but they are not achieved with a single switch of policy. Achieving true open government is necessarily a constant and evolving challenge, and given I am here speaking at an Open Source Developer’s conference, we all understand the difference between an ideal, and striving for the ideal whilst operating within reality.

Government won’t get it exactly right all the time every time, but we are in an extremely exciting time for open culture, and with a government position in Australia that firmly supports openness through policy, in legislation and in implementation of projects, we need to continue to encourage and support progress.

(Originally posted at what are we doing today, brain?)

The U.S. Government Promotes Open Innovation—Is it Now Mainstream?

Mark Bohannon, Vice President of Corporate Affairs and Global Public Policy at Red Hat (originally published March 2012)

“We live in an open source world.”

For many readers of opensource.com, those words are probably a part of your daily life; in all likelihood, you take them for granted. They reflect the commonality of how many of you work, and engage publicly.

But I heard those words last month from a former member of Congress. Tom Perriello, the moderator of a panel on ‘open innovation’ held at a mainstream think tank here in Washington (the Center for American Progress), gives them a different context.

The event was a look at “Open Innovation: Tools to Solve Problems and Grow the Economy.” U.S. Chief Technology Officer Aneesh Chopra shared (on his last day in government service) the ‘half’-time’ assessment of the Administration’s work on this important area of policy work. Joined by innovative government leaders—Todd Park, Chief Technology Officer, U.S. Department of Health and Human Services; Peter Levin, Senior Advisor to the Secretary and Chief Technology Officer, U.S. Department of Veterans Affairs; and Chris Vein, Deputy U.S. Chief Technology Officer for Government Innovation, White House Office of Science and Technology Policy—Aneesh released an open innovator’s toolkit.

As Aneesh explains, rather than pursue traditional “top-down” models to spur breakthroughs in these areas of national importance, the Administration’s ‘open innovation’ policy has sought to “emphasize a ’bottom-up’ philosophy that taps into the expertise of the American people.” In his view, it has already delivered tangible results in areas like health IT, learning technologies, and smart grid—and “has surfaced new or improved policy tools deployed by our government to achieve them.” The memo catalogs “20 leading practices that an ‘open innovator’ should consider when confronting any policy challenge—at any level of government.” These are focused on innovators in government, and can be summarized as:

Moving beyond data “by request” to “computer-friendly by default”

Engaging not just as “regulator” but as “impatient convener”

Adding the ability to pay for outcomes through “prizes” not just “procurements”

Attracting “top talent” including “entrepreneurs-in-residence”

I won’t delve into the particulars here; you can check them out at on the White House OSTP blog.

Rather, the question that kept coming up for me after listening to these leaders is: How is “open innovation” tangibly different than the older models of innovation?

It’s not a simple question to answer, and I think our collective understanding is evolving—evolving as quickly as innovation is manifesting itself in so many sectors and areas (geographic, as well as technology).

When I was in the US Government working on technology issues, I recall a conversation with a mentor, then Under Secretary Mary L. Good—a former tenured professor of chemistry, Chair of the National Science Board, holder of patents, and senior executive in industry who was responsible for product development in a global marketplace—about her experience in innovation. This was more than 15 years ago, and the specific words she used have faded. But the gist of what she learned is that innovation is, at its core, a contact sport: it emerges from putting dedicated minds together, mashing it up, and seeing what emerges.

This was the old model of innovation, before the commercialization of the Internet. Open innovation appears to embody these known processes and expands them beyond anything that earlier innovators could imagine. It seems that open innovation differs in the following respects:

It is inherently tied to our networked, Internet-powered world. What used to take place in a physical lab now takes place online, in collaborative settings, in what might be called a virtual contact sport. This has a number of implications, which were important themes at the Chopra event last week.

New ideas and solutions can come from any place in the world and from any level of expertise or discipline. This was often a challenge in the old model where finding expertise that might be relevant to a particular inquiry was a laborious, time-consuming and often expensive proposition.

For some, this dynamic has been encapsulated as ‘crowd-sourcing’, but I think this only begins to describe the changed model. I think a supercharged skunk works probably captures it better.

Prospective solutions have many more eyes that review and critique the on-going work and improve the overall result, a factor that is too often understated in describing the bottom-up aspect of open innovation. Peer review that used to take weeks, even months, now happens instantaneously.

There are several other aspects that I believe are different:

The older models of innovation were heavily focused on the production of intellectual property as a primary output. This was certainly the case when I was in government. In the newer model, this may be less so, and in some environments, there is a conscious attempt to avoid locking up the results. In my view, open innovation seems to be characterized, where intellectual property is concerned, by efforts to more widely distribute the results that allows further use and innovation, whether incremental or otherwise.

The demands of users drive a more rapid time frame in which open innovation operates. VA’s CTO Peter Levin described how he is often implementing solutions within 30 minutes that previously took days or hours to find and develop. Open innovation is a reflection of the fast-paced dynamics we face.

Management of the research and development process has been turned on its head. This is a point that Red Hat CEO Jim Whitehurst has made on several occasions. As Tim O’Reilly has said, “Sustained innovation is no longer just about who has the most gifted scientists or the best equipped labs. It’s about who has the most compelling architecture of participation.”

For some, open innovation may sound vaguely familiar to the concepts laid out by Henry Chesborough, author of the book Open Innovation. Chesborough focused on the contrasts between the open and closed innovation models, described in the chart below:

Source: Table I-1, page xxvi of the Introduction—“Open Innovation:The New Imperative for creating and profiting from Technology” (Harvard Business School Press, 2003)

I find that collaborative innovation resonates as a term for this new model described by Chopra. But I understand the open theme of the Administration's initiative—open government, open innovation, open participation. As was clear from the CAP event, open innovation and collaborative innovation have unique characteristics for different sectors and technologies.

What was also clear was the importance of open source software in the open innovation model. At one level, it was almost taken for granted as the quintessential example of open innovation success. Each of the panelists referred to it in some way as they described the work they are engaged in. It also showed up as a fundamental input in the variety of areas where the forum indicated open innovation is taking off. CTO Levin indicated the goal of open innovation in his agency was the ability to reuse, to have modularity and interoperability in his agency's IT infrastructure. Others referred to it as a tool that is regularly used.

We do, indeed, live in an open source world. I'd like to hear other readers thoughts on this topic. Let me know what you think is unique about the open collaborative innovation model.

How Consumer Finance Made Open Source Both a Policy and a Mission

John Scott, Technologist Technologist in the Department of Defense and US Government (originally published April 2012)

For the first time a U.S. Federal Agency, The Consumer Financial Protection Bureau (CFPB), has come out with a policy that clearly delineates how taxpayer investments in technology should be handled. Since they say it best:

The Consumer Financial Protection Bureau was fortunate to be born in the digital era. We’ve been able to rethink many of the practices that make financial products confusing to consumers and certain regulations burdensome for businesses. We've also been able to launch the CFPB with a state-of-the-art technical infrastructure that’s more stable and more cost-effective than an equivalent system was just ten years ago.

Good internal technology policies can help, especially the policy that governs our use of software source code.

Some software lets users modify its source code, so that they can tweak the code to achieve their own goals if the software doesn't specifically do what users want. Source code that can be freely modified and redistributed is known as "open source software," and it has been instrumental to the CFPB's innovation efforts for a few reasons:

It is usually very easy to acquire, as there are no ongoing licensing fees. Just pay once, and the product is yours.

It keeps our data open. If we decide one day to move our website to another platform, we don’t have to worry about whether the current platform is going to keep us from exporting all of our data. (Only some proprietary software keeps its data open, but all open source software does so.)

It lets us use tailor-made tools without having to build those tools from scratch. This lets us do things that nobody else has ever done, and do them quickly.

Until recently, the federal government was hesitant to adopt open source software due to a perceived ambiguity around its legal status as a commercial good. In 2009, however, the Department of Defense made it clear that open source software products are on equal footing with their proprietary counterparts.

We use open source software, and we do so because it helps us fulfill our mission.

Open source software works because it enables people from around the world to share their contributions with each other. The CFPB has benefited tremendously from other people's efforts, so it’s only right that we give back to the community by sharing our work with others.

This brings us to the second part of our policy:

When we build our own software or contract with a third party to build it for us, we will share the code with the public at no charge.

Exceptions will be made when source code exposes sensitive details that would put the Bureau at risk for security breaches; but we believe that, in general, hiding source code does not make the software safer.

Read more about the policy at:

The CFPB's source code policy: Open and Shared

Source Code Policy

History of Open Source in Government

Gunnar Hellekson, Chief Technology Strategist for Red Hat's US Public Sector group (originally published May 2012)

It is difficult to imagine the Federal government moving in one well-coordinated direction on any matter, and so it has been with the adoption of open source software. Some agencies were early adopters, especially the academic and research communities. As it did in universities, open source adoption in the US government originated in research settings, where sharing and collaboration were already part of the culture of pedagogy. In this way, the government had been using and creating open source software even before it was called "open source." Other agencies and departments have been more conservative, for a variety of reasons, and are only just now bringing open source software into their operations. With this in mind, the history of open source in the US government is best understood as a series of individual stories that have collectively led to the pervasive adoption of open source we see today.

It was in 1997 that open source as an enterprise computing trend emerged, and the US government was there. While Eric Raymond was writing his seminal treatise on open source, "The Cathedral and the Bazaar," a Major in the US Air Force named Justin Seiferth published "Intranet Hallways Systems Based on Linux"46 in the Linux Gazette. This article described a simple web-based explorer for Windows file servers built on the Linux operating system. This may be the first public acknowledgment of the US Government’s use of open source software as we know it today.

For the next several years, advocates in the private sector and cautious staff in government began to engage the questions that still confront open source today: Is it ready? Is it secure? How do we use it? In 1999, Mitch Stoltz of NetAction wrote the first persuasive essay on the topic, "The Case for Government Promotion of Open Source Software." 47 Stoltz invokes many arguments that are still being used today: lower cost, increased flexibility, and better security. That same year, the President’s National Coordinator for Security, Infrastructure Protection, and Counter-Terrorism convened a multi-agency working group to produce "Open Source Code and the Security of Federal Systems." That report is the first official study of open source by the federal government.

While at the Air Command and Staff College, Major Seiferth returns to our history again, this time publishing a research report on the potential benefits of open source specifically in the DOD. Seiferth notes ironically that the US Government is at once reluctant to use open source, and a great creator of open source projects:

Within the Department of Defense, the National Laboratories and Defense Advanced Research Agency have been the most visible users and producers of open licensed systems. They’ve released such advances as the original firewall and network security toolkits. As a more recent example, within the last year the National Air and Space Agency has debuted several inexpensive supercomputers. Open licensed operating systems and applications allowed the scaling of inexpensive pentium-based machines into an integrated hardware/software system. In addition to being inexpensive, these machines are among the most powerful available.

Seiferth, like Stoltz, makes a number of familiar arguments for open source, but his greatest insight is that open source is ”Commercial Off-the-Shelf” (COTS) software. This is significant, because it means that open source would be able to use the existing policy and regulations that had already been created for software more generally, rather than being treated as a special case and thus hampering its adoption. This will later become the explicit policy of the Office of Management and Budget, as well as the Department of Defense.

The very next year brings an explosion of open source activity in government. In the private sector, IBM announced that they are investing one billion dollars in the Linux project. The Open Source Software Institute was founded to aid the adoption of open source in the Federal government.

Meanwhile, government adoption continues apace. We begin to see the procurement apparatus wrestle with open source licensing in procurements. The US Air Force Scientific Advisory Board’s “Ensuring Successful Implementation of Commercial Items in Air Force Systems” is the first procurement guidance to explicitly mention open source.

Some agencies aren’t waiting, though. The National Security Agency–to the astonishment of its peers and the open source community–releases SELinux, which provided a set of strong security controls to the Linux operating system. In doing so, the NSA was taking technology that had been useful to a very small set of customers, and was therefore very expensive, and made it freely available to the general public. Innovation quickened, the software improved, and SELinux is still used in Linux today. Most recently, SELinux was ported to the Android system, where it provides mobile phone users protections against hostile applications. This wasn’t the first time the US government has released software, but it made headlines because it was an implicit endorsement of the open source process by arguably the most security-conscious intelligence agency.

This flurry of activity continues into 2001, with MITRE releasing "Making the Business Case for Open Source Software." This document, the most comprehensive treatment of open source to that point, was published as part of the larger “Open Source Software in Military Systems” study which the US Army had commissioned from MITRE. The report concludes: “Open source will benefit the government by improving interoperability, long term access to data, and the ability to incorporate new technology.” Here, we see the US Army, who is later to become one of the largest open source users in the world, taking its first exploratory steps.

The next major milestone is in 2003, with the release of the "Stenbit Memo." On May 28, the DOD CIO John Stenbit released the first DOD-wide guidance on open source software, which implicitly permits its acquisition, development, and use. Meanwhile, the Army begins to deploy the "Blue Force Tracker," running on open source software, to over 80,000 tactical vehicles. Famously, General Nicholas Justice proclaims, “When we rolled into Baghdad, we did it using open source.” Nine months later, in July of 2004, the OMB issues a memo similar to the Stenbit Memo that covers the government as a whole. At approximately the same time, NASA releases the very popular World Wind geospatial visualization project under the newly-minted "NASA Open Source Agreement." Six months later, Red Hat, the world’s largest open source company at the time, creates a US Government division61 and the first Government Open Source Conference61 (GOSCON) is held in Portland, Oregon.

In 2006, Sue Peyton, the Air Force Assistant Secretary of Defense for Acquisition, commissioned the "Open Technology Development Roadmap," which goes beyond the simple benefits of open source, and describes how it can be put to productive use in the context of the DOD’s Net-Centric doctrine, which was in fashion at the time. This is the first effort to align the principles of open source with an overall agency strategy, demonstrating how savvy open source advocates inside the government have become.

In 2007, the US Navy commissioned Raytheon, IBM, and Red Hat to add “real-time” features to the Linux kernel, which it required for the new destroyer it was building. Significantly, the Navy ensured that the software is released into the open source community. Shortly thereafter, the US Navy CIO Robert Carey releases the Navy Open Source Memo, which explicitly classifies open source as COTS software. This is a significant change in tone from the Stenbit memo and OMB memos of 2004, which only implicitly provide this same guidance.

Open source use subsequently explodes. By September of 2008, the Microsoft-funded Open Source Census was reporting that open source use in government was higher than any other industry. The Federal Open Source Alliance’s Federal Open Source Referendum study reported that, 71% of agency executives believed they could benefit from open source and 58% said they were likely to consider open source.

The Obama Administration’s first act on taking office was to issue the Open Government Memo, which articulated a general policy of "transparency, collaboration, and participation." Subsequent agency initiatives prominently featured open source software as a means to achieve those goals. Open source policies began to pour out of governments at the federal, state and local level. NASA, in particular, made open source software and the open source development process a cornerstone of their open government plan. In the private sector, Open Source for America was founded. This coalition of industry, advocates, and individuals is meant to be a central resource for advocates of open source software in government. That August, Macon Phillips, the White House New Media Director who would later release portions of the software for whitehouse.gov, called open source “…the most concrete form of civic participation.” Clearly, open source and open government became inextricably related.

In October of 2009, the “DOD Open Source Memo” is released by David Wennergren, the DOD CIO. This memo got headlines around the world, and remains the single most influential government policy document on open source today. The memo itself is simple, and following the Navy’s declaration two years earlier, reminds procurement officials that open source software is COTS. The appendices to the memo, however, go into much more detail about the potential advantages and risks of open source software. The memo specifically encourages the DOD to take advantage of its ability to modify software to suit a mission’s need.

Later in 2009, CENDI, an organization of government managers, issues a FAQ on copyright and open source to help agency lawyers understand open source licensing and the sometimes confusing intellectual property questions that they pose. A few months later, for the first time since 2004, OMB refreshes its open source guidance with the “Technology Neutrality” memo, reminding agencies that competition in software is important, and that they are forbidden from discriminating against software based on its development method. Once this memo was published, most of the barriers to open source adoption had been diminished or eliminated in the US government.

Unburdened, open source continued its growth in 2011. Sue Peyton’s Open Technology Development Roadmap from 2006 receives a “Lessons Learned” sequel, which makes recommendations to DOD programs interested in releasing their own software. Eben Moglen, one of the most prominent open source lawyers in the country, and head of the Software Freedom Law Center71, releases “Government Computer Software Acquisition and the GNU General Public License72,” which explains the provisions of that very popular open source license in the context of government procurement regulations. Clearly, the government’s understanding of open source had grown more sophisticated since its first tentative forays a decade before. A survey conducted by Lockheed Martin at this time found that 69% of government contractors and 40% of federal agency respondents were already using open source. The survey also found that 66% of all respondents said that they would be using more open source in the next 12-18 months.

With this increased comfort, 2011 also saw the release of more open source software from the government than ever before. The White House released portions of the code for whitehouse.gov, the code for the Federal CIO’s IT Dashboard, and the data.gov platform. At the end of 2011, the Federal CIO announced a draft “Shared First” policy, which mandates re-use and sharing of IT resources amongst civilian agencies, and specifically mentions that agencies should collaborate on software development. Also, NASA releases code.nasa.gov, a landmark project to centralize all the source code released by NASA in one citizen-friendly web site.

So we see the adoption of open source in the Federal government as an evolution: the first furtive steps in the late 1990s and early 2000s, manifested in persuasive essays and studies. From there, certain organizations like NASA and the Army take leadership roles in open source adoptions. From 2003 to 2009, a series of policies institutionalize its use throughout the government. By the close of the first decade, the White House, NASA, the Office of Management and Budget, and other agencies are not just using open source, but creating and releasing open source software of their own.

Did I miss a major event? A major code release? Let me know in the comments.

[This is a writeup I did as a companion to the History of Open Source in Government Timeline75. Karl Fogel76 and I will be presenting more findings77 from the timeline at OSCON78 this year.]

Building a Civic Commons

Abhi Nemani, Director of Strategy and Communications at Code for America (originally published August 2011)

Amid the last two decades' astounding advances in consumer and enterprise technologies, governments at the city and county level—ones that are responsible for delivering public services every day—have largely been standing on the sidelines. Civic Commons is a new non-profit initiative that’s dedicated to helping government embrace the transformative potential of shared technologies and collaborative development techniques that have been pioneered and proven in the private sector.

We believe that governments can now take advantage of the same technologies that have generated such enormous efficiencies and innovative services in our lives as citizens and consumers. In a digitally interconnected world, governments don’t have to operate in isolation. They can pool their resources, their talents, and their ever-shrinking budgets to build shared technologies, save money, and innovate.

Some of 81 this 82 is already happening, but there are still technical, political, and cultural barriers in place that are inhibiting widespread collaboration. And it’s those barriers that Civic Commons is hoping to bring down.

Here’s how:

Helping governments open their code. We work directly with government entities to turn the applications they’re developing into shareable public goods.

Documenting technologies, practices, and policies. Our wiki is one of the most comprehensive sources on open data, open source software, and open government.

Building community. We are working to strengthen and connect the worldwide network of government and civic technologists.

Finally, we’re also building the technology infrastructure needed to help governments share technology: the "commons." Civic technology experts have recognized the benefits of sharing technology among governments and institutions. However, instances of successful collaboration and sharing are still few and far between, in part because there is no easy, structured way to share knowledge about this software, let alone the software itself. There is no one place to go to look for civic software that cities need, and no roadmap to share what they have. We aim to change that.

Enter the Commons Project: this project will foster the creation and growth of a community of civic technologists sharing not only information about the applications they use and their experiences with them, but also the very application code. Think of it like a community-driven civic app store. By connecting the nation’s best civic innovators, we will stimulate better IT decision making and the reuse of civic code across the country.

We’re just getting started on the project, and you can help us make it successful. We need to inventory the civic technology currently being deployed by governments across the country to seed the commons. That’s where you come in. As active members of the open source community, you have the insight into what technology is being used where. Please share your knowledge here, and you can help us build the Civic Commons.

Creating Legislation the Open Source Way

Marek Mahut, System Engineer for Red Hat Czech (originally published September 2012)

In recent weeks we've seen a number of projects in the area of collaborative legislation that operate similarly to open source software. Today, you can find French, German, and Swiss proposals in git repositories. If you're a developer familiar with these tools, it's easy for you to review the patches (bills), submit your own, and collaborate around the code (law). These are exciting projects undertaken by people in many different countries, but very few governing bodies appear to be harnessing their citizens' input.

Under a traditional 'democratic' system, bills are often drafted behind closed doors by legislative staff with the help of a few lobbyists and subject matter experts. With advances in technology, bills introduced into a legislative body are now often posted online, but changes are submitted by other legislators, or can be suggested via email, letters, or phone calls from citizens. It isn't the most efficient or transparent process.

Governments, with help from legal academia and ordinary citizens, could be pushing forward systems that could make the democratic process easier, more effective, and cheaper—as we know, democracy is not cheap! So, why not utilize technology to help us with it?

There are now a few government-sponsored projects aiming at this problem, such as the legislation portal of the Slovak Republic's Ministry of Justice, where you can comment on laws in the making. Sadly, because this portal is closed source, it cannot expand due to vendor lock-in and the lack of public access to the source code. More interesting software may come from LEOS, Legislation Editing Open Software, an open source project funded by the ISA for the European Union expected to be completed in 2015.

I think this is the question for discussion: Is legislative collaboration one of the essential parts of eGovernment?

How Federal Agencies Can Implement and Benefit from Transparency

Tom Moritz, Project Director at Sonoma Valley Heritage Coalition (originally published October 2011)

The publication, Guide to Owning Transparency: How Federal Agencies Can Implement and Benefit from Transparency, was released earlier this month and is the result of an extended collaboration. The guide was sponsored by the US Office of Personnel Management (formerly the US Civil Service Commission)—which is the "human resources" agency for the US Government.

Transparency—as in the free and open sharing of scientific information and data—is an essential democratic value irrespective of whether data originates in the private or public sectors. It includes both primary scientific data, as well as data and information about organizational practice.

Open source, specifically, has an important part to play in the open government movement. Open source software is, by definition, transparent. It is developed by a democratic community of users and shared in an egalitarian way.

Moreover, when budgetary constraints are imposing severe limits on government's ability to adapt to a dynamically changing technical environment, open source software minimizes the transaction costs associated with adaptation and use.

Some of key legal, technical, and budgetary challenges are outlined in Chapter 4, "Constraints on Transparency." In the interest of transparency (and disclosure), I authored Chapter 4 as a volunteer.

In the private sector, transparency focuses on disclosures of information and data essential to the informed evaluation of the performance of for-profit corporations and not-for-profit organizations. In the public sector, open government seeks to improve the transparency of government operations so that both the government and the public can make well-informed judgments about the relative efficiency and effectiveness of government, about the success of government programs in meeting their intended missions. Thomas Jefferson argued that such transparency would enable "every member of Congress, and every man of any mind in the Union... to comprehend..., to investigate abuses, and consequently to control them..." (Jefferson, 1802, as quoted in Rawson and Miner, 2006)

What are your thoughts on these issues and on transparency in government?

Five Essential Elements of an Open Government Unconference

Jason Hibbets, Project Manager in Corporate Marketing at Red Hat (originally published January 2012)

Joining the open source (and CityCamp) movement has been one of the best experiences of my life. I've been involved with open source for over a decade, but I never got involved in a community project in any significant way—until I found CityCamp. I haven't submitted a single line of code, but I'm able to bring my project management and community-building skills to the table. That's important because it highlights the fact that there is more to open source contributions than writing code.

I interned at Red Hat in 2000, which introduced me to the open source way. I joined the company full-time in 2003. I've come across a lot of open source projects, but nothing grabbed my attention quite like CityCamp. I got involved with the movement earlier this year and it has allowed me to blend my open source experience and community management skills with my passion for participatory government.

I jumped right into the thick of things and helped organize CityCamp Raleigh. I was able to attend CityCamp Colorado and CityCamp Honolulu. I was bummed to miss out on CityCamp Minnesota. I learned a great deal by participating in other camps and from following the ones I couldn't attend.

I really liked how the CityCamp movement took an open source approach, especially for the brand. Any city or community, worldwide, that has people who want to organize and advance their local open government movement is free to adapt the CityCamp framework and brand for their mission—as long as it's in-line with the goals of CityCamp.

I've met a lot of great people along the way and seen some amazing things happen in the course of a weekend. In the spirit of giving back, I gathered some of the documentation used for CityCamp Raleigh and shared it with other planning groups. Now I want to share some of the observations and lessons learned from all my 2011 CityCamp experiences.

Five organizing tips for a successful CityCamp

If you're thinking about planning a CityCamp, you've probably already discovered the 'start a camp' page. Based on my experience attending several events, planning one event, and mentoring other planners, there are a few best practices that can improve the outcome of a CityCamp significantly.

1. Generate ideas before the camp. Participating in an unconference like CityCamp is new to many people. Especially when you include many varied participants: citizens, municipal workers, developers, designers, elected officials, and anyone else interested in participating. You can overcome these barriers by gathering problems citizens face and generating ideas for solving them before your conference starts. This helps people make the connection between open government and how they can participate. It also gives people a reason to attend and allows the organizers to invite key stakeholders from their local government. Most groups are doing this online using technology such as User Voice, which includes a voting feature. The key here is to make sure there are ideas populated on the forum when people visit. Have your planning group generate at least 3-5 ideas before you announce it. Also, make sure users who visit can build on those ideas.

2. Pair municipal staff with ideas. Now that you've got some ideas before your camp, invite key stakeholders to participate. If you have an idea with community interest and a high number of votes, show this momentum to a department or agency that can foster the idea and make real progress. It is important to have access to data or internal knowledge that can help municipal staff identify barriers that will need to be worked out, or other plans that need to be considered. The staff often wants to help out, and is happy to engage with CityCampers because you are working together towards a common goal. As a team working towards the same goals, any 'us versus them' mentality goes away. It also helps to create accountability on the government side, as well as a level of excitement—new people working on something new to them, with (hopefully) new and creative approaches. I have found that if you don't have access to municipal staff, your ideas can potentially stall and progress will take longer.

3. Document. Document. Document. It may sound like an easy thing to do, but pulling it off with all the other things happening may be more difficult than you'd expect. My number one piece of advice: Don't let documentation become an afterthought. At CityCamp Honolulu, they hooked up with University of Hawaii journalism students who helped to document each breakout session. These summaries are now posted on their wiki. This has two major benefits. First, ideas and sessions are documented for people that cannot attend camp in person. This lets them participate later and serves as a reference for those who were there. Second, the involvement of students helps boost energy and increases the familiarity with a lot of the technologies, tools, and processes. In most major universities, students are coming in contact with some form of open source. Students are more likely to be users of social media and web-based collaboration tools. They are tomorrow's leaders—and it's important to invite and include them in your camp.

4. Bring in an outside perspective. At each camp that I've attended, there have been attendees from out-of-town. This was extremely valuable for CityCamp Raleigh (my hometown), because it helped generate different ideas and build on what's happening at other camps in other cities. This cross-pollination of ideas is powerful and, as more camps start up, this will be more important. At CityCamp Honolulu, I was one of a handful of people providing that outside perspective. I found myself helping the organizers, brainstorming with attendees, moderating sessions, and sitting for a panel. If you're attending a CityCamp—whether near or far—be prepared to play multiple roles.

5. Have an action plan after the camp. You'll have a great time at your CityCamp event. It will be even better if attendees have something to look forward to at the end. Whatever you decide to do, I think it's important to establish a cadence–a regular repeated event or engagement–that keeps the community coming back together. There are a variety of ways to do this.

Before the end of your camp, host a session to organize the next steps. Get folks who want to help advance your local movement generate ideas to keep things moving. This will help you get new folks on your planning committee and, in the long-term, prevent burnout.

CityCamp San Francisco participates in Third Thursdays, a monthly meet-up. They recently held a hackathon that brought together developers and other creative professionals. The goals were to build applications that deliver valuable resources to the community.

CityCamp Colorado helped create a local Open Government Directive at their first camp. At this years camp, they explored ways to help further the adoption of the directive. In other words, have your camp work on a project that extends beyond your unconference to keep campers motivated and engaged.

CityCamp Raleigh has been hosting quarterly meet-ups and is looking at having a forum/hackathon in early 2012. CityCampers have also started a local wiki project that allows both developers and citizens to contribute to a common knowledge platform. A wiki project is a great way to get non-developers involved.

CityCamp Honolulu laid out a timeline at the start of their camp. They have a hackathon planned for January 2012 and a Code for America project coming in February 2012. Organizers Forest Frizzell and Burt Lum have also committed to monthly meet-ups. Having a road map is important to show campers the journey you plan on taking.

Those are some key lesson learned from my 2011 CityCamp experiences. Did you attend a CityCamp and learn something new? I welcome those ideas and other thoughts in the comments.

About This Series

The Open Voices ebook series highlights ways open source tools and open source values can change the world. Read more at http://opensource.com/resources/ebooks.

Created with Writer2ePub

by Luca Calcinai