Gabe Wachob

Thanks Omar Ahmad

Omar Ahmad, by all accounts, was a popular man, both in his role as mayor of San Carlos, and as a member of the political and tech communities in the Bay Area and beyond. Thats why, in part, so many people are shocked and saddened by his sudden death by heart attack this morning.

When my kids watched a "black man" (actually a man of mixed race, just like my kids) get elected to be president of the United States, their joy and elation went beyond the politics... I really believe they (my kids) felt like they were part of the American community because someone *just like them* was elected by a majority of Americans. Obama was elected based on his credentials, capabilities, intellect, and leadership, and his racial background did not prevent him from being elected to the highest office in the land. My kids, to this day, identify with Obama, and (notably) even draw him and themselves with the same color markers. But when Obama was attacked for "being Muslim" or having an Arabic middle name, I was horrified. Being 'black' was OK, but being Muslim wasn't?

I'm writing this note because I never got to tell Omar that I really appreciated his visible leadership and presence in the community in which I lived in (San Carlos). Omar had one of those funny names. An Arabic name. And he was Muslim... that religion that all the politicians can't help but demonize.

Why is this so personal to me? You see, *my kids* have funny Arabic names (Aliyah Maria, Joshua Sultan). And to the extent they are being raised with any religious upbringing, it is Islam (their mom's religious affiliation).

So maybe I don't have to spell it out, but its really important to say. My kids saw (then council member) Mayor Omar Ahmad, a brown-skinned Muslim man with an Arabic name, leading their home town. Just like with Obama's election, I know they felt part of the community and were given the boost in pride that they could thrive as much as any other kid with any other name, religion, skin color or special feature. They probably don't even notice it explicitly. They may never have mentioned it. But I'm sure, absolutely sure, that my kids are so much better off for having Omar as an unintended role model. Just by being an active, positive and joyful leader of the community, he helped build an environment in which my kids are thriving despite being "different".

Differences should be celebrated and embraced and I can't think of a better example than Mayor Ahmad in San Carlos. But *highlighting* differences is not why we celebrate him. Indeed, I don't think he ever made an issue of his differences. I'm celebrating his service because he was just "one of us" who made space for those who are different in whatever way they are unique. He made a positive impact by being and doing, *not* talking, and his impact will go on beyond his political career, and indeed his life.

Goodbye Omar, I'm sorry I didn't get to tell you this before you left us...

Do API Service Providers Need Community Managers?

"The Five Habits of Highly Successful Community Managers" (by Roland Legrand) is a great article that discusses tactics for successful online community managers. These include "Speak up", "Focus on Concrete Issues", "Be Honest", "Be Firm", "Be Grateful". These "people skills" are as equally applicable to a social community (online or offline) as they are to a developer community. 

This got me thinking, should API service providers have a visible "community manager"  (and not just "maintainer" or "evangelist") for their users and outside developers? I'd say yes. The issues and tactics highlighted in the article seem to me to be just as applicable to a technical user community as any other. But its not something I see very often - maybe its because developers don't see themselves as a community? Are there some types of API services that more naturally grow an ecosystem of users/developers around them?

What do you think? Do you know of API service providers that have someone with this responsibility and title? 

[Thanks to Chia Hwu for pointing it out this article.]

API Documentation Sites Are An Opportunity!

A hint to all companies offering access to their platforms via an API: look at your API documentation sites as an opportunity to build a community around your API. Do not require users of the documentation to login to your service to read the documentation, do not require them to click through arcane paths to "find" documentation. Make it as easy to find the API documentation as it would be to find your blog or support site (i.e. http://api.yourcompany.com).

Why make it hard for folks to evaluate your product for the purpose of investing their time and effort into building your community of users?  

I'm proud to say that not only does Socialtext make their API documentation public, its on a wiki that allows for feedback inline. In fact, Facebook and Twitter (and many others) use wikis for API documentation - a practice I highly recommend. What better way to create dialogue and community with your developer/users than giving them a direct means to give feedback on the APIs they are being asked to use? 

New Blog: BeatSlacker

A week or two ago, I launched a new blog: BeatSlacker

 

Some of you know that I love music of all sorts, and when it intersects with the net (my other "love") I get excited-squared. So I started a blog about music things and especially people I find online. There's so much good music out there that you won't hear about unless you go looking. 

So, please take a look at BeatSlacker and let me know what you think!

My Ada Lovelace Day Woman in Tech

Today is the day I pledged to a blog about a woman in tech for Ada Lovelace Day. Before I mention who I wanted to blog about, let me explain why I am participating. I'm a dad of a very smart, precocious, and interested 8 year old girl. She loves dolls and art and music, but I've also noticed she really loves one of the two OLPC's I have. 

I want her to grow up to follow her passion, whatever that is. But as a guy who's been into tech since he was a kid like her, I must say that I'd be tickled pink (no pun intended) if she followed in her dad's footsteps. So, for her, and millions of girls like here, I decided it would be great to participate in today's blogging about women in tech so that some other girl or young woman feels like there's a place for her in the tech world.

I'd like to talk about someone who has personally inspired me to continue to be involved in the various fights around intellectual property and the digital revolution: Pamela Samuelson.

Now, my nomination might come as a surprise, since Pam isn't, strictly speaking, in the tech industry, nor is engaged in a technical profession. But I believe she's had a very  profound affect on shaping the techand creative industries attitudes toward intellectual property and its effect on creative expression, innovation, and the growth of the Internet. I first met her when she joined the faculty at UC Berkeley's Boalt Hall School of Law. For me, she made law relevant to the emerging culture around the Internet, and was one of the main reasons I chose to stay in law school beyond the first year. She understood and spoke to the technology but also to the real politik behind such efforts as the DMCA (which would be enacted after I left boalt), and a variety of lesser known, though equally insidious US and international laws and regulations that quietly twisted and distorted intellectual property against the interests of innovation and the commons (as its now referred to). And beyond speaking to just lawyers, she teaches at UC Berkeley's I-School, and has written numerous articles for non-lawyers in publications like the Communications of the ACM and Wired Magazine. 

Today, the Samuelson Clinic at UC Berkeley School of Law focuses on a wide variety of legal and policy issues around technology, including intellectual property, privacy, free speech, open source, and even voting. She's singlehandedly inspired a generation (or two?) of lawyers and public policy advocates to think of the public interest in technology. For that reason and I others, it seemed entirely obvious that she would be my pick for the Ada Lovelace Day.

The Case for Bar Associations to Be OpenID Providers

Summary

It seems abundantly clear to me that officlal Bar Associations can better serve their membership and the public by adopting a new technology which allows attorneys to prove to third parties that they are bar members and in good standing (along with other information). That technology is OpenID (and OpenID Attribute Exchange), and the cost of implementing these technologies are relatively minimal. The benefits to the bar members, the web, and the general public far outweigh these costs and I would therefore propose that the time is now to implement this new technology.

What is OpenID and How Could Attorneys Use It?

OpenID is an emerging standard that allows a user to prove that they own an identity (technically speaking, an identifier) online.  It allows a user to prove to a relying party (such as a social network) that they are associated with an identity at another site or application (the OpenID Provider).

The applicaiton of OpenID to state bar associations should be obvious. An attorney visiting a 3rd party website can prove to that website that a) they are an attorney that is a member of the bar, b) that they are in good standing, and c) that they have special certifications, etc.

