One of the important changes occurring across the federal government is the role of open source for non-code projects - using an open, iterative model of collaboration inherited from the coding community for all kinds of new purposes. Want to see a great example of this in action? In recent years, as more and more agencies offer public APIs, some have included a developer terms of service (TOS).
This document helps to frame expectations, rights, and responsibilities for any developers who want to use a specific API. Rather than re-invent the wheel, agencies are encouraged to look at existing examples from their sister agencies and repurpose existing language. But that also means that there may be a need for new thinking about the clauses that make up the relationship agencies set up with outside developers.
Agencies are now taking the next step to collaborate on a model terms of service that reflects the best practices and up-to-date thinking of the developers that are the target audience of government APIs. A robust discussion is ongoing and a range of options will be available to agencies to use. Some contributors evolved the conversation further, urging the use of an API service accord in the place of a terms of service.
If you’re a developer who uses APIs of any kind - government-produced or not - please share your thoughts on how agencies can optimize their developer experience and keep improving their APIs. API usability is a core value here at 18F but we need your help, so keep the feedback coming.