What Do You Care What Other People Think?

Do Open Source Projects Need Foundations?

The Linux Foundation.  The Apache Software Foundation.  The Perl Foundation.  The Eclipse Foundation.  The Mozilla Foundation.  The Free Software Foundation.  Arguably the six most successful open source projects (and collections) have their own foundations, and there are a number of others.  Stephen Walli (his blogs are found here and here) recently quoted Henrik Ingo's research that shows the top 9 open source projects (measured by code contribution) are all housed in foundations.

There are also notable exceptions, like PHP which has the PHP Group as a governance system but no foundation; however the PHP Group still acts as a legal entity capable of copyright ownership.

What I've observed in the last few years is that with the "legal fiction" of a corporation being a person, and the "legal reality" of a person being a person, without a foundation or similar legal entity, open source projects are literally second-class citizens.  There are at least a few negative effects of this worth noting:

1) Small projects run by one or two people run into trouble when those people take jobs at major corporations.  Who owns the project?  What about the rights to the code when the committer is now working at a corporation?  What if the company hired the person specifically to gain rights to the project?  The project becomes a chattel, regardless of whether it has many users and many opportunities beyond what the corporation wants to see.

2) Corporations or individuals who want to "donate to the project" cannot do so directly; they can take the risk of donating to the individual developers but there is no way to ensure that these donations will be applied purely to the project.  This not to say that committers can't be relied on to do the right thing, but that there's no standard legal agreement outside of a "work for hire" that can be used.  The project can't be treated as a charity and the ownership of the work done under hire becomes questionable - is it owned by the donor corporation or the developer committing the code?

What could be useful here is a system that enables projects to become legal entities more easily, so that the multiple influences of different corporations and individuals can be matched by the idea of "the needs of the project".  

You hear the term frequently within a company ("what are the needs of the company?") in a way that does not invoke "what are the sum of the needs of the employees?"  This is important because the company itself has a mission, and decisions can be made in the context of that mission.

Currently the creation of a non-profit foundation is expensive, requires significant time and overhead on the part of the founders and officers, requires skills ranging from legal to financial to everyday administration to ensure that national and state laws are followed to support non-profit operation.

This seems inherently inefficient; there are many popular and useful open source projects that don't have the wherewithal to generate foundations, and are not sufficiently aligned with major projects like Linux, Apache, Perl, Eclipse, or Mozilla to be merged under their umbrella corporations.

I am on the board of the Outercurve Foundation, which is one example of a solution to the problem laid out above.  I wonder what other low-cost solutions exist for the sake of open source projects, what long-term legislative fixes might be made, and how many others observe the problems and opportunities I've described above.

[Edit: Thanks to Stefano Maffulli for pointing out my oversight of the Free Software Foundation, home of the crucial GNU tools]

[Edit 2: Thanks to Stephen Walli for sending me the direct link to the research he quoted from Henrik Ingo]

API Virtualization

We've seen an architectural pattern emerge over the last two years that deals with the expanding variety of computing devices and the exploding number of APIs used in modern applications.  This pattern is API Virtualization - applying a virtual layer above the API itself to deal with the different concerns that come into play when delivering an API to different device and machine endpoints as well as across a range of different classes of business relationships.

One of the big shifts that has occurred in application development is the move from libraries to APIs for use of pre-written code.   APIs enable access to not just logic but data and the the computational power required to render that data appropriately.  The Facebook and Twitter APIs are good examples of this, but there are many more including Paypal's X.com, Ebay, Amazon, Netflix, Sears, Blockbuster, Best Buy, MTV and Google. 

While applications like Siri which use 20 or more web APIs are still unusual, most applications use several APIs to deal with access to content, social networks, events, identification, payment, and other concerns.  These APIs change frequently, as do the applications that consume them, resulting in a web of dependencies and causing chaos in the development lifecycle.

API Virtualization enables these different concerns and dependencies to be isolated from the application or API provider, resulting in a cleaner development process and higher-performing applications.

I gave this presentation at GlueCon as a Prezi.  The prezi is available here, and I've put the audio with it in the screencast below.

Darwin's Finches, 20th Century Business, and APIs

This is a talk I did at Web 2.0 Expo in San Francisco on May 4th, 2010.  I'm working on a proper slidecast with a voiceover - until then here are the slides.

There is a perspective some people apply to evolution, social theory, and language change called punctuated equilibrium (credit goes to Jess Ruefli for pointing this out).  It suggests that change is not gradual, but that change comes in sudden punctuated bursts between stretches of relative stasis or equilibrium.

The Web from 1995-2000 was certainly a surge like this as every business "went online" in order to continue to function in a newly competitive economy.  I believe that we're going through such a surge right now as the early versions of the web - designed for people using browsers - gives way to the next version: using APIs to design the web for people using applications that communicate on their behalf in complex ways to the services that make up the world's businesses.

If we look to evolution and to the last similar shift - the move from direct to indirect channels for business in the 20th century, we can apply old lessons to this new world in order to succeed.  Towards the end of the talk there are 5 key "successful adaptations" that we've observed that are common to those who are winning in the world of APIs.

As you should expect, the slide deck is freely downloadable and licensed under Creative Commons BY-SA 3.0 United States.

Darwin's Finches, 20th Century Business, and APIs

View more presentations from Sam Ramji.

In Search Of Value

When I started my career in software I wanted to find a way to deliver great educational experiences to junior high and high school children who didn’t have access to great schools or parental support.  That drive was meaningful and led me from San Diego where I’d gone to university and my first educational software job to Silicon Valley, home of Maxis and Broderbund.  Making educational games was fun and challenging.  Unfortunately it did not pay well at all – the class of developer drawn to games at that time – 1995 – was expected to view the mere fact that they worked on games as part of the compensation package.  This was not a big issue as a single guy; my expenses were low and my tastes were inexpensive, so I could basically afford whatever I wanted.  Apartment, beer, car, computer, and I was set.

Then I fell in love, got married, and had a baby on the way.  Suddenly my interests were not about what they were before, but shifted almost unconsciously to “how well can I provide for my family”, some kind of deep programming that kicked in.  With a different star to sail by, I started looking around for other programming jobs and realized that anywhere outside of games and education I could make 50% more salary.  The proverbial “no-brainer”, that meant the difference between raising a child in a one-room apartment over a shared carport and renting a two-bedroom house with a yard.  Goodbye games, hello credit-scoring software and Fair Isaac.  Part of me still wanted to work for meaning so I tried hard and came up with “credit scoring software means that more small business owners can get the right loans faster.”  Not even on the same planet as educating inner-city children.  Ironically my wife had come out of exactly that environment (as a sixth-grade teacher in an impoverished part of San Francisco) into educational software.  But with the need to support our children and create their future, our own lofty goals were out the window.

Then came job after job, and raise after raise, and I’d totally lost connection with value in my work.  We had a nice house in a nice town, and my family was happy, but I found myself in a world of steak dinners with customers from Wall Street firms, working at BEA Systems where we sold multi-million-dollar systems to the richest companies in the world.  I was in an environment where all that mattered was “the software business model”, meaning generating 80% profit margins as a design center, and working from there.  Nobody else talked about value or what they’d left behind either.  It was 2004.