This is not a theoretical excercise. Web 2.0 technologies are as much about two-way conversation and contribution. Attorneys will be left behind if they cannot carry their trustable credentials with them.  In addition, sites and applications serving the legal community can become much more scalable and interesting when proof of bar membership is automated,  rather than a manual process. A recent twitter thread demonstrates this issue.

The technical solution is now simple, and based on open standards which are implemented widely in open source software. Implementation of OpenID both on the Provider (bar association) and Relying Party (3rd party service) is relatively easy and well understood. Furthermore, with the proposal I make here, the user experience is relatively straightforward for attorneys (simpler than generic OpenID authentication).

The User Experience Proposal

An attorney wishing to prove, to a 3rd party site,  their membership and status in a bar association has a very simple experience. Instead of prompting the attorney for their typical OpenID identifier, the relying party should only prompt the attorney for the state bar association and membership ID they are claiming. Because there are a relatively few number of bar associations, the relying party could map those two pieces of information to a URL which would be the identifier used in the normal OpenID authentication flow (e.g. http://openid.calbar.ca.gov/<membershipid>). (Alternatively, in the longer term, the construction of the URL might be provided by a third party site/service)

After the attorney enters their bar information, the 3rd party site redirects that user to their bar association, which performs whatever online authentication the bar site normally provides (e.g. username/password). At the end of that authentication, the bar site redirects the user back to the 3rd party site (with some back and forth in the background, invisible to the user). The net result is that user has logged into the bar association site, but proven to the 3rd party site that they are a member of the bar. There's really almost nothing simpler. And this is based almost entirely on technology already written and deployed.

Implementation by the Bar Association

The Bar Association has to do the following:

• Implement the basic OpenID Provider functionality. This means hooking up several new URLs to a library that processes incoming OpenID authentication requests, and minimal changes to the user experience flow for authenticating users during the OpenID flow.
• Implement OpenID attribute exchange for a handful of  "attributes": membership_id, membership_status
• Produce documentation to give members an idea of what is going on. Because of the user-experience enhancement I propose below, end users really don't have to even know they are using OpenID (the use of an identifier other than bar membership ID is not needed)

Assuming the bar association already has a personalized/authenticated site for their attorneys, this functionality is relatively easy to deploy in a variety of server environments.

Implementation by the 3rd Party

The 3rd party has to do the following:

• When asking the user to prove they are an attorney, present them with a prompt that allows them to select which bar association (if more than one) and their bar membership ID (the format of which is probably specific to each bar association). This need not mention OpenID specifically - they are only being prompted for bar association information, not an OpenID URL
• Construct of the OpenID URL from the bar association information given by the user. How that information is built into a OpenID URL is likely to be specific to each bar association. It would be nice (as a followon effort, perhaps?) to have some pattern of construction that makes this process easier to implement for multiple bar associations. But initially, the construction rules need to be hardcoded (something like http://openid.calbar.ca.gov/<membership id>)
• Perform normal OpenID relying party functionality with the URL constructed above.
• Perform attribute exchange with the bar association to get membership and status information. The exact attributes (and identifiers for those attributes) is something that needs to be specified by the bar association - hopefully a standard set of identifiers would emerge (or could be proposed!)
• Display prominently the bar association verification associated with the bar member attorney. By creating an understanding among users that the verification is available, lack of verification associated with a user on the 3rd party site will both enhance the reputation and value of contributions by verified attorney users while also raising awareness about the risks around receiving legal advice and opinions from people who are not bar-accredited.  

The Benefits for All of Us

There's a famous cartoon whose caption is  "On the Internet, nobody knows you are a dog" This is the challenge for professionals online, whose opinion laypeople have to ability to judge. We certainly don't want to be getting legal opinions (even if not specifically in the context of a attorney-client relationship) from dogs, do we? I believe that when attorneys can carry proof of their professional status with them, their contributions will be more valued and they will be given more incentives (reputation, monetary) to contribute to the intellectual commons of the Internet, and provide a better service to the public at large.

We can do this now, without much effort, and the benefits are manifest. What do you think?

ADDENDUM

The Flow

Non-technical  readers may want to skip over this diagram.

What Twitter Should Do With Its API

There's been some recent announcements (here) about changes to the Twitter API and I thought I'd take this occasion to blog, in one place, the various thoughts I've had about what Twitter should do with their API:

Distinguish between Client Apps and Third Party Apps

Make a distinction between "client apps" and "third party apps" in the REST API so that the access rate caps can be treated differently.  "Client Apps" are apps that run in the domain of the one user whose credentials are being used (ie a desktop app).  These sort of apps generally have no good reason for hitting the API many times a second. "Third party apps"are accessing the API in an unauthenticated manner, or using the credentials of the user (ie a third party site like http://twitter.grader.com). These have a legitimate need for high volume access. 

Why is this distinction important? The answer is that the relationship between the developer and Twitter, Inc is different in the two cases. In the Client App case (such as a desktop app), the developer doesn't really care about high volume access, assuming the user isn't hitting reload an astounding number of times a second. A Third Party app developer, on the other hand, is the party that cares about rate limits. By partitioning these two types of relationships, you can segregate the market of REST API users, and implement different policies for them. You want to encourage both types of developers, but you do so in different ways. The current rate accessing policies, especially after the new caps were announced, are better tuned for Client App developers - so there's really nothing that needs changing for this segment of developers. Its the Third Party App developers, where much of the value of twitter is created, that need to be treated more predictably.

Give the Opportunity for Heavy API Users to Pay

Cap the number of requests to some reasonably large number, but offer tiers of access above that cap for pay.  Along with the increased caps, offer a modest for-pay support program for heavy use third party applications. (something like $20-$100 per month for each level of 10000 requests/hr) The idea here is not to punish heavy users, but rather create an incentive for Twitter to support them better.

Everyone comes out happier that way. If I'm building a business on the service infrastructure of Twitter, I want to know that I've got a relationship that matters to Twitter, my service provider. Whats a better way to build a relationship than a revenue stream! :)

Implement OAuth Already!

Implement OAuth for third party apps and require, as terms of service, that third party apps (as opposed to client apps, see below) do NOT collect username and passwords for users. OAuth is designed exactly for this scenario, and reduces greatly the exposure to illicit username and password capture.

In implementing OAuth, you'll also be requiring that applications (either third party or desktop) are explicitly identified as a party to the REST call interaction. This is a good thing! Instead of applications being anonymous parts of the infrastructure sitting beween you and the user (at least for "reads" in the API), applications can now be identified and managed (on the Twitter side). This presents new opportunities (as if you need them) for reaching out to your developer community and gives you more insite on the usage patterns that specific applications have.

Think of Yourself as Common Carrier - Don't Discriminate

While Twitter is legally far from being a "Common Carrier", act like you are, at least from the perspective of an API provider. While you support tiered levels of service from a support and volume point of view, do NOT offer that level of discrimination for functionality. The key here is that the innovation starts on the long tail - the "big end" of the curve pays for the extra level of volume and support to sustain the service, not to create special functional access only for those who can pay. The little guys using the REST API should be able to be "big guys" simply by participating in the for-pay program when its in their interest, and not as a way to get access to an exclusive club of functionality.

President Obama

I just liked seeing that in words: President Obama.

There's so much emotion in the people around me. Its unlike anything I've ever seen.

Tomorrow, we get to work. But today, we celebrate.

The Problem with the Technology Agenda

I'm really happy to see Obama's transition website continue from the earlier campaign site to feature a "Technology Agenda". However, it has one particularly glaring deficiency that concerns me. Even while calling for "reform", the following statement demonstrates a fatal misunderstanding of the role of intellectual property in today's world:

"Intellectual property is to the digital age what physical goods were to the industrial age."

This statement is dangerous because it ignores the real story of the "digital age": the fact that the rise of the Internet can be largely credited to free and open source software that expressly disclaims any notion of property rights. In fact, one could argue that the Internet is built primarily on open source software. Apache, LAMP stacks, low-level TCP/IP networking code, firewall code, all open source.

Without the intellectual commons created by the coders, tool builders, web designers and other enthusiasts who've built the Net, the Internet would look more like a gigantic closed AOL of yesteryear. Tinkering, hacking, and "scratching your own itch" are as important drivers for the open Net as are the billions of dollars of investment in commercial software protected by strong intellectual property.

This language in the Technology agenda would be more accurate if it read:

"Intellectual property is to the digital age what monopolies were to the industrial age."

In fact, most forms of intellectual property are state-created monopolies created around the exploitation of  expressions (copyright), ideas (patents), or brands (trademark). Monopolies in and of themselves are not evil - in fact there are good reasons for some monopolies to exist (for example, so-called 'natural monopolies'). But any policy towards intellectual property should recognize its basis as  a form of monopoly, and should treat intellectual property policy with the same public policy aims as the monopolies of the industrial age. That is, to sustain growth and most effectively meet our  economic (and creative) potential, the rights of IP holders (those who hold state-protected monopolies) should be balanced against factors such as consumer benefit (very broadly defined), and the distortion of normal markets (tying, anti-competitive behavior, etc). The language used in the technology agenda raises concerns that no such balancing would be part of the Obama administration's policy objectives.

I hope I am wrong, and that the actual policies developed by this administration will be more balanced.

I am writing this blog partially as experiment in direct democracy via blogging. In doing so, I'm hoping this new administration is more willing to adapt to public calls for change than the last one. 

In other words, I'm hopeful we can make the change we seek!

[Thanks to Kevin Marks for pointing this text out]

YES WE DID

President-elect Barack Obama. I can't put it into words. So I won't for now.

YES WE DID!