Hacker News new | ask | show | jobs
by cryptonector 2725 days ago
The best open source business model I've seen yet is SQLite's. That business model goes as follows:

  0. produce something very widely useful
  1. wait for it to become essential
  2. create a consortium and profit from the dependence bred by #0
Granted, bootstrapping that is really really difficult.
2 comments

The problem with this model is that quite a few of these open source companies are funded by VCs. In this case, a “consortium” is just never going to cut it, revenue-wise.

The most profitable way appears to be to offer a cloud-hosted solution, and herein lies precisely the problem with AWS et al providing these services by taking the OSS software for free.

I don't see the problem.

First, SQLite's developers are not an open source company funded by VCs. I don't know what funding they had originally, but they've leveraged their success into a well-funded consortium. Does it matter if it could or could not work in combination with VC funding? No: what matters is that the developers got funding, end of story.

Second, I don't see why a company (regardless of funding source) couldn't spin off a consortium to fund further development of some open source created by that company.

Your goal seems to be "profit", which is a fine business goal. Open source is a fine business tool, but not so much a fine business _goal_. It can help you profit, but it can also hinder. Open source is a business tool to be applied on a case-by-case basis.

Open source is not easy to use as a core business value. That's because the most important core value to any public corporation is profit, and open source does not intrinsically lead to profit. Building a for-profit business around open source projects with open source as a core business value is undoubtedly difficult. Indeed, the example I gave is of a non-for-profit organization that funds development of one project.

Open source is a tool with following costs and benefits (and risks), some of which are:

  - cost: loss of confidentiality for "secret sauce"
    embodied in open source
  - cost: the cost of opening a code base and keeping it open
  - cost: dealing with a community
  
  - benefit: good will
  - benefit: mind share (this is the big one)
  - benefit: quality (hopefully) contributions from
             the community
  - benefit: credit (especially for developers, which
             functions as a form of compensation and
             recruitment incentives)
If for some project open source is a tool whose costs exceed the benefits, then don't open source that project. It's that simple.
What are the main ways for the consortium to extract value from #0 ?
You'd have to ask them. I suspect the consortium compensates the developers. I've no idea how much that pays.