Then I got very lucky.  I came within inches of leaving software and information technology altogether, really the only thing I was good at and had ever been paid for.  I started programming when I was 9, and apart from washing dishes at the UCSD cafeteria and doing wet science in a neurobiology lab, even my high school and college summer jobs were in programming.  I was ready to do anything else as long as it was meaningful.  I suppose this is what Dante Alighieri meant when he wrote “I awoke in the middle of my life in a dark wood, and the true way was wholly lost.”

Then a mentor and close friend of mine called me from his new company – a $44B software company based in Redmond, Washington.  He said, “I have the perfect job for you.  You have to come see.”  Now of all the companies that I would have thought would rekindle my love for software, I never would have thought it would be Microsoft.  I regarded the company as representing most of what was wrong with the industry, and the “Microsoft model” was what had spawned so many imitators looking for that 80% margin rather than looking to create value for real human beings.  “Being in the software business means having a license to print money” was a quote attributed by many in Silicon Valley to Microsoft.

As I started to take it seriously, I got a chance to look beyond the Fortune 500 infrastructure software into an incredibly broad range of technology designed to make people more productive and have more fun.  No one was building as much different software across as many different areas as Microsoft.  I could see the fun, and even the joy, in building experiences that crossed everything from mobile phones and devices to games, consoles, and even office productivity.  My parents had started their own company and I could see how they struggled with bad technology, and I saw Microsoft as a company that had built itself on selling to millions of mom-and-pop companies rather than the usual suspects of financial services and telecommunications.  And the role they offered was close to my heart: working with startup CEO and CTOs to help them build successful businesses through partnership with Microsoft.  This was a very different company than the Microsoft of 1998 which had stolen the features, messaging and box design of my first startup, NetStudio, leaving us dead in the water as they bundled their clone “PhotoDraw” for free with Office Premium.

I took the plunge, joining my 9th software company, and before long got the chance to do one of the strangest jobs in the industry: educating the inventor of the software business model and the bastion of proprietary code that open source made sense, that people who used Linux were smart, rational, and ethical, and that we needed to really think hard and compete based on value.  I argued that free software developers weren’t ignorant of intellectual property and startups were running on free software because they got more value out of it – and further, that the free software ecosystem was a very logical keiretsu that included commercial interests in a more efficient system of collaboration than any proprietary approaches yet seen.  Microsoft needed to compete with Linux and Unix value, and attract the open source software developers to Microsoft technologies based on the power of their platforms to make development and distribution far easier than the alternatives.

For me this was meaningful work – and in the geekiest sort of way.  For all the slings and arrows it was satisfying and what I was doing mattered.  I had failures and success, and sometimes repeat failures that turned into successes.  I certainly didn’t do everything right and left many important things undone.  But I never had to wonder if it was important or if I cared about it.

Having recovered this sense I think it will be hard if not impossible to lose it a second time.   I certainly hope so.  Right now I’m getting the chance to work with amazing people on a free service that is designed to help open up cloud computing and make it easy for any developer to build cloud applications more easily.  We really care about getting the design right and truly believe that if we build something that’s valuable enough to enough people, the money will come.  Yes, you need to build for a large enough market, and yes, you need to think about the business model… and yes, naïve idealists get eaten for breakfast in Silicon Valley.  But most startups don’t succeed, and success solves everything, so you can’t plan for it.  So how do you decide what you’re going to build?  We’ve come at this from a lot of angles and we’ve found that the most powerful question that focused us on what matters is this:

What is it that is so important that you’re willing to fail at it?

Twitter demonstrates that they're a platform company

Initial feedback from parts of the Twitter developer community on the acquisition of Tweetie from last week was pretty heated.  Tweetie is a popular client for the iPhone, written by a single developer (Loren Brichter).  The reason they bought it is to let the "mainstream user" find a Twitter client for the iPhone without the cognitive load of "which of these 3rd party apps is better using Twitter?"  This will increase Twitter adoption and will increase traffic by existing adopters and is in line with their mobile strategy as shown on the Blackberry.

Overall this shows me that Twitter is maturing, developing business models and making acquisitions as appropriate.  There is a growing market here and Twitter's acquisition was a bid to be as mainstream as possible given their competition with Facebook for the heart of the web. 

The comparisons with Microsoft will be inevitable, but when you're in the platform business it's actually friendlier to purchase parts of the partner ecosystem than to launch a competitive product.  The ecosystem then shifts and development starts somewhere else. It's impossible to grow a platform without upsetting part of your community, but you can make it up to them by showing them where the new opportunities are and staying consistent with the platform vision.

What this acquisition shows is twofold - that Twitter is committed to being a platform, and that "my app is Twitter for the Foo device" is not a value proposition that will last very long.  Fred Wilson from Union Square Ventures (an investor in Twitter) spelled this out in a post earlier this week.

So while there is some very real short-term gnashing of teeth, this was an inevitable move that demonstrates the strategy they need if the service is to be successful at scale (100s of millions to billions of users).  It tells me that there will be much more development to come, doing much more valuable things - including examples from Raffi Krikorian's post below:

 - [I] don't have time to sit and watch twitter 24/7/365. while i love to scan through my timeline, frankly, that's a lot of content. can you summarize it for me? can you do something better than chronological sort?

- [I] want to understand what's going on around them. how do i discover people talking about the place i currently am? how do i know this restaurant is good? this involves user discovery, place discovery, content analysis, etc.

- [I] want to see what people are talking about a particular tv show, news article, or any piece of live-real-world content in real time. how can twitter be a "second/third/fourth screen" to the world?

To compare a couple of new, growing, and very cool Twitter-related technologies:

• StockTwits is non-core and won't be acquired, and represents a long-term differentiated market opportunity.
• Publitweet looks like it could end up being core (it is a Facebook-like rendering of Twitter traffic geared for using Twitter as a media publishing platform).

These are just my opinions.  After living in a platform-based technology world for many years and 5 years working at Microsoft in platform strategy, I think: that the Twitter plan is  a good one, that the ecosystem is alive and well, and that the Twitter ecosystem is a great place to make long-term bets on building value.

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!

Open Source Cloud Projects

I had the privilege of meeting some of the developers of open source cloud projects today at CloudConnect.  Adrian Cole of jClouds, Mitch Garnaat of Boto, and Mike Mayo of CloudTouch were on a panel called "Writing Code for Many Clouds." 

We're heading rapidly toward a world where there will be a small number of very big providers of cloud infrastructure - Amazon and Rackspace are currently the top in volume (see Guy Rosen's State of the Cloud for March 2010), with a huge gap to the next providers.  Google and Microsoft will surely account for a large number of sites as they get their adoption engines and developer evangelist teams going.

