_posts/2014-04-11-open-source-terms-of-service-a-better-developer.md
---
layout: post
date: '2014-04-11T11:07:00-04:00'
tumblr_url: http://18fblog.tumblr.com/post/82388500373/open-source-terms-of-service-a-better-developer
title: "Open source and terms of service = a better developer experience"
description: "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)."
excerpt: "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)."
image:
authors:
- gray
tags:
- api
- best practices
- open source
- how we work
---
One of the important changes occurring across the federal government is
the role of [open source for non-code
projects](http://ben.balter.com/2014/01/27/open-collaboration/) - 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](https://www.data.gov/developers/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](https://github.com/18F/API-All-the-X/blob/master/developer_hub_kit.md#terms-of-service)
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](https://github.com/GSA/API-Resources/issues/1)
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](http://apievangelist.com/2014/03/14/api-service-accord/).
If you’re a developer who uses APIs of any kind - government-produced or
not - please [share your
thoughts](https://github.com/GSA/API-Resources/issues/1) 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.