Tim O'Reilly: "[Open] architecture trumps [open source] licensing any time"
In a fantastic, insightful post, Tim O'Reilly lays the blueprint for the next decade of open source in the cloud. Money quote?
[I]f you care about open source for the cloud, build on services that are designed to be federated rather than centralized. Architecture trumps licensing any time.
This follows on Tim's constant theme over the last few years: Data is the new Intel Inside. It's a critical point given the almost meaningless tie between open-source licensing, triggered upon distribution of software, and the web, which is premised on non-distribution of software. Increasingly the web is being turned into competing bunkers of data, as Tim writes:
All of the platform as a service plays, from Amazon's S3 and EC2 and Google's AppEngine to Salesforce's force.com -- not to mention Facebook's social networking platform -- have a lot more in common with AOL than they do with internet services as we've known them over the past decade and a half. Will we have to spend a decade backtracking from centralized approaches? The interoperable internet should be the platform, not any one vendor's private preserve.
How do we get there? Tim believes that "a reasonably open, re-usable system service in any particular area is going to get the biggest uptake." This isn't a moral plea, he suggests, but a strategic decision to win by being "reusable." This resonates with me. As he describes, Google Maps didn't win because it was open source, but rather because it was openly reusable by others, including competitors.
Granted, Google has yet to effectively monetize Google Maps, but that's a secondary concern. The first concern is adoption. Monetization can follow adoption. It should, assuming we get the revenue model right.
This is one of the best posts ever written by Tim. If you care about open source and/or the cloud, you need to read his post. I believe the next decade of software will be driven by the principles he articulates there. It opened my mind on open data, and that's saying something. :-)
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
"@Tim and @Justin, regarding Eucalyptus and opening the "EC2 market": I wrote a post a little while back pointing out that markets will form "solar system" like groupings of cloud providers, with large central players surrounded by others who graft onto their platform and/or API. This is clearly already happening with Amazon AWS (read the post), but Google AppEngine and others are also seeing some support out there.
My point is that Eucalyptus's success will drive people towards Amazon's APIs, which will give Amazon *more* control over that section of the market unless they choose to either release control of the API to an independent body, or add extreme levels of extensibility to the API specs. How can the API evolve to meet the needs of the market over the needs of just Amazon otherwise?
Having a Eucalyptus is no panacea when it comes to lock-in, it just shifts the problem from the vendor to the API--which in the end could be a no-op."
"@Tim and @Justin, regarding Eucalyptus and opening the "EC2 market": I wrote a post a little while back pointing out that markets will form "solar system" like groupings of cloud providers, with large central players surrounded by others who graft onto their platform and/or API. This is clearly already happening with Amazon AWS (read the post), but Google AppEngine and others are also seeing some support out there.
My point is that Eucalyptus's success will drive people towards Amazon's APIs, which will give Amazon *more* control over that section of the market unless they choose to either release control of the API to an independent body, or add extreme levels of extensibility to the API specs. How can the API evolve to meet the needs of the market over the needs of just Amazon otherwise?
Having a Eucalyptus is no panacea when it comes to lock-in, it just shifts the problem from the vendor to the API--which in the end could be a no-op."