Basic economics and business strategy dictate that these providers will differentiate from each other based on features and APIs, regardless of standards.  We need to accept this as fact.  We don't have to accept that we have no choice but to pick one or the other, however.  We can embrace open source projects which limit the impact of different clouds, making portability easier. 

This will only happen if developers get involved.  To that end, here's a short (not exhaustive) list of some open source projects that are trying to make a difference.  They need your usage and participation.  You need them to keep the cloud open. 

In no particular order, and including some very early stage projects (like cloudtouch for iPhone and iPad based management of clouds):

(Click to enlarge)

In the slide above (which we presented on the panel) lists the type of abstractions managed by the project.  Compute means managing instances (like EC2), storage means managing storage (like S3 or EBS), IAAS means the works - including load balancing, networking, etc.

Here are links to the projects:

• Fog - http://github.com/geemus/fog
• CloudTouch - http://github.com/greenisus/cloudtouch
• jClouds - http://www.jclouds.org/
• Boto - http://code.google.com/p/boto/
• Dasein Cloud - http://dasein.org/
• libcloud - http://incubator.apache.org/libcloud/
• Deltacloud - http://deltacloud.org/
• Eucalyptus - http://open.eucalyptus.com/
  

Building Apigee for Multiple Clouds

TL;DR warning – this article is about 1500 words.  I prepared this for Shlomo Swidler's panel "Writing Code for Many Clouds" at CloudConnect 2010.

At Sonoa, we have an enterprise product which we turned into a service called Apigee.  From the first, we needed to move beyond just being packaged as a VM and “deployable anywhere” to really living in the cloud.

This is what we’ve learned so far – some of which we anticipated and some of which we reacted to.  Build, deploy, and manage – of the three basic parts of running a service only deploy and manage really change.  The big difference is in operationalization of the system.

Most recently we realized that we needed to be HA across providers and get total control of our latency, so we are building a new datacenter on Rackspace as well.  This is a work in progress so I’ll be reporting from the front lines.

Finally, we’ve helped implement a multi-cloud architecture for ING which has taught us something about where multi-cloud services may be headed.

The first cloud: EC2

1.    Build:

The first and biggest step for any system will be building it as a VM if you haven’t done so before.  Once you have done this, you can practically drop it onto any box.  You’ve become independent of the hardware and other aspects of the operating environment. 

Beyond build, you have to focus on: setting up the network topology, configuring the virtual boxes once they’re up, and managing the result.

2.    Deploy:

 The next phase is figuring out how you bring up instances in your cloud platform.  EC2 has its own interfaces for this, and Rackspace has different ones.  Rightscale normalizes these interfaces and provides a UI.  There’s an open source package with no UI that we evaluated but aren’t using called libcloud. 

Now that you’re hardware independent, you can run as many instances of your service’s components as you can afford.  The main solutions here are Chef and Puppet, both open source.  We use Capistrano for scripting automation. 

Then you need to configure the topology of the different subsystems you’ve built.  Here things get interesting.  EC2 does not support multicasting across your default virtual network; this was tough for us and would be for anyone relying on clustering.  VPN-Cubed from CohesiveFT let us build a private network within our EC2 environment and let us do the multicasting we needed.

Once your network is up and you can push software, it’s just the same as having your own private datacenter.  You can connect from anywhere, manage instances, and get alerts and reports.

3.    Manage:

That brings us to management.  We use Nagios for monitoring our virtual boxes.  We learned that we needed to have a separate machine outside of EC2 as a “monitor monitor” – a Nagios instance that monitored the health and responsiveness of the Nagios box in the cloud environment  We use RightScale for managing all of our accounts and instance creation.  With this setup we’ve had zero downtime since our launch in late August of last year.

We realized at the outset that we wanted to build a service that would be portable, so we chose not to use the least portable features of AWS, such as S3.  While it would have made our life simpler for some of the assets we were managing, there was no corollary (and Walrus, the Eucalyptus storage subsystem that mimics S3, does not count as a corollary, even though it really works).  We did use EBS (Elastic Block Storage) which is so close to a SAN that we felt it was reasonably standard; and forcing our hand was the fact that we needed to solve for persistence and performance. 

But the evils of cloud computing were present as well as the the good.  EC2 does not guarantee the availability of an instance, but the availability of a zone.  As a result we found that the latency of our service had a high degree of jitter (between 5 and 15ms), which was acceptable but not ideal.  The lack of control in this environment means that we’ve been buying instances ahead of our need in order to guarantee not just availability but performance.  This is one of the headaches that cloud computing is supposed to transcend.

In a nutshell – “it’s elastic but you have to manage it.”

So in order to manage the network performance issues (achieve constant performance AND availability) we realized that we needed to go multi-cloud.  We also realized that our core service principle – we’re a cloud service gateway and active proxy for people's API traffic – meant that we had to have a “strongest link” architecture so that no set of failures at a single cloud provider could take down our service.

We’re now building on what we’d anticipated and developing a new instance of our service at Rackspace.  The big changes here are the level of control we have out of the gate for network topology, process isolation, CPU performance… and price, which is higher. 

The second cloud: Rackspace

1.    Build

Architecturally the big differences are database replication and cross-provider load balancing.  This places really specific requirements on your networking design and technology as well as your database design. 

One of the things our service does is store all of our customers’ cloud API traffic for their later use in analytics.  Thinking about data modularly helps with replication.  In a replicated world we need to break out types of datasets – such as customer information and service configuration – into smaller chunks that can meet higher-speed replication requirements cost-effectively, and break them away from all the historical traffic data.  Even the traffic data needs to be handled differently in this world. 

We are now sharding the database into circular tables, where the incoming data is always written to a write-only area, and revolves to the next area every five minutes.  In our user base a 5-minute delay on analytics is more than acceptable (compare this with the SLA for Google Analytics), and the working set of data used for traffic management is handled separately in realtime.  All of this means that we can have either a hot standby or live-live dual-cloud configuration without breaking our customer promise that they can tweak their service at any time at all, and that their analytics are consistently available.  This will also let us evolve both sides of the service as it grows.

2.    Deploy

Deployment tooling stays the same – our old friends RightScale and Capistrano are used to spin and configure instances.

On the networking side, obviously you need to connect your clouds securely in order to replicate between them as well as to exchange performance data which can be used for load balancing.  We found again that VPN-Cubed helps us establish a trusted connection between our heterogeneous cloud environments. 

3.    Manage

Since we are using standard monitoring and management tools – Nagios, RightScale, and Capistrano – these all work in both environments, and our approach of using a “monitor monitor” doesn’t change.. although now we need to monitor monitors in each cloud.

Is there an easier way?

For an infrastructure play like Apigee, we don’t think so.  Given our customer promise of near-zero and predictable latency we need as much control as possible.  For an application-level service play though, we think some parts can be easier.  We’re built on Sonoa technology that manages all of our cloud API traffic processing, as is ING, a financial service company that’s moving to cloud. Their challenge is elasticity in financial modeling – specifically the Monte Carlo simulation workload which is compute-intensive and highly intermittent in use of resource.  When you’re running the simulation, you need all the compute resource you can get.  When you’re not running a simulation, you need almost none.

