Government Open Source Projects

U.S. Digital Services and Playbook: “Default to Open” by Mark Bohannon

U.S. Digital Services and Playbook: “Default to Open” by Mark Bohannon

Originally posted on About this time last year, I laid out some trends I saw for the coming year in government take up of open source software. Looking back now, it appears those trends are not only here to stay, they are accelerating and are more important than ever.

In particular, I wrote that “open source will continue to be the ‘go to’ approach for governments around the world” and that “increasingly, governments are wrestling with the ‘how tos’ of open source choices; not whether to use it.”

Recent developments in the United States highlight these points.

First, the White House (via OMB and the Federal CIO) has issued a Digital Services Playbookdescribed in some quarters as “something of a marvel for an official government policy: it’s elegantly designed, has clear navigation, and is responsive to any device you choose to view it upon.” It is well worth a read.

At its core, the Playbook is about more agile use of reusable software and processes that focus on the customer. Central to that approach is its emphasis on open source. The final ‘play’ in the Playbook captures the notion of ‘Default to Open’. Play 8 encourages agencies to ‘Choose a Modern Technology Stack’. “In particular, digital services teams should consider using open source, cloud based, and commodity solutions across the technology stack, as these solutions have seen widespread adoption and support by the most successful private-sector consumer and enterprise software technology companies.” It clearly states, “Consider open source software solutions at all layers of the stack.”

Of course, none of this is entirely new. One can find echoes of all these points in earlier Administration policy statements. For example, its ‘Shared Services‘ strategy clearly calls for use of open standards in data and information exchange and states clearly the technology principle that “open-source software solutions should be included in alternatives analyses.” (If there is one concern I have with the Digital Services Playbook, it is that there is an ‘old school’ statement that “open source solutions are [to be] evaluated alongside commercial solutions when technology choices are made,” a throwback to the days when there was confusion on this front. In fact, the US government has long recognized that open source software is, in fact, commercial software.)

The Digital Services Playbook bears strong resemblance to the principles driving the United Kingdom’s (UK) Government Digital Service (GDS), announced in 2013. As Mike Bracken, the head of the UK’s DGS said in an interview, “The principles by which we work are nothing more than applied common sense in the Internet age. If they make sense, use them: they’re for everybody.” The same can be said for the US government’s Playbook.

Second, the Administration also announced two other initiatives this summer. One was the creation of 18F, which will be housed at the US General Services Agency (GSA). Also known as “Digital Services Delivery,” 18F is a self-described ‘open source team’ that encompasses the Presidential Innovation Fellows and an “in house digital delivery team.” 18F has published a policy which clearly states as its mantra to:

  • Use Free and Open Source Software (FOSS) in our projects and to contribute back to the open source community
  • Create an environment where any project can be developed in the open
  • Publish all source code created or modified by 18F publicly

And, on August 11, the White House announced a new U.S. Digital Service, which it described as “a small team made up of our country’s brightest digital talent that will work with agencies to remove barriers to exceptional service delivery and help remake the digital experience that people and businesses have with their government.” It is the Administration’s intention that the two groups “will collaborate closely.” The U.S. Digital Service will, as far as I can tell, be the proverbial shepherd herding the cats.

My colleague, Gunnar Hellekson, Red Hat’s North American Public Sector Chief Technology Strategist, has posted a thoughtful blog: U.S. Digital Service is Born. It is well worth a read, as it highlights both the challenges and opportunities facing these recent initiatives. As he says, “the questions of talent, agency appetite for change, procurement reform, and the bureaucratic home are all implementation details.” Yes, it’s about the how of open source software (and IT reform generally); it’s not about the whether.

These initiatives, particularly 18F and the U.S. Digital Services, are just getting started. By any measure they are works in progress. While there are some lessons from the UK experience to draw on, as one report indicates, “unlike the United Kingdom’s Digital Government Service, the United States has not created a singular new entity with a large budget and spending authority. Nor has it hired dozens and dozens of top technologists at high pay grades who then set about building core digital services for the country, although 18F merits comparison. Instead, the USDS will work with federal agencies as they create or upgrade services and products.”

The question for the US, however, is not merely staff size or budget, per se. Rather, it is assessing the ‘gap’ or problem where it can make a difference. And making sure that the lessons from prior US government efforts to develop open source software are not lost.

As I laid out in my post last year, I assessed government’s growing use of open source software and observed, “If government IT professionals rely solely on ad hoc rules or seat-of-the pants judgment, this exposes government agencies to significant risk that is not, at present, properly documented or understood.” I identified at least three areas where the ‘how to’ of open source needs to be considered:

  • There are distinct risks associated with choosing a freebie/insourced model for use of open source software. In particular, community/freebie projects or insourced projects are likely to lack key security certifications, regular updates, support from third-party vendors, and interoperability with your critical applications.
  • Relying on freebie/insourced open source software effectively means a strategy of relying on internal support for critical mission which is unknown territory and potentially expensive, given the difficulty of obtaining and retaining qualified IT and management personnel.
  • We could see a repeat of the failures and long-term costs associated with ‘government-off-the-shelf’ (GOTS) solutions. Although the projects may be, technically, commercial items as generally understood by governments, they present the same risks and economic liabilities as government-off-the-shelf software.

