Why Open Source Startups Fail
techcrunch.com
techcrunch.com
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.
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.
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.
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.
- 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.
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.
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.
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?
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.
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.
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.
(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.")
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.
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.
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.
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.
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.
Because no one reports theirs? It's not a good reason to laugh if you think of it.
http://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity/
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).
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.
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.
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.
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.
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.
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.
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 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.
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!
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.
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.
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)
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.
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.
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.
If all of the product is released under a Free Software license, what is there to complain about? Not receiving free consulting services?
Can you name some that did?
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.
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.
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.
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.
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."
SpringSource by VMWare, $382m.
SuSE Linux AG by Novell, $210m.
Trolltech (Qt) by Nokia, $153m.
[1] http://iphone.appleinsider.com/articles/07/07/12/apple_acqui...
HN folks may recognize EFF board member John Gilmore as the founder.
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".
Did you know that the word "gnullable" wasn't in /usr/dict/words either?
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://www.networkcomputing.com/careers-and-certifications/c...
NB: I'm not saying they were wrong for this, because they've got to make money.
Zimbra --> Yahoo $350 million
Sleepycat --> Oracle
Revolution Analytics --> Microsoft