Quick 2 question survey

[Gray Brooks]

Hi folks,  

Can you take a second and respond - either for your self or any other agencies you know of:  

• Using a pay model for API services they offer
• Offering a service-level agreement (SLA)

In addition to any examples, any thoughts about this?  Of course the default is free, but I think there's a place for pragmatic use of either or both of these.  It's come up a few times lately and it'd be great for us to know of any precedence.  

Thanks a bunch and please do respond with any thoughts.  

Gray 

[Luke Fretwell]

Great topic, Gray. I'm not with an agency, but here's my .02.

My default answer to this is no, that we should treat it much like we do other public goods. Just like any venture, government agencies need to reconfigure their budgets and IT operations to provide a public API offering. In this day and age, government needs to take into account that data and APIs are a twenty-first century public offering. If agencies are trying to justify data/APIs from a budgetary perspective, the first step would be to reallocate funding priorities and eliminate antiquated services these offerings replace.

Pay for the data, streamline IT processes that make it easier and cheaper to publish data, eliminate outdated operations they replace and empower third-parties to leverage that data and provide more market-based public services. If we’re going to start charging for data/APIs, we need to first do a holistic assessment of what the ecosystem looks like if we’re going to innovate our thinking around it, as opposed to looking at it from a micro perspective.

I can see in high-usage cases where there may be some merit to charging for data usage, but we’re still a long ways away from that discussion. Let’s innovate first before jumping into pay-for-use fees.

Thank you for letting me share.

[Christopher Murphy]

Gray,

I am not aware of any fees for any APIs.

It is not clear how an SLA would be enforceable.

I would hope that anyone depending on a .gov API would remember the recent budget issues and plan accordingly.

Chris

[Hyon Kim - XI]

If you really wanted to look into it you'd want to consult your administrative law specialist (see this statutory provision.) If you look at the CFR tab, it appears that establishing user fees could also entail rulemaking.

Hyon

--
Hyon Kim

Deputy Program Director

Data.gov

(202) 694 8148

[Lily Bradley]

Gray: 

I am not aware of any user fees being charged for APIs at HHS. However, HHS charges for data when legally obligated (e.g., FOIA requests, CMS restricted data). 

There could be tremendous value in charging for data services, if it meant that those fees could be used to sustain, expand, improve those services (i.e., an "investment" in the public good). However, CMS data fees, for example, are not returned to the business unit that handles data dissemination (OIPDA). 

What I understand from an online appropriations law course is that: 

1. Congress controls the purse. 

2. Congress is conscientious of maintaining that budgetary control. 

3. So the Legislature does not want executive agencies going and raising money, by collecting fees, to support things that Congress has not authorized them to. 

• PDUFA is actually a great example of where Congress did authorize FDA to collect user fees to accelerate new drug approval applications.
  
• One could hypothesize about scenarios where Congress might defund, or limit funding of an activity (food stamps or data liberation). 
• Admittedly, it seems difficult to know at times when authorization or lack thereof, is deliberate or unintentional. 

4. I think the folks at NTIS might be helpful. http://www.ntis.gov/about/index.aspx#statutes They are a clearinghouse for some data, such as the Master Death File, which charges a subscription fee as required by statute. The subscription may have analogous characteristics to an API.

Hope you are successful in moving this conversation forward. Let us know if you need evidence or potential user cases to help make the business case. 

Best, 

Lily

(HHS)

[Luke Fretwell]

Additional thoughts from Kin/Mark:

• http://civic.io/2014/03/07/apis-to-charge-or-not-to-charge/
  
• http://apievangelist.com/2014/03/07/a-better-understanding-of-government-apis-and-their-consumers-before-considering-charging-for-use/
  

On Thursday, March 6, 2014 11:06:19 AM UTC-8, Gray Brooks wrote:

[Noah Kunin]

On payments, I can't see any pay-for-use rationale at the moment. I do see use cases for "pay-for-infrastructure", sort of akin to Twitter firehouse access. But to underline points below, let's get clients who are demanding that level of access before we figure that part of the model out.

For SLAs, I don't know what that would mean in an API context. The rate limit and endpoints form a much more concrete SLA than could ever be put on paper. If a client needs more than that, well, see above.

If I put on my API consumer hat, here are the things I want as opposed to a SLA.

Who/how...

• ...do I contact if something is broken? 
• ...if I have an idea for something new?
• ...if I have general inquiries?

[Eric Mill]

It's hard to come up with a blanket rule that covers all possible APIs -- "API" is an overloaded term that can mean just about anything that computers do on the web.

