Digital democracy reforms tends to advance or retreat in fits and starts, but when exigent circumstances require more from us and our governments, change can happen unexpectedly. On May 26, I requested an absentee ballot, intending to cast my vote … Continue reading
On 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.
There are roughly 1,361 .gov domains* operated by the executive branch of the United States federal government, 700-800 of which are live and in active use. Today, for the first time, the public can see how many people are visiting 300 executive branch government domains in real-time, including every cabinet department, by visiting analytics.usa.gov.
According to a post on the White House blog, the United States Digital Service “will use the data from the Digital Analytics Program to focus our digital service teams on the services that matter most to the American people, and analyze how much progress we are making. The Dashboard will help government agencies understand how people find, access, and use government services online to better serve the public – all while protecting privacy. The program does not track individuals. It anonymizes the IP addresses of all visitors and then uses the resulting information in the aggregate.”
On Thursday morning, March 19th, tax-related services, weather, and immigration status are all popular. Notably, there’s an e-petition on the White House WeThePeople platform listed as well, adding data-driven transparency to what’s popular there right now.
Former United States deputy chief technology officer Nick Sinai is excited about seeing the Web analytics data opened up online. Writing for the Harvard Shorenstein Center, where he is currently a fellow, Sinai adds some context for the new feature:
“Making government web performance open follows the digital services playbook from the new U.S. Digital Services,” he wrote. “Using data to drive decisions and defaulting to open are important strategies for building simple and useful citizen-facing digital services. Teal-time and historical government web performance is another example of how open government data holds the promise of improving government accountability and rebuilding trust in government.”
Here’s what the U.S. digital services team says they’ve already learned from analyzing this data:
Here’s what we’ve already learned from the data:
- Our services must work well on all devices. Over the past 90 days, 33% all traffic to our sites came from people using phones and tablets. Over the same period last year, the number was 24%. Most of this growth came from an increase in mobile traffic. Every year, building digital services that work well on small screens becomes more important.
- Seasonal services and unexpected events can cause surges in traffic. As you might expect, tax season is a busy time for the IRS. This is reflected in visits to pages on IRS.gov, which have more than tripled in the past 90 days compared with the previous quarter. Other jumps in traffic are less easy to predict. For example, a recently-announced settlement between AT&T and the Federal Trade Commissiongenerated a large increase in visits to the FTC’s website. Shortly after the settlement was announced, FTC.gov had four times more visitors than the same period in the previous year. These fluctuations underscore the importance of flexibility in the way we deploy our services so that we can scale our web hosting to support surges in traffic as well as save money when our sites are less busy.
- Most people access our sites using newer web browsers. How do we improve digital services for everyone when not all web browsers work the same way? The data tells us that the percentage of people accessing our sites using outdated browsers is declining steadily. As users adopt newer web browsers, we can build services that use modern features and spend less time and money building services that work on outdated browsers. This change will also allow us to take advantage of features found in modern browsers that make it easier to build services that work well for Americans with disabilities, who access digital services using specialized devices such as screen readers.
If you have ideas, feedback or questions, the team behind the dashboard is working in the open on Github.
Over the coming months, we will encourage more sites to join the Digital Analytics Program, and we’ll include more information and insights about traffic to government sites with the same open source development process we used to create the Dashboard. If you have ideas for the project, or want to help improve it, let us know by contributing to the project on GitHub or emailing digitalgov@gsa.gov.
That last bit is notable; as its true all of the projects that 18F works on, this analytics dashboard is open source software.
There are some interesting additional details in 18F’s blog post on how the analytics dashbard was built, including the estimate that it took place “over the course of 2-3 weeks” with usability testing at a “local civic hacking meetup.”
First, that big number is made from HTML and D3, a Javascript library, that downloads and render the data. Using open standards means it renders well across browsers and mobile devices.
Second, 18F made an open source tool to manage the data reporting process called “analytics-reporter” that downloads Google Analytics reports and transforms that data into JSON.
Hopefully, in the years ahead, the American people will see more than the traffic to .gov websites: they’ll see concrete performance metrics like those displayed for the digital services the United Kingdom’s Government Digital Services team publishes at gov.uk/performance, including uptime, completion rate and satisfaction rate.
In the future, if the public can see the performance of Heathcare.gov, including glitches, or other government digital services, perhaps the people building and operating them will have more accountability for uptime and quality of service.
E Pluribus Unum 