Cloud infrastructure like EC2 and Rackspace take care of the racking & stacking problem associated with scaling up for Monte Carlo.  You still need to manage that with a  tool like RightScale or libcloud plus your configuration and deployment tool of choice.  But at the higher level where you’re load-balancing between clouds you don’t necessarily need a VPN, as there’s no data replication requirement.  At this layer they’ve implemented a secure API which is called by internal clients, and then this API request is load-balanced by Sonoa’s API gateway.  The gateway then calls the right cloud based on policies set by the monitoring and scheduling software.  So in this situation you are monitoring your cloud instances and letting the API gateway handle the dirty work of dispatching and securing the calls.

10 Lessons Learned From Building to Multiple Clouds:

1.    Get everyone comfortable with virtualization fundamentals, from developers to admins.

2.    Limit your dependency on provider-specific APIs by using 3rd party tools that manage this for you.

3.    There may be SLAs on your cloud instances but there are no SLAs on the APIs your cloud providers give you.

4.    Refuse to use services that have no corollary in other clouds.  It will cost you more in rearchitecture than you gain by using it.

5.    Understand the cost trade-offs for your business of the different clouds’ strengths – especially in the dimension of availability, price, and performance.

6.    Anticipate your needs for data replication and design your databases accordingly.

7.    Pay attention to your networking requirements and network topology.

8.    Consider the granularity of the requests that you need to load balance – is it at the service or API layer or is it finer-grained than that?

9.    You’ll still buy more than you need but the waste ratio is much less in the cloud.

10.    Monitor the monitors!

Mobile is the future of cloud; cloud is the future of mobile

Note - this post is an expansion on an earlier draft posted at Sonoa's blog in early December 2009.

Mary Meeker’s Web 2.0 presentation made a strong case for the imminent boom on the mobile internet.  Some statistics that caught my attention:

• Mobile internet users will exceed 500M human beings in early 2010
• The mobile consumer device market will exceed 10B in the next 5 years
• The current iPhone + iTouch user base is larger than Netscape’s base in 1999
• More than 20% of the world will be on 3G networks by the close of 2010

This is a serious change in how people are using the Internet.  I don’t think of the Internet as synonymous with the Web; the Web is one pattern of applications, based on HTML and HTTP, that uses a common infrastructure – the Internet.  Both the iPhone and Android phones have a much higher share of Web and Internet usage than previous generations of mobile devices.  But are they really using the internet?  Or are they using the Cloud?

From my point of view, the Cloud is another pattern of applications – like the Web – that use a common infrastructure – the internet.  But just as Web application patterns are different from other Internet applications (like email, for example), Cloud application patterns have their own rich array of styles and requirements.  And what we’re seeing with mobile consumer devices is an explosion of applications that reside on the device and use the Cloud for access to remote logic and data.  

 

 (click to enlarge)

APIs are a major part of this - they are user interfaces for machines.  RSS and ATOM are effectively simple, standard APIs for machines to get at content that hasn't been marked up for a human interface.  APIs do this for business logic and data, rather than simple content. Mobile app and web app developers can use a site's APIs to build very cool new applications that look and behave totally unlike the original website.

There are many implications of this pattern, including the need for elastic computing capabilities, commonly thought of as "cloud infrastructure".  Elasticity is an attractive capability in its own right, but when coupled with API-driven applications running on many devices and machines in many places, it becomes crucial.

 (click to enlarge)

While there is plenty of usage of WAP vs. APIs today (the yellow bars vs. the green bars) to power limited functionality versions of websites and deliver these to mobile devices, this is proving both brittle and unappealing by comparison to the vibrant experiences of native applications on iPhone and Android devices.  It seems to me that future of the mobile internet is not the mobile web – resized, limited web pages rendered by a WAP server and discovered via Google and Bing – but the cloud.  

What we’re starting to see across multiple industries and business models (from Amazon and Netflix to Sears and Blockbuster) are the first generation of sites rebuilding their backends to be accessible via cloud APIs in order to give access to mobile applications that will drive their business.  Some sites are on their second and third generation, having rebuilt their web presence to rely on the same cloud APIs that their mobile applications do.  

With the launch of the Apple iPad and the Motorola Droid we are already seeing Ms. Meeker's predictions about mobile devices coming true.  There is more to come and in my mind it's guaranteed that the mobile boom will be accompanied by a massive expansion of APIs and cloud infrastructure along with it.

In the cloud, scale means concurrency

In enterprise computing, scale has traditionally meant "lots of transactions per second."  On Wall Street for many years, "20,000 TPS" was the magic number as it was the rate of a typical market data feed.  Infrastructure like TIBCO's UDP-based information bus and then IBM's MQSeries became the base platforms for much of this scale of computing, and are still heavily used alongside modern JMS and MSMQ implementations.
 
Relatively little attention was paid to concurrent connections.  Enterprise environments tend to be well-regulated, and most applications will have under 1000 simultaneous users (whether human or machine driven).  As a result, application servers and related technologies evolved to support high transaction throughput at limited concurrency.
 
The web on the other hand brought in much higher concurrency requirements, and platforms like WebLogic became default components of web computing environments for sites serving 1,000s people at the same time.  This was a breakthrough and led to significant market success in a short time period.
 
With the rise of cloud computing, two things change.  First, mobile applications and the API economy are driving an order of magnitude increase in the number of simultaneous users.  Second, these users are often machines rather than people, and therefore aren't limited to the demand patterns of humans users clicking links or refreshing their pages.
 
This produces a new set of demand patterns which increase both total throughput and peak concurrency.  As an example, travel sites like Kayak.com and Bing.com/travel issue hundreds of API requests to airline reservation system backends as a result of a single human-driven query.  Furthermore, these requests are being made not just by desktop or web applications but by mobile applications – especially iPhone applications.  As most people are aware, the next 10 billion devices that come online will not be PCs or netbooks but will be mobile devices (phones, MIDs, GPS, game units, media players).  Each of these is prized for its native application experiences.  Each of these devices will be making user-driven and automated calls to cloud services in order to deliver those experiences.
 
Where backend systems are not protected from this demand, they are being penalized in performance and load management.  This causes either outright outages, "web brownouts" where the core website that uses the same backend slows down, or erratic performance across both the web and cloud properties.  Again, mobile access exacerbates the issue due to the intermittent nature of mobile internet connectivity, which multiplies the number of connections that need to be set up and torn down as the device comes on and off the network.
 
So the explosion of concurrent usage is already beginning, as the traffic and backend impact is expanding.  To manage this and maintain stability of existing infrastructure, a new layer of infrastructure is emerging, much as HTTP load balancers have evolved to serve the needs of web computing.  What we're seeing is the rise of cloud service controllers, a category of infrastructure that works well with existing systems and builds on top of the strengths of application servers, enterprise messaging systems, and application delivery controllers.

Business Logic vs. Business Policy in Cloud Services and APIs

