History and future of open source at CFPB

At CFPB, we develop nearly all of our software publicly on GitHub and release it under a Public Domain/CC0 license. We adopted this policy in order for taxpayers to benefit from the products they pay for, to provide a window into how our agency conducts business, and to increase the quality of our source code through contributions from the wider development community.

Since 2012, we have seen the benefits of an open source by default policy in the following outcomes:

Open source software development has been critical at CFPB since we opened our doors. In April 2012, just nine months after the Bureau opened, we released our Source Code Policy, based on the work of the Department of Defense, along with our first two open source projects. Just six days later, we accepted our first pull request from a member of the public.

Our approach to open source in these early days was to publicly release small bits of source code that had potential for wider application. In November of 2012 and January of 2013, our first class of design and development fellows began working at the Bureau. Two of the projects that were developed by this initial class of fellows, the open data platform Qu and eRegulations, set a new precedent: they were developed from day one entirely in the open on GitHub. Shortly afterwards, we formed an open source working group, which worked to put procedures in place for open sourcing code that was only available internally. As more code was moved to the public, the team moved towards a policy of open source by default, where source code is developed in private only in certain well-defined cases, including security risks or when the license is restricted.

With an open source by default policy in place, we’ve been able to collaborate with other government agencies and the public at hackathon events where designers and developers come together to work on open source software:

  • CFPB staff have been present at National Day of Civic Hacking events in 2013, 2014, and 2015, working with developers to create data visualizations using the Consumer Complaint Database and Home Mortgage Disclosure Act data.
  • Software developers from 18F’s eRegs team attended the General Services Administration’s GovTechHack in 2015, where they focused on improving the software’s local setup process. They succeeded in decreasing the setup time for eRegs from 2 hours to 15 minutes.
  • CFPB Developer Catherine Farman gathered a team of designers and developers to contribute to the Owning a Home website at LadyHacks.

These experiences led us to create internal guidelines for attending these events and sharing our work to get developer contributions at them. Though we’ve come a long way in the way we approach open source, we are continually seeking to improve by:

  • Ensuring our project setup documentation is up to date by holding regular README Refresh Days.
  • Sharing our experiences with our fellow federal agencies and learning from them too, so we can incorporate their efforts into our own process.
  • Educating developers about CFPB’s open source projects and data sets, inspired by 18F’s data visualization workshop.
  • Increasing our community outreach by presenting our work at conferences and meetups.

In March 2016, the White House released a draft federal open source software policy for public comment. Members of the public gave feedback and suggested changes via GitHub.com. To date, the public has contributed 20 merged pull requests and over 200 discussion threads.

If you have thoughts about how we can or other federal agencies might continue to evolve our approach to open source software, we’d encourage you to discuss the Federal Open Source Policy on GitHub.