Gabe Wachob

Please Vote Tomorrow, November 4, 2008

If you haven't already voted, and you are an American citizen, please vote tomorrow.

 I support Barack Obama and would ask you to vote for him too.

If you care about equality, fairness, and the foundations of liberty that this country was built on, I would also ask you, as a Californian, to vote no on Prop 8, a heinous proposition that would encode bigotry and hate into the California Constitution by stating that currently legal marriages will no longer be performed simply because they don't fit someone's religiously-based definition of marriage. It wasn't that long ago that marriage between people of different races was illegal. However, it is now hard to fathom how  such discrimination was considered acceptable in civil society. The discrimination behind Prop 8 is no different, and history will judge us harshly if we legalize and enforce that sort of bigotry again. I strongly urge you, for the good of your own personal liberty, and for the protection of our nation's tradition of equality, to vote NO on Prop 8.

Thanks for listening, and please go out and vote.

My Tweet-Summary of the "Bailout Bill"

[UPDATE 10:12PM PDT: Sunlight foundation has the bill marked up in html with public commenting.]

[UPDATE 7:52PM PDT: It looks like a final draft was published, and its somewhat different from the draft I was reviewing below. Most of the comments below stand, even though the page references, and many of the specific references phrases have changed. IN particular, it appears the final draft has more language about an "insurance" program that financial institutions can participate in, in lieu of selling bad mortgages. Most of the oversight and scope of authority language seems to be the same. One notable addition is language on p.90 which calls for the president to impose a way of recovering any losses (after 5 years) from the TARP program. ]

Minutes after the first discussion draft of the "Economic Recovery and Corporate Accountability Act of 2008" was published, I went through and reviewed all 104 pages of it. Here's a coalescing of the Tweets I produced while reading it.

• Here's the bailout bill: http://links.sfgate.com/ZEYS  
• The bill is 102 pages long. Its time to review it in detail. Potential to reshape American economy for a generation.
• I'm on page 7 of the 110 page bill. I'm definitely gonna read every line of this. Its times like this I'm glad I went to law school ;)
• @schnaars What's amazing is the massive power that the Treas. Secty is granted. The choice of prez has very *real* short term impact.  in reply to schnaars
• I think this grants more power to the executive than even the (awful) PATRIOT act. I'm not sure its avoidable, though.
• I really want to ensure is that the transactions the TARP envisions are transparent - there are reporting requirements in there (p17-18)
• hmm, at least 20% of profits from sales of assets are to go 65/35 into Housing Trust Fund, Capital Magnet Fund - what are these? #bailout
• So far (as of page 24), nothing about Secty of Treasury *forcing* mortgage lenders to modify loans to avoid foreclosures #bailout
• Any wiki for comments on the bailout bill? Someone want to htmlize and wikify it? #bailout #tarp
• BTW, the bill proposal is titled "Economic Recovery and Corporate Accountability Act of 2008" #bailout
• The main program in the bailout bill is the "Troubled Assets Relief Program" #bailout #tarp
• Not that it will change it, but could we put a thousand eyeballs to make any bugs shallow in the bailout bill?? #bailout
• Apparently the secty only has power to prevent foreclosures *as an investor* - no special power: .#bailout
• "The Secretary shall request (mortgage loan servicers) to avoid preventable foreclosures, to the greatest extent possible" - p. 24 #bailout
• p37: The Secty shall make available to the public, in electronic form, a description, amounts, and pricing of assets acquired #bailout
• p39: Congress can basically put the brakes on after $350B if they pass a joint resolution- and there's rules about fast tracking it #bailout
• Dammit, @donlemoncnn, when it comes to $700B, there's no such thing as "fine print"!!!
• p44 The GAO also shall audit the program (in addition to the oversight board). #bailout
• p. 54 Wow, the standard for judicial review is "arbitrary". Wow. Wow. Wow. That means almost no judicial review at all. #bailout
• p. 55 Wow, the Secty's authority terminates at the end of 2009, unless extended. Thats awfully short time window. Is that enough? #bailout
• p. 63: Statutory limit on public debt increased to $11.315 Trillion. Whoa. Currently (I think) $8.184 Trillion. Big jump. #bailout
• 65 Some changes in foreclosure rules which I don't understand out of context. #bailout
• p.69 Congressional oversight as well (3rd independent oversight function, afaict) #bailout
• p.74 Some enhancements to the power of regulatory agencies (FDIC in particular) #bailout
• @Ross Like many sunset provisions, it is dual-edged. Keeps it politicized, but also keeps it in check. Probably good idea bcuz of the rush.  in reply to Ross
• p.82 Some stuff about the fed making emergency loans and having to report to Congress about such activities #bailout
• p.86 Title 3 of the act is about budget planning around the TARP (title 2 was defining TARP itself). #bailout
• p.86 Title *2* is the budget-related provisions, Title *1* is the TARP program, and TItle *3* (p 91) is tax implications (of course!) #bailout
• The title 3 tax provisions are complicated. It looks like some stock sales are treated as ordinary, not capital income. Needs revu #bailout
• p.94 The tax provision which limits tax deduction for salaries over $400k, some language about golden parachutes, needs more revu #bailout
• @Radu43 I think its pretty radical, but I'm not sure there's practically a better way. The treasury secty *needs* a lot of discretion.  in reply to Radu43
• p. 102 has text which I *think* extends until 2010 provisions which may exclude from taxable income forgiven debt on a foreclosure #bailout