As companies move from websites to cloud APIs - we're seeing them separating business logic from business policy.

When you think about business logic, you probably imagine an application server or stored procedures, or custom code that accesses stored data and exposes it in a useful and manageable way – such as “show me all of a given customer’s purchases in this timeframe”.  

These pieces of code reflect the understanding of the fundamentals of the business - like customers, orders, tickets, requests – and how they interact.  In any business you build skill over time in understanding your domain and then build on top of that understanding to take the business further.  Business logic is generally stable, consistent across requests, and subject to careful modification.  After all, you wouldn’t want to put partly tested logic about bank balance transfers into production.

When you think about business policy, what comes to mind? 

Maybe a stack of papers documenting HR or accounting guidelines, or maybe the elements of Sarbanes-Oxley requirements.  Policy is not about how you compute a specific result – like the customer’s purchase history – but about other factors like who can access it, how frequently, from what locations, how it’s rendered, how long the result is considered valid, and other “meta-logic” issues.  In any business you make changes to your policies frequently, as a way to meet the changing face of the market environment.  The nature of business policy is therefore to be dynamic, varied according to the request context, and subject to frequent experimentation.  For example, product managers need to continually test the value of different offers to given segments without having to redevelop the product.

When policies like security (“who can access this and what credentials do they have to show?”) and service level (“how many requests can be made in a given time interval?”) are collapsed into code responsible for business logic, the result is loss of agility, high cost to adopt new policy implementations (e.g. for identity and access schemes or to keep pace with increased hardware capacity), and confusion of concerns (rather than separation of concerns).

In the current era of cloud APIs, where these interfaces are being built as a direct link to what started as the backend for the website, many developers are realizing that what was really policy was built into their business logic layer.  They’re also seeing that adding new clients – going from enabling partners to enabling rich clients to enabling mobile device (such as iPhone or Android) applications – require many adjustments to how the request and response of an API are rendered, but should require no changes to the stable core of business logic.  

Supporting an API with a set of policies that activate based on the user (such as preventing or enabling access to different parts of the API – for example, only the development & testing methods but not production methods, or query methods only, or limiting requests to a certain transaction volume or financial value) and type of client (such as providing pagination and format translation for a mobile device) means that the risk of delivering the API is reduced, and the risk of negative impact to existing users of the API (typically the original website) are reduced.   Also,  the computational load for the policy processing can be moved to a low-cost, scale-out tier and away from the high-value application servers that host the business logic.

So what this seems to indicate is a movement towards a separation of concerns between logic and policy.  Responsibility for business logic processing lies in a stable and slowly changing layer, and policy is processed in a tier that allows for agile modification and enables the total computational result to meet the shifting needs of the business.

Why modern applications need an API proxy

Structures of control are spontaneously generated in every environment and every wave of computing.

Today on the web we have a model where browsers are the single point of control for much of what happens, not just at the level of applications, but at the meta-application level as well.  Not simply usage (“point-click-type”), but things about usage – who is the user (browser cookie), what are they using the app through (user agent), where did they come from (referrer), what can we infer about their behavioral state, and so on – as well as modifications of usage (browser add-ins, content filters, security modes, local caching for performance).  To be sure, some of these things can be and are performed using infrastructure between the browser and the website (such as content filtering, security, and caching), but the guaranteed component is the browser.

This is one of the reasons that Google Analytics is so popular and useful – you can rely on it to tell you useful things about your traffic because it can rely on the browser as a predictable point of control.  Including an invisible piece of content on your web page makes the browser fetch data from Google, implicitly sending information that enables Google to report on your usage.

For web and cloud APIs, what is the equivalent structure of control?

Currently there is no one point like the browser.  This is for great reasons – APIs are all about reusing application or service logic and rendering it to different form factors: pure logic (built into an internal application computation), web UIs (part of a mashup), and most notably, client applications on a wide range of devices (from PCs to mobile phones, set-top boxes, and tablets like the iPad).  These devices are in the early part of a boom that will see over 10 billion individual units in use, representing at least hundreds of unique hardware/software designs.  The sheer utility of these internet-connected devices predicts that their usage will drive high demand for APIs rather than standard websites.  There are initial specifications like BONDI that suggest a standard contract across all of these for “mobile web applications” that include interaction with the features of the local device (such as a camera or GPS) but they are years from broad adoption and don’t attempt to unify all API access down to a common control point.

Given that APIs are to application logic what RSS is for content, we know they will be very important; at least as important as the visible web that we use today and possibly more important.  This suggests that the other things that are spontaneously generated in value-exchange environments like user/customer management, behavior analysis, content filtering, caching, and security – will show up for APIs as well.

The web API equivalent of the browser’s control structure is an API proxy.

This is a control point which unlike a web proxy is fully aware of API content, communications patterns, and able to drive the meta-application controls discussed above.  An architecture like Google Analytics which is founded on a browser’s predictable algorithms cannot work in an API setting.  The same rule applies to add-ons that modify usage – they can’t do so relying on the local device if they are to be widely adopted.  But an API proxy – a server or service on the internet, sitting between the client (regardless of type) – is able to be that point of control.  As traffic runs through it, meaningful data can be captured for immediate outcomes (block access, change the message, or respond from a cache) and later used for behavior analysis and business planning.  Add-ons that modify usage of the API can be installed at this point (content filtering, adding new information such as advertising, or identity management).  All of this can be done while adhering to the contracts of the APIs and supporting the web architecture and rules of HTTP-based applications, and without attempting to solve the logarithmically complex problem of modifications to all the world’s clients.

So API proxies are likely to be necessary for the sustained growth of web and cloud API usage.  There are likely to be several nuances that end up differentiating the different implementations and providers of API proxies.  The key is to start experimenting with them now in order to build better apps and stay ahead of the competition.

Reflecting on 120 days of the CodePlex Foundation

Andy Updegrove wrote an article this week on the CodePlex Foundation's progress to date and where he'd like to see it go.  It put me in a reflective mindset, so I thought I'd take a minute to publish those thoughts. 120 days, in, what are the accomplishments of the CodePlex Foundation?

Back on September 10th, we set a pretty high bar for what the CodePlex Foundation would accomplish in its first 100 days of operations.

I said at the launch press conference:

“What are our plans for the first 100 days? We will recruit an executive director, replace the interim board with a permanent board, establish a Board of Advisors, and begin to solicit projects.”

So what did we actually get done?

Executive Director: "B" We have been working to recruit permanent staff, particularly an Executive Director and a Technical Director. We announced that search in December but we’ve been looking at candidates all along. Here I'd give us a B, because we are very close to making offers to outstanding candidates.  We realized that the technical leadership and mentoring role would be very important, so we elevated the priority of hiring a Technical Director.

Permanent Board: "C"  We’re almost at the point where we can announce a permanent Board of Directors. These will be names that resonate in open source, academic, and corporate software worlds. Look for an announcement this month. It was disappointing to miss this goal in the first 100 days, but the interim Board made a decision early to focus on the project acceptance process, and there we can claim real success. Driven by feedback from our advisors and directors, two of the current six directors will be returning to board, with three newcomers.  For the "replacing the Board of Directors" goal, I give us a C with strong effort. 

