The activity on Stack Apps has dwindled noticeably; this might be a topic for its own discussion, however I'd like to revisit the API roadmap beforehand to set a proper stage and expectations in this regard. 

## Status

I'll try to summarize the API status from my perspective, which might be a little biased regarding my own interest in the Stack Exchange platform, which, despite being a very happy Stack Overflow user myself, has always been integration with other platforms I'm involved with (partially with commercial interest, i.e. turning a solution into a product I could live from developing); so please take my statements with a grain of salt.

### Bugs / Feature Requests

There have been [141 bugs][1] posted, with [100 completed][2], [23 bydesign][3], [7 norepro][4] and [2 deferred][5], leaving 11 unaddressed so far, which isn't nice, but all in all bugs have been handled properly and promptly so far.

On the other hand there have been [118 feature-requests][6] posted, with only [23 completed][7], [3 bydesign][8], [20 declined][9], [12 deferred][10] and [4 planned][11], so a whopping 56 are not even acknowledged/classified officially as of today. (Note that a couple of feature requests are covered in [API V2 Musings: What would you like to see][12] as well.)

### API / App Promotion

After announcing the [Stack Exchange API Contest Winners][13] there haven't been much promotional activities, *as far as I know*; it seems particularly worrying that respective inquiries do not even get any comment from the authorities, see [Is it possible to have a StackApps Advertising - Sidebar contest?][14].

### Legal Issues

There are still no *API Terms of Service* and I haven't gotten any kind of feedback regarding this on several channels, see e.g. [Where can I find the “API Terms of Service” referred to from the legal pages?][15]

### Summary
The outlined partial (or rather selective) lack of feedback can be seen on [MSO][16] as well, but I think it is even more of a problem for API/App developers, who need to decide whether and how to deal with their own app user base and roadmap in this regard; this is a rather huge impediment for anybody considering investments into App development from a professional perspective (i.e. time/money), I'm afraid.

But enough regarding orphaned topics, let's move on to those where official statements/hints are available at least and try to figure out some ideas on how to accelerate API/Apps development from here, eventually:

## Official Statements/Hints

The design goals for the API v1, specifically the read only restrictions are covered in Jeffs blog post [Stack Exchange API Public Beta Starts][17]:

> **Version 1 is read only**. Coming up with
> a solid API is hard enough without
> adding writing and authentication to
> the mix. For the initial release, it’s
> a read-only API. We’ll take on the
> much more challenging problem of
> writing (and authentication) in v2.

Likely it has been this statement which introduced the theme of tying the API v2 with *writing (and authentication)*.

A more recent and granular update regarding this has been [Kevins answer][18] to [Timeline for v2.0 of the API?][19], which added bugs and improvements to the API v2 theme:

> [...] defects in v1.0. Part of v2.0 would be
> addressing these issues [...]  
>
> Another part of v2.0 would be bringing
> the API into line with the improvements made on the sites. [...]  
>
> Finally, since we've implied - though not quite promised - write access in
> v2.0 the exact mechanisms for that
> need to be worked out. [...]

Back then I already asked *have you considered a more agile approach of progressive improvement instead*, but haven't gotten any response, hence the revisit here ...

### Jeffs Code Camp Video Interview

Recently I've fast forwarded through [Jeffs Interview][20] to get some clues eventually, and actually did - please see [Selective API oriented transcript fragment of Jeffs Code Camp Video Interview][21] for a bit more context, but essentially Jeff is expressing **serious doubts about the feasibility of a write enabled API**:

> Yeah, the UI is helping [...] there's
> a lot of ambient information present
> on the website, how would that even be
> presented in an external app we can't
> control? I'm fine with reading [...]
> but one of the quickest way to ruin a
> Q&A system is to flood it with bad
> questions - now I'm not sayin having a
> write API would cause that, but
> anything that risks that is a very
> very serious risk.

I actually agree with his observations, he definitely has a point in that a writable API could exhibit quality issues and a *rich ajax app* offering much better UI options to deal with this (an interesting variation of the same old argument between *rich clients* vs. *web apps* in general btw.).

Still, this puts a serious bump into the current expectations among Stack Apps developers, I'm afraid, in so far *writing (and authentication)* have been the number one feature request, obviously. However, this shouldn't provide a full stop to API development forever, or should it?

I'd rather say it is a strong hint towards a necessary *shift in pace and scope* in order to let the API evolve *more* agile with the platform as best as possible under the current read only restriction. I'd personally pretty much prefer an API keeping track of *essential and stabilized* platform improvements (e.g. [Linked Questions][22], [Tag Wikis][23], [Tag Info Pages][24] etc.) over waiting for the golden age of *writing (and authentication)*, which apparently isn't going to happen anytime soon, if ever.

**What do you think?**


  [1]: http://stackapps.com/questions/tagged/bug
  [2]: http://stackapps.com/questions/tagged/bug+status-completed
  [3]: http://stackapps.com/questions/tagged/bug+status-bydesign
  [4]: http://stackapps.com/questions/tagged/bug+status-norepro
  [5]: http://stackapps.com/questions/tagged/bug+status-deferred
  [6]: http://stackapps.com/questions/tagged/feature-request
  [7]: http://stackapps.com/questions/tagged/feature-request+status-completed
  [8]: http://stackapps.com/questions/tagged/feature-request+status-bydesign
  [9]: http://stackapps.com/questions/tagged/feature-request+status-declined
  [10]: http://stackapps.com/questions/tagged/feature-request+status-deferred
  [11]: http://stackapps.com/questions/tagged/feature-request+status-planned
  [12]: http://stackapps.com/questions/751/api-v2-musings-what-would-you-like-to-see
  [13]: http://blog.stackoverflow.com/2010/08/stack-exchange-api-contest-winners/
  [14]: http://meta.stackoverflow.com/questions/67272/is-it-possible-to-have-a-stackapps-advertising-sidebar-contest
  [15]: http://meta.stackoverflow.com/questions/56349/where-can-i-find-the-api-terms-of-service-referred-to-from-the-legal-pages
  [16]: http://meta.stackoverflow.com/
  [17]:  http://blog.stackoverflow.com/2010/05/stack-exchange-api-public-beta-starts/
  [18]: http://stackapps.com/questions/1074/timeline-for-v2-0-of-the-api/1076#1076
  [19]: http://stackapps.com/questions/1074/timeline-for-v2-0-of-the-api
  [20]: http://blog.stackoverflow.com/2010/10/code-camp-video-interview/
  [21]: http://stackapps.com/questions/1803/selective-api-oriented-transcript-fragment-of-jeffs-code-camp-video-interview
  [22]: http://stackapps.com/questions/1348/add-linked-question-data-to-the-api
  [23]: http://blog.stackoverflow.com/2010/08/tag-folksonomy-and-tag-synonyms/
  [24]: http://blog.stackoverflow.com/2010/08/new-tag-info-pages/