Open API Economy Inaugural Meetup

We had a fantastic inaugural session for the Open API Economy meetup.  We had 16 people attend, most stayed well past the planned stop time of 9 PM, and the quality of the conversation was open and productive.

Many thanks to True Ventures and Puneet Agarwal for hosting our event at their very cool space at Pier 38. And thanks to Om Malik for helping get the word out about the event.

Opening

We started with casual discussions in ad hoc groups over drinks and snacks; when we had critical mass (around 7 PM) we started to gather chairs for everyone into a circle and began the Open Space process. 

I took a few minutes to introduce myself, my hopes for the meetup, and what I thought it took to produce successful groups. 

Philosophy

I believe that the most satisfying groups that we participate in are at once social, selfish, and selfless. 

• Social – you like the people there and look forward to seeing them
• Selfish – you have a meaningful personal outcome in your life or work that will result
• Selfless – you can help others in the process and participate in something larger than yourself

While this may seem paradoxical, it’s really not.  In particular where we are right now in the development of the API market, these apply strongly.  Most companies at the core of the API Economy are relatively small, many are located near each other – both in and around San Francisco and farther out into Silicon Valley – and all benefit from highly connected social networks that stimulate ideas.  Each player needs to grow their business, which they’ll do from improving their understanding of the dynamics of the market for APIs.  Finally, each person needs to help others in order to be successful – customer success is the core of any successful business endeavor – and feels motivated by both the acknowledgment of membership in a community and the growth and success of that community.

Right now, since we are at the heart of the technology and customers that make up the API Economy, we have both opportunity and responsibility.  We have the opportunity to build great businesses and benefit from being both early and successful in a rapidly growing market.  We have the responsibility to help others participate – both customers and new market entrants (aka “competitors”) – in order to grow the whole phenomenon for the benefit of each player.

Most importantly, we established that while we were all employed by various companies, we represented ourselves as individuals first, and with our companies second.

Introductions

Each attendee introduced themselves, and we had a terrific cross section of perspectives and experiences.  The community that was present was made up of technologists and businesspeople, mostly with 10-20 years’ experience in technology companies, and with real activity and insight into both APIs and cloud computing.  I cannot do justice to each member’s introduction.  People there were building EC2-based Hadoop services (Cascading), social media (Digg, Formspring), API infrastructure (Sonoa, Mashery), business systems (Salesforce.com), healthcare systems, and developer communities like CloudCamp. 

I reviewed the Open Space rules that I’d learned from Scott Bellware at his excellent conference, Monospace, and documented on Wikipedia.  Open Space is unique in that it ensures that the group works on what the collective members feel are the most important topics, and is not subject to control by a moderator or sponsor.

Finally we agreed that this would be an open meeting, where all the ideas were free to be owned, blogged, or turned into businesses by any participant.  This was significant and contributed greatly to the quality of the conversation, especially since we had people employed by companies that viewed each other as competitors.

Discussion Topics

We then moved to the Agenda Creation phase.   Roughly 8 topics were generated, and the votes picked the top 3.  In practice, there were only enough people to have critical mass for 2 discussions, so we broke up into:

• API Evolution (versioning, compatibility, etc.)
• Data Ownership (Privacy)

I participated in the Data Ownership discussion.  We discussed the topic for nearly two hours.  The main aspects of the discussion follow.

Data Ownership in APIs

Even more than cloud infrastructure providers, APIs to cloud services (like Twitter and Salesforce) represent lock-in.

• There was anecdotal evidence that some older companies moving to an API model want to make it very easy to move data from competitors, but “nearly impossible” to get data out.  This tension lies at the heart of the problem.
• There are economic incentives to make it easy to interoperate into, but not out of, the service you’re building.  It’s a bit like why un-installation is often the worst part of any given client application’s user experience.
• Salesforce has succeeded despite concerns of lock-in by being proven trustworthy and putting “Trust, Security, and Customer Success” as the three pillars of their brand and culture.  With 10 years behind them they have a solid track record. 
• But how do those of us just starting out get there?