Metering access to public information has serious problems. So many applications of public datasets require first obtaining the entire dataset (not just a way to plug in to an API), and so if bulk data isn't offered, then the API becomes the bulk data source. 

A year ago, GPO was nudged by NAPA to consider user fees, and I wrote for Sunlight about the harm this could bring. There's no such thing as a small fee when multiplied by millions of requests. If the Federal Register API charged per-query, it would be expensive even to experiment with the activity of the executive branch.

A more classic example is PACER. Using PACER to find a court docket and download public records -- and watching your bill skyrocket as you **navigate search results** -- is enough to put anyone in a righteous rage. But the real problem is not just PACER's particularly hostile metering approach - it's that now that their budget is defined by user fees, they now have to vigorously defend their fees to defend their budget. It completely misaligns their incentives to serve the public, and causes them to see their true audience as whatever their current (well-budgeted) customers are.

And that to me is the real problem with charging for public data - even if you make a pricing plan that feels accessible to your current audience, today, you're willingly putting blinders on, and creating an engine whose future evolution is difficult to predict and that will be very hard to turn off.

Other kinds of APIs - infrastructural stuff, like the firehose example Noah mentioned, or specialized service delivery, are more complicated questions. No matter what kind, it certainly seems like everyone is saying "think very carefully first".

-- Eric

--

Developer | sunlightfoundation.com

[Charles Worthington]

Dept. of Energy has a small number of APIs with paid tiers and/or "usage fees" or "licensing fees." So far as I know, all of these were built by and are operated by a National Lab or other contractor. One example I can think of is the Home Energy Score Tool API: https://developers.buildingsapi.lbl.gov/hescore/documentation/licensing. In practice I don't think there are many users of this API, but it's at least one example I could find.

I commonly hear program managers worry that by investing in creating a dataset or tool and providing API access to the data, that they are basically committing to some ongoing cost to maintain the service in perpetuity. I don't think this fear is unreasonable. The idea that large users/businesses that directly benefit from these APIs could help defray this cost is appealing to these managers.

I have very mixed opinions on whether this is a good idea. But even if I was fully on board with the idea of charging a usage fee I would strongly advocate for a completely self-provisioned sign up process and a generous free tier (capped by total calls per month or by rate limiting) that makes it totally free to get started with the API in a matter of minutes. That's a best practice in the commercial API space.

[Sean Herron]

I have mixed opinions on this as well. I'd be interested in hearing what NIH or Census have to say on this matter, as I know their APIs are pretty heavily used. I think it's also reasonable to say that if the alternative to producing an API is offering bulk download of the data that one could realize significant cost savings through reduced bandwidth, as you are no longer paying to deliver the entire dataset to every user who requests it, but rather just relevant portions that they query.

I also think it's reasonable to put some sort of upper cap on queries within a time period and request that users who need more than that are caching as much as they can locally. The vast majority of datasets we're releasing don't have updates so frequently that caching isn't a realistic option.

[Josh Tauberer]

On 03/14/2014 11:26 AM, Charles Worthington wrote:

The idea that large users/businesses that directly benefit from these APIs could help defray this cost is appealing to these managers.

One more perspective- In the open data world, especially internationally, it's generally accepted that gov can charge for the marginal cost of reproducing a record. If it costs 5 cents to photocopy a page for a FOIA request, then most people agree that in many circumstances that cost can be passed on to the requestor. But fixed operating costs of FOIA itself should not be spread across requestors. And there are exemptions so that journalists etc. don't have to pay or pay as much.

For APIs, the marginal cost of an API call is, maybe, the proportion of the server expenses used up by that call. At scale that may not be negligible, and it's probably perfectly fair to start charging users that use significant resources the marginal cost of their API calls, especially if there are the same sorts of fee waivers as with FOIA.

So maybe there's a carve-out there for cases where agencies can charge that isn't too controversial: marginal cost with fee waivers in the same spirit as FOIA.

- Josh Tauberer (@JoshData)

http://razor.occams.info

[Ian Kalin]

Good afternoon, 

I have an international perspective to share on this topic.  Apparently, the French national government charges for a great deal of their APIs and even the most popular open data sets.  When I suggested that the government should give these away from free, it was the crowd of Developers that protested.  Saying (through translation) that if the data was freely availalble, the quality would inevitably go down.  Dependencies had been built on high-quality data and this crowd (was at the Numa innovation center) couldn't imagine not paying.

Of course, there are a number of factors that differentiate this scenario from the U.S.  But it was still illuminating for me.

Ian

[Kin Lane]