As I noted, I'm looking for a better place to post these notes, (ie a wiki) where the markup and feedback can more collaboratively edited. Looks like the good folks at Sunlight Foundation are  going to put it up at the Open House Project based on the final draft of the bill (which has been published).

First Stab: Guiding Principles for the Open Web Foundation

[Update 2008-07-27 9:47PM: These principles are up on a wiki and being edited there]

The OWF is an organization to facilitate community efforts to create technical specifications that conform to the ethos that anyone can use the specification and nobody “owns” the specification or its ideas.

Towards that end, the following principles guide work in the OWF:

• All specifications produced by OWF groups should be clear of IPR encumbrances (patent, copyright, trademark, etc)
• All participants contributing to specifications are acting as individuals, but both organizations and individuals may contribute IPR.
• Anyone can participate in specifications work in any group in the OWF, so as long as they are not disruptive and are active contributors.
• Working groups are free to manage themselves so long as they adhere to OWF Way.
• It is the OWF’s goal to create as large an intellectual playing field for implementers free from IPR constraints as possible. The OWF working groups should make decisions about which IPR contributions to accept with this in mind.
• All specifications should be created in a meritocratic and transparent manner
  • All contributions should be judged on technical merit, and not on the identity of the contributor or their position in the community
  • Specifications efforts need not be democratic, but they should be run on rough consensus, with “running code” having special significance (nod to rough consensus/working code)
• All specification work must be clearly documented with a clear audit trail of IPR contributions
• All specification work must be done under the IPR rules of the OWF
• All OWF groups must operate in a manner which maximizes diverse participation across geography, wealth, language, and participant background. In particular, at a minimum, all decisions in OWF working groups (committees?) must be made in email or other asynchronous electronic means.
• There are no specific guidelines around the type of specification work that can be done in the OWF. However, the work should be technical specifications (ie not advocacy, policy, or other specifications that aren’t implementable in code)
• The OWF believes in maximizing the marketplace of ideas. Thus, the OWF does not make any judgement about the quality or market viability of the work produced in OWF working groups. It is perfectly acceptable for OWF groups to produce two specifications which overlap or compete.
• The OWF does not intend to compete with existing standards bodies, and expects work emerging from the OWF to frequently be input to work in other bodies.

Open Web Foundation

The Open Web Foundation was announced today:

The Open Web Foundation is an attempt to create a home for community-driven specifications. Following the open source model similar to the Apache Software Foundation, the foundation is aimed at building a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specification.

After my experience with helping to craft the IPR policy around OpenID, OAuth, and XRDS-Simple, along with my experience with the IPR around XRI, I've been arguing for a very lightweight organization whose simple purpose is to make it dead simple for a community of interested people to create specifications that are free from IPR (specifically patent) encumbrances as possible, but without all the extra baggage (politics, cost, process) that comes with a traditional standards body. I had been advocating making OASIS a more lightweight, and open (read: free for individuals) organization, but those suggestions didn't get enthusiastic responses.