Board of Advisors: "A" We were fortunate to assemble a great Board of Advisors, who we learn from in every Advisors' meeting.  A very solid core of people has been involved right through and has been present for every issue.  People like Bob Gobeille, the head of the FOSSology project and a key contributor to FOSSbazaar, Aaron Fulkerson of Mindtouch, Larry Augustin of SugarCRM, and Stephen Walli provided extraordinary advice very early on. We also had great input from our Microsoft advisors Phil Haack, Scott Hanselman and Rob Conery, who are deeply invested in the open source ecosystem for .NET.  Sara Ford, Monty O'Kelley, John Lam, and Monty Widenius have contributed their expertise at critical points.  Also, we recently added Advisors Michael Bechauf, VP of Developer Network and Standards Strategy at SAP as well as Stuart Cohen, CEO of Collaborative Software Initiative and past Executive Director of the OSDL (now Linux Foundation).  As interim board members from the Board of Directors transition off as we move to a permanent board, we hope they will join the Board of Advisors. It’s a significant time commitment, so I suspect a couple of the current Board of Advisors will select out and move into a friends-of-the-foundation role.  So for the Board of Advisors, I'd give the Foundation an A.

Solicit Projects: "A-" Our biggest stretch accomplishment has been the acceptance of a technology gallery, the ASP.Net Open Source Gallery, and two projects, the ASP.Net Ajax Library Project and the Orchard Project. To get that result we first had to develop a project acceptance process, described in the Project Acceptance and Operations Guidelines document, which was released in October. With these guidelines in place we were able to accept a gallery donation and Board members Bill Staples and Shaun Walker drove that process. The Project Acceptance and Operations Guidelines document also described very strong guiding principles for the Foundation.  We also minted our first Gallery Manager (Dmitry Robsman).  Ideally I would have liked to have seen us also accept a community-led project and a non-Microsoft technology stack project.  We're making progress on both but didn't achieve these in the first 100 days, so I'd grade our progress at an A-.

Additional achievements:

"+" I think we did well at a technical level in introducing innovations in contribution agreements, legal structure, licensing agreements and other functional documents that will make it easier for corporations to participate in open source, and easier for developers to contribute code and projects without getting in the weeds with licensing and legal issues. While we do need to change the licensing agreement based on the experience we have had with community contributions, I think the assignment agreement is strong and working as intended.  So far it looks like the patent aspects of our agreements work as well. 

"-" We did not do so well in broadly communicating the structure and value of these innovations - people who we explained these to in small group settings or one-on-one understood pretty quickly, but we didn't figure out how to articulate our work in a way that it made sense at scale.

"√" We had another internal stretch goal of signing a second corporate sponsor in the first 100 days, which we didn't achieve but made good progress on.

Unsung labor:

This doesn't include all of the mundane work that the Directors and Advisors, our Deputy Director Mark Stone, our legal teams at K&L Gates and Greenberg Traurig, our operations team from Virtual Inc., our site hosting work from Engage Software, and our marketing team from Topaz Partners have done in raising a startup off the ground from scratch.  When we launched in September we had no infrastructure, no management practices, and no permanent staff.  We were a raw startup in every way.

One thing that many people that I've met don't realize is that the board members of a non-profit are non-paid volunteers.  Titles like Treasurer and President just mean that you are doing that much more work for free.  So I appreciate the support that each of our companies have given us to spend so much time on this - Microsoft for Bill, Britt, and Stephanie, DotNetNuke Corp for Shaun, Novell for Miguel, and my employer Sonoa all get our thanks.

Closing Thoughts:

I think we will continue to learn more as we go along, and our governance and legal documents may change as we get more advice. What we have to do better is explain the value of the Foundation. I think we have explained a lot of the intent and ideals, and we have connected on a detailed level with some community projects as well as some Microsoft sponsored projects, but we really need to step up to a new level of effort and be very clear and specific about what our agreements say, what results they are intended to produce and the process that wraps them up.

So the next few months will see changes on the Board, permanent staff, and progress in how we communicate our value propositions. Making progress there will let us attract new sponsors, especially when people begin to appreciate the value of the legal innovations we offer to corporate sponsors.  Longer term I'd like to transition to being a membership-based organization.

We have learned a great deal so far; we're grateful to those who have helped us get this far; and we’re excited about the next period of growth. Let us know what you think on our CodePlex Foundation Google group, or comment here.

Startup Adjustments

The patterns of day-to-day life are very different in a startup. 

At Microsoft, the sheer size of the organization builds a set of nearly automatic patterns, with constant demands for attention to specific projects and specific teams, and recurring requirements like quarterly financial statements, preparation for quarterly business reviews, monitoring and guidance of execution both locally at corporate headquarters and in worldwide subsidiaries.  The challenge was not in determining what will get done but how to compress my schedule and manage my team more effectively by teaching and encouraging, rather than directing and demanding.  With a full-time administrative assistant and a business manager (Microsoft’s equivalent of a chief-of-staff), more than 70% of my time was effectively directed by the undeniable needs of the business. 

Running a team of 120 people in 80 countries in a company of 91,000 requires not just worldwide timezone awareness, but connection to the corporate and local constituencies that those 80 people need to have on their side.  At Microsoft, 120 people is a lean team that must rely on many other organizations in order to execute anything from marketing campaigns to discounts to customer intelligence.  These dependencies include corporate and field marketing and sales for multiple channels (direct/enterprise, indirect/enterprise, indirect/midmarket, indirect/small business; direct/government, indirect/telecommunications… the list goes on but you get the point). 

Add to this the corporate governance team and process and you begin to see the layers of clockwork required to operate such a massive machine.  Political influence and personal connection is the lubricant that lets these gears run, so to be an effective leader you need to be available and involved in the workings of each of these adjacent gears.  This translates to understanding their challenges, finding ways to be relevant and helpful, and integrate your needs into their plans so that your goals are truly shared – you could say “adopted” in the context of adopting a child – by these other teams.

This is not much more complex than required – overall the structure at Microsoft is fairly lean for a company of its revenue and profit, and is constantly tuned by an executive who ran operations for Wal-Mart and his outstanding team.  It’s just that the problem itself is really hard, and the clock is always running.

Switching to a startup of 65 people (mostly engineers) with a shallow hierarchy and a flat leadership team structure as an individual contributor leading strategy is about as different of a day-to-day experience as I can imagine (apart from not working at all, of course).  No forced direction, no gaps between departments (including the fact that some departments are fully represented in a single person) and no mandatory schedule.  Seemingly endless expanses of open time on my schedule.  Titular responsibility for the company’s strategy. 

