The White House Open Source Policy – Close, But No Cigar

May 26, 2016 Jason Levy

Some argue that the US Government’s new released open source policy, released this March, marked a watershed in its position towards Open Source Software. The policy main two requirements are that customer code developed for US agencies will become available to all other agencies and to release a portion of this custom code to the public as open source – and herein lies the rub.

Is 20% a New Beginning?

Under the terms outlined in the draft policy, government agencies will only be obliged to release a 20% minimum of its proprietary code as open source. It must be noted however that agencies will be encouraged to release as much custom code as possible, yet no measures to incentivise such encouragement were laid out.

After its release, the open source community was invited to give its evaluation of the policy on GitHub. And as you probably have predicted, there was an uproar that the worldís largest producer of code, who just so happens to be funded by tax-dollars, was considering open sourcing 20% of its customer code as revolutionary.

Surely, if the White House truly wishes the American taxpayer to get more bang for their buck, whilst simultaneously ensuring code quality and security is enhanced, this measly release of 20% needs to be revised. Doesnít logic dictate that those very people who funded the codeís development should be able to reuse that code to develop products and services, which will, in turn, drive the economy?

In this opinion post, Ben Balter explains why the WhiteHouse should have opted for an open by default approach, but even a more moderate move was needed as a first step it should have been a minimum of releasing 50% of its custom code as open source. It’s realistic to assume that around 10-20% of the Federal Governmentís new projects are open source, consequently, the proposed 20% threshold could mark only a 10% increase of what the Government releases today. Therefore, in order to judge the true benefits of releasing custom code as OSS against todayís status quo, the amount of code to be released needs to be drastically expanded.


Do We Really Need to Pilot Test Open Source?

Another issue that started many debates was that the new draft will be valid for only 3 years as a pilot program to test out this new approach. Isn’t it bad enough that the US government, like many other governments worldwide, is lagging behind software companies and enterprises in maximizing the value of open source, but now it questions the entire value?

Open source has already undergone a two-decade pilot. Do we really question the value open source may bring to US government agencies?

Luckily I have my crystal ball with me and I can predict that the three-year pilot project will confirm what we all already know, open source is the way to go to ensure the development of efficient and secure software infrastructure. However, by the time the Government comes to realise this, it will be further lagging behind the majority of companies and organisations who know the move to open source is inevitable.

More importantly, it may not even be possible to determine the success of the pilot project. If the open source community embraces the Government’s newly released custom code, as they surely will, a whole new culture towards Government agencies will emerge. Government programs will enjoy greater transparency and accountability, thus encouraging increased public confidence and engagement. Although these outcomes are undoubtedly positive, they are extremely hard, if not impossible, to measure.


Are Government Agencies the Exception?

It cannot be denied that the Federal Government is oblivious to the benefits releasing its custom code as open source has upon on its operations. The aforementioned draft policy asserts that ëthe continual improvement of Federal code projects can be enabled when a broader community of users implements the code for its own purposes and publishes bugs and improvementsí.

After all, this is what open source is all about.

It seems Luke McCormack, CIO of the Department of Homeland Security (DHS), is attuned to this very debate. In response to an earlier post by the DHS claiming that releasing the 20% would be akin to giving the mafia a copy of the FBI system code, he responded that releasing custom code as open source can have ëextensive cybersecurity benefitsí due to the public scrutiny that open source code offers, together with incentivising innovation and allowing a whole new breed of companies to do business with the Government.


A Wild Goose Chase

The Federal source code policy is a half-measure designed to placate those bureaucrats who claim that the Government’s source code should remain proprietary, whilst dangle the carrot of ever-increasing adoption of OSS in the future.  However, if the Federal Government is going to hold true to its own reasoning that ëusing and contributing back to open source software can fuel innovation, lower costs, and benefit the publicí, it has a civic and indeed moral duty to make its custom code open by default.

The public discussion was closed in April and now The Office of Management and Budget (OMB) is analysing feedback to agree on a final draft, which is to be followed by a three-year pilot project. II guess we will have to wait and see how this will roll out in the next few months, but it seems public outcry on the 20% markup and the 3-year pilot program will not have any real impact on the final policy.



Previous Article
Opening Pandora’s Box – Overcoming Software Supply Chain Risk
Opening Pandora’s Box – Overcoming Software Supply Chain Risk

With so many different software suppliers using many different types of code, can you really know what you ...

Next Article
Why Open Source Dependencies Are Your Blind Spot?
Why Open Source Dependencies Are Your Blind Spot?

Dependency Hell to Thousands of npm Users   Not more than two months ago, JavaScript developers worldwide s...