What We’re Reading


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.

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

Liberating America’s secret, for-pay laws via BoingBoing

Brilliant article/project by Carl Malamud of Public.Resource.Org snip:

Public.Resource.Org spent $7,414.26 buying privately-produced technical public safety standards that have been incorporated into U.S. federal law. These public safety standards govern and protect a wide range of activity, from how bicycle helmets are constructed to how to test for lead in water to the safety characteristics of hearing aids and protective footwear. We have started copying those 73 standards despite the fact they are festooned with copyright warnings, shrinkwrap agreements, and other dire warnings. The reason we are making those copies is because citizens have the right to read and speak the laws that we are required to obey and which are critical to the public safety.

more here: Liberating America’s secret, for-pay laws

Congrats to Todd Park to be US CTO

Word broke today that Todd Park currently Health and Human Services CTO is to be promoted to Federal CTO.

In a Whitehouse blog post the announcement was made today snip:

“For nearly three years, Todd has served as CTO of the U.S. Department of Health and Human Services, where he was a hugely energetic force for positive change. He led the successful execution of an array of breakthrough initiatives, including the creation of HealthCare.gov, the first website to provide consumers with a comprehensive inventory of public and private health insurance plans available across the Nation by zip code in a single, easy-to-use tool.

On his first full day in office, President Obama created the position of “Chief Technology Officer” to help modernize a Federal government relying too heavily on 20th century technology, and to better use technological tools to address a wide range of national challenges. In his role as U.S. CTO, Todd will continue the work of Aneesh Chopra, the Nation’s first Chief Technology Officer, who stepped down last month after an inspired and productive three years on the job.

The U.S. CTO’s office is situated here within the White House Office of Science and Technology Policy, where Todd will work closely with U.S. Deputy Chief Technology Officer for Telecommunications Tom Power.  Tom will perform the duties of OSTP’s Associate Director for Technology—a position previously held by Chopra in conjunction with his role as U.S. CTO—while a search is conducted for a permanent replacement.”

Congrats to Todd!

New Hampshire passes open source, open data legislation

Congratulations to New Hampshire, whose newly passed HB418 now requires the consideration of open source software, and promotes open data standards. Great work!

OSFA responds to draft “Shared First” policy

[If you agree with this position, please head over to the IT Shared Service Strategy IdeaScale site and upvote! Thanks!]

Open Source for America applauds OMB’s effort to increase the efficiency of the Federal IT budget through the principles of commoditization, reuse, sharing, and collaboration described in the draft IT Shared Services Policy distributed on December 8th, 2011. These principles are also the hallmarks of open source software, and while there is no explicit mention of open source in the plan at this time, we believe that there should be. We see a unique opportunity for open source to improve the effectiveness of Shared First.

“A number of barriers exist which have prevented the broader adoption of shared IT services. Lack of information sharing among the Federal agencies, budgetary restrictions, acquisition issues, and other factors have all contributed to a culture in which proprietary, specialized systems are the norm.”

We could not agree more. We believe that OMB should explicitly mention open source as a recommended method for overcoming these barriers. Open source software itself, of course, can reduce costs and ease acquisition challenges. We can assume that many agencies will naturally use open source software as part of their Shared First implementation.

Embracing the open source approach, though, and using it to encourage sharing between agencies, departments, other governments, and the general public is the purest expression of the goals of the Shared First policy. Open source excels at the Shared First Design Goals, including visibility, commoditization, reusability, extensibility, and standardization, and we believe it should be actively and explicitly encouraged by the policy.

Much of the draft is concerned with the sharing of existing infrastructure, and is in this way very similar to the Federal Data Center Consolidation Initiative. As the scope of the Shared First policy is much broader than the FDCCI, and concerns itself with LoB information systems and applications, we would like OMB to consider expanding the scope of the mandate to include the sharing of development resources, and not just their ongoing operations and maintenance.

As the policy encourages agencies to “move up the stack,” and share ever-more complex layers of their information systems, agencies will need to perform more customization to meet their specific mission needs. If they were to use proprietary commercial offerings or systems developed for just one agency, this can become very difficult and very expensive.

If agencies were to instead employ open source software, or better still: share their taxpayer-funded software under an open source license, customization would become easier, and the need for customization would be reduced, owing to the natural modularity of open source projects.

In the process, agencies would be making themselves available to contributions and improvements from their partner agencies as well as state and local governments who also have a use for that same software. Certainly, it is possible to share complex application software amongst agencies without open source software. We believe, however, that releasing software under an open source license can simplify this process, and simultaneously encourage sharing among other state and local governments, and the private sector as well. This approach has already been successful at NASA and the National Institutes for Health. We see no reason why other agencies cannot realize the same benefits.

“Open source is… the most concrete form of civic participation.”

— Macon Phillips, White House New Media Director

An excellent example of this is the effort currently underway at the EPA to develop a shared management system for Freedom of Information Act (FOIA) responses, one of the goals of the President’s National Action Plan under the Open Government Initiative. Almost as soon as the FOIA project was announced, it became clear that many citizens, state and local governments were interested in developing this platform alongside the EPA.

Should this project succeed, there would be a single, common platform for handling FOIA responses that would be freely available to the 93 agencies required to perform this task. Rather than 93 purpose-built systems, agencies could take advantage of each other’s innovation, the innovation of the private sector, and the innovation of thousands of state, local, municipal, and tribal governments who have their own Freedom of Information requirements.

Unlike working with proprietary FOI software, the number of agency-specific customizations would be drastically reduced, and since customizations can be contributed back to the main project, the ongoing maintenance burden of these customizations would be reduced, as well.

This kind of inter-, intra-, and extra-agency collaboration using the open source model is already finding success throughout the government, including the Veterans’ Administration Open Source VistA program, the National Security Agency’s SELinux project, and the OMB’s own data.gov.

It’s not difficult to imagine that these projects can encourage the growth of small businesses specializing in the implementation and maintenance of this software. Incorporating these stakeholders would bring to bear on the EPA’s FOIA platform far more development and testing resources than the EPA could muster on its own. Because the software assets have been commoditized, the EPA and other agencies would no longer be beholden to a single vendor for its FOIA software. This is the kind of relationship that OMB would like with its software assets, and this is precisely the kind of collaboration and commoditization that the current Shared First policy encourages. This is why we believe that the policy should make the role of open source explicit.

Open source software is particularly useful when the Federal government mandates action by state governments. The New York State Office of Temporary Disability Assistance has had great success in sharing open source eligibility logic with its counterparts in other states, allowing them all to share the burden of implementing CMS eligibility requirements. The Office of the National Coordinator for Health IT has employed open source software to encourage the adoption of its CONNECT standards for electronic health records. Without open source, these efforts would rely on potentially expensive proprietary software, which would have to be either unfunded or subsidized by the Federal partner to encourage adoption of their mandates. Instead, these organizations can now work collaboratively and transparently to solve their common missions.

Releasing agency software as open source has other benefits, as well. One of the primary concerns of the draft policy is to encourage visibility: agencies cannot share with each other if they do not know what’s being shared. The open source community has largely solved this discoverability problem through tools like sourceforge.net and github.com, both of which may be used, free of cost, by Federal staff and the public.

Open Source for America is excited by this renewed focus on agency collaboration and transparency. We strongly support the Shared First policy, and believe that it is one of the best tools available to meet agencies’ current challenges. We look forward to working together with OMB and the implementing agencies to make the policy successful. We also believe that by encouraging agencies to open source their software, and to share that software with each other, we can together ensure that agencies are putting their existing budgets to their best and highest use.