In my interview with David A. Wheeler, the long-time recognized leader in advising and working with the US government on issues related to open source software, he elaborated on the last point. “Project forking is still a big problem. … Government employees who are officially managing the project may be smart in general, but they often know little about software. Obviously, managers who don’t understand what they’re managing are often easily fooled. For example, government managers often don’t realize that most software costs are in maintenance and typically do not understand that maintenance costs can be greatly reduced (through sharing) if changes are released back to a larger community. … Part of the problem is that in most agencies, the easy thing to do is to create project-special forks, even though it is almost always the highest-cost and highest-risk approach for maintenance.”

As one step to mitigate that risk, Wheeler pointed to the open source software policy created by the Consumer Financial Protection Bureau (CFPB). In the CFPB approach, software developed using government funds must be released as open source software unless a special waiver is granted.

To their credit, 18F has built on that example and established as a key operating principle that it will publish all source code created or modified by 18F publicly. And the Digital Services Playbook in its ‘Default to Open’ play suggests for agencies to, “when appropriate, publish source code of projects or components online… and share your development process and progress publicly.”

Notably, this key Play advises agencies to “ensure that we maintain the rights to all data developed by third parties in such a manner that is releasable and reusable at no cost to the public… [and] that we maintain contractual rights to all custom software developed by third parties in such a manner that is publishable and reusable at no cost.”

In the end, 18F and the U.S. Digital Service will be successful if they set by way of example and show leadership with US agencies on the ‘how to’ of open source software. They need to focus on instilling best practices across government as they work to implement this key tenet of IT reform, centered on agility, reusability, and default to open.

This measurement of achievement may be as, if not more, important than any specific application or tool that emerges from their efforts.

The latest White House moves on open source: Connecting citizen developers to tools

This week, in the latest step to connect citizen developers with the tools they need to unlock government data, the White House updated their website to include a developers resources section. More than a mere technical reference post, the White House affirmed that:

“We believe in using and contributing back to open source software as a way of making it easier for the government to share data, improve tools and services, and return value to taxpayers.”

The section includes a list of their open source projects. GitHub and Drupal get top billing in the list.

In 2010, the White House was recognized by Open Source for America for its leadership in using and recognizing open source. This latest affirmation confirms that commitment.

But, it is not only manifestation of that engagement. For example:

On August 23, they released the code for the White House apps and the code for the “We the People” online petition system. Releasing the source code for We the People is like a double dose of open source. The program allows citizens to create online petitions. If the petitions reach 25,000 signatures, the topic receives special attention from the Obama Administration. Since October 2011, 30 petitions have crossed the threshold and spurred change. This allows citizens to have direct influence on important topics and is a fantastic example of open government in practice.

Bringing the issue to the international stage, President Obama spoke about it at the Open Government Partnership. He made clear that steps like those taken by his own White House on open source are an important component of the US Government’s efforts to “share the technology so any government in the world can enable its citizens to do the same.” In so doing, the Administration sees a direct connection to the goal of the Partnership, which seeks to foster a “global effort to make governments better … more transparent, effective and accountable … with institutions that empower citizens and are responsive to their aspirations.”

On September 4, they released the source code for the White House apps made for iOS and Android on GitHub. The administration hopes that anyone “from civic hackers and local organizations to federal agencies” will download the apps, make changes, and use them for their own projects, according to the White House blog. President Obama’s goal for these apps is to make the government more open by sharing more information.

Thanks to Casey Brown for her research and contributions to this post.

Original article authored by Mark Bohanan on .

Budget for Open Source Software Services Growing in Europe

NASA launches open source web site
NASA, the National Aeronautics and Space Administration in the US, has launched, a web site that will serve as the central source of information about the agency’s open source projects. The site, which is still in early alpha, is intended to help unify and expand NASA’s open source activities

UK Government publishes open source guidelines

by: Steve Evans, Published 04 November 2011
UK govt wants to dispel some of the myths around open source software
The toolkit contains information on procuring open source software as well as guides to vendors and what sort of costs are likely to be associated with going down the open source route.

In total the toolkit, available on the Cabinet Office’s website, contains six documents: All About Open Source – including FAQs, ICT Advice Note – Procurement of Open Source, Procurement Policy Note on Open Source, OSS Options, CESG Guidance on Open Source and Total Cost of Ownership.


BRL-CAD was developed by the US Army Research and Development Command, and released to the public in 2004. You can learn more about BRL-CAD, and their experience with releasing open source code in the presentation below.


Opticks is a image and video analysis tool that grew out of the USAF COMET program. It was created for the USAF by Ball Aerospace and subsequently released under the LGPLv2 license in 2007. You can learn more about how this project successfully started their community in this slide show:

World Wind

NASA released World Wind, a Java SDK for Google Earth-style visualizations under the NASA Open Source Agreement (NOSA).

Open Source Electronic Health Record (OSEHR) aka VistA

The VA released their venerable VistA electronic health record system under the Apache license.

Object-Oriented Data Technology

OODT is “data middleware” that ties together distributed data sets for processing. It was created by NASA, and is now part of the Apache project.