Why Open Source Startups Fail(techcrunch.com)
techcrunch.com
Why Open Source Startups Fail
http://techcrunch.com/2015/04/12/the-real-reason-open-source-startups-fail/
88 comments
You're mistaken about why VCs want firms to focus on product rather consultancy, it's not for the short-term as you suggest but rather the long term.
Time spent on consultancy today gets you revenue today but time spent on product gets you revenue tomorrow. Focusing on product rather than consultancy is the long-term play because you're focusing on what maximizes your value 5-10 years down the line rather than what pays the bill today.
The big difference between consultancy and product based development is that with consultancy you're building what the individual customer needs rather than building what your product needs strategically in the long term (if they're both the same thing that great but doesn't happen that often in practice).
There's also a distinctively different mindset between product and consultancy companies. At a consultancy the consultants are seen as the revenue generators and the product developers as a cost base; at a product company developers are seen as revenue creators. It's easy to underestimate the cultural impact that has on companies.
Time spent on consultancy today gets you revenue today but time spent on product gets you revenue tomorrow. Focusing on product rather than consultancy is the long-term play because you're focusing on what maximizes your value 5-10 years down the line rather than what pays the bill today.
The big difference between consultancy and product based development is that with consultancy you're building what the individual customer needs rather than building what your product needs strategically in the long term (if they're both the same thing that great but doesn't happen that often in practice).
There's also a distinctively different mindset between product and consultancy companies. At a consultancy the consultants are seen as the revenue generators and the product developers as a cost base; at a product company developers are seen as revenue creators. It's easy to underestimate the cultural impact that has on companies.
"if they're both the same thing that great but doesn't happen that often in practice"
On one side you've got a customer who needs something badly enough that they're willing to pay you real money. On the other side you have a larger number of potential future customers. As they say "a bird in the hand is worth more than than two in the bush".
Of course the customer is never taking the product in exactly the direction you want it to take. But there are few things less valuable to a company than a close relationship with customers and visibility into their needs.
If your consulting clients' needs and your planned product's capabilities aren't aligning, how about adjusting the plan rather than dropping the clients? In my 20 years of experience in the industry, adjusting the plan has always been the better strategy.
On one side you've got a customer who needs something badly enough that they're willing to pay you real money. On the other side you have a larger number of potential future customers. As they say "a bird in the hand is worth more than than two in the bush".
Of course the customer is never taking the product in exactly the direction you want it to take. But there are few things less valuable to a company than a close relationship with customers and visibility into their needs.
If your consulting clients' needs and your planned product's capabilities aren't aligning, how about adjusting the plan rather than dropping the clients? In my 20 years of experience in the industry, adjusting the plan has always been the better strategy.
> the customer is never taking the product in exactly the direction you want it to take.
This may actually a good thing. When you are developing a product, getting a good market fit is tricky. Consulting for your user allows you to precisely understand what your users expect of your product.
Yes, it may not be what you expected to build, but building what your users actually want is usually a good idea.
This may actually a good thing. When you are developing a product, getting a good market fit is tricky. Consulting for your user allows you to precisely understand what your users expect of your product.
Yes, it may not be what you expected to build, but building what your users actually want is usually a good idea.
I think you're mistaken on a couple of points:
- VCs aren't interested in "revenue tomorrow" unless you mean a 10x+ exit multiple. VCs want you you to focus on your product because there's an invisible( and sometimes not so invisible) clock running as soon as you take the investment.
- VCs aren't interested in 5-10 year tails on their investments. Most are looking for an 18mo.-3.yr ROI. If you can prove revenue and 'market traction' they'll extend your runway accordingly, however that's a constantly moving target and generally the types of VCs who are interested in the 'long tail' aren't the same that want to give you money at the infancy of your company.
- There is definitely a big difference between a traditional consultancy and a product focused organization but only in the sense of the 'end goal'. If your entire plan is to bootstrap your company by building a consultancy, it's easy to keep a separation of concerns between the two halves of your organization. Usually the "clash" that you're talking about is when a consultancy based/focused organization decides to build a product, not when a product company decides to do some consultancy.
Developers (in fact, all of technology) are considered cost centers at ALL businesses. There's not an MBA on the planet that wouldn't jettison the entire technology cost-center of their business in a heart-beat if they could figure out how to do it and still achieve their monetary objectives.
- VCs aren't interested in "revenue tomorrow" unless you mean a 10x+ exit multiple. VCs want you you to focus on your product because there's an invisible( and sometimes not so invisible) clock running as soon as you take the investment.
- VCs aren't interested in 5-10 year tails on their investments. Most are looking for an 18mo.-3.yr ROI. If you can prove revenue and 'market traction' they'll extend your runway accordingly, however that's a constantly moving target and generally the types of VCs who are interested in the 'long tail' aren't the same that want to give you money at the infancy of your company.
- There is definitely a big difference between a traditional consultancy and a product focused organization but only in the sense of the 'end goal'. If your entire plan is to bootstrap your company by building a consultancy, it's easy to keep a separation of concerns between the two halves of your organization. Usually the "clash" that you're talking about is when a consultancy based/focused organization decides to build a product, not when a product company decides to do some consultancy.
Developers (in fact, all of technology) are considered cost centers at ALL businesses. There's not an MBA on the planet that wouldn't jettison the entire technology cost-center of their business in a heart-beat if they could figure out how to do it and still achieve their monetary objectives.
> Developers (in fact, all of technology) are considered cost centers at ALL businesses. There's not an MBA on the planet that wouldn't jettison the entire technology cost-center of their business in a heart-beat if they could figure out how to do it and still achieve their monetary objectives.
This is pretty funny because in a software company, devs are the only ones creating actual global value (as in, something that a customer could realistically derive value from). Every other instrument in the company is pretty much how to turn value into incoming cash flow or reduce outgoing cash flow.
It'd be like Apple trying to jettison its designers.
This is pretty funny because in a software company, devs are the only ones creating actual global value (as in, something that a customer could realistically derive value from). Every other instrument in the company is pretty much how to turn value into incoming cash flow or reduce outgoing cash flow.
It'd be like Apple trying to jettison its designers.
I have an MBA and I certainly do not think devs are a cost center.
This is an extremely cynical comment. First, hard-line profit/cost center thinking is falling out of fashion at top MBA schools like Harvard and has been for years. But also, a reasonable MBA would be able to recognize when the tech team is actually creating value vs. when they are dead weight that could be outsourced. And, it's really myopic (and the kind of thing that people make fun of engineers for) to believe that tech is the only ones adding value. Value (perceived, communicated) is potentially created all up and down the chain.
> (perceived, communicated)
Oh, I just meant value as it applies to the person who actually ends up using whatever the business is making. Of course perceived and communicated value is most important to a business. After all, if you could somehow convince people to just dump money on you without doing anything for them at all, you'd be the best business of all.
Oh, I just meant value as it applies to the person who actually ends up using whatever the business is making. Of course perceived and communicated value is most important to a business. After all, if you could somehow convince people to just dump money on you without doing anything for them at all, you'd be the best business of all.
Either they're dead weights or they're not. How does outsourcing change the equation? Certainly not by reducing cost -- not if you want to outsource to non-dead-weight development group.
Seriously? Take a bunch of do-nothing office drones, can them all and get a maintenance contract with some consultant in eastern Europe. What's hard to understand about that?
You will probably lose the same amount of money you thought you were saving in management and communication.
"The big difference between consultancy and product based development is that with consultancy you're building what the individual customer needs rather than building what your product needs strategically in the long term...."
If so, then focusing only on product development is going to be successful only if you know what your customers in aggregate need better than they do. Isn't that the whole 'agile' lesson?
If so, then focusing only on product development is going to be successful only if you know what your customers in aggregate need better than they do. Isn't that the whole 'agile' lesson?
Focusing too narrowly on immediate improvements can constrain scope to bug fixing and building the best version of the current product possible rather than adding new features and directions for the product. It makes the product vulnerable to competition that better meets the ever-changing needs of the market.
I'm not saying it can't be done, just saying that you have to be careful when managing scope. And that isn't even a unique concern to a consultancy-based model, it just has different pitfalls.
I'm not saying it can't be done, just saying that you have to be careful when managing scope. And that isn't even a unique concern to a consultancy-based model, it just has different pitfalls.
Keep in mind you don't know what the features and directions of your product should be until you talk to your customers and understand what roadmap will fit their needs. For every DropBox there are hundreds of failures that didn't get it right about whom we never heard about.
Let's say your consulting pays for the time of one engineer while your investors pay for another one. If you stop your consultancy, your workforce will have to be slashed by 50%. Unless the custom development job is focusing on features that add no value to the product for other customers, this is insanity.
Let's say your consulting pays for the time of one engineer while your investors pay for another one. If you stop your consultancy, your workforce will have to be slashed by 50%. Unless the custom development job is focusing on features that add no value to the product for other customers, this is insanity.
> These companies were using the income from other companies they were consulting for to build out the product. It's like free development. You get your engineer time paid for, and make a profit on it, and much of the work goes into the product side of things.
Also, consultancy gives your team experience with how your customers are using product in the real world. You are basically building the product with input from one or more representatives of the class of customers that are likely to be most willing to pay the most money for your product.
Also, consultancy gives your team experience with how your customers are using product in the real world. You are basically building the product with input from one or more representatives of the class of customers that are likely to be most willing to pay the most money for your product.
This article made me realize that I don't know of any open source startup which got acquired for a significant sum of money.
Can you name some that did?
Can you name some that did?
There was Cygnus Solutions, which I believe maintained GNU software (debugger, binutils) and contributed large parts of gcc. Cygnus was bought by Red Hat for $674M in 1999.
HN folks may recognize EFF board member John Gilmore as the founder.
HN folks may recognize EFF board member John Gilmore as the founder.
And also Michael Tiemann (now at RedHat), and David Henkel-Wallace (now at Technical Illusions, making CastAR).
Their slogan was "We make free software affordable". (In answer to the anti-slogans: "Free software: more expensive than money" and "Linux is only free if your time is worthless".)
I asked David if they named the company "Cygnus" after grepping /usr/dict/words for "gnu". He answered no, because if they'd thought of doing that, they would have named it "Wingnut".
Their slogan was "We make free software affordable". (In answer to the anti-slogans: "Free software: more expensive than money" and "Linux is only free if your time is worthless".)
I asked David if they named the company "Cygnus" after grepping /usr/dict/words for "gnu". He answered no, because if they'd thought of doing that, they would have named it "Wingnut".
Funny, but "wingnut" doesn't actually appear in /usr/dict/words
The funniest thing is that David shot that back without missing a beat, with a perfectly straight face, and a somber tone that suggested he deeply regretted the missed opportunity.
Did you know that the word "gnullable" wasn't in /usr/dict/words either?
Did you know that the word "gnullable" wasn't in /usr/dict/words either?
Yup, because I took 0.2 seconds to actually grep /usr/dict/words for "gnu" just recently.
I think Gumby was either making a self-effacing joke, or a gratuitous dig at RMS -- I'm not sure which.
http://en.wikipedia.org/wiki/Wingnut_%28politics%29
"Wingnut" (sometimes "wing-nut") is an American political term used as a slur referring to a person who holds extreme, and often irrational, political views usually with a religious overtone. According to Merriam-Webster, it is "a mentally deranged person" or "one who advocates extreme measures or changes : radical."
http://en.wikipedia.org/wiki/Wingnut_%28politics%29
"Wingnut" (sometimes "wing-nut") is an American political term used as a slur referring to a person who holds extreme, and often irrational, political views usually with a religious overtone. According to Merriam-Webster, it is "a mentally deranged person" or "one who advocates extreme measures or changes : radical."
Cygnus were the go-to company for GCC/GNU related work for hire, like doing compiler toolchain and support for your new embedded platform/new cpu. Even the name was a recursive acronym, like GNU: "Cygnus, Your GNu Support"
I was at Cygnus (and still at RH). The total deal value was actually much higher because it was a stock deal and the Red Hat stock price kept climbing before everything was wrapped up.
JBoss; acquired by RedHat for $420M in 2006 (http://en.m.wikipedia.org/wiki/JBoss_%28company%29)
$2.7 Billion dollars: snort -> sourcefire -> Cisco
http://www.networkcomputing.com/careers-and-certifications/c...
http://www.networkcomputing.com/careers-and-certifications/c...
Sourcefire significantly clamped down on the openness of Snort. Pushing out new versions with less-free licenses, and changing the alert format regularly.
NB: I'm not saying they were wrong for this, because they've got to make money.
NB: I'm not saying they were wrong for this, because they've got to make money.
JBoss by Redhat, $400m.
SpringSource by VMWare, $382m.
SuSE Linux AG by Novell, $210m.
Trolltech (Qt) by Nokia, $153m.
SpringSource by VMWare, $382m.
SuSE Linux AG by Novell, $210m.
Trolltech (Qt) by Nokia, $153m.
That's a very limited definition of "fail". If a company opens it's product, runs successfully for years, builds something people actually use, and eventually shuts down leaving a legacy of a piece of useful software, then that isn't really a failure.
The investors would probably consider that business to have failed, in the sense that their gamble didn't pay off, but that's their problem. We don't have to think like investors.
The investors would probably consider that business to have failed, in the sense that their gamble didn't pay off, but that's their problem. We don't have to think like investors.
It's a failure if any founders or employees took equity in lieu of significant salary.
Within the past year I had the experience of "oh, you wrote X? We used that all the time at my last company!" "So will you hire me." "No."
Within the past year I had the experience of "oh, you wrote X? We used that all the time at my last company!" "So will you hire me." "No."
MySQL, 1 billion USD (2008).
By Sun Microsystems http://web.archive.org/web/20110718044718/http://mysql.com/n...
They bought it out yes, but the guy forked it and now develops MariaDB, which a few OS' have switched to after the Oracle take over. I'm sure he's enjoying still working on his project.
A valuable lesson to those buying OSS companies with the intention of destroying the competition to their core product.
There's another side: IF the company does a great job, the OSS project becomes much more fruitful, however, if it doesn't do much of a great job, well you end up with MariaDB vs. MySQL and LibreOffice vs. OpenOffice (not sure they haven't bothered to merge).
At least the GNU does what it was intended to do, stop companies from hijacking / buying out a software product and getting rid of it entirely.
At least the GNU does what it was intended to do, stop companies from hijacking / buying out a software product and getting rid of it entirely.
I hope they never learn that lesson.
Phineas Barnum was right and we can use the money better than Larry Ellison.
At least, we can use it to build nice things for everyone to enjoy.
Phineas Barnum was right and we can use the money better than Larry Ellison.
At least, we can use it to build nice things for everyone to enjoy.
A valuable lesson to those buying OSS companies.
It's a lesson for those who want OSS companies for the wrong reasons.
I am quite sure had Oracle agreed to fund the development of MySQL into the Oracle RDMS killer it may eventually become, the fork would not happen.
If I were Monty, I'd try to sell MariaDB to Larry Ellison for a billion dollars.
I am quite sure had Oracle agreed to fund the development of MySQL into the Oracle RDMS killer it may eventually become, the fork would not happen.
If I were Monty, I'd try to sell MariaDB to Larry Ellison for a billion dollars.
www.gluster.org - https://www.redhat.com/promo/storage/press-release.html - $136m
XenSource --> Citrix $500 million
Zimbra --> Yahoo $350 million
Sleepycat --> Oracle
Revolution Analytics --> Microsoft
Zimbra --> Yahoo $350 million
Sleepycat --> Oracle
Revolution Analytics --> Microsoft
Cannot speak to the $$, but CUPS was purchased by Apple[1]
[1] http://iphone.appleinsider.com/articles/07/07/12/apple_acqui...
[1] http://iphone.appleinsider.com/articles/07/07/12/apple_acqui...
The problem here might be that those startups, at the time they got acquired, were not perceived any more as startups.
This could be simplified: A company needs something that cannot be dublicated using a significant effort. A company that releases their source code to the public really _has_ to build up some knowledge in their domain (because the public source can be easily dublicated), while another closed source company gets away with just selling their product.
Bit of a tangent, but I think most closed source products are pretty easy to copy. What can't be copied is the headstart. If they keep on advancing, they'll retain it. And if customers want those advances - not overshooting - then they'll win most sales. (Though your point still stands, because open source gives away the headstart.)
"I want to believe." ~Poster on Mulder's wall.
You can interpret "get's away with" as "makes better business sense". On a slight tangent - in the infosec space those with closed source products (e.g. WAF's) laugh at those with open source products when it comes to the numbers of embarrassing and business-damaging zero-days reported.
Closed source rocks if you're a capitalist. Those who sell closed source love that open sourcers are so distracted by singing-it from the mountain.
~From a guy who runs a not-that-small open source biz.
You can interpret "get's away with" as "makes better business sense". On a slight tangent - in the infosec space those with closed source products (e.g. WAF's) laugh at those with open source products when it comes to the numbers of embarrassing and business-damaging zero-days reported.
Closed source rocks if you're a capitalist. Those who sell closed source love that open sourcers are so distracted by singing-it from the mountain.
~From a guy who runs a not-that-small open source biz.
> in the infosec space those with closed source products (e.g. WAF's) laugh at those with open source products when it comes to the numbers of embarrassing and business-damaging zero-days reported.
Because no one reports theirs? It's not a good reason to laugh if you think of it.
Because no one reports theirs? It's not a good reason to laugh if you think of it.
> in the infosec space those with closed source products (e.g. WAF's) laugh at those with open source products
I would imagine open source has more reported zero days because, well, the source is open and auditable.
I do see a lot more closed source in the info/app sec space, but I suppose if you know that space well enough, the source code is just a bonus to seeing how the program works, not a requirement.
I would imagine open source has more reported zero days because, well, the source is open and auditable.
I do see a lot more closed source in the info/app sec space, but I suppose if you know that space well enough, the source code is just a bonus to seeing how the program works, not a requirement.
You need something that is "scarce":
http://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity/
http://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity/
Note: since you wrote it twice incorrectly, the word is spelled 'duplicate'. 'Dublicate' could be an interesting word since it resembles double, but it doesn't exist yet.
This is a good article but I think the focus on “the IP-based product playbook” vs “the ecosystem-based services playbook” exposes an issue without making it explicit: that these are very different kinds of businesses. Maybe the swing-for-the-fences returns VCs are looking for are not possible in businesses that have such a large services component because of the inability to scale up quickly.
I am working on a Free Software startup. What I think makes it unique is it caters to an underserved market, and customers in that market usually don't have the resources to implement our solutions themselves.
Of course, respecting our (potential) customers' freedom and not withholding knowledge means we have to be innovative in areas other than technology such as marketing, sales, and support. And if we cannot keep customers happy, another company can eventually come in and compete with us by offering better service and/or lower prices.
Edit: fixed a typo.
Of course, respecting our (potential) customers' freedom and not withholding knowledge means we have to be innovative in areas other than technology such as marketing, sales, and support. And if we cannot keep customers happy, another company can eventually come in and compete with us by offering better service and/or lower prices.
Edit: fixed a typo.
This is probably my most shared link: http://www.oreilly.com/openbook/opensources/book/tiemans.htm...
My favourite quote from that link:
"At first I tried to make my argument the way that Stallman made his: on the merits. I would explain how freedom to share would lead to greater innovation at lower cost, greater economies of scale through more open standards, etc., and people would universally respond "It's a great idea, but it will never work, because nobody is going to pay money for free software." After two years of polishing my rhetoric, refining my arguments, and delivering my messages to people who paid for me to fly all over the world, I never got farther than "It's a great idea, but . . .," when I had my second insight: if everybody thinks it's a great idea, it probably is, and if nobody thinks it will work, I'll have no competition!"
My favourite free advice (worth what you paid for it): similar to what the original article stated, the "innovation path" is for the gold prospectors going out to make it rich. Trying to make a differentiator and then get paid multiples on your good idea won't work for free software because everybody gets to use your good idea.
Free software business models require you to execute at a level higher than anyone else can execute. Usually if you are the person who built that infrastructure, you have an edge, but it really is all about building a viable business, not building crazy software.
In that way, I think free software businesses are inherently less risky. Often you don't need VC, because if you can't get people to pay for your services, you are SOL anyway.
From your short message, you seem to understand this. I wish you good luck!
My favourite quote from that link:
"At first I tried to make my argument the way that Stallman made his: on the merits. I would explain how freedom to share would lead to greater innovation at lower cost, greater economies of scale through more open standards, etc., and people would universally respond "It's a great idea, but it will never work, because nobody is going to pay money for free software." After two years of polishing my rhetoric, refining my arguments, and delivering my messages to people who paid for me to fly all over the world, I never got farther than "It's a great idea, but . . .," when I had my second insight: if everybody thinks it's a great idea, it probably is, and if nobody thinks it will work, I'll have no competition!"
My favourite free advice (worth what you paid for it): similar to what the original article stated, the "innovation path" is for the gold prospectors going out to make it rich. Trying to make a differentiator and then get paid multiples on your good idea won't work for free software because everybody gets to use your good idea.
Free software business models require you to execute at a level higher than anyone else can execute. Usually if you are the person who built that infrastructure, you have an edge, but it really is all about building a viable business, not building crazy software.
In that way, I think free software businesses are inherently less risky. Often you don't need VC, because if you can't get people to pay for your services, you are SOL anyway.
From your short message, you seem to understand this. I wish you good luck!
An interesting aspect of the discussion here is that the opinion is that there seems to be only a few options for funding an open source organisation: venture funded or organic growth. Venture funded is challenging, as it is all about gold digging. Organic growth is generally a slow and hard path.
If you have other goals than just money, there is actually quite a lot of opportunity to work on open source software, with viable business models and interesting things to work on.
If you have other goals than just money, there is actually quite a lot of opportunity to work on open source software, with viable business models and interesting things to work on.
> means we have to be innovative in areas other than technology such as marketing, sales, and support. And if we cannot keep customers happy, another company can eventually come in and compete with us by offering better service and/or lower prices.
Building a company is hard enough even if things are "simple" in that someone pays for a good or service. It becomes much harder if you have to innovate in multiple ways.
That is why it is so difficult to do open source companies.
Building a company is hard enough even if things are "simple" in that someone pays for a good or service. It becomes much harder if you have to innovate in multiple ways.
That is why it is so difficult to do open source companies.
Paul Graham advises companies to do things that don't scale: http://paulgraham.com/ds.html
Respecting your customers and building meaningful relationships with them can, in some industries, be disruptive. For a company truly committed to user/customer Freedom, the respect part should come naturally.
And if you view Freedom-respecting technology as being part of an ecosystem rather than something developed in a silo, it is easier to overcome the apparent efficiency and simplicity of the proprietary business model.
Respecting your customers and building meaningful relationships with them can, in some industries, be disruptive. For a company truly committed to user/customer Freedom, the respect part should come naturally.
And if you view Freedom-respecting technology as being part of an ecosystem rather than something developed in a silo, it is easier to overcome the apparent efficiency and simplicity of the proprietary business model.
"Doing things that don't scale" is great advice for people whose first inclination is to automate everything with code, and not do 'people' stuff.
Ultimately, though, you've got to be able to work "on" the business, and not in it, as they say. And that means doing things that "scale" in some sense. If you aim to keep the business small, it means doing things that let you remove yourself from the day-to-day operations of the company.
Ultimately, though, you've got to be able to work "on" the business, and not in it, as they say. And that means doing things that "scale" in some sense. If you aim to keep the business small, it means doing things that let you remove yourself from the day-to-day operations of the company.
This is a common misinterpretion IMO of PG's "do things that don't scale" quote. PG is not generally suggesting you should just willy nilly "do things that don't scale" - that would be stupid. He is not generally valuing the concept of unscalable activities.
He is saying "build your initial customer base in any way you can, including in ways that aren't scalable but will get you users, and then treat your first users well in ways that would not be practical if you had thousands of millions of users". That's way I read it anyway.
He is saying "build your initial customer base in any way you can, including in ways that aren't scalable but will get you users, and then treat your first users well in ways that would not be practical if you had thousands of millions of users". That's way I read it anyway.
I think you're right.
I see it as how in my first startup, I did phone sales despite being a tech guy, because we had to figure out how to sell our services and wouldn't have known what to tell someone about how to sell them if we didn't. And how all of us took tech support calls because we needed to understand what problems our users had (I learned to troubleshoot Trumpet Winsock setups over the phone "blind" without even once having run the program that way, as we didn't have any Windows machines...) before we could automate things and before we could write better instructions to try to eliminate the problems.
It wasn't that anything we did couldn't be scaled - we eventually outsourced our consumer sales, and wrote detailed installation instructions and automated parts of our setup with scripts - but the easiest way of learning how to do that was to do things in ways that couldn't scale first.
It also helps you recognise potentials for scaling things that potential competitors may take a long time to realise can be scaled, and that they thus may decide to stay away from because of that belief.
I'm deeply asocial, and hates phone calls, but doing phone sales and taking support calls have provided most of the best lessons about customer needs and opportunities I've ever gotten.
I see it as how in my first startup, I did phone sales despite being a tech guy, because we had to figure out how to sell our services and wouldn't have known what to tell someone about how to sell them if we didn't. And how all of us took tech support calls because we needed to understand what problems our users had (I learned to troubleshoot Trumpet Winsock setups over the phone "blind" without even once having run the program that way, as we didn't have any Windows machines...) before we could automate things and before we could write better instructions to try to eliminate the problems.
It wasn't that anything we did couldn't be scaled - we eventually outsourced our consumer sales, and wrote detailed installation instructions and automated parts of our setup with scripts - but the easiest way of learning how to do that was to do things in ways that couldn't scale first.
It also helps you recognise potentials for scaling things that potential competitors may take a long time to realise can be scaled, and that they thus may decide to stay away from because of that belief.
I'm deeply asocial, and hates phone calls, but doing phone sales and taking support calls have provided most of the best lessons about customer needs and opportunities I've ever gotten.
We're going with the open core model ourselves. In our case focusing on commoditizing our competitors by giving away the algorithms while at the same time enabling companies to build their own solutions.
One interesting aspect of open source is the pitch for enterprise. It aligns your business model with the consumer's needs and if it's close to data (storage or analytics) the risk of a company going under or getting acquired doesn't leave them in the dust (ala apple/foundationdb)
Open core (like cloudera worth 4x horton) allows for the best of both worlds where you don't leave your customers locked in but you can still get licensing fees for added layers on top.
Edit: Let me clarify a bit. Open core is for company's who just want to pay for solutions also allowing them to serve companies who want to build their own infrastructure. There's some amount of lock in with open core, but if the core infra is open source it still allows the customer an easier migration path. In our case we went with an apache license for the core tech and sell a layer on top that allows for easier deployments.
While open source startups are rare I think it's critical for core infrastructure to be open source.
One interesting aspect of open source is the pitch for enterprise. It aligns your business model with the consumer's needs and if it's close to data (storage or analytics) the risk of a company going under or getting acquired doesn't leave them in the dust (ala apple/foundationdb)
Open core (like cloudera worth 4x horton) allows for the best of both worlds where you don't leave your customers locked in but you can still get licensing fees for added layers on top.
Edit: Let me clarify a bit. Open core is for company's who just want to pay for solutions also allowing them to serve companies who want to build their own infrastructure. There's some amount of lock in with open core, but if the core infra is open source it still allows the customer an easier migration path. In our case we went with an apache license for the core tech and sell a layer on top that allows for easier deployments.
While open source startups are rare I think it's critical for core infrastructure to be open source.
[deleted]
Along with building customer engagement it is important to build a brand. The brand becomes a gateway to other services like certification, training and consulting.
For an open source OEM, a brand is obvious, but for a community player, it is not so intuitive. The brand is built by focusing on contribution, good writing (blogs, articles etc) and showing visibility on the forum. Like the OP mentioned, you cannot be too invested in the IP as a non-core player.
For an open source OEM, a brand is obvious, but for a community player, it is not so intuitive. The brand is built by focusing on contribution, good writing (blogs, articles etc) and showing visibility on the forum. Like the OP mentioned, you cannot be too invested in the IP as a non-core player.
That's been huge for me as well. Speaking at conferences and writing my book over the past year has been a great entrance in to getting business. It's really paying dividends.
You could switch "open source" with "zero-revenue business model" (not quite as catchy).
This is something unique to startups, who can raise huge sums of money (with insane valuations), yet have no revenue model. Having no revenue stream can (and has worked) for many startups, but it is incredibly risky. How long you can keep going until the money/ luck runs out is massive uncertainty (there's enough uncertainty as it is).
This is something unique to startups, who can raise huge sums of money (with insane valuations), yet have no revenue model. Having no revenue stream can (and has worked) for many startups, but it is incredibly risky. How long you can keep going until the money/ luck runs out is massive uncertainty (there's enough uncertainty as it is).
Fundamentally open source companies and no-revenue model companies are very different, I think it's a mistake to lump them together. The defining trait of a no-revenue company is the investors' confidence that massive revenues or at least a bombastic acquisition will come further down the line.
This model does not work for open source companies, because the "figuring out how to make money later" step typically can't happen without a massive pivot (whether it's all that likely to happen with your typical no-revenue company either is open to debate).
Maybe the break-even point in open source companies tends to come at a later point, but the path to revenue needs to be baked in from the start. Typically, switching on a revenue generator later will require more than just putting some ads up on the company site, so if massive changes are required to make that happen you must include those plans in your DNA from the start.
Open source and zero-revenue companies share the assumption that reach and influence can be translated into money, but when running an open source company the nature of that reach has to be designed more carefully.
This model does not work for open source companies, because the "figuring out how to make money later" step typically can't happen without a massive pivot (whether it's all that likely to happen with your typical no-revenue company either is open to debate).
Maybe the break-even point in open source companies tends to come at a later point, but the path to revenue needs to be baked in from the start. Typically, switching on a revenue generator later will require more than just putting some ads up on the company site, so if massive changes are required to make that happen you must include those plans in your DNA from the start.
Open source and zero-revenue companies share the assumption that reach and influence can be translated into money, but when running an open source company the nature of that reach has to be designed more carefully.
The obvious answer would be that you are not trying to raise money, but you are building a one-off "work of art" that will sell for million dollars.
That gives an idea of why such a a zero-revenue business model makes some sense, but also gives an idea of why it's incredibly hard to make it work.
That gives an idea of why such a a zero-revenue business model makes some sense, but also gives an idea of why it's incredibly hard to make it work.
Some open source startups fail because they are non-scalable service companies deluding themselves that they are product companies. Furthermore, they do not own enough of any durable advantage (IP, talent, mindshare), and so multiple "product" companies pretend to not compete while offering similar services in a niche that does not have that much demand. Furthermore with FOSS, most potential customers are often politically incentivized to poach upstream code and talent, give nothing back and eschew overpriced "consulting" services entirely. So it's almost always the wrong business model, unless you dominate it.
(I've plenty of enterprise FOSS consulting to realize there are easier ways to make much more $/time, like enterprise startups that are product companies. Also, PGs essays about "consultingish.")
(I've plenty of enterprise FOSS consulting to realize there are easier ways to make much more $/time, like enterprise startups that are product companies. Also, PGs essays about "consultingish.")
Yeah, you are right; look at companies in the hadoop eco system: cloudera, hortonworks, mapr. They are just burning the cash; most of the money comes from the services/consulting. This will succeed if one dominates the sector, the way Redhat does in the area of enterprise linux.
I think this is a big part of it (from someone who has considered a consultancy). These aren't necessarily hugely scalable, which isn't a problem unless you are looking to be a big hit...which is exactly what VCs are aiming for.
I worked at Cloudscaling for several years. It seems like this article simplified (actually complicated, read on) the issue too much by truncating it into its two "playbooks." I think the first thing that needs to be argued properly is why open source startups need to be analyzed differently from other startups. If you have a feasible (scalable, sustainable, etc) business model to make money with using open source software - say by deploying it and supporting it - then that business model can be judged by the same criteria as other startup's business models.
The issue of productizing software which several OpenStack companies have attempted is part a basic part of their business requirement for scaling - because supporting dozens of heterogeneous deployments is impossible with reasonably sized engineering & support teams.
This article implies that Cloudscaling used the first playbook. It did do the items listed on the first playbook, but it also did all of the ones on the second playbook too (though, while being a smaller startup didn't contribute as much code back to OpenStack as some of the larger companies/contributors).
Creating new success formulas - like these "playbooks" - ignores what we know to be true about the success of many great startups in our midst. There are patterns behind that success which are consistent. These patterns and factors have been written about extensively by folks like Paul Graham, Eric Schmidt, and the like. They rarely synthesize new complexities or factors when talking about what creates success. What they do is go back to basic principles. However, the data to analyze failed startups well enough to determine which fundamentals were lacking is rarely available - so we make stuff up. Company culture is a big one - and it may or may not have had a significant impact on Cloudscaling.
The issue of productizing software which several OpenStack companies have attempted is part a basic part of their business requirement for scaling - because supporting dozens of heterogeneous deployments is impossible with reasonably sized engineering & support teams.
This article implies that Cloudscaling used the first playbook. It did do the items listed on the first playbook, but it also did all of the ones on the second playbook too (though, while being a smaller startup didn't contribute as much code back to OpenStack as some of the larger companies/contributors).
Creating new success formulas - like these "playbooks" - ignores what we know to be true about the success of many great startups in our midst. There are patterns behind that success which are consistent. These patterns and factors have been written about extensively by folks like Paul Graham, Eric Schmidt, and the like. They rarely synthesize new complexities or factors when talking about what creates success. What they do is go back to basic principles. However, the data to analyze failed startups well enough to determine which fundamentals were lacking is rarely available - so we make stuff up. Company culture is a big one - and it may or may not have had a significant impact on Cloudscaling.
Techcrunch is somewhat behind the curve here, ever since IBM started undercutting RedHat on support and stealing their customers open source companies have stepped away from having consultancy as their only form of revenue.
Modern open source based business tend to be about network effect and building ecosystem business (Android, Github, Docker).
(I wrote a blog post on this a while back http://blog.imranghory.org/open-source-business-models)
Modern open source based business tend to be about network effect and building ecosystem business (Android, Github, Docker).
(I wrote a blog post on this a while back http://blog.imranghory.org/open-source-business-models)
"ever since IBM started undercutting RedHat on support and stealing their customers open source companies have stepped away from having consultancy as their only form of revenue."
This hasn't really been Red Hat's only form of revenue, generally it's been subscriptions + qualified builds, etc, they've had proprietary software from time to time too. Red Hat Network and "getting the bits quickly", also.
Though it always seemed to me a large chunk of business revolves around banks, with major needs in areas like realtime, needing access and changes from some of the very strong kernel developers Red Hat typically employs. Smaller companies won't need support, banks are mandated to require it, and have very technical needs. This isn't "how do I chown", it's often very specific performance/timing/hardware related things.
While things may have changed, I remember Oralce making some noise, but not really getting any traction, and I don't really think IBM was a big predator in any case. Customers would know they didn't have the specialization.
Anyway, if I had to use a broad brush, Red Hat support is more key to Red Hat than consultancy - but yes, though they produce lots of products, they aren't a product company.
I think Red Hat is somewhat unique in this regard, as they are one of the few that HAVE scaled that way. Nebula seemed to be a product company, but it may have been true that their products required too much hand-holding to scale.
This hasn't really been Red Hat's only form of revenue, generally it's been subscriptions + qualified builds, etc, they've had proprietary software from time to time too. Red Hat Network and "getting the bits quickly", also.
Though it always seemed to me a large chunk of business revolves around banks, with major needs in areas like realtime, needing access and changes from some of the very strong kernel developers Red Hat typically employs. Smaller companies won't need support, banks are mandated to require it, and have very technical needs. This isn't "how do I chown", it's often very specific performance/timing/hardware related things.
While things may have changed, I remember Oralce making some noise, but not really getting any traction, and I don't really think IBM was a big predator in any case. Customers would know they didn't have the specialization.
Anyway, if I had to use a broad brush, Red Hat support is more key to Red Hat than consultancy - but yes, though they produce lots of products, they aren't a product company.
I think Red Hat is somewhat unique in this regard, as they are one of the few that HAVE scaled that way. Nebula seemed to be a product company, but it may have been true that their products required too much hand-holding to scale.
This article wasn't really so much about it's headline, but someone in the same industry saying "we are not also in bad shape".
I suspect to answer the actual headline "The Real Reason Open Source Startups Fail", is pretty much why all companies may fail - PLUS the possibility that their paid component is not sufficiently compelling or that while their open source piece is compelling, they have trouble competing iwth their open source component or are becoming too services heavy, which can cut into margins.
It seems the article tries to claim Nebula wasn't "operatioanlly excellent", which is something a competitor would naturally say, but Nebula was trying to make a proprietary "appliance" approach to wrapping OpenStack (apologies if I've mistranslated this) - which I think might have just been too weird.
And that's a reason any company can crash - the product idea was perhaps not something the market wanted.
OpenStack, increasingly, is one of those things large companies are interested in, and if you have a large team of people to wrangle OpenStack, you likely need more flexibility, and want to put the components together yourself.
So were they making OpenStack for the little guy? Probably not, and OpenStack for the little guy is a bit of an oxymoron. It's pretty hands on. I can see where they'd have problems, and I also think it's likely is that there aren't a lot of OpenStack customers - but there are some very very large ones, so it's a huge fight to get someone to pay you - and not someone else - for something.
But most of the time, there's nothing particularly interesting in OSS business models except finding the right line of how much you are going to give away. In fact, I'd say you have an advantage out of the gate in getting people to be interested in what you do, that makes some parts easier.
I still think SaaS models (.com's, websites), etc, may be more easier though, to avoid the need to maintain that balance. But can you do that in systems software? Not so much, with a few exceptions for hosted monitoring.
Anyway, it's possible to build a good product company on OSS bits - and a services company can be something a lot of companies don't want to build. You just have to find the right line, but I think this was really about product/market fit, and not about open source business model failure, per se.
I suspect to answer the actual headline "The Real Reason Open Source Startups Fail", is pretty much why all companies may fail - PLUS the possibility that their paid component is not sufficiently compelling or that while their open source piece is compelling, they have trouble competing iwth their open source component or are becoming too services heavy, which can cut into margins.
It seems the article tries to claim Nebula wasn't "operatioanlly excellent", which is something a competitor would naturally say, but Nebula was trying to make a proprietary "appliance" approach to wrapping OpenStack (apologies if I've mistranslated this) - which I think might have just been too weird.
And that's a reason any company can crash - the product idea was perhaps not something the market wanted.
OpenStack, increasingly, is one of those things large companies are interested in, and if you have a large team of people to wrangle OpenStack, you likely need more flexibility, and want to put the components together yourself.
So were they making OpenStack for the little guy? Probably not, and OpenStack for the little guy is a bit of an oxymoron. It's pretty hands on. I can see where they'd have problems, and I also think it's likely is that there aren't a lot of OpenStack customers - but there are some very very large ones, so it's a huge fight to get someone to pay you - and not someone else - for something.
But most of the time, there's nothing particularly interesting in OSS business models except finding the right line of how much you are going to give away. In fact, I'd say you have an advantage out of the gate in getting people to be interested in what you do, that makes some parts easier.
I still think SaaS models (.com's, websites), etc, may be more easier though, to avoid the need to maintain that balance. But can you do that in systems software? Not so much, with a few exceptions for hosted monitoring.
Anyway, it's possible to build a good product company on OSS bits - and a services company can be something a lot of companies don't want to build. You just have to find the right line, but I think this was really about product/market fit, and not about open source business model failure, per se.
The concept of a SV style startup is orthogonal to that of a consultancy. Consultancies face one major problem: scaling.
The problem with growing a consultancy is that their growth is limited to the the number of a consultant's hours they can sell. If you can't scale your income exponentially to the number of man-hours you have available to you, you'll never be capable of evolving into a 100% + growth-per-quarter business.
I can't say I'm surprised that VCs looking for the big winners would not want to invest in a consultancy.
The problem with growing a consultancy is that their growth is limited to the the number of a consultant's hours they can sell. If you can't scale your income exponentially to the number of man-hours you have available to you, you'll never be capable of evolving into a 100% + growth-per-quarter business.
I can't say I'm surprised that VCs looking for the big winners would not want to invest in a consultancy.
What this is saying is that open source startups are just a PaaS. Act accordingly.
I think maybe the most interesting open source companies today are Couchbase and Mongo.
AFAICT, everything Couchbase does is Apache Licensed. An old-school traditionalist could look at them and conclude that they have no proprietary IP at all.
Mongo has perhaps a little more of a boundary because they use the AGPL (which will scare away more enterprise customers than the Apache license will). But still.
AFAIK, both of these firms are paying the significant costs of developing their own software. Neither of them can be characterized as building their business model on low dev costs from the use of community-developed code.
These firms have more funding than many open source firms get from an exit. Both of them seem to have significant and fast-growing revenue. Both of them seem to be on track to a successful IPO with reasonable expectations for continued growth thereafter.
Even in today's open source world, what these two companies are apparently doing seems kind of amazing.
AFAICT, everything Couchbase does is Apache Licensed. An old-school traditionalist could look at them and conclude that they have no proprietary IP at all.
Mongo has perhaps a little more of a boundary because they use the AGPL (which will scare away more enterprise customers than the Apache license will). But still.
AFAIK, both of these firms are paying the significant costs of developing their own software. Neither of them can be characterized as building their business model on low dev costs from the use of community-developed code.
These firms have more funding than many open source firms get from an exit. Both of them seem to have significant and fast-growing revenue. Both of them seem to be on track to a successful IPO with reasonable expectations for continued growth thereafter.
Even in today's open source world, what these two companies are apparently doing seems kind of amazing.
It recently occurred to me, free open source project + paid enterprise service companies are the software world equivalent of freemium games.
Not always. Some companies distribute 'open source' crippleware and try to sell proprietary extensions, just like 'freemium' games, but you seem to be talking about paid services, not proprietary extensions.
If all of the product is released under a Free Software license, what is there to complain about? Not receiving free consulting services?
If all of the product is released under a Free Software license, what is there to complain about? Not receiving free consulting services?
This is an example of where VC's interests and the companies are not aligned and VCs are pursuing short term goals.
Specifically, they often "request" this be done well before a term sheet. If the company complies then they start running out of cash, making them more dependent on the VC money and less able to negotiate terms.
Further, it's a mistake. These companies were using the income from other companies they were consulting for to build out the product. It's like free development. You get your engineer time paid for, and make a profit on it, and much of the work goes into the product side of things. All you need is to take some of those profits and build up a separate team that is focused on productizing the core product.
IF you do it right, you can bootstrap and never need to take VC funding. Either way, a successful consulting business extends your runway.
The claim about lacking focus is BS. Because the consulting- if being done right-- is in the exact area where the product is being built.
You know what takes focus away? Running the senior management team all over the country or the valley talking to VCs who are mostly going to waste their time because they don't have the balls to say "no"... looking for the 1 in 100 that will invest in the company.
I've seen this many times.
If you're able to secure consulting for your company and it's in the core area of what you want the company to do long term, do it.