That is very illuminating Ian. Interesting how other countries view these resources.

I'm having a civic workshop and separate session at #APIStrat in Amsterdam in two weeks.

I have Dutch and Finnish city open data folks, I will pose the topic there. 

Kin Lane (API Evangelist)

kin...@gmail.com

@kinlane

--

apievangelist.com

apicommons.org

apivoice.com

--

[Kin Lane]

Another interesting lense to look at APIs through -Data at rest is free, data in motion costs money
- http://blog.thestateofme.com/2014/03/14/data-at-rest-is-free-data-in-motion-costs-money/

[Hale, David (NIH/NLM) [E]]

I see data quality as a requirement of data provision. If you’re going to release data and encourage people to build useful things, you are obligated to aggressively address data quality issues. Additionally, providing data without addressing the nuances or subject matter expertise required to utilize it severely limits the potential impact.

My data responsibilities, as stated in my PMAP, are bottom-to-top: data acquisition, restructuring, meaningful access via development of search classes/engine, provision via API and downloads, AND data quality. I think this type of vertical integration is necessary during the early stages of opening data. Perhaps later, once this ecosystem is more self-sustaining and the cultural issues have been addressed, it will transition to a more horizontal structure, with external stakeholders taking a greater role and government acting more as a data steward.

As for ongoing budgetary issues, in my experience the vast majority of resources and headaches focus on 1) meaningful access via development of search engines/classes that incorporate the subject matter expertise of an agency and 2) data quality, which usually has to be addressed both systemically and culturally, frequently with external stakeholders. Not surprisingly, these are the areas that are most inherently governmental.

David

David Hale
Project Manager, Pillbox
National Library of Medicine
National Institutes of Health

From: Ian Kalin <ianj...@gmail.com<mailto:ianj...@gmail.com>>
Date: Friday, March 14, 2014 at 4:01 PM
To: Sean Herron <seanh...@gmail.com<mailto:seanh...@gmail.com>>
Cc: Charles Worthington <c.e.wor...@gmail.com<mailto:c.e.wor...@gmail.com>>, "us-govern...@googlegroups.com<mailto:us-govern...@googlegroups.com>" <us-govern...@googlegroups.com<mailto:us-govern...@googlegroups.com>>
Subject: Re: Quick 2 question survey

Good afternoon,