I have a flood of thoughts, and so I'll just copy some comments I've been making on Twitter, GetSatisfaction, and the OpenWebFoundation discussion list:

  (you'll have to excuse the terseness - this is largely lifted from Twitter, where brevity is king):

•  The open web foundation is being positioned as NOT a standards body. Fine line.
•  I think the Open Web Foundation is motivated primarily by IPR hygiene concerns. Thats the main relevance that standards bodies have today. And what makes IPR hygiene more important these days is patents. Patent non-encumberance can be maximized by agreement -> coordination.
• Freedom from copyright encumberance is easy - copyrights are about tangible expressions. Patents are about abstract *ideas*. Its hard to conclusively say, ahead of time, that an idea is or IS NOT being used by a community's specmaking. Instead, agree to not sue.
• Hence, a standards body, or a "IPR hygiene" organization. An IPR DMZ.. Yah, thats it. IPR DMZ...
• A patent commons is more like a mutual defense pact. Donate your patent and we'll wield them against infiltrators.
• OWF is more about groups who want to operate under non-assertion covenants - a more passive (less friction) way of ensuring open.
• Community specs are being written outside those orgs *today* for a reason. Politics, lack of individual memberships/focus, etc
• The OWF's main distinguishing factor *must* be its lightweight-ness. Otherwise, it does become YASDO (yet another stds dev org).
• Non-assertion covenants (OWF's IPR mode of operation, I'm assuming) are to patent pools like the Nuclear Non-Proliferation Agreements are to NATO...

I made the following comment to a question about "how is this different than the w3c or ietf"?:

My guess is that for a lot of specs that need to have clean IPR hygiene, but aren't really concerned with official status (at least in the short term), the OWF will probably be the end of the line (in terms of standardization).

But for some things, you *have* to go to formal standards bodies. There are literally some orgs that can't use specs that don't come from ISO, for example.

This org is an attempt to make the mechanics of around IPR become "non issues" for communities of interest around technologies (to the extent such a community is interested in making a truly open web - if someone has patents and doesn't want to participate - there's nothing much that can be done there).

And finally my post to the google group:

An early way I'm describing the Open Web Foundation is (as Scott says) not a Standards Body, but a "IPR DMZ" - (an intellectual property rights demilitarized zone).

Most folks who are hearing about this haven't directly participated in a community standards effort, or a more formal standards body. They think the W3C/IETF/OASIS "covers it".

But I think the sense of folks here is that there needs to be something lighter weight that's only focused on the minimum needed for a spec to become widely adoptable. For me, thats IPR hygiene -- almost everything else can be done *easily* without an org (save, maybe the organizational standup of a new org to hold/manage IPR). Having slogged through this IPR policy stuff several times,I'm really happy to see this effort to create a reusable framework for community efforts. I only hope it remains lightweight and facilitates the widest range of community efforts as possible.

 I'm in #owf on irc.freenode.net (GabeW) to discuss the Open Web Foundation, if you're interested.

Announcing xrdstype.net

After a discussion this afternoon in Second Life and Skype with the dataportability folks, I decided to register a domain name called xrdstype.net and set up a registry of service types used in XRDS documents.

The idea was to create a community-neutral URIspace (registry) for URIs used as XRDS Service Type values. Christian Scholz describes the motivation for this:

One question we in the DataPortability Project had was which service types are actually already defined and what the process is to define new ones, e.g. for defining that one endpoint is data marked up in hCard and another one in FOAF. We thought that it wouldn’t be a good idea to just define URIs which belong to namespaces we don’t control and we also didn’t want to use the dataportability.org namespace as this is not part of our mission. This is true even more as the goal should be to create a general directoy of service types also for services which are outside the scope of the DataPortability project.

Gabe then proposed to register a neutral domain for it which now became xrdstype.net.The goal is to put some sort of wiki or other structure there which describes these service types and links to their definitions. This is not supposed to be a list just for XRDS-Simple of course but for the “complete” XRDS standard as well.

A couple things I want to amplify:

• Where an existing namespace exists, and the community controlling that URI space is cooperating, please use that URI space for XRDS Service Types. Some communities are understandably hostile or suspicious of the XRDS discovery model, and aren't going to cooperate. Thats in part why xrdstype.net is being created
• http://xrdstype.net should be thought of neutral infrastructure. It was created simply to provide a community-neutral place where Service Type URIs could be derived from. By community-neutral, I mean that a service type that may be usable beyond a single organizations uses can have a URI home for its service type that doesn't tie it to that organization/community.
• I'm going to be a benevolent dictator for this URI space for now. I see running xrdstype.net as an extremely ministerial task. At some point, if there's enough life in this, some appropriate group or organzation or individual(s) can take over.
• The infrastructure behind xrdstype.net will probably be a wiki - the idea here is that Service Type URLs should be resolvable to something useful by humans. Eventually there will probably also be machine-readable metadata, etc.

I haven't set any infrastructure up, but in the short term, if you'd like to use a URL under the xrdstype.net namespace, please email me with the following, which will be published at that URL:

• What path you'd like under xrdstype.net (I reserve the right to push back on this)
• A brief sentence or two describing the service
• Your email address (this will be published publicly)
• A link to more information (e.g. specs, project home page)

Eventually this information will be put on a wiki or some other page - but for now I'll manage this stuff by hand. I may be asking for help if there's serious demand for namespaces, though.

IIW2008a and BONUS: Datasharing Summit

Two can't-miss events are coming up May 12-15 at the Computer History Museum in Mountain View, California:

• The Internet Identity Workshop 2008a (http://www.windley.com/events/iiw2008a/)
• The DataSharingSummit (http://datasharingsummit.com)

This is where things happen, so you don't want to miss it. Both events will be mostly unconference-style, so you get to make the agenda. If these are new areas to you, or if you consider yourself a seasoned expert, these are best opportunities of the year to share and learn with others.

Each requires independent registration.

See you there!

P.S. If you need any more reason to come, the evening fun should worth it alone...

Google App Engine: Its the Architecture Stupid!

I think most people are missing the point about Google App Engine.

Its the Commoditization of Software Architecture and Scaling Skills

Google App Engine is Google's attempt to democratize  the scaling of web applications. Put it another way, they're trying to commoditize the hard-to-find skills and experience needed for building massively scalable web apps. Ask any startup and they can find any number of web developers who've built a web 2.0 app. But how many developers or architects have experience and the mindset to build applications that support 100s of thousands of concurrent users with 5 9's uptime?

Scaling Big is Really Hard

The web industry has mostly moved to a horizontal scaling model - but this is not a model that most web application developers have experience with. Horizontal scaling means, basically, that instead of using more capable hardware, you use more instances of less-capable hardware, each handling a slice of the work, but doing the same function (e.g. sliced between groups of users). The intent, as much as is possible, is to reduce centralization of resources - the ultimate goal is to simply be able to add more instances of the hardware without limit to meet increased scale requirements.

Without getting into too much detail, this stuff is hard. Its not how we're used to thinking about applications - instead of application flow, we have to think about asynchronous interactions with application components. Instead of thinking about centralized data stores, we have to think about data clouds. For the vast majority of web application developers, its black magic.

Google AppEngine Makes It Easy by Imposing a New Architecture

Here's why Google App Engine is important, at least in intent. If you build your app on the Google App Engine architecture, it will scale to unlimited levels without any extra effort. Full stop.

You won't have to worry about things like replicating state, scaling datastores, building caches, etc. You won't have to hire as many really smart systems architects to bend your applications around the constraints imposed by a requirement of unbounded scaling.

As a developer, you'll have to learn a new way of thinking about building your apps. Most unnerving, you'll have to unlearn some deeply held principles about "efficiency" and scalability.

Here's a great example: your instincts as a developer are to keep as much state (e.g. web sessions) in memory between requests as possible. With App Engine, however, you'll learn to accept a certain fixed (i.e. invariant with respect to scale) latency of accessing BigTable (Google's 'data could') in exchange for never having to have to worry about any added latency in handling 100,000 (or a million) concurrent users. As a software architect, I'll take the fixed hit for the benefit of infinite scaling.

In other words, I could probably make each request "faster" with one concurrent user with traditional web app architectures. However, at a large scale (say 10,000 concurrent users), the Google App Engine architecture requests are going to run as quickly, while a traditional application may run 100x slower, unless I were to invest major effort to build a scalable architecture for it (using expensive software systems architects, of course).

Why the BigTable is so Important

In this section, I'm going to make a few points about why the data architecture Google has picked forces the developer to make a scalable app:

• BigTable, the "data objects in the cloud" technology which undergirds Google's massive applications, has the magic property of being essentially infinitely scalable with respect to the amount of data, and the amount of transaction activity. It is essentially the horizontal "partitioning" or "sharding" of data taken to the extreme.
• Most people using frameworks like Ruby on Rails (or O/R systems like Hibernate) are using relational databases (like MySQL) as object databases, and not leveraging most of the relational features. They are paying a big cost for relational functionality without real need. Google App Engine acknowledges this fact, and provides the true object interface that most application developers are using anyway.
• Google App Engine forces you to be explicit about data indexes, but this is something you have to do anyway when horizontally scaling traditional databases anyway. In traditional web application architectures, scalability almost always involves partitioning data among several database instances. The moment you partition data among multiple SQL stores, you have to think about indexes, because searches across those stores requires you to perform some sort of scatter/gather (in functional programming & Google parlance "MapReduce") - and if you aren't careful about how you build indexes, you'll end up with incredible inefficiencies (like having to merge large data sets from multiple stores in memory).

Dragging Developers into Event Think

One of the most painful things developers are going to experience with AppEngine is the concept that their app must be built entirely from event handlers. In some senses, an AppEngine app looks just like a traditional web app, answering HTTP requests, and rendering HTTP responses. But the subtle difference (and what makes it all scalable) is that each request handler must be entirely stateless. This means no web session state on the server side - no data specific to this user can be stored in memory between requests. This is good because it allows requests to be routed to any server in the world that has the code loaded (and can access BigTable) - this is what enables inifinite scalability. But because of this subtle little change, a developer may have to rethink what they are doing in each request.

When scaling big, you've got to think minimal. Do your processing, modify your data store, fire off other behavior (other events), and return. You don't worry about threading (mostly), you don't worry about hanging the server (there is no "the server"), you don't worry about resources beyond those which you consume in handling the immediate request. Its not actually different than the PHP model, actually...

(In fact, if an application framework has a way of automatically storing web session data to BigTable,
then the app can probably be deployed as before - the "event-ness" of the app is hidden from the developer by simulating state in the BigTable. I haven't looked in detail about whether this is practical in App Engine or not, though)

And there's a deep structure here - underneath all the abstractions, Internet interactions are just reallya series of events. A HTTP request comes in. Event. A datastore request is made. Event. An XMPP message comes in. Event. In fact, from this point of view, there's no reason why other protocols could be supported in the App Engine architecture - while they have deployed only HTTP connectors and routers, there's no reason why Google couldn't deploy other connectors for other protocols like XMPP.

And the Moral Is

The moral of the story is that Google App Engine will be remembered primarily for ushering in the era of uber-scalability for the masses. Its not about free hosting or lock-in (though it arguably is), its not about competing with AWS (though it will), and its not even about Python (though it will certainly bring Python more attention). Its about giving out the secrets to the Google kingdom. I predict that we'll see an open source suite that allows any individual or organization to deploy a system architecture that roughly approximates the scalability features of AppEngine. In fact, the pieces are probably already out there.

Google is pushing the community of web developers to rethink how they build web applications. Other will follow and innovate, but Google will get credit for the first big push. Thats what AppEngine's role in history will be.

Memo to API Service Providers

This is a followup and expansion to a blog entry I wrote in October 2007, titled "Memo to OAuth Service Providers".

Recently, I've been working with a host of companies with open APIs built specifically for 3rd parties to build on. Call them mashups companies, platform companies, or just plain old smart companies. But if you are contemplating creating an API for your new online service, I have some suggestions on making your API offerings a success. 

Use Building Blocks
If at all possible, don't invent a new protocol, don't invent new formats, and don't even invent a new API, if you can avoid it. There any number of building blocks out there such as OpenID, OAuth, HTTP (REST especially) and Atom upon which you can compose a set of interactions to fulfill a wide variety of needs. This isn't to say that your API demands unique components, but the thing to remember is that the service offering behind your API, not the mechanics of the API itself, should distinguish your API offering from others. 

Think of the API as a Separate Product You Are Delivering
It really is a separate product. Its your company's service packaged as a product for delivery to a new set of customers (other developers) with a new intent (letting third parties make your business successful and creating an ecosystem in which you are cemented as a core participant). Along these lines, there are several key things to keep in mind:

• The API isn't delivered until your side (the provider) conforms to a publicly published specification. This seems so obvious stated this way, but like other product launches, its all to easy to make "vaporware" claims about APIs - declaring you have delivered more than what is actually there.
• You may even want to go so far as to build tests for your API first, before you build a server-side implementation. Build a proof of concept client application that exercises all the functionality in the API. When that POC works, your API is complete!

Your API User are Your Customers and Partners.
As I mentioned in Memo to OAuth Service Providers", the mindset you should have is that the users of your API are your customers as well your partners. This is especially true if you are entirely or largely a platform company with little or no direct contact with end users. Your API customers are likely going to bring you business development leads. They are your best sales team -if you're lucky, maybe they are your only sales team! Think of them and care for them like you would any other service user: understand their needs, maintain bidirectional communication channels and respect their sensitivity to quality (uptime, performance, etc).

Make Life for Your Developer Users EASY
This is probably the most important message I have to deliver. To these nice folks (many of whom are just like you and may even themselves be providing services behind APIs), you are often one of several options and you need to make their lives easier than it is today, not harder. Here are a number of concrete steps you can take, some of which I've seen implemented, some of which I think may be novel:

• Document the service and not just the API. Start at 50,000 feet and work your way down. Nothing frustrates me more as an API user to get API documentation that starts with API methods and fields, without bothering to tell me what they do. So many times, API providers forget to describe to me what the service behind the API does - it is often the most critical thing for an API client to understand. After all, an API customer is typically not writing to the network level specification, but rather they are orchestrating interactions with your service via calls to a API client library.
• Provide open source client API libraries in all the major languages your users are likely to implement in. This one is obvious, but its a prerequisite for success these days.
• Provide a reference client application to demonstrate usage of the API. Again, another obvious one. Make sure its well documented, and reflects any updates in the API over time. Consider the reference client part of the deliverable package when you update the API.
• Make an instance of your service available for developers in a sandbox, if at all possible. Developers will do stupid things and need to hit your API to learn. Don't make them feel guilty for doing it, or punish them for messing up. Encourage them. Make it easy. Allow them to make mistakes in the privacy of a development sandbox, if at all possible.
• Don't neglect error reporting, and think of it as an educational tool for the API client developer. People developing server sides of APIs often think that the appropriate solution for reporting errors is to be cryptic and expect folks to refer to specifications to understand what has happened. There's generally no reason for this sort of torture. Especially when a client developer has no insight into the server environment, its nice to give them some extra information about what's going wrong. Unless you have a buggy server implementation, its usually a problem on the client side - and more often than not its a bug in comprehension of how your API is supposed to be used. Use failures and exceptions as learning moments.
• Build mechanisms to give client developers extra debugging information during development. Perhaps you can provide an internal log of how an API call is being processed and the steps inside your implementation, at some general level of detail. This could be controversial (some API client developers may claim your system is not doing the right thing if they have too much insight). However, it can help them understand how the system is actually working when things are going right, so they can see why things are going wrong when they are going wrong. Also, we know that abstractions are leaky (an API is one sort of abstraction) so giving client developers a peek under the covers of the API implementation on the server side may occasionally be helpful in discovering when those leaky abstractions are causing them problems.
• Build a way for developers to reset your service to a known state for development and debugging. There's really nothing more frustrating than trying to create tests or track down bugs that only occur when the API being accessed is in a certain (sometimes unknown) state. In many cases, it could be very helpful for a client developer to "push a button" to set the server side to some known state (e.g. empty out a database, populate a database with a known set of data, etc). This also helps greatly with the next bullet point.
• Think about your client developers' testing issues. Think about their testability problems and how you might be able to help them, or at least not create extra problems. This is especially true with a test-first development approach that is advocated in some agile development methodologies. This sort of testability may mean providing a client API with a test harness built in (e.g. Mock Objects to stub out the actual service API). Or, it could mean the sort of "known-state setting" that I mentioned in the last bullet point, so that even unit testing of the client software can happen against the live (development) API you are providing. 

Eat Your Own Dogfood
This is more than just building a proof of concept. I actually advocate building a live application that accesses your API as would any other client. This is so that you can feel the pain (and experience the joy) of your API client customers. If you are good, you'll be able to anticipate what your customers want and need before they even know it.

Monitor Usage of Your API
Like any other online service, you really need to know, at a technical level, what's going on with your API service as it is getting used. Know your usage patterns - they are almost certainly going to be different than what you first guess. Knowing your service helps you maintain uptime, predict scalability issues, and be able to avoid issues that will keep your customers from being happy. You will be able to predict future growth and plan for investments in the API offering. Finally, monitoring usage will also help you in the area of security, because monitoring helps establish baseline usage volumes and patterns that can be used to detect security or other anomalies.

Build a Community of Developer Customers
If you launch an API and have developers building to it, you already have a community. Recognize it, support it, and realize that they are likely investing a lot of time and exposing themselves to a certain amount of business risk by relying on your API. Give them reasons to continue the partnership and feel that the risk is well understood (if not completely managed). Let them know who you are as a company, and the sorts of investments and commitments you are making in this API, and acknowledge the fact that this is a symbiosis. There is no such thing as a service provider if there isn't a service consumer.

And here's one more thing about the community. Call it the Wachob corrollary to Selfridge's law: "The API Customer is Always Right". Thats not literally true, of course, but it is the mentality you need to have, especially when you are just launching. This is a make or break time - either your API users like what you have, or they will quickly walk away. You are serving the API users, not the other way around (unless you are special or have some abnormal market power). You aren't doing them a favor by providing the API - they are doing you a favor by embedding your service in their offering. Recognize.

Don't Forget the Legal Stuff
Your lawyers will surely tell you this, but let me save you 15 minutes of your lawyers time (spent lecturing you). Protect yourself. Think about disclaimers (esp with respect to warranties and service level agreements). If you want to offer those things, think about how you are exposing yourself and how you can cover the risk cost. Think about other legal issues such as copyright (and the DMCA), privacy laws, or other oddball legal issues that your customers may drag you into (online gambling?).

But also look at your legal agreements as an opportunity to express, in a positive way, commitments to your API customers that signal your appreciation of them as part of the ecosystem. One of my favorite signaling mechanisms, built into legal agreements for user-created content service offerings, is explicit language preserving intellectual property ownership on the part of the user for all content they upload/contribute/share through the service. Also, strongly worded privacy commitments, though they may raise the hackles of many lawyers, are also a great way to indicate your intentions towards your API users.

Make it Fun, Make it Personal
Lastly, I think you need to make developing against your API fun and personal. Try to enable "The Thrill of the Hack". Be real, be available, be a company of people, not a company behind a API call. Do this and everything above and you'll have the best odds for developing the fanatical userbase your service API so richly deserves... 

Want Some Help on This?
Glad you asked. I'm available to consult to any company that would like help on the issues described in this blog post. I can be reached at gwachob@wachob.com

XRDS-Simple 1.0 Draft 1

Eran Hammer-Lahav announces the first draft of XRDS-Simple 1.0, which is the attempt to make a simplified profile of the XRDS/XRD XML document that is the core of XRI Resolution. Drummond Reed and I, along with other members of the XRI TC (more than) enthusiastically supported and contributed to the crafting of this spec.

From the spec:

The goal of XRDS-Simple is to provide a lightweight version of XRDS that simplifies the implementation of parsers while maintaining full compatibility with XRDS and any XRDS-compliant parsers and resolvers. It also serves as an introduction to XRDS, giving implementers an upgrade path to other XRDS features when appropriate.

Please review and give feedback.

Lessig Doesn't Attempt Congressional Run

Larry Lessig has decided not to run for congress here in the 12th Congressional District, recognizing that an attempt to beat Jackie Speier is only going to end in a blowout defeat, which doesn't further the goals of Change Congress.

This only redoubles my respect for the good law professor. This first decision was a right one, I only hope there are many more to follow!