We identified two major components to data ownership:

• Moral Ownership
• Moral Ownership is “the sense that the data belongs to me and that I can get it out”.
• Moral Ownership has to do with how someone feels about the service than the service’s actual qualities.  It’s similar to the sense of flexibility and the “right to change the code” with open source projects – appreciated by everyone but exercised by very few.
• Practical Ownership
• Practical Ownership is “the physical ability to get the data out with a reasonable amount of effort”
• Physical Ownership has to do with the technical capabilities offered by the service, ranging from quantity and cost of data to transfer, understandability of data removed from the context of the service, and time and effort required to move the data.
• Dividing these aspects let us make progress in the discussion.

We recognized that the practical ownership has a lot to do with the choices we make as we build our service.

• This includes the API design, the documentation of the data, the security and privacy of the data itself, and fallback plans in case the business fails and the customers need their data back. 
• Choosing to build our services on Amazon AWS introduces new challenges in retrieving bulk data due to bandwidth costs.  Porting from AWS or supporting multiple clouds introduces bandwidth and network architecture costs.  These are ultimately details best left to the team building the service.

The major outcome of the discussion was on the topic of moral ownership.

• We collectively assessed that the growth and success of our businesses depend in part upon whether customers trust our services to give them ownership of their data.
• As new companies, we don’t have much of a track record to provide this trust. 
• To compound the issue, our user agreements are typically written by our legal counsel, built with a goal of protecting the company and its shareholders, rather than being transparent to users. 
• Even worse, every service’s terms are different, requiring users to either puzzle through them, or (more likely) not read or understand them.
• There is a huge risk inherent here that large populations of users will end up giving up rights they never intended to, which will result in frustration, litigation, and ultimately legislated regulation.  All of this represents waste for the industry and is likely to produce slower growth for each of our businesses.
• We agreed that it is crucial to reduce the cognitive load and dissonance experienced by prospective customers and users by simplifying the language of data ownership.  We admired Creative Commons’ approach to a simple set of licenses, simply described, with engaged iconography to make copyright sensible.
• We explored DataPortability.org and appreciated their design, but agreed that the focus that group is both broader (all social data, in the context of the user, interoperable across all social services) and narrower (only social data, not data for any application) than we can work with.

We resolved to explore any existing organizations that are focused on simplifying the legal language and transparent meaning of data ownership within services, in the spirit of Creative Commons.

• If we can’t find such an organization, we will work within our own companies, with each other, and with other concerned parties to establish one.
• We will raise this topic among our own communities and in our writing and speaking.
• We will share our tactical thoughts with each other on the short-term effects on our own businesses and what our users’ key concerns and needs are on data ownership.

Conclusion

All in all, I learned a great deal that is relevant to the work I’m trying to do both in my business (Sonoa) and in my non-profit (Codeplex.org).  I really appreciated the time, energy, and candor that everyone brought to the discussion.

I did not participate in the “API Versioning” discussion, but it looked lively and I hope that someone from that group will provide a writeup of their discussions.

I look forward to the next meetup.  I welcome the group’s feedback on what the format and content for the next meetup should be.  I think we should aim for a monthly cadence, meaning that the next meetup would be in the second week of May.  Let’s pick a great venue and have a great time!

Comments

[AdamD]

This is a great overview of the event. As an organizer of similar stuff in Portland, I appreciate how hard it is to keep the momentum of these things going. From a selfish standpoint (hey! One out of three ain't bad!) I hope you maintain these sorts of digests of future meetings.

[Benmadsen]

Having done only a little bit of investigation into these guys, TRUSTe ( http://www.truste.com ) seems to do at least a little bit of what we were discussing at the meeting.

However, later that evening (and I apologize for not posting until now), I had some brief ideas on classifying the different types of roles that organizations play into a few small roles. Do you know if there is significant enough interest from the Open API participants to further pursue that conversation? I haven't seen much public discussion yet...