Blogs

RedMonk

Skip to content

Re: Making Billions with Open Source, Revisited

Hooked Chumby up to new mini stereo

Yesterday, when writing up the “how do you make mega-money off of open source?” note, I left out an explicit discussion of the “uses” open source angle. Both Mike Dolan and Matt Aslett pointed this out. And, yeah, there is something there, though I tend to think it falls under the category of “Lump it and just sell closed source.”

Using/Embedding Open Source

First off, let’s lay out some definitions, the invalidation or misunderstanding of which could hiccup all this.

By “embedding” open source you’re combining that open source software into another “product” be that a physical device or another piece of software.

As Mike Dolan puts it:

What about embedded uses of open source, independent of monetization? Look at Eclipse. It’s there for anyone to take and reuse (e.g. embedded in IBM Lotus products, Adobe products, Wall Street trading apps) though none of them package/sell Eclipse itself that you download for free. You can get “rich off open source” without focusing on selling a compiled version of that source code. Take for instance building a tax preparation application on say Google Gears and Chrome.

Boxes, man, boxes

Usually when I hear “embedded,” though, I think of shipping the software in physical devices, like cable set-top boxes, routers, and TiVos. Indeed, with TiVo there’s a famous instance of sorting this out. TiVo’s ship with Linux (or “GNU/Linux,” if you prefer) but used software magic (that’s a technical term) to ensure that you couldn’t muck with the operating systems on the box – which was against the spirit (if not the letter) of the GPL license that Linux was provided under. TiVo, of course, makes money off open source software, then. Here, it seems clear to me that these box-sellers are using open source wrapped in closed source layers: they don’t exactly provide the specs for the boxes online for anyone to go and replicate a TiVo or a Cisco box.

You could look at Chumby as another interesting example, that pulls in the SaaS angle for monetization. Chumbys are weirdly-fun little devices that essentially lay a widget slide show. They seem to run on some Linux varient, ship with Flash Lite, and rely on a SaaS to provide the stream of widgets. There’s closed and open source running all around there, and a physical device itself. You buy the device for ~$120 and that’s all you pay.

As with TiVo or Cisco boxes, the question is: could Chumby be a successful business if it “let” anyone clone a Chumby? You could point towards the PC clone market here as a historical example of how that can work for companies (Compaq, Dell, etc.) and blow-up in the face of others (IBM). You could also point out the open source chips that Sun has, which seem to be doing more good than harm by being open source – chips are out of my keen, though.

There may be something here though: in order to make money off open source software, you have to sell hardware. Which, still, for me points towards making money off something other than only the open source software itself. In a round-about kind of way, I suppose iPod + pirated music is an example of this as well.

Back to Software: The Eclipse Example

Eclipse is the better example for us software-types: the open source Eclipse stack is used by the likes of IBM, Adobe, Oracle/BEA, SAP, and so on as the basis for their software development tools. However, products like Flex Builder are certainly not open source.

On this angle of “using open source,” of course that makes sense and works. I’d wager that almost every closed source vendor uses open source – they’d be insane not to. When I was writing very much so closed source software at BMC Software, we used only open source software for a long time (or free, in the case of Sun’s JRE back then) to build software that drove large, close source based revenues.

The question is if companies can make those Big Bucks only on open source, without that closed source layering on-top, additional services, etc. Like, could you open source the entirely of that tax preparation application or Flex Builder and still sell each of those products? More than likely, you’d need something else you sold to customers that was not open source (one of the services or closed source components I outlined yesterday).

The GPL Tax

There’s also the embedded/”pay to not be GPL” angle where the clever, commercial-friendly irony of the GPL comes in. This example applies to any license, but we’ll use the GPL because it’s popular here (as well at MPL-derivitives). If you GPL your code, you can dual-license the code such that people who use it aren’t effect by the reciprocal/viral (choose your diction per your party affiliation) nature of the open source code. The nature licensers are trying to avoid here is having to open source their own code because they use that GPL’ed software.

Hyperic does this with their SIGAR stack, for instance. SIGAR normalizes low-level IT management tasks across different operating systems, so it’s very handy if you’re writing IT management software. But, if you were writing a closed source IT management product, you wouldn’t be able to use SIGAR under the GPL because then you’d have to open source your product. Thus, you can license the software under a “closed source license” from Hyperic. This allows Hyperic to not only profit from such use but also stop competitors from using “their” (see if you can spot the open source semantic trap in that phrasing) own software against them. Hyperic can deny the license (I believe) or price it so high that the potential competitor doesn’t want to use it.

