Technically, of course, open source refers to how you've licensed something-but legalities aside, the real point of this licensing-at least in the beginning-was to foster the more intriguing, and I would argue, revolutionary aspects of the open source community: the "collective knowledge of the commons."
I've long thought the concept had business and intellectual potential beyond what it does for IT software. In fact, I recently suggested to a political scientist friend of mine that smaller universities might benefit from a research commons since, as things stand now, individually they lack the resources-and graduate students - to generate the research he and his colleagues need to do if they want to publish.
The problem is, no one really wants to share, particularly if they think, for a glimmer of a moment, that what they're sharing will give them any kind of edge. Ever.
There are ways, however, in which the open source philosophy seems to be slipping out of its OS and application roots: integration.
Last year, the open source ESB company, MuleSoft, announced a new tool for Java developers using the Apache TomCat server. Called iBeans, it allows developers to create quick integrations,as Greg Schott, CEO of MuleSuft, explained in an October interview with yours truly:
"What iBeans does is allows a developer - with just a few lines of code - to provide integrations, to a cloud service or a SaaS service. We're talking about things like Gmail and Twitter and Flickr and things like that. So, there could be an iBean that really provides the access to the APIs of those third-party services or somebody can develop an internal iBean that is a reusable component that other people in their organization can use."
But to me, the really nifty thing about iBeans wasn't the tool-it was iBeans Central, a commons for sharing iBeans.
Of course, the concept is restricted to those on Apache TomCat.
Still, the concept makes perfect sense. Many integrations are just tactical needs that offer you little strategic value, other than allowing two systems to talk. Why not share-particularly if you could, say, make money for doing so?
That's the idea behind SnapLogic's new venture, SnapStore, which is scheduled for public beta release on Feb. 15, 2010. Currently, it's in a 100-day private beta.
"The basic idea behind SnapStore is that there are far too many data sources for any one data integration vendor to provide a connector for every such source and when you start to consider combinations of sources with targets then that number increases exponentially. ... The idea behind SnapStore is that you provide facilities for creating snaps, where a snap is anything from a simple connector to a complete dataflow that integrates (say) a SalesForce quote with a NetSuite order."
The connectors are tested and certified before being included in the SnapStore, Howards adds. For more technical details, you might want to check out the Developer FAQ.
That sounds very open source-y, right? Well, by now, we all know open source doesn't mean free - and it's not called "SnapStore" for nothing. You'll have to pay for the "Snaps."
How much you pay, however, will be up to the individual developers. SnapLogic is allowing the developers to set the price, as well as the licensing terms. The company keeps 30 percent of the revenue, with the rest going to the developer.
Still, given how much time and cost hand-coding can require, it's easy to see how buying a Snap could save you money over developing your own.
I know-that's not quite so warm and fuzzy as "free," but it does take advantage of the wisdom of the commons in a remarkably practical way.