I have an international perspective to share on this topic. Apparently, the French national government charges for a great deal of their APIs and even the most popular open data sets. When I suggested that the government should give these away from free, it was the crowd of Developers that protested. Saying (through translation) that if the data was freely availalble, the quality would inevitably go down. Dependencies had been built on high-quality data and this crowd (was at the Numa<https://www.numaparis.com/> innovation center) couldn't imagine not paying.

Of course, there are a number of factors that differentiate this scenario from the U.S. But it was still illuminating for me.

Ian

On Fri, Mar 14, 2014 at 8:33 AM, Sean Herron <seanh...@gmail.com<mailto:seanh...@gmail.com>> wrote:
I have mixed opinions on this as well. I'd be interested in hearing what NIH or Census have to say on this matter, as I know their APIs are pretty heavily used. I think it's also reasonable to say that if the alternative to producing an API is offering bulk download of the data that one could realize significant cost savings through reduced bandwidth, as you are no longer paying to deliver the entire dataset to every user who requests it, but rather just relevant portions that they query.

I also think it's reasonable to put some sort of upper cap on queries within a time period and request that users who need more than that are caching as much as they can locally. The vast majority of datasets we're releasing don't have updates so frequently that caching isn't a realistic option.

On Fri, Mar 14, 2014 at 11:26 AM, Charles Worthington <c.e.wor...@gmail.com<mailto:c.e.wor...@gmail.com>> wrote:
Dept. of Energy has a small number of APIs with paid tiers and/or "usage fees" or "licensing fees." So far as I know, all of these were built by and are operated by a National Lab or other contractor. One example I can think of is the Home Energy Score Tool API: https://developers.buildingsapi.lbl.gov/hescore/documentation/licensing. In practice I don't think there are many users of this API, but it's at least one example I could find.

I commonly hear program managers worry that by investing in creating a dataset or tool and providing API access to the data, that they are basically committing to some ongoing cost to maintain the service in perpetuity. I don't think this fear is unreasonable. The idea that large users/businesses that directly benefit from these APIs could help defray this cost is appealing to these managers.

I have very mixed opinions on whether this is a good idea. But even if I was fully on board with the idea of charging a usage fee I would strongly advocate for a completely self-provisioned sign up process and a generous free tier (capped by total calls per month or by rate limiting) that makes it totally free to get started with the API in a matter of minutes. That's a best practice in the commercial API space.



On Thursday, March 6, 2014 2:06:19 PM UTC-5, Gray Brooks wrote:
Hi folks,

Can you take a second and respond - either for your self or any other agencies you know of:

* Using a pay model for API services they offer
* Offering a service-level agreement (SLA)

[Philip Ashlock]

The only justification I can think for charging for API use is if it was to exceed a rate cap that would otherwise restrict other people's use of the API. In other words, if an API provider has a set amount of bandwidth and server capacity and one user is consuming 99% of that, then you'd want rate limiting in place to ensure that everyone has more equitable access. Charging could be a way of surpassing the normal rate limiting and passing on that additional cost to the relevant users (at cost).

I don't think you could really ever justify charging for API access without first making bulk data available for free on a regular basis.

In most cases, I don't think there's a justifiable cost recovery model if tax payers already paid for the data collection and providing it via API is cheaper than FOIA processing. For the most part the amount of overhead to handle payment processing in government is probably a little overbearing as well, so it might be difficult to really pass on the cost at a reasonable rate while actually recovering cost in government.

If a government API is at risk of needing to implement rate limiting it could probably ensure a basic quality of service to some syndicators that could provide heavier levels of use and manage their cost recovery and business model however they see fit. This is already generally the norm for transforming government data into more useable forms.

Depending on the data involved, I think there will be varying levels of sensitivity to equitable access and the need for government to provide resources to meet demand versus allowing paid privileged access or private companies to fill the gap.

Most of this assumes we're talking about read-only data. For write APIs, I think government should generally encourage that and I think you could usually argue that third party services built around write APIs will save government money - although they might not always save citizens money

[Gray Brooks]

FYI - Good coverage from Alex Howard of the issues being thought through in this thread.  

Gray 

On Monday, March 17, 2014 1:36:40 PM UTC-4, Philip Ashlock wrote:

The only justification I can think for charging for API use is if it was to exceed a rate cap that would otherwise restrict other people's use of the API. In other words, if an API provider has a set amount of bandwidth and server capacity and one user is consuming 99% of that, then you'd want rate limiting in place to ensure that everyone has more equitable access. Charging could be a way of surpassing the normal rate limiting and passing on that additional cost to the relevant users (at cost).

I don't think you could really ever justify charging for API access without first making bulk data available for free on a regular basis.

In most cases, I don't think there's a justifiable cost recovery model if tax payers already paid for the data collection and providing it via API is cheaper than FOIA processing. For the most part the amount of overhead to handle payment processing in government is probably a little overbearing as well, so it might be difficult to really pass on the cost at a reasonable rate while actually recovering cost in government.

If a government API is at risk of needing to implement rate limiting it could probably ensure a basic quality of service to some syndicators that could provide heavier levels of use and manage their cost recovery and business model however they see fit. This is already generally the norm for transforming government data into more useable forms.

Depending on the data involved, I think there will be varying levels of sensitivity to equitable access and the need for government to provide resources to meet demand versus allowing paid privileged access or private companies to fill the gap.

Most of this assumes we're talking about read-only data. For write APIs, I think government should generally encourage that and I think you could usually argue that third party services built around write APIs will save government money - although they might not always save citizens money

On Mon, Mar 17, 2014 at 11:10 AM, Hale, David (NIH/NLM) [E] <dave...@mail.nih.gov> wrote:

I see data quality as a requirement of data provision.  If you’re going to release data and encourage people to build useful things, you are obligated to aggressively address data quality issues.  Additionally, providing data without addressing the nuances or subject matter expertise required to utilize it severely limits the potential impact.

My data responsibilities, as stated in my PMAP, are bottom-to-top: data acquisition, restructuring, meaningful access via development of search classes/engine, provision via API and downloads, AND data quality.  I think this type of vertical integration is necessary during the early stages of opening data.  Perhaps later, once this ecosystem is more self-sustaining and the cultural issues have been addressed, it will transition to a more horizontal structure, with external stakeholders taking a greater role and government acting more as a data steward.

As for ongoing budgetary issues, in my experience the vast majority of resources and headaches focus on 1) meaningful access via development of search engines/classes that incorporate the subject matter expertise of an agency and 2) data quality, which usually has to be addressed both systemically and culturally, frequently with external stakeholders.  Not surprisingly, these are the areas that are most inherently governmental.

David

David Hale
Project Manager, Pillbox
National Library of Medicine
National Institutes of Health