Could someone please explain the business model of such open source based startups in general?
There are a few different models: for example, "open core" where part of the overall product is open source, and then layers of proprietary stuff are put on top and the aggregated "thing" is sold (but can't be redistributed). Then you have "dual licensing" where the product is purely under a F/OSS license (often times the GPL or another "copyleft" license) and the company sells commercial licenses that offer different terms (such as the right to redistribute a derivative product without needing to make your own product F/OSS).
And then there are the "pure play" OSS firms... everything is F/OSS, but they test/certify certain builds, and ship binaries for money even though you can download something which is probably 99.999% bit identical (images and copyright notices being the main differences). In this model what the customer is paying for is - arguably - not software at all, but "peace of mind," indemnification, certification, the "somebody to sue" factor, support, etc. Red Hat are a good example of this latter model. JBoss binaries are freely available, and CentOS is nearly identical to RHEL, but yet people still pay Red Hat for JBoss and RHEL.
In all three cases, there are also supplemental things the firm can sell for revenue, such as training classes, certifications, professional services work, T-shirts, etc.
There are probably still some other variations that I'm forgetting at the moment, but I think those are the big three.
Here's what I learned when doing this research for Meteor.
* You can sell training, but it's low-margin. If that's all you do, it probably ends up looking more like a consulting business, because you have to recruit armies of teachers if you want to scale up the business.
* You might think you can sell support, but it's hard. There's a catch-22. If your product is good enough that people want to use it, it's probably good enough that they don't use their support incidents and end up not wanting to renew their support contracts.
* You can sell some kind of management software or application server that only big companies need. This has been a sweet spot for some other projects. Developers at small companies don't have any money, and developers at large companies don't have any budgetary authority. But, the operations teams at larger companies have a budget, and if you have an offering that's useful to them, they're able to pay what it's worth.
* You can sell long term maintenance of other people's software. This is the Red Hat model. They put their LTS stamp of approval on a collection of packages, and guarantee that those packages will be maintained for N years. People will pay for this. The investors I talked to seemed wary about this model. "Yeah, Red Hat got to $1B of revenue, good for them, but man, it took a long time."
* Platform-as-a-service is harder than it looks. Small customers will pay incredibly huge markups. But that's only if you look at it on a percentage basis, rather than in terms of absolute dollars. When someone gets big enough to be paying you "real money," they tend to leave your PaaS, either because it's too expensive (it becomes financially reasonable to pull the function in-house) or because you don't give them enough control or security.
* If you make your software GPL, you can extract a few million bucks from big companies that can't use any GPL software, which sometimes happens for complicated reasons involving, eg, patent cross-licensing deals. If your software is truly universal and something that every developer must have, they will write you big checks for GPL exceptions. But these are one-off deals and you can't really build a business on them.
Mostly training and consulting. There is no better indicator that you know a framework best if you made and maintain it.
Another way, that the Meteor guys are trying (probably on top of training and consulting) is to sell an enterprise solutions. This solution will probably be an all in one appliance that enterprises can buy so they have an easy way to deploy and manage Meteor applications internally.
By raising this amount of money, we've (semi-deliberately) closed the door on any possibility of an acquihire. The valuation is too high for the VCs to agree to that outcome, and one of the privileges of Series A shares is the ability to veto acquisitions.
So we have two choices: (1) build Meteor into a great development platform, get a lot of people to build apps on it, and find something that we can sell to the operations department of big companies that are using it (I wrote a bit about this in other comments), or (2) fail.
