open source

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.

Doubling down on government technology by Luke Fretwell

Doubling down on government technology by Luke Fretwell

Originally posted on     We’ve recently seen an uptick in venture capital interest around government and civic technology startups, but before we enthusiastically celebrate these investments, we must ask ourselves whether this potential bubble will truly reshape government IT or simply leave us five years from now in the same place we are today.

During the Code for America Summit in September, Govtech Fund’s Ron Bouganim and Code for America Director of Products & Startups Lane Becker had a great “Emerging Startup Ecosystem” discussion about the the difference between civic and government technology, and the latter’s focus on solving inherent bureaucratic problems.

Bouganim’s closing comments have stuck with me since watching the interview, and they’re important for us all to think about as we commit to building technology solutions, whether it’s for internal government operations or public-facing citizen engagement applications:

“It is tough because it’s early. Clearly everybody in this room is transformers. These are the folks … that are at the front of this, so it’s tough, because you often at times feel alone, but I think there’s a growing community, and it’s only going to get better. So, I guess my fundamental advice is that if you’re really passionate about this space, and you really identify a big problem, you have to kind of double down on being an entrepreneur. It’s hard enough being an entrepreneur and, in an emerging space like gov tech, you have to double down on that, and I would just encourage you to stick with it.”

Announced in September, Govtech Fund will invest $23 million into government-focused technology ventures. Recently, Y Combinator also expressed an interest in the industry when it issued a request for startups that included those focused on the public sector. Andreessen Horowitz has already invested $15 million in OpenGov, focused on bringing visualizations to government budgets. Other startups such as Socrata and MindMixer have also received multi-million dollar infusions to build the future of public sector IT.

Given the consistent inability for government projects to deliver on time or on budget, especially in the light of recent, major IT failures, we’ve collectively identified the problem. While much of this is due to culture, bureaucratic procurement processes and waterfall project management practices, the fundamental issue with failed government IT is that it is built on proprietary solutions.

Because of this, not only do we not have access to code, more importantly, we lose an opportunity to create an ecosystem of community and collaboration that sustains itself. To put it in context of the latest civic meme, today’s government technology is built for, not with.

The early trend we’re seeing in government technology venture investments is that the focus is still on the proprietary. While this will have incremental benefits and provide short-term excitement with each new launch, they don’t address the bigger issue every government faces in harnessing control over their IT systems.

They’re locked down and locked in.

The argument you often hear when discussing open source with proprietary government technology startup entrepreneurs is that businesses need some form of competitive advantage to build a product and develop a customer base with enough runway to sustain itself longer term. While this makes sense in a commercial market, it addresses the needs not of government, but that of the entrepreneur. The technology may provide a cutting-edge, cloud-based, big data, mobile or social solution worthy of a press release or mention in the trades, but what is it doing to really change the IT conundrum we can’t seem to procure our way out of?

This isn’t to say these new technologies don’t have merit or their builders don’t have good intention. Indeed, some do, however, there’s a classic innovation wall proprietary government IT software hits when it has reached a certain level of customer acquisition and no longer needs to compete. Oakland’s recent insistence that Granicus open up its application programming interface is exhibit A on what happens when a vendor corners a government market: technology stagnation trumps innovation. Without open systems or modularity, government is safely locked in.

We frequently hear the vending machine analogy applied to government. Today, the vending machine is the proprietary vendor machine, and government is the one doing the shaking.

If we’re going to double down and truly build a civic operating system anyone can plug into, and be proud of, we must invest in a strategy that sustains beyond one software solution.

We need to double down on a philosophical approach to government technology.

There’s not an overnight solution and the problem won’t be solved tomorrow, but if you’re really in this business to transform government, whether you’re an entrepreneur or investor, it’s time to double down on open.

Government can, literally, no longer afford to operate business as usual when it comes to technology. If ‘Vendor 2.0′ is simply a new class of fresh faces operating no differently than its predecessor, let’s prepare our kids for disappointment.

You’re either investing in or building tomorrow’s problem today, or you’re co-creating the future of government.

The latter might be a longer, lonelier road, but we have to stick with it because, as Bouganim says, it’s only going to get better.

Let’s double down.

What’s Ahead for Open Source in Government?

What’s Ahead for Open Source in Government?