Here, in the generalized model, I think this is more cleverness to push the revenue model from to selling open source software directly to selling closed source software. While you developed the software as open source, you monetize it as closed source (under a “closed source” license). Personally, I don’t find this distasteful or ill-adviced at all (I regularly advice clients to do all these “clever” things), but it defiantly crosses The Tarus Line.

Is it all about money?

I’ve painted myself into a weird definitional corner here: if you require your customers to pay you to use your software, that software probably isn’t “open source.” I’m not sure what I think of that. If anything, it seems way too simple. Worse, it looks like the kind of definition that’s the first step towards some heated trackback-spew that ends with an application of Godwin’s Law.

Disclosure: Eclipse, IBM, and Hyperic are clients, as is Adobe

Categories: Marketing, Open Source.

Comment Feed

8 Responses

  1. I think you've missed the point. The reason Hyperic is able to dual-license SIGAR is that Hyperic holds the copyright on the entirety of SIGAR. It's Hyperic's prerogative to license SIGAR any way it sees fit. Digium does the same thing with Asterisk — you can get it under a traditional commercial license as Asterisk Business Edition for end-user use or for embedding in another product. Sun does it with OpenSolaris, of which Solaris is a commercially-licensed distribution.

    The distinction that keeps Sun and Digium on the right side of The Tarus Line is that each company recognizes its debt to its open source community and takes great pains to avoid moves that could put the company's interests at odds with those of the community. For instance, while Asterisk Business Edition is not exactly the same as any released version of GPL Asterisk, ABE also does not include any features (other than license enforcement code) that are missing from GPL Asterisk. Similarly, Sun does not withhold such valuable features as ZFS or Zones from CDDL-licensed OpenSolaris. I don't know where SIGAR falls along this spectrum, but what puts Hyperic HQ on the other side of the line is that the GPL version of HQ is missing features that make it usable at any appreciable scale. If you want those features, you've got to spring for HQ Enterprise. This puts Hyperic potentially at odds with its open source community, because Hyperic's revenue depends largely on preventing the community from developing and contributing features that would fill the gap between HQ and HQ Enterprise.

  2. My company practices dual licensing, GPL and proprietary, with all the code being the same.

    For people trying to make some features only available on proprietary, there is always the danger that users will see it as crippling the open source version. That less energy is going into it.

    Maybe we should just admit that if you just want to make billions selling software, just go proprietary. Case closed.

    On the other hand, search for Umair Haque and his writing at Harvard Business: maximizing billions of dollars in profit without regard to users is ultimately doomed.

  3. At the end of the day I think all of this comes down to trust. Customers will go with who they trust, not their lines of source code (open or not).

    I have been working on a thesis about the topic of open source and services. There are many services that use and extend open source code but since they don't physically (tar ball etc) redistribute their source code they can avoid license issues.

    My argument is starting to move towards something more radical: why not open source your service code? If you have the ideas and reputation people will go with you over someone else anyway. The days of smoke and mirrors when it comes to software may be numbered.

  4. In business terms, anything open source is a loss-leader, pure and simple. If you get millions in the door for your fantabulous code, great, but if you can't upsell some significant portion of them to support/services/plugins/extensions/warranties/whatever, then you're just a volunteer.

    Of course, lots of other things can be loss leaders, and if you're not necessarily selling to the back office, then there are often more attractive (to everyone involved) loss leaders than open sourced code.

  5. Jeff, Perry, Kyle, Chas: thanks so much for those quick comments, they're each great!

  6. cote:

    You quote:

    "if you require your customers to pay you to use your software, that software probably isn’t “open source"

    is almost perfect. If it changed to:

    "if you require your customers to pay you to use your software, that they can't also get freely, that software isn’t “open source"

    Sure, some companies produce open source software as a teaser for more feature enriched proprietary versions that "imbed" the open source bits. Where you cross the Tarus line is calling these companies "open source" companies. The line is crossed because their revenue isn't based on selling open source software or services. They're commercial software companies with a new freeware model where the free stuff is open source.

    IF companies are changing their software strategies to use open source for all the "known" reasons open source is a benefit (no code escrow clauses, no vendor lock-in, easier code audits, etc.) then the Tarus line should be clearly drawn.

    My opinion, these open source benefits put the advantage in the open source court when a comparison is made. Of course, when it ultimately comes down to the purchase order, the "best" choice might not always be open. Unless it's openNMS! (grin)

Continuing the Discussion

  1. [...] Update: see this addendum on models that involve using, or “embedding” open source. [...]

  2. [...] business strategies had reared its head again thanks to posts by Dave Rosenberg and Michael Coté (twice) – not to mention Matt Asay and Tarus [...]