Category Archives: 18F

United States Releases Draft National Open Source Software Policy

Posted on by

0

IMG_1256On September 23, 2014, the White House announced that the United States would create an official policy for open source software. Today, the nation took a big step towards making more software built for the people available to the people.

“We believe the policies released for public comment today will fuel innovation, lower costs, and better serve the public,” wrote U.S. chief information officer Tony Scott in a blog post at WhiteHouse.gov, announcing that the Obama administration had published a draft open source policy and would now take public comments on it online.

This policy will require new software developed specifically for or by the Federal Government to be made available for sharing and re-use across Federal agencies. It also includes a pilot program that will result in a portion of that new federally-funded custom code being released to the public.

Through this policy and pilot program, we can save taxpayer dollars by avoiding duplicative custom software purchases and promote innovation and collaboration across Federal agencies. We will also enable the brightest minds inside and outside of government to review and improve our code, and work together to ensure that the code is secure, reliable, and effective in furthering our national objectives. This policy is consistent with the Federal Government’s long-standing policy of technology neutrality through which we seek to ensure that Federal investments in IT are merit-based, improve the performance of our Government, and create value for the American people.

Scott highlighted several open source software projects that the federal government has deployed in recent years, including a tool to find nearby housing counselors, NotAlone.gov, the College Scorecard, data.gov, and an online traffic dashboard. platform, and the work of 18F, which publishes all of its work as free and open software by default.

The draft policy is more limited than it might be: as noted by Greg Otto at Fedscoop, federal agencies will be required to release 20 percent of newly developed code as open source.

As Jack Moore reports at NextGov, the policy won’t apply to software developed for national security systems, a development that might prove disappointing to members of the military open source community that has pioneered policy and deployment in this area.

The draft policy sensibly instructs federal agencies to prioritize releasing of code that could have broader use outside of government.

The federal government is now soliciting feedback to the following considerations regarding its use of open source software.

Considerations Regarding Releasing Custom Code as Open Source Software

  • To what extent is the proposed pilot an effective means to fuel innovation, lower costs, benefit the public, and meet the operational and mission needs of covered agencies?
    • Would a different minimum percentage be more or less effective in achieving the goals above?
    • Would an “open source by default” approach that required all new Federal custom code to be released as OSS, subject to exceptions for things like national security, be more or less effective in achieving the goals above?
    • Is there an alternative approach that OMB should consider?
  • What are the advantages and disadvantages associated with implementing this type of pilot program? To what extent could this policy have an effect on the software development market? For example, could such a policy increase or decrease competition among vendors, dollar amounts bid on Federal contracts, or total life-cycle cost to the Federal Government? How could it impact new products developed or transparency in quality of vendor-produced code?
  • What metrics should be used to determine the impact and effectiveness of the pilot proposed in this draft policy, and of an open source policy more generally?
  • What opportunities and challenges exist in Government-wide adoption of an open source policy?
  • How broadly should an open source policy apply across the Government? Would a focus on particular agencies be more or less effective?
  • This policy addresses custom code that is created by Federal Government employees as well as custom code that is Federally-procured. To what extent would it be appropriate and desirable for aspects of this draft policy to be applied in the context of Federal grants and cooperative agreements?
  • How can the policy achieve its objectives for code that is developed with Government funds while at the same time enabling Federal agencies to select suitable software solutions on a case-by-case basis to meet the particular operational and mission needs of the agency? How should agencies consider factors such as performance, total life-cycle cost of ownership, security and privacy protections, interoperability, ability to share or reuse, resources required to later switch vendors, and availability of support?

If you have thoughts on any of these questions, you can email sourcecode@omb.eop.gov,
participate in discussions on existing issues on Github, start a new one, or make a pull request to the draft policy on Github. You can see existing pull requests here and view all comments received here.

With this policy, the White House has fulfilled one of the commitments added to the second National Action Plan for open government in the fall of 2014. While there has been limited progress (or worse) on of the dozens of other new and old commitments made in the three action plans published to date, this draft open source policy is a historic recognition of the principle that the source code for software developed by government agencies or contractors working for them can and should be released to other agencies and the general public for use or re-use.

USASpending.gov addresses some data issues, adds Github issues tracker for feedback

Posted on by

2

usaspending

On April 1st, some reporters, open government advocates and people in industry may have hoped that a new redesign of USASpending.gov, the flagship financial transparency website of the United States government, was just a poorly conceived April Fool’s joke. Unfortunately, an official statement about the USASpending.gov redesign at the U.S. Treasury’s blog confirmed that the redesign was real. Analysts, media and businesses that rely on the contracting data on the site were loudly decried the decreased functionality of USASpending.gov.

A week later, there’s a still no evidence of deliberate intent on the part of Treasury not to publish accurate spending data or break the tool, despite headlines about rolling back transparency. Rather, it looks more likely that there were been a number of mistakes or even unavoidable errors made in the transitioning the site and data from a bankrupt federal contractor. There was certainly poor communication with the business community and advocates who use the site, a reality that Luke Fretwell helpfully suggested at Govfresh that other government agencies work to avoid next time.

Today, as Fretwell first reported, the federal government launched a new repository for tracking issues on USASpending.gov on Github, the social coding site that’s become an increasingly important platform for 18F, which committed to developing free and open source software by default last year.

In an email to the White House’s open government Google Group, Corinna Zarek, the senior advisor for open government in the Obama administration, followed up on earlier concerns about the redesign:

The USAspending team has been working to improve the usability of the site and has made some great strides to make it easier for average citizens to navigate information. But at the same time, we all understand that some of our expert users (like a lot of you) seek more technical information and the team is striving to meet your needs as well.

This is definitely a work in progress so please keep working with the team as it iterates on the best ways to improve function of the site while maintaining the content you seek. Your initial comments have been really helpful and the USAspending team is already working to address some of them.

Zarek also said that several of the problems with data that people have reported been addressed, including the capacity to download larger data sets and define specific dates in search, and asked for more feedback.

Specifically, this week the team addressed data export issues to allow the ability to specify date ranges to download data, added the bulk file format API, and modified the download capability so larger datasets can be downloaded. Additionally, data archives are being added continually. This week, they loaded the 2014 and 2015 delta files that show the new transactions in the last month. You can keep track of the ongoing improvements on the “What’s new” page.

Please keep sharing your feedback and continue working with the USAspending team as it makes improvements to the site. You can do this through the site’s contact page or on the new Github page where you can report issues and track them in the open.

If you find bugs, let the feds know about them on Github so that everyone can see the issues and how they’re addressed. As Mollie Walker reported for FierceGovernmentIT, there’s still missing functionality yet to be restored.

[Image Credit: Govfresh, via USASpending.gov]