Gabe Wachob

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!

Lessig Wants to be My Congressperson (maybe)

[Update Feb 21, 2008 11:31pm PST: Shelly Powers has a much more negative response to Lessig's run for Congress. She makes some good points about the Change Congress plan, and raises some important substantive concerns about Lessig's proposed candidacy. ]

Professor Lawrence Lessig, in conjunction with his recently announced "Change Congress" effort has announced that he is contemplating running for Congress from the 12th Congressional District, recently vacated by Tom Lantos' surprising and unfortunate death recently. Thats my congressional district. A chorus of netizens have cheered loudly about the prospect of a Representative Lessig, and have begun a Facebook group and a web site to encourage him to run.

I have been a supporter of Jackie Speier, a local public servant who has a long and magnificent history serving this area in a variety of seats, from county supervisor to state senator. She announced her intention to run for this Congressional seat and everyone I talk to enthusiastically supports her. She's got deep grassroots as well as establishment support. We've got a special election coming up April 8th (to fill the remainder of the term) where she is certainly going to win a plurality and very likely to win 50%, thus heading off a "runoff" in June. She'd have to run again at the end of the year for the seat as well (for the next term). Its too bad that we have to choose between Lessig and her - neither of them are your run-of-the-mill "hold your nose and vote" candidate!

I'm deeply torn because though I have been (and continue to be) a Jackie supporter, I, like many of my fellow netizens, am deeply moved by Lessig's attempt to change congress through the severing of the ties between election-driven fundraising and legislative activities. Its a sincere effort to kill the corrupting systemic influence of money on politics. I was moved by the video on Lessig's exploratory site:

I must also admit that I also feel a tinge of resentment to the chorus of calls for him to run. He would be my representative, not yours. He's never been to local community events or been involved in local political activities or causes, as far as I know. Other than living in the district, I'm not clear what ties he has to to the community. He's got to deal with issues in the district first and foremost, and not just the reform agenda. Also, being a legislator means practicing the art of compromise. Being an effective legislator is about sausage making. Is this really the best way to push forward the Change Congress agenda? I really am uncertain and am eager to be convinced.

