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.
OpeningWe 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.
PhilosophyI 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
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.
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.
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)
Data Ownership in APIsEven 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?
- 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.
- 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.
- 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.
- 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.
ConclusionAll 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!