Ask YC: What are the downsides of open source?
What is the challenge to make open source software successful in terms of making revenue?
Has anyone from here done it before? Would you make the same decision again to go open? What problems did you come across?
41 comments
[ 2.7 ms ] story [ 92.4 ms ] threadIn discussions about open source software, I'm frequently reminded of the following PG quote:
To be a startup, a company has to be a product business, not a service business. By which I mean not that it has to make something physical, but that it has to have one thing it sells to many people, rather than doing custom work for individual clients.
Open source is inherently not a product -- at least, not in the sense of being something you can sell to many people. The frequent cry of "but we'll make money selling support" ignores a critical fact: There aren't enough hours in the day to get rich by selling support contracts.
The one "open source" company which was successful at making lots of money -- MySQL -- wasn't in fact an open source company: They made their money selling a commercial product, and they just happened to use releasing a GPLed version as a cheap advertising mechanism.
I strongly support open source software; but a startup which builds open source software? It ain't a startup.
http://journal.dedasys.com/articles/2007/02/03/in-thrall-to-...
Looking at several successful "open source" oriented companies, we can see what kind of scarcity they introduced:
- Mysql, as you say, had their wonky licensing and a commercial product.
- Redhat decided to not license the 'branding' component of their distribution under a free license, so while you can copy the software, you have to remove a lot of bits and pieces (which CentOS has done), and it's not really Redhat anymore... If you want the support, you have to pay their licensing fees.
- Cygnus was relatively successful, a while ago, and were successful because they seemed, IMO, to stick to the letter of the law rather than the spirit: they'd give their clients full source code, but didn't make it public. They did a lot of 'billing' work, too, IIRC.
Still - I think there are a lot of advantages to using open source, and in many cases there are even business cases for developing it, but it is hard to base a business exclusively on open source.
If you make an enterprise product, you can sell an appliance or a VM that runs it, and GPL the programs themselves, like SourceFire.
If you make a web product, you can GPL the code and sell the hosted version, like WordPress.
If you make an extensible product, you can GPL the core and sell the bells and whistles, like Splunk.
If you make an end-user product, you can GPL the core and sell the UI.
Thats my concern basically, while also the probabilities are mostly against you, and probably the product will disappear.
Of course, you seize to be considered a startup anymore, because a startup is about rapid growth.
So probably thats why te best way to go is to have a free version of the product and more advanced features for those who pay, and a seperate license to have access to the source code, like Symbian does?
In short, fantastic tools with which to build a business, but as a selling point of a product...once you take the genie out of the bottle, you often find yourself wishing you could put it back in later.
Now, provide another example of a company that screwed up by "halfway" doing OSS without "proving the addons were worth the cost". I've provided plenty of specific counterexamples.
Speaking of ignoring critical facts:
1) You can hire more people to do support, which increases the total available amount of hours in the day.
2) Most support contracts are barely used and bought purely for comfort, so you can oversubscribe your support team to increase profit margins.
3) Every year software companies make billions on support contracts. MySQL made many millions on support.
It's not an easy road.
Sleepycat software, purveyors of Berkeley DB under dual GPL and commercial license, acquired by Oracle? Not a startup.
Splunk, purveyors of Splunk, open source core and proprietary commercial extensions, with over 20MM in VC funding? Not a startup.
Hyperic, purveyors of Hyperic, which is OSS end-to-end, with a 6MM B from Accel? Not a startup.
Zimbra, purveyors of OSS Exchange clone Zimbra, acquired by Yahoo!? Not a startup.
Astaro, purveyors of one of the top 5 "UTM" (IPS+firewall) boxes, now profitable? Not a startup.
None of these companies are services businesses.
Your characterization of MySQL is laughable, too. The "cheap advertising version of MySQL" you mention accounts for 99% of the real-world usage of MySQL in the marketplace, and anybody on Hacker News wishes they had the market power MySQL did.
So, my response to you: name an equivalent number of companies any of us has heard of with an open-source product that is services-driven that isn't Red Hat or IBM.
I don't agree that if you build open source software, you aren't a startup -- but I do think that a big part of being a (VC) backed startup is the potential to achieve "hockey stick" growth, and that can be hard to do through support contracts, consulting, and certification alone.
The whole point of the service vs. product distinction that PG was making is that a service business is less scalable: its revenue is basically linear in the number of employees that it has, because a human being has to do more work for each new customer. That is not the case for product businesses or for Reddit or Octopart (or most other web startups) -- if Reddit's traffic increases 100x overnight, they don't need 100x the employees to capitalize. Craigslist is an example that makes the difference pretty clear. Whether you want to call them "product businesses" or not misses the point.
Reddit is still different from an actual product company. The Reddit product scales independantly of the number of redditors or subreddits, because the Reddit product isn't hosted.
This is all a tangent, though. My fault.
To make open source work, you need to either (a) believe that opening up source is not a big competitive disadvantage, e.g. your customers will still come to you for services, consulting etc (the kind of business you can build on top of an open source platform) or (b) have enough of a community where you can go the MySQL route. There you need to be part of the community as someone else has pointed out.
The #1 and #2 problems you have with large businesses is lead generation and qualifying prospects, so that you aren't wasting $5,000-$10,000 of time and expenses on sales leads that don't pan out, or $50,000 going to conferences that won't result in a single sale.
With open source software, the geeks that infest every Fortune 1000 company bring your software in house just to play with it. If you get them to register their email addresses, and you follow up with them inside-sales style, and just 10% of them love what you built, you just converted 100 Fortune 1000 companies to customers.
This is exactly the model SourceFire used. It's not a "strategic platform"; it's a go-to-market plan, pure and simple.
I doubt anything very interesting would happen if Amazon or eBay opened their source, because their internal applications are likely such a rat's nest of interdependencies. It would take 6 mo - 1 year of full time study (i.e. the amount of time it takes a new hire to ramp up) for anyone to even begin to understand exactly how the systems fit together.
Even with the time and energy to learn how their code works, you'd still need to replicate their internal environments to be able to run their apps.
Open Source is a license and a community, and SugarCRM has both. It also has some extensions that are not Open Source, and the fact is, extracting money from Open Source fanatics is like getting blood from a turnip...so they will never be a customer anyway. So, it's about the only model that works for a large class of problems.
However, you still get a lot of benefits of Open Source from SugarCRM: Open data formats and no possibility for them to lock you in; as long as the core always remains Open Source you can never be "stuck" with your business based on an end-of-lifed product, as with some of the mergers in that field over the years, because it can fork if SugarCRM stops being developed for some reason; community of helpful users and developers means that the level of expertise available is high and affordable.
Over 10 years of building businesses based on Open Source software, I've grown to be pragmatic rather than ideological about how best to produce Open Source software and make money with it. I still prefer to produce and use Open Source tools...but I also know that a thriving business-backed OSS project can build thoroughly kickass software at a rate that a purely community-backed project rarely can. It's not impossible, of course, but it's rare and requires several factors to converge: one or more smart developers who need and use the software being developed and who can devote significant time to it, small core of useful functionality that can be implemented and launched quickly, and a large community of users to help support the product so the developer doesn't burn out.
Our target audience is composed of consumers who want a simple product to backup their computers and a more sophisticated audience that wants to design and maintain their own distributed backup service. For the consumers, open-source isn't necessarily a plus or minus (see marketing below) but for the more sophisticated users (enterprise IT folks) open-source is great if they need to make modifications for their special needs.
Similar to above, marketing your project/product/service as open-source may be very attractive to some audiences (enterprise IT, hackers who want their own storage grid), irrelevant to some (consumer PC user), and negative to others (some investors, some potential buyers).
One very strong benefit that we've received is peer review by experts in the field. Because our system must securely and robustly store sensitive information, the more people who read through our design and implementation and comment on it the better. Several design and implementation suggestions have helped us fix or improve our system immensely.
Because our project is open-source the peer pressure placed upon good design, documentation, and code is much higher than in my previous experiences with proprietary software. Though not perfect, it means that our team has worked hard to make the system usable and not pushed off important items that might not be visible to a busy project manager.
Code contribution has not been a major focus of our project, though we have received several very good additions to our project. I believe (but not backed up with data yet) that our particular project does not lend itself to large amounts of people coding on it as it is not (yet) a platform.
Hope this helps, Peter
Are there other companies that have succeeded with this model?
http://inthebox.webmin.com/open-source-and-business-a-precar...
And here at HN:
http://news.ycombinator.com/item?id=131662
http://news.ycombinator.com/item?id=81351
And many more. I'm on my second Open Source based business, and I think we've found a combination of factors that's going to be successful this time around: Huge and rapidly growing market, our Open Source offering is uniquely capable of filling niches that have never been served before, and...we offer a proprietary product on top that makes it really clear (to investors, to our customers, to our Open Source contributors) where and how we make money.
Just because Rails costs nothing doesn't mean a big economy can't surround it.. and if you were the creator of the technology, you get first dibs on making that cash.
Unless you reach a certain level, external developer contribution will be minimal as well (compared to what's done internally), so you can't depend on that for benefit either. And as for selling support, forget it. If your product is stable, 99% of people will opt for the "we'll just call you when we need you" option and take the hourly billing rate (even a jacked up one for emergencies), because they'll only need it maybe once a year.
I've run a successful albeit very small open source company for 7 years, and we're gearing up to release another major version by end of summer (www.simian.ca). I really don't mean to come off cynical or unappreciative of certain users (we have a number of users who have been amazingly helpful, and those are the users that make it all worthwhile), but as a model for a new business you have to look at the reality of how well it can work and grow into a sustainable model. Open source is a big risk for little potential gain these days.
My advice, start a company that offers a subscription-based service or boxed product (closed source). You can always provide APIs for 3rd parties to interact with, and you can open source libraries and other useful but non-essential bits. But giving away the central thing that defines your company is a difficult sell.
Open source makes a huge difference when your product is intended to be embedded in your customer's product. When their business depends on yours it's obvious they need to pay you or ultimately suffer the higher cost to them of having to maintain your code-base themselves.
When you're talking about some dinky utility a non-technical end-user may use then you're probably smarter to go the shareware route.
One thing to worry a little about is how to protect yourself from competitors that may try to compete with you using your own code. If you're the sole owner of your core technology and there isn't any significant secret factual information in it then you're probably safe going open source with the appropriate licensing.
There's where subscription-based services shine, because support is expected with it, but it's distributed over exactly one installation instead of hundreds, so fixes are made once and apply to everyone. This way you're essentially selling access to the software plus support over time, making residual income, and cutting down the amount of effort it takes to support many customers.
While that's not the right model for every type of software obviously, many companies have shown it can be made to apply to a surprising number of cases you wouldn't think it suitable for at first :)
Acceptance in enterprise.