(originally published at  Republished with permission.

It’s a relatively quiet time for most governments around the world right now. Typically, during this time there are few new initiatives, policies, or announcements related to open source.

So, it’s a good time to consider the trends of the first half of the year and ponder what the remainder of this calendar year holds.

Here are a few that come to mind.

Open Source will continue to be the ‘go to’ approach for governments around the world facing budget constraints amid growing demand for innovative services and citizen engagement.

I speak regularly about the trends in government open source and one of my consistent themes is that the ‘wind is behind’ the take up of open source for government missions.

More than 40 governments, by my conservative count, have policies that create a positive environment for open source use.

These policies are important to level the playing field: on the one hand highlighting the benefits of open source to governments (saying ‘it’s ok to use it’) as well as providing meaningful answers to commonly asked questions by government IT professionals.

The more potent driver toward open source software utilization, I’ve come to realize in recent years, is the fundamental shift in IT architecture, away from coupled hardware, software, and data to more modularity, reuse, and a central focus on interoperability—all of which is enhanced by tigher government IT budgets and the goal of avoiding vendor lock-in.

More recently, open source use has grown with the rise of high profile ‘digital agendas’. As a means of enhancing civic engagement, governments are using community-powered innovation to build open data and digital services platforms that are almost entirely built on open software and applications. We may truly be on the verge of the ‘citizen CIO’.

Increasingly, governments are wrestling with the ‘how tos’ of open source choices; not ‘whether’ to use it.

As broader acceptance of open source grows, governments are seeking to understand how to grasp the broad array of open source offerings that are available.

Their challenge has grown as governments move beyond use of open source in traditional server environments. Today, the cloud, big data, and mobile—which are heavily enabled by open source—are driving IT strategies. They make the question of How? especially acute: How do I take advantage of all this innovation, while still ensuring long-term reliability and consistency with my procurement goals?

To start, it’s important to understand the differences. There are OSS products which have commercial support from firms with proven track records of service and integrity. There are also “insourced” projects where agencies share software with each other, but not with the private sector. Finally, some agencies download community (also known as “freebie”) projects without any commercial support.

If government IT professionals rely solely on ad hoc rules or seat-of-the pants judgement, this exposes government agencies to significant risk that is not, at present, properly documented or understood:

  • 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.

On-going policy discussions will continue about ensuring an ‘open’ cloud.

In a recent post, long-time open source advocate Georg Greve writes of the ‘storm triggered in the cloud’ by recent disclosures of access by intelligence agencies (US and others).

The challenge for open source software advocates is to continue to press for ‘openness’ in the infrastructure and implementation of open source, even as the critical issues of access to information is sorted through.

It won’t be easy. Even prior to these disclosures, it was becoming clear that government initiatives on the cloud were testing the community’s ability to maintain ‘openness’ in implementation of those strategies, even where there were long-standing public commitment to open source and open standards. Some have even spoken of the prospect of a forthcoming ‘cloud war’ between Europe and the US, which would undermine even basic efforts to promote open source cloud offerings globally.

That’s my quick take at the rest of 2013. What are your thoughts?

DC Metro Open Source Community Summit May 10, 2013

The Open Source Initiative (OSI) is hosting the non-profit DC Metro Open Source Community Summit, to be held in Washington, DC on May 10th, 2013.  The program will include short sessions by community notables and an “unconference” format for maximum attendee participation, collaboration, and learning.
Open source community and user group leadership, open source project leads, committers and developers, non-profit foundations, open data engineers and others with an interest in learning more about growing and sustaining open source should attend.  Registration is free to government employees, $20 to non, and includes lunch.
Program details and registration information is available at the event web site.
Event sponsors underwriting the non-profit event include Google, Eclipse Foundation, Red Hat, GitHub, Georgia Tech Research Institute, and MIL-OSS.

Budget for Open Source Software Services Growing in Europe

New source code policy: open and shared

For the first time a U.S. Federal Agency (The Consumer Financial Protection Bureau) 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 web site 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 agree, and the first section of our source code policy is unequivocal:

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.

2012 CFPB Source Code Policy

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.

Government moves to ease security restrictions stifling cloud and open source

Article in the by Mark Ballard on Friday 30 September 2011 11:53

The government’s IT security arm, CESG, has begun relaxing security restrictions on the software it approves for public sector use to accommodate Cabinet Office plans for cloud computing and wider use of open source.

The electronics and computing arm of GCHQ has begun reforming its accreditations of IT suppliers to prevent CESG becoming an obstacle to the G-Cloud, through which the Cabinet Office intends to introduce a more liberal procurement regime.
More here:


  • reforms aimed to avoid putting SME suppliers through a “relentless”, “long-winded” and “burdensome” process “where you need to jump through x-many hoops”.
  • remove the obstacle CESG’s software certification process had put in the way of the local authority’s attempts to build an open source computing infrastructure.

Promoting Open Source Software in Government: The Challenges of Motivation and Follow-Through
by Andrew Oram

This is a prepublication version of an article published in the Journal of Information Technology & Politics, Volume 8, Issue 3, July-September 2011, copyright Taylor & Francis.
See permission notes here:

Discusses: “the four main criteria for successful adoption of open source by government agencies:

1. An external trigger, such as a deadline for upgrading existing software
2. An emphasis on strategic goals, rather than a naive focus on cost
3. A principled commitment to open source among managers and IT staff responsible for making the transition, accompanied by the technical sophistication and creativity to implement an open source strategy
4. High-level support at the policy-making level, such as the legislature or city council

NHIN Connect

If the Nationwide Health Information Network (NHIN) is the information highway for health data exchange, CONNECT is the universal on-ramp for federal agencies. CONNECT is a software solution that lets federal agencies securely link their existing systems to the NHIN. During 2008, more than 20 federal agencies and the private sector collaborated to build CONNECT through the Federal Health Architecture (FHA), and as a result, agencies are heading down the road toward electronic health information interoperability…

The CONNECT solution enables secure and interoperable electronic health information exchanges with other NHIN participating organizations, including federal agencies, state, tribal and local-level health organizations, and healthcare participants in the private sector. The NHIN will ultimately be a vast network of public and private-sector organizations sharing information with each other under clearly defined specifications, agreements and policies.


Based upon federal agency demand, FHA built the CONNECT gateway software from open source code. The solution was jointly developed by federal agencies yet deployed individually at the agency level. The decision to build the solution in open source provides many benefits, including:

  • Driving down the cost of the solution for each agency and saves taxpayer dollars
  • Making it affordable for other organizations to implement
  • Promoting consistency throughout the federal government
  • Decreasing deployment times for agencies
  • Encouraging government and industry to innovate and build on CONNECT to continually make it stronger and promote interoperability throughout the industry

The CONNECT software is now available to any and all stakeholders in the health information exchange community for download. The goal is for CONNECT to be a platform on which government and industry can continue to collaborate and innovate. This will allow the software vendors to build, sell and compete with better AND interoperable solutions for the healthcare sector.


The CONNECT Gateway is built on open source technologies and was made available publicly in spring of 2009. Three primary elements make up the CONNECT Gateway:

  • The Core Services Gateway provides the ability to locate patients at other health organizations within the NHIN, request and receive documents associated with the patient, and record these transactions for subsequent auditing by patients and others. Other features include mechanisms for authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information.
  • The Enterprise Service Components, which provide default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), XDS.b Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log and others. Agencies are free to adopt the components or substitute their own implementations.
  • The Software Development Kit (SDK) enables agencies to develop adapter components that integrate their existing electronic health information systems with the Core Services Gateway.