And what is strategy, really?  To me, strategy is a conversation – a conversation shared by all the operational leaders of an organization that accurately reflects the market, a belief in its future shape, and the appropriate actions required to match the company to that future shape.  If the conversation is managed correctly, the appropriate actions will show up almost automatically based on how each leader is thinking.  So to be effective in a role like this you have to be engaged with the operational leaders, understand and add value to their day-to-day work, and then reflect the company’s beliefs back to itself and to the market.  Start with a  blank slate, discarding your preconceptions, and go from there.  But starting from scratch takes much more effort than keeping pace with an existing flow.

Eight weeks later, I am finally (mostly) adjusted to the changes – from the trivial (managing my own schedule and coordinating with other people’s admins) to the substantial (feeling emotionally satisfied at the end of a week where I didn’t have “important meetings” scheduled every 30 minutes) to the crucial (entering the rhythm of the company and adding value without direct authority).

I’m satisfied with the changes and find that for the most part I’m more lighthearted, more flexible, and softer in style than I was at Microsoft.  My family certainly approves.  There is a certain “West Wing” feeling of constantly dealing with issues of world-shaking importance that is missing, but in that space I think I’m finding room for more thinking and writing, and interest in other aspects of what’s happening in the software industry and beyond.

Open vs. Free in Cloud APIs

Open and free are orthogonal in cloud computing APIs, but in this world the free aspect isn't typically interpreted as freedom, but price. Freedom in the cloud is more typically associated with data and your rights to move it from one service to another and this is a very important attribute. Application portability has also been raised as an important attribute but currently the application models are early in their maturity curve and vary from straight web programming with a REST or SOAP front end to prepackaged virtual machines to application frameworks like Microsoft's Azure and Google's AppEngine.

Open and free are both crucial attributes in order for a market economy to grow. There are many aspects of cloud computing but for the developers and users of cloud services, the atomic unit of the cloud is the API. Openness and economic growth is a deep subject that may provide clues for how to build a better cloud – in reading the linked paper, consider that a company's APIs represent the "export goods in which it has a comparative advantage". In the software industry open platforms have typically outperformed closed platforms in the long run due to the economies that develop on top of them, cementing those platforms' place in a range of markets.

Open APIs…

Open APIs in the cloud are:

• Openly documented
• Available via self-service (i.e. developers can sign up on a website, get an API key, with no hassle)
• Using open technologies (SOAP, REST, RSS)

An easily accessible example of this is http://bit.ly. There are enterprise services that meet these criteria as well, but bit.ly is clear and can be used to understand the broader applications of APIs. Bit.ly is a simple URL shortening service that also lets you see how many people have clicked on your shortened version of that URL. It's really useful if you want to both project important articles on the web and understand the reach of your projection.

Test 1: Openly documented

• APIs are documented here: http://code.google.com/p/bitly-api/wiki/ApiDocumentation)

Test 2: Available via self-service

• Go to bit.ly and you'll be able to sign up for an account right away for their direct website
• Click the "account" button at the top right and look at the second section, "API Key"
• You can now access their APIs programmatically by using this key

Test 3: Using open technologies

• You can see this is a REST API from reading the API documentation (granted, it is a mix of verbs and nouns)

… lead to 3^rd party innovation

Tweetdeck has already used this to integrate with them, so Tweetdeck users put their bit.ly API key into Tweetdeck, which then uses the Twitter API to talk with Twitter, and automatically uses their bit.ly account (indicated by the API key) to shorten URLs that are typed into tweets. It made Tweetdeck better and probably increases the traffic to bit.ly.

This could also work on the iPhone application of Tweetdeck but it's not yet implemented in the version I have. Many iPhone applications work by combining the native client capabilities of the iPhone with one or more cloud APIs that provide access to services in a clean, machine-friendly way.

From the efficiency of innovation perspective, keep in mind that Twitter never contacted Tweetdeck to use their API, nor did bit.ly (as far as I know).  The Tweetdeck guys simply built a killer application that uses those services via APIs rather than scraping their web sites (a brittle and slow approach).  In the last month, Tweetdeck also added Facebook and MySpace support via their APIs.  Again, efficiency and reach through designing your core business service to be "remixed" is found through APIs – Tweetdeck users got new value through the app they like and Facebook and MySpace got a new stream of user-driven content, all without sales or business development teams engaging at the outset.

If we take that example and scale that across different services offered by different businesses in different industries - media, financial services, marketing, e-commerce – we see that open APIs against these services are leading to increase usage and revenue due to new innovation by their partners and customers.  The classic example of this is eBay's statement back in 2008 that 60% of their traffic was coming through APIs rather than their website – 6 billion API calls per month. That API has been available since 2001, and what we're seeing in 2009 is an API tipping point as Dion Hinchcliffe articulated last November. 

Coming next: Free vs. Paid APIs.

Free Is Not The Opposite Of Commercial

Free software is not the opposite of commercial software. It is not an attack on commercial software; it can be a way of getting work done that enables software companies to collaborate with community projects for the betterment of both. Users can benefit, because they have access to software that is the product of the efforts of vibrant, diverse communities, dedicated to creating great software, efficiently and cost-effectively.

For those who have followed these topics for some time, this is not new information, but I wanted to take the opportunity to clearly establish the CodePlex Foundation's perspective on these issues.

There are successful software companies whose businesses are based on free software.

The CodePlex Foundation’s Board of Directors and Board of Advisors prove the point. The individuals who are contributing their time and effort to our success have decades of industry experience leading companies that have successfully built revenue and profit solely from free software. Ximian, VA Linux, MySQL, SugarCRM, and DotNetNuke are examples of how to run profitable software companies, built on a free software license base. Ximian (Miguel de Icaza) and VA Linux (Larry Augustin, Mark Stone) were built on GPLv2-licensed software technologies; MySQL (Monty Widenius) is licensed under GPLv2, SugarCRM (Larry Augustin) is based on GPLv3, and DotNetNuke (Shaun Walker) is based on BSD.

Ximian provided Linux-based applications for email (Evolution), messaging (Gaim), and productivity (OpenOffice.org) which were packaged into the Ximian Desktop and were all free software.  The company was acquired in 2003 by Novell.

VA Linux, which began life as one of first commercial businesses focused on distributing and managing Linux-based IT systems, provided companies with an alternative to more expensive UNIX-based workstations; the company has since changed its business model to become a publisher and provider of software development support. Now known as SourceForge, the company operates SourceForge.net, Slashdot, IT Manager's Journal and Freshmeat as well as Ohloh.

MySQL used GPLv2 to establish one of the early dual licensing businesses, offering a free community version under GPLv2. For companies that wanted to embed the database into proprietary products, MySQL was offered under a royalty-based non-GPL license.

SugarCRM in 2007 was re-licensed under GPLv3. It had previously offered its software under a custom license.  Like MySQL, SugarCRM has a dual-license business model: the Sugar Community Edition is available as free software, and the company also sells annual subscriptions to SaaS versions of Sugar Professional and Sugar Enterprise. This model has built value for SugarCRM, its partners, and also for developers looking for a good CRM system.

