Last Saturday, I made my fourth annual visit to the CalTech campus for what’s become a June tradition of discussing entrepreneurial opportunities in software. The CalTech/MIT Enterprise Forum organizers have gotten used to the idea of having me keynote a session on this subject each year: it’s always an occasion for meeting some interesting people and thinking about the business of turning ideas into services or products.
This year’s theme was the commercial use of open-source software. If I’d had editorial input on the session announcement, I’d have asked them at least to think about saying "free and open-source" to emphasize that they aren’t the same thing. Digging through my archive of past slide decks, I found my first presentation (given back in 2000) on enterprise use of open-source code, and found that my seven-year-old list (at right) of key characteristics of "openness" is still worth discussing: the "things people know that ain’t so" about open-source software continue to create opportunities for revelation.
I’m clearly a fan of open-source efforts because they create more opportunities for developers to add value. Quality open-source underpinnings free up scarce IT funds from paying license fees for undifferentiating infraware. It’s a matter of record that salesforce.com, unsurprisingly, uses open-source tools and technologies internally to develop and deliver its services, although the hyperlinked 2004 article in which that 2003 disclosure was mentioned made its own errors in confusing on-demand with "hosted" delivery models. (At the risk of over-simplification, if it’s a customer-specific customized stack being run on a service provider’s infrastructure, it’s hosted; if it’s a multi-tenant architecture incorporating customer-specific customizations through metadata, it’s on-demand.) And we have multiple partners who’ve chosen to offer products that integrate with our services that they deliver under open-source terms.
It should also be clear that I’m perplexed by questions that seem to position open-source as a competitor to on-demand. It’s like calling the turbine engine a competitor to the airline. There are airplanes that use turbine engines: they’re faster, quieter, and more economical than airplanes that use piston engines, with technical improvements continually making turbines cost-effective in ever-smaller aircraft. Pilot/owners can take advantage of those technical improvements when they buy and operate aircraft to go to places that no one else wants to go, or airlines can favor turbine technology when building scalable systems for service to multiple customers.
Disclosing the source code behind an on-demand offering is about as useful as giving an airline passenger a copy of the aircraft engine service manual. The whole idea is that you buy your ticket, you get to your destination, and everything else is someone else’s problem. It’s the on-demand provider’s job to disclose and maintain APIs for service confederation, just as it’s in an airline’s interest to make its flight availability and fare information accessible to Expedia or Orbitz or Travelocity. It’s in the on-demand provider’s interest to maximize use of industry standards, just as it’s in an airline’s interest to minimize its own operational complexity (for example, in the way that Southwest uses only 737-family aircraft).
But "Open Source" is an ingredient, not a product; source code availability is a feature, not a benefit.