Category Archives: Blog

OSFA Awards!

Congrats to our latest OSFA Award winners who have demonstrated their great commitment to use of open source by the federal government.

Organizational winners are: Office of the Federal Register for the Federal Register 2.0 project and OWASP, the Open Web Application Security Project.

Individual winners are Kane McLean and Alan Cudmore.

To read more about our winners, click here.

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?


On the Health IT Buzz blog from HHS, Office of the National Coordinator for Health IT’s Special Assistant for Consumer e-Health, Damon Davis, visits OSCON:

…it seems that those involved in the development of open source software believe it has the potential to be a driving force in advances in personal health and wellness, the technological transformation of the health care system, and government innovations small and large.  It is incumbent on those of us in the federal government to continue to strive for greater openness, transparency, and collaboration.

Read more here.

The Accumulo Challenge, Part II

Public domain image courtesy of the U.S. Navy.

These guys care a lot about open source.

In Part I, we discussed the Senate Armed Services Committee (SASC)’s attempt to hobble the open source Accumulo project in the DOD. They directed the Department’s CIO to jump through a number of reporting hoops before Accumulo would be allowed inside the DOD, and directed the Accumulo team to upstream their work into related open source projects. It appears to be an attempt to dismantle the project on the assumption that it was competing with products and project from the private sector.

The Accumulo case isn’t the first, and will not be the last, project to encounter this kind of resistance. As the government gets more comfortable with open source, it will inevitably create more of its own projects, and collaborate with existing projects. So rather than think about Accumulo narrowly, this is a good time to think more generally about how the government creates open source projects, how it chooses supported or unsupported software, and what should happen when government projects begin to compete with the private sector.

Here’s my take, animated largely by OMB Circular A-130 §8b1(b) which I mentioned in Part I. Though A-130 is mostly toothless, it does embody a number of common-sense IT practices and it’s as good a framework as any to answer some of these questions. Now’s a good time to re-read that section if you’re not already familiar with it.

Continue reading

The Accumulo Challenge, Part I

The dozens of software projects launched in the wake of Google’s Big Table and Map Reduce papers have changed the way we handle large datasets. Like many organizations, the NSA began experimenting with these “big data” tools and realized that the open source implementations available at the time were not addressing some of their particular needs. They decided to embark on their own project: Accumulo. Once they were happy with how Accumulo was working, they did the right thing and released Accumulo to the world through the Apache Foundation.

This is great for open source and the taxpayer. The government found a requirement not being fulfilled by the private sector, and rather than letting their work languish inside its walls, or paying a contractor to develop a proprietary solution, they shared what they had with the world. This is what open source advocates have been clamoring for, and with the Shared First initiative at OMB and innovative open source policies like those at the Consumer Financial Protection Bureau, it’s certain we’ll see more of this kind of sharing of taxpayer-funded work.

There’s a catch, though. Since it was launched, Accumulo has joined an increasingly crowded space for tools that manage big data. As these upstarts compete – witness the extraordinary success of MongoDB from 10genHadoop implementations from Cloudera and HortonWorks, tools like HadaptHBaseCassandraMapR, and many, many others – Accumulo presents a threat. Some of these products and projects already compete with each other, and the private sector doesn’t like it when the government competes alongside them, for good reason.

There’s a frequently-ignored policy called OMB Circular A-130 which says that the government shouldn’t build something already available from the private sector. In the language of the policy, the government should:

…acquire off-the-shelf software from commercial sources, unless the cost effectiveness of developing custom software is clear and has been documented through pilot projects or prototypes

So there’s a tension here: we want the government to share its innovations, but we don’t want the government to crowd out the private sector. That’s the thinking behind this recent language in Section 929 of S.3254, the 2013 Defense Authorization as reported out by the Senate Armed Services Committee:

(a) Limitation on Use of NSA Database-

(1) LIMITATION- No component of the Department of Defense may utilize the cloud computing database developed by the National Security Agency (NSA) called Accumulo after September 30, 2013, unless the Chief Information Officer of the Department of Defense certifies one of the following:

(A) That there are no viable commercial open source databases with extensive industry support (such as the Apache Foundation HBase and Cassandra databases) that have security features comparable to the Accumulo database that are considered essential by the Chief Information Officer for purposes of the certification under this paragraph.

(B) That the Accumulo database has become a successful Apache Foundation open source database with adequate industry support and diversification, based on criteria to be established by the Chief Information Officer for purposes of the certification under this paragraph and submitted to the appropriate committees of Congress not later than January 1, 2013.