The CONNECT initiative sped from concept to reality in 2008. In March 2008, FHA awarded a contract to develop the CONNECT solution. The solution was built with federal agency participation, and in September of 2008, three agencies were already demonstrating the ability to share information with the private sector through the NHIN. The number of participating agencies grew to six for the December 2008 public demonstrations, and the plan is to have all federal agencies with a health line of business participate in the NHIN by the end of 2009. In the meantime, federal agencies have continued to participate in a series of trial implementations that focus on defining and deploying an initial set of services for the secure exchange of interoperable health information, and all agencies have received a deployable package that includes the CONNECT Gateway, enterprise service components and an adapter SDK.


CONNECT has identified a number of opportunities for federal agencies to utilize the Gateway to address their mission needs in 2009 and beyond. These citizen-centric initiatives will provide a roadmap for 2009 development. Expected FHA activities include helping agencies deliver solutions that:

  • Collect patient status assessments as they move among various care settings to track effectiveness of treatment
  • Populate patient personal health records with information from federal systems
  • Support needs of health plans to combat fraud and waste
  • Improve coordination of benefits with other payer organizations
  • Enhance onsite care for patients during disasters and other public health emergencies
  • Support data collection for analysis of potential adverse events associated with drugs and medical equipment
  • Help establish local networks among community health clinics that provide care to underserved populations

The expected journey forward is exciting. The progress achieved to date clearly demonstrates the viability of the NHIN and provides a glimpse into a dramatically enhanced healthcare future for Americans – one based on agreed standards, attention to interoperability, affordability, and that leverages the advantages of open source software.