In addition, I have very little idea about what his policy positions are outside reform. We have a tendency to support similar candidates (notably Ro Khanna's challenge to Lantos in 2003/2004, and now Barack Obama), but I've heard NOTHING about his view on local issues where someone in this position has quite a lot of influence. To be clear, I think these deficiencies are "curable" (not sure if thats possible in the 6 or so weeks we have until the election), but they definitely need to be addressed if he is to be anything other than a footnote candidate. I'd invite him to come, for example, to a meeting of San Mateo County Democracy For America and discuss face to face why he wants to be our representative - at least one other candidate already has.

Finally, I want to share an email I sent personally to Larry Lessig. I've actually grown more positive towards his run since I wrote this, but I think it probably reflects the sentiments of many of us locals:

Prof Lessig-

    I have rumors that you are considering a run for the 12th CD congressional seat recently vacated due to Tom Lantos' untimely passing. As a fellow resident of the 12th CD, I urge you *not* to run for this seat, both because I think you can be more effective in other roles, and because I believe Jackie Speier will win and will be an even more effective representative.
     I believe I share many of the same values with you, judging by your past and current political and other advocacy positions. In 2003, I actively supported Ro Khanna in his primary challenege to Tom Lantos (in addition to supporting the Howard Dean candidacy). In fact, I attended a fundraiser at your house for Ro. More recently, I have been actively supporting Obama - another candidate you have been vocal in supporting. I am also an active supporter of Creative Commons and all the work you've done over the last 10 years - I first heard your name while at Boalt in the mid-90s, and you've clearly inspired a whole generation to focus on legal and policy issues unlike others before.
      I am enthusiastic about your recent change in focus towards political corruption and the influence of money - while I've been a huge supporter of Creative Commons and IP reform in general, I believe your attempt to tackle systemic corruption is so much more important. However, I believe you can be more effective in this role as an independent voice, not as a member of Congress. Even a position for you in an Obama administration (lets hope!) would be more conducive to your message, I would think.
       In closing, let me also make a pitch for Jackie Speier. She has deep roots in northern San Mateo county and southwest San Francisco. She's shown her ability to be an effective legislator and has a record of leadership on privacy and consumer protection legislation. I would hope that you could build a relationship with her to pursue your goals rather than trying to challenge her in the primaries. If you aren't in communication with her, I'm sure should would be more than excited to talk with you directly - I'd be happy to help facilitate that in any way I could.
       Let me be clear - I understand the enthusiasm that many have for the possibility of being able to say "Representative Lessig". It gives me goose pimples too! But the realist in me believes that you would be more effective in other roles, unencumbered by the day-to-day sausage-making that is the House of Representatives.
       Thanks for listening, and I look forward to hearing more from you on this topic soon!

SuperDelegates.org

Because the Democratic primary race looks likely to go to the convention, and that the Democratic Party super delegates may swing the nomination one way or another, there's been a lot of interest in the last few days about who exactly these super delegates are. My friend and fellow netroots junkie, Rick Klau, announced SuperDelegates.org today:

In an attempt to shed some light on this process, I built a site over the weekend – SuperDelegates.org. Starting with a terrific list provided by the guys who maintain DemConWatch, I started filling in a little info about the super delegates and linking to their endorsement (if given). After finding a great extension to MediaWiki (KMLExport, in case you’re interested), I was also able to add in geo coordinates (latitude and longitude) to the delegate pages, so that you can see the delegates in a Google Earth layer.

The data is far from complete, but that’s by design: this is a wiki, and the site will succeed only if others decide to contribute to it. It takes just a couple minutes to do some quick searches on Google to find basic info about the delegates, and entering in the basic info on a delegate is simple:

{{Endorsed Barack Obama|Latitude|Longitude}}

I'm helping Rick with this, but with the California primary coming up, I'm quite busy for the next few days helping out my candidate, Barack Obama (Super Duper Tuesday primary election is this coming Feb 5th!). However, if you'd like to help with SuperDelegates.org, please contact me and I'll get you started.

Barack Obama

I don't think its any secret for anybody who knows me that I'm a very big and active supporter of Barack Obama for President. Perhaps even more than I was a Howard Dean supporter 4 years ago. There's so much that that I can say, but I want to make sure that readers of my blog understand that he is the only candidate with a technology issues statement on their web site.

In addition, Don Park created this logo which I think is distinctive, inspiring and catchy:

If you want to get more involved in the campaign, or just want to know more, please do not hesitate to contact me directly.

Yahoo OpenID Announcement and IPR Policy

Yahoo! announced planned support for OpenID (as a OpenID provider) today. Thats thrilling news - congratulations to everyone at Yahoo! for taking the plunge. The timing, however, is not much of a surprise to me...

If anyone doubts the importance of an IPR policy for your grassroots community-driven open standards effort, this should be an important lesson. A group of us from the OpenID community worked for a number of months with a number of large organizations including Yahoo! to hammer out a OpenID IPR policy (and a lightweight community process to support the policy). That policy wasn't finally agreed to by the OIDF board until mid-December of 2007 (and the announcement on the OpenID site wasn't made until there were only 2 minutes left in 2007!). Without such a policy, large organizations such as Yahoo!, Microsoft, Sun (and a number of others) are not comfortable participating, especially with unclear rules about copyright and patents. While these companies have been itching to contribute to (and use) OpenID in a very community-positive manner, they simply haven't been able to without having a well-defined set of rules to play by. After all, it's the big pockets like them that get sued, not the 5 person startups and independent developers who have been the mainstay of OpenID development until recently.

We'll have to see how this policy and process works out. Its a new thing, and we'll have to explain to a lot of folks why the rules are the way they are. If you are a OpenID community  participant, I encourage you to review the documents, and please do not hesitate to ask questions to me, individuals the board, or the openid-legal email list.

One issue that has not been finalized is dealing with trademark around the OpenID mark. That discussion is starting now. Look for news on that in the upcoming month or two.