(2) CONSTRUCTION- The limitation in paragraph (1) shall not apply to the National Security Agency.

(b) Adaptation of Accumulo Security Features to HBase Database- The Director of the National Security Agency shall take appropriate actions to ensure that companies and organizations developing and supporting open source and commercial open source versions of the Apache Foundation HBase and Cassandra databases, or similar systems, receive technical assistance from government and contractor developers of software code for the Accumulo database to enable adaptation and integration of the security features of the Accumulo database.

First of all: Wow. The Senate Armed Services Committee proposes to order the DOD to stop using Accumulo, and direct NSA to help push Accumulo’s code back to other projects, specifically calling out HBase and Cassandra. The level of sophistication required for legislative language like this is astonishing. Under different circumstances, I’d find that sophistication encouraging. Instead, I’m concerned that SASC feels compelled to blacklist an open source project for the DOD. Surely there’s a better response than this?

Let’s put the Committee’s reasoning to the side for a moment, and look at the remedy they proposed. What if it wasn’t Accumulo, but another piece of software? Imagine that we’re talking about the Apache Web Server, Red Hat Enterprise Linux, Microsoft SharePoint, or Adobe Acrobat. If Congress put any of those software packages on a blacklist, industry would lose its mind. Accumulo is no different: once it was open sourced, Accumulo became commercial software under the FAR and DFAR. Congress has no business intervening in this way.

There’s more. The requirement that Accumulo be certified as “a successful Apache Foundation open source database with adequate industry support and diversification, based on criteria to be established by the Chief Information Officer” is extremely dangerous for Accumulo and for open source in general. It’s not sufficient that the software be commercial, functional and be available at reasonable cost. It must now have “adequate industry support and diversification.”

If the DOD CIO is compelled to create such criteria for Accumulo, it doesn’t take much imagination to see that same “adequacy criteria” applied to all open source software projects. Got a favorite open source project on your DOD program, but no commercial vendor? Inadequate. Only one vendor for the package? Lacks diversity. Proprietary software doesn’t have a burden like this.

The last clause of Section 929 is bewildering. SASC directs Accumulo to help other projects that want to use the Accumulo security code, and singles out HBase and Cassandra. There’s nothing wrong with the desire to spread Accumulo’s technology, but doesn’t an act of Congress seem like an extraordinarily, comically inappropriate tool for that? Wouldn’t the Accumulo team, like all open source developers, be generally helpful with folks who want to integrate their code? Perhaps more importantly, why is Congress so interested in HBase and Cassandra?

I think the Committee (and whoever provided them this legislative language) is right to be concerned about the government unnecessarily maintaining a duplicative software project. It’s bad for the private sector, and it’s bad for the government to maintain its own codebase when there are perfectly good alternatives elsewhere.

At the same time, the Accumulo folks indisputably did the right thing by releasing their code, and even went so far as to join the Apache Foundation, which is no small effort. They should be rewarded for their excellent stewardship of taxpayer money. Through their effort, everyone can already benefit from the work that they’ve done – with or without legislative orders to do so – and they’re perfectly capable of winning or losing market share on their own merits, just like everyone else.

This Accumulo issue opens the door to a host of valid questions about the role of government in open source projects. In part two, we’ll put this specific bill aside and ask the questions behind the legislation: does the government harm the private sector when they release open source projects? How can we know when open source is an appropriate way for the government to develop software? How should the government handle forks? I’ll also examine some possible remedies that could eliminate the need for a dangerously crude tool like Section 929.

In the meantime, please let your Senator know how you feel about this.

[Original post here.]

Lessons Learned: Roadblocks and Opportunities for Open Source Software in U.S. Government

Join GovLoop, the Homeland Open Source Technology (HOST) program, and a number of OSFA luminaries on June 7, 2012 at 2PM ET to discuss a recent HOST report. The report highlights key roadblocks and opportunities in the government application of open technology solutions (OTS), as reported in interviews of experts, suppliers, and potential users.

Attend this webinar to learn:

  • Current Open Source Software roadblocks
  • The state of the collaborative development of software
  • Open Source Software security: Fact or Fiction
  • Opportunities for Open Source Software in Government
  • Available solutions


Dr. David Wheeler, Analyst, Institute for Defense Analyses
Joshua L. Davis, Research Scientist and HOST Principal Investigator
Gunnar Hellekson, Chief Technology Strategist, Red Hat Public Sector Group

Register today to learn more about the status of Open Source Software in Government.