Shaun Walker of Dot Net Nuke built a great content management system on a BSD license.  Contributors sign a Contributor License Agreement (CLA) that enables the company to defend the project in the event of a legal dispute regarding intellectual property claims. 

There are also business models beyond software companies that can build profitable enterprises based on free software - including development services, hosting, and deployment services companies - which are beyond the scope of this discussion.

So from my perspective and that of the CodePlex Foundation, free software is not the opposite of commercial software.  The two terms are orthogonal and can either apply or not apply to any given piece of code. We also acknowledge the distinctions present in the community between “free software” and “open source software”.  We will tend to use the latter to describe the broad range of software projects that we want to support. We believe in making it easier to get things done, with the best tool for the job, with the best license for the tool; and we believe that by enabling more software companies to contribute to community projects, we can help advance the state of software.

Why It's Called the CodePlex Foundation

It's taken from www.codeplex.com, an open source project repository built by Microsoft a few years ago that has now expanded to host over 10,000 open source projects built by individual developers as well as roughly 500 by Microsoft employees.  The "code" part of the name refers to the source code which is the substance of an open source project.  The idea behind "plex", like metroplex or building complex is that it's a commons which serves a wide range of individuals. 

The CodePlex Foundation (www.codeplex.org) is intended to serve a wide range of projects, regardless of platform or technology base, to enable the exchange of code and understanding among software companies and open source communities.  Many people benefit from open source software, but a small number of people contribute back.  It seems to us that software companies should be in a very good position to contribute back based on employee skills and the benefit that these companies derive from specific open source projects, but in our experience there are a variety of obstacles that prevent or reduce contribution.  These range from development culture to copyright and patent licensing practices.

We are working with the leaders of other foundations, including the Apache Software Foundation and the Eclipse Foundation, to ensure that the CodePlex Foundation is a useful complement and enables community-based open source projects to expand their reach through increased contributions from software companies.  We are also receiving a great deal of thoughtful input (including Andy Updegrove's article and the community input on our Google Group).  There's a long way to go - this really is a brand-new startup and we are clearly in the alpha release - but from what I've seen I'm very optimistic that we can provide value to open source community projects.

Moving on and the CodePlex Foundation

After 5 great years at Microsoft I am moving on.  Yesterday, the creation of the CodePlex Foundation was announced, as well as my departure from Microsoft.  I'll be joining a cloud computing startup later this month in Silicon Valley.

It was a hard decision, as the time I've spent at the company has been both challenging and rewarding.  I remember a sense of disbelief when I first interviewed for the Open Source Technology Strategy role in December 2005 and Bill Hilf told me that one of the core responsibilities of the job would be a quarterly briefing with Bill Gates and Ray Ozzie on open source technology trends.  On the other hand, he said it would involve external public speaking - primarily to fairly polarized audiences.  That was a doubly scary proposition as I was not a public speaker and I knew the audiences quite well, since I'd competed with Microsoft for many years in prior companies and used Slashdot as my homepage. 

I was certain that open source was an industry wave that Microsoft would not be able to ignore, and that it was getting closer to an inflection point.  I had spent over a year at the company in the Silicon Valley-based  venture capital team under Dan'l Lewin and Cliff Reeves, and I could see that the company's approach to disruptive market dynamics was starting to change.  No matter what happened, I was sure that being at the center of the open source team at Microsoft during the coming years would be fascinating and important.

46 months later, I am amazed at the changes that have occurred for the company, for the team I belonged to, and the sentiments of the industry.  There is much work left to be done but the distance we traveled was remarkable.  I have a feeling that I'll be reflecting on this period for the next several months, so I won't try to cover it all here.  Matt Asay wrote a very generous article with a brief reflection of the changes which is here.  I've learned an enormous amount thanks to the intelligent, energetic, and fearless people that worked for me, the bold and honest open source community leaders who engaged with me, and the Microsoft executives who supported me.

I have heard some strange speculation on why I'm leaving and the answer is simple - for personal reasons, my wife and I have decided to move our family back to California.  I had many discussions with executives at Microsoft about how to continue my work from here, and received a warm reception along with a range of opportunities.  Ultimately I decided that I could not do justice to a corporate/worldwide position from afar, and that I could not bear to live away from my family and commute to Seattle five days a week.

So the change is made, and it has been very challenging.  But it's now complete and I am excited to launch the CodePlex Foundation and join my new startup.  As a close friend told me this week, "The best is yet to come" and I do believe that.  To everyone who has helped bring me this far, I say thank you; I am very grateful.

Architecture Strategies for Catching the Long Tail

Fred Chong has completed his work on the overview of the architectural guidance for building Software-as-a-Service (SaaS) applications on Microsoft infrastructure.  If you haven't seen it yet, check it out.

Fred spent several weeks in the field with SaaS providers who have built their applications on Microsoft in order to understand the key issues core principles in building a scalable, multi-tenant on-demand environment.  Many of the companies they worked with are startups managed by the Microsoft Emerging Business Team (EBT), and I had the privilege to connect with some of them.

The EBT is actively reaching out to and working with SaaS providers building on the Microsoft platform in order to improve their market exposure and business relationships.  If you are interested in connecting with the EBT, check out their SaaS page and drop a line to SaaSMS@microsoft.com

Open Source Strategy at Microsoft

I've been quiet on this blog for the last few months because I've taken on a new role at Microsoft: Open Source Technical Strategy.  At this point, some of you are thinking:

a) I'm joking
b) I'm crazy
c) I've joined a dark conspiracy

But in fact the truth is:

d) none of the above

As Director of Platform Technology Strategy (official title), I run the Open Source Software Lab at Microsoft, where we have hundreds of physical and virtual servers running 40+ distributions of Linux, 12+ variant of Unix, and several versions of Windows.  The research projects we do run from testing interoperability of network protocols like IPSEC and IPv6 between Linux and and Windows technology, the user experience and technical capabilities of HPC projects like ROCKS and Ganglia, to the broader attributes like size of developer base and changes in the development model for different Open Source projects.

We're also working with JBoss and SugarCRM on optimizing their open source applications for Microsoft infrastructure like Windows Server and SQL Server.  This has been fun, rewarding work that has helped to demonstrate the truth of our statements about working with Open Source.

Finally, I'm active in the Microsoft Shared Source Initiative, where I am responsible for Technical Strategy.  We are seeing some great work from inside the company - teams from all product groups wanting to contribute to Open Source in some way.  This week, Microsoft launched CodePlex in beta.  CodePlex is a developer community infrastructure hosted by Microsoft on behalf of Open Source developers - a place for code from both Microsoft product teams and the community to reside and for the developers themselves to collaborate.  Currently a dozen projects are there, ranging from IronPython to the Commerce Starter Kit.

I have a new blog at http://port25.technet.com, a site we've built to have a constructive dialog on Open Source, Interoperability, and Microsoft. 

Change is coming and I'm thrilled to be a part of it.  I'm particularly grateful to people like Andrew Aitken, Mary Coleman, and Matt Asay for what they taught me about Open Source and the Open Source community.