(1) They say that 78% of the companies surveyed use OSS internally. I'll bet it's more like 78% realize or admit it. It would probably be very hard to run a business nowadays without using at least some OSS somewhere.
(2) The author's recommended approach of combining some OSS with proprietary enhancements (commonly called "open core") is certainly not the only way to make money from OSS, and I don't think there's even much evidence that it's a particularly effective approach. Some customers are "more than happy" to pay for an "enterprise grade" version. Others aren't, and that number goes up as the price for the proprietary version increases. They'll go it alone, hire consultants, or switch to competitors.
A recurring-revenue "subscription" model works surprisingly well. (This is where I should add a disclaimer that I work at Red Hat.) Customers will pay a modest amount, year after year, to get easy/timely updates, priority bug fixes, training, certification, indemnification, access to developers, and so on. People will be "more than happy" to pay for a safety net that they never actually use, and it's easier to keep TCO lower than competitors with this model than with the open core "freemium" model. Less immediate revenue per customer, but more customers and more loyalty. I guess "don't be greedy" is the lesson here. ;)
Canonical, MySQL (now Oracle), Zimbra (now VMware), Zend, Gluster (also acquired, I forgot by who) and a whole bunch of others are or were at some point open source companies.
Pure open source software companies are relatively few in number but companies that contribute to open source and profit from that open source in that they have a lot more people working on the code and taking care of bug spotting and bug fixing is considerable.
One nice example of that is Basecamp.
Open source companies that are successful are acquired at a relatively high rate so they don't usually last as such independently.
It isn't about product success, it's about company success. Even for one-trick-monkey companies like Android (see how their prior sale to Microsoft went... smashing success)—selling a company is the literal death of the company and the absence of success outside of private financial engineering.
I think many founders would disagree that company success matters more than product success. A lot of companies are started purely to develop and promote an idea. This is obviously so for companies spun off from academia or from internal projects at other companies, only a bit less obviously for those created around preexisting open-source projects, and not uncommonly for others.
Maybe you care more about the company. You certainly shouldn't project your personal beliefs onto others. Many founders would love to see their pet idea continue without the tedium of running a company. Many founders and employees would be similarly happy to trade in the company letterhead for a bigger paycheck. It's only "selling out" if one was more in love with the idea of the company than with the idea of the product, and frankly I can see few reasons other than ego for that to be the case.
I think you're stuck in a groove of your own making. Selling a company is not a 'literal death' because a company never was 'literally alive'. It is merely a convenient fiction that allows multiple people to work together and to somewhat fairly share the proceeds. Survival of a company is never an inherent goal. Survival of a product can be such a goal.
Companies are utterly un-important, they are simply vehicles.
It's difficult to buy stock in a product. It's difficult to make an index fund of products. It's difficult to retire on "product dividends."
Companies exist as an attempt to get all the money in the world, and most fail that goal. Apple is pretty close. Refusal to acknowledge failure as failure is pathological insanity. Getting paid to fail (or to "soft land" and save face on an outright failure) doesn't mean the fail didn't happen.
> It's difficult to make an index fund of products.
Well, that's what I said, companies are vehicles.
> It's difficult to retire on "product dividends.
But you can retire on corporate dividends. And when a companies shares are acquired you either get money or shares in the acquiring company.
> Companies exist as an attempt to get all the money in the world
How do you square that with 'it is hard to retire on product dividends'? Companies pay out dividends to their shareholders.
Companies clearly do not exist to 'get all the money in the world' because then the economy would grind to a halt.
> and most fail that goal.
All companies fail that goal. They fail every time they buy new resources, pay out salaries, rent offices, pay out dividends and so on.
In fact, the worst thing for a company is to have a whole pile of cash and nothing to do with it, that's money that is not currently working for the company in a meaningful way. That's why companies tend to manage their liquid reserves very carefully.
> Apple is pretty close.
Close to getting all the money in the world? No, not even remotely close. And even all that money that Apple has is indirectly owned by the shareholders of Apple. Either Apple will have to spend it or they will have to pay out. Having it sit there does them no good.
> Refusal to acknowledge failure as failure is pathological insanity.
Are you calling me insane in a roundabout way?
> Getting paid to fail (or to "soft land" and save face on an outright failure) doesn't mean the fail didn't happen.
Oh, that happens. But it's pretty rare. But better than chapter 11 if that's the alternative.
Pretty rare? That's back to the beginning, because every acquisition means the bought company has explicitly failed to become "real" in a make-more-than-we-spend (and continually grow the "make more") sense.
But better than chapter 11 if that's the alternative.
I'd rather see 20-somethings lose everything and learn tough, introspective, life changing lessons, than see them running around with their "soft landing" $10 million paydays just because they had the right connections.
If you are a cult-of-pg founder with "money money money startups exist to make me rich rich rich!" mindset, sure, it's a personal success.
But it's a blatant, raw, undeniable failure when a company lets itself get acquired no matter how much money changes hands.
(this is one of the topics that induce harsh West Coast Cognitive Dissonance because it goes against what the billionaire priests of finance tell you to believe about your life)
> But it's a blatant, raw, undeniable failure when a company lets itself get acquired no matter how much money changes hands.
You mean that when Intel acquired Altera that was a failure, and when Microsoft acquired Mojang that was a failure too? And Google with Android and so on. All 'blatant, raw, undeniable failures' according to you.
Yes? "Failure" is a little harsh, but reasonably accurate. Even the companies that sell out "to ensure we have the resources to develop all our visionary synergies" have better ways to raise money.
The 'end' is but a moment and it's very well possible to have a success even if it ends in one way or another. Success is a measure of the total net effect a company had. if the net effect was negative then a company can be classed a failure, if the net effect was positive then the company was a success.
Selling out is to sell a company with the specific intent to shut it down, that's different.
Since we can't know the values of the founders of those companies I think that to say someone 'sold out' without giving them an opportunity to voice their position (and which they are not even obliged to state) it's a bit of a harsh judgment. Everybody is entitled to their own opinion of course but this 'failure' thing is another creative use of a word that has a different meaning in normal language. I have a problem with that. I do my very best to communicate and then people will start to use words in ways in which they definitely weren't intended.
Let's take Mojang as an example. Mojang was run for many years by the same people. Maybe they simply got tired of it and wanted to move on to other things. Having a significant chunk of money in the bank is generally considered to be a good thing and from what I see minecraft is still working just fine. I find it hard to square that deal with the meaning of the word 'failure'. That's just trying to be too clever for my taste I prefer a simpler and more direct interpretation of words, this cleverness is really rather tiresome.
It looks as if the whole thing is constructed in such a way that it a negative association is attached to the success of others in a way that says more about the user of the words than about the people and events that it is supposed to describe.
What if it's not about raising money? Sometimes it's about gaining access to markets, or to technology, or to other things that the acquiring company controls. How is it "failure" to gain access to those things, and money besides?
We are an open source company that's profitable, and proud of it. We want to create an open source ecosystem like Wordpress but not capture all the value created around it.
What on earth is going on with your header? You have four options that look like links (Qbix, Apps, Platform, Blog) but I cannot click on them. I cannot imagine what I am doing wrong. I tried clicking on them for 10-15 seconds before I realized nothing was happening. You have tons of Javascript reference errors. Are those links created in Javascript using onclick? Whether they are links or not, that header might be worth rethinking... (I am running Chromium 46 on FreeBSD/Mate.)
What are these Javascript reference errors? I will try to reproduce them. Very strange, the javascript passed all the linting and worked on all the browsers in our test array.
To be clear: Red Hat is a $billion business that is purely Open Source (nothing they sell or do is not open source, and when they acquire things that aren't open, they open them within weeks or months of acquisition), which is pretty amazing.
I've been involved in Open Source based businesses for almost two decades now, and I still don't grasp how to build a billion dollar business on entirely open source software (though I've made a decent living at it most of that time). But, I stubbornly keep trying.
You mean I have to deal with government purchasing processes? No thanks. I guess I'll never build that billion dollar OSS company. Or, maybe I can hire someone to handle that part of the equation.
If you cheat the definition, you could say Apple has opened some code, therefore they are an open source company.
But, clearly that's not what's in play here. It's difficult to be an open source startup because it's easy to get a big ego and start doing software wrong. You don't get people to use your software by saying "LOOK! We have VCs. Trust us. Buy our support contracts!"
You get people to use your software by making good features, growing by word of mouth, then you're entrenched and can start milking the support cow. Your word-of-mouth features don't even have to work (coughmongocough), they just have to be easy to brag about so developers get ego boosts by telling others "hey, look, i found this thing and you should think I'm cool because I'm telling you about it."
Another really important point: open source companies aren't proven. The current crop of open source startup VC funded happy towns are all experiments. It's very possible you can't create sustainable open source software companies (support contracts aren't zero margin software products, and nobody buys software anymore because lol "it's free!!!"). There's no natural "supernormal profit" engine if you make a good, clean, understandable open source product. In fact, it's actually the opposite: open source companies get big when the product is garbage (or too complex) because then everybody needs support to CYA against higher management.
(I've been thinking about writing a few articles about all this in January. Stay tuned.)
> support contracts aren't zero margin software products, and nobody buys software anymore
There have been other models for open-source software companies, such as the "sell some defaults to advertisers or sponsors".
If someone could manage to work out the details, I think the open-source ecosystem would respond favorably to a bitcoin approach to revenue share (which would make it explicitly not "open source", but I think people are willing to forgive this violation). The hard part is figuring out how to negotiate with thousands of separate tiny "open-source" components, without project leaders making demands too ridiculous.
At the same time, we don't really want a race-to-the-bottom of poorly-maintained software projects just because someone figured reimplementation could net him a bunch of revenue if he prices everything lower... presumably this cuts into long-term software maintenance, which is something that a good system would ideally incentivize both from the perspective of library authors but also from the perspective of software purchasers, who don't want to suffer from bitrot.
(Another approach could be "performance targets" where bonds are created by library authors, but funded by company purchasers, who would be buying up some amount of technical debt in exchange for rights to deploy and use the software in their production environments. These bonds would then pay out to the library author team based on milestones, like long-term maintenance, or fixing scaling bugs, or something... But similar problems remain regarding how to handle the negotiation between thousands of tiny library authors vs companies that don't have 1000s of hours to waste on software negotiation..... Also lots of questions about "rebundling"- we can't have negotiations with all 100k library authors between themselves and some company just to strike a deal for the company to use an Ubuntu-like software system. Answer is probably something like "have an array of default ready-to-go contracts that any new business can use, and then have terms for renegotiation after a certain period of time or certain amount of revenue accumulation by the downstream company"..)
we can't have negotiations with all 100k library authors between themselves
Yeah, it's the "nobody is ever going to pay for bash, vim, top, netcat, ..." problem.
Apple has found a good middle ground though. Pay developers millions of dollars internally (infinitely growing stock) then they release what they work on as open source code. It solves the (reasonable) compensation problem for individuals while letting new software spread purposefully throughout the world.
We're just missing a middle ground where you can write open source software while not being owned by the most valuable company in the world.
> Pay developers millions of dollars internally then they release what they work on as open source code.
What do they release as open source code, apart from TextEdit? I am really surprised by your comparison since it seems to me that the two (bash, vim, top, netcat… and Apple's open source code) do not compare at all.
Apple "owns" LLVM which has changed our computing landscape from the bottom up in more ways than I can count. GCC was happy being stagnant until LLVM came along and GCC could finally see how awful and behind the times they had become. Now there's at least some competition again.
(competition-free platforms are never a good thing, no matter how many times you pray to your zero-to-one god)
Or perhaps (and here's a potentially worrying thought), we'll get open source software making any proprietary stuff impossible to sell. Like how the app store has become filled with 'freemium' apps and 99 cent paid apps.
Open source would definitely be eating the world... though quite a few companies wouldn't be very happy in the process.
That is the end goal, right? Your margin is my opportunity. The problem in the middle is: open source software is considered free-as-in-never-pay-me free.
I have multibillion dollar companies using some of my open source software. They've never paid me anything. They ask for bug fixes and feature improvements that would take me six months (or more) of full time work. They don't offer to pay (or then even balk at the thought), they just keep saying "you should support us for free because it's open source."
Part of the "we won't/can't pay" is due to programmers being very low status people in organizations. Programmers don't have budgets to buy anything because "lol free open source" and "it's just code, do whatever." If programmers could allocate resources towards getting features/fixes they need from external projects, the software world could be more... synergistic.
Developers need to be bringing the culture of open source to their places of work. That means asking management for monthly budget they can use to make donations to open source projects (preferably to the projects they use in the company). If the most successful open source projects are not receiving donations from the companies that use them it's our own failing.
And if management refuses to allocate a budget for donating back to open source projects (either in developer time or in money) then developers should tell their coworkers that the company they work for is not an open-source friendly company. They're not doing their part to give back to the community of developers who are working so hard in their spare time to make what they do possible. I think the last thing companies want is to build a wall between management and their developer teams like that.
Imagine if programmers unionized and enforced corporate usage-based givebacks to independent software creators through collective bargaining.
When the default position of management is to fight progress (or hoard private profits enabled by using public goods), playing the role of docile puppies and kittens won't enact change.
I agree. But in a long-term scenario as long as all developers within a company know (and share with their co-workers) that their management are not open-source friendly and do not give back to the community of developers that they directly benefit from will find ways to revolt silently. Whether it's look for another job, or spend an extra day on a project they could've wrapped up in a few hours.
Those corporations who do not have good hearts and do not make good choices within their leadership will ultimately lose to those that do. Darwinism in full effect.
EDIT: In fact one of my ideas for a while now is to have a standardized disclosure that corporations could use to publicize to the world how they give back to the open source community (specifically and generally). This public disclosure would be primarily used as a recruiting tool. Eventually if it became big enough, the assumption would be that those who are not disclosing are probably not contributing. Huge implications as a recruiting tool IMO.
And it's not a lot to ask. It's not like you're asking for even $1000's of dollars. Khan Academy I think set the bar when they announced a while back they would allocate $5/mo/developer to allow each developer to donate to open source projects as they saw fit. If a company with a large team of developers can't afford something as simple as that then they have bigger problems.
> They ask for bug fixes and feature improvements that would take me six months (or more) of full time work. They don't offer to pay (or then even balk at the thought), they just keep saying "you should support us for free because it's open source."
If you ever do business with corporations, you will get used to the fact, that they will for the moon and expect it for free. It is your task to tell them, what you expect to be paid and stick to it. They won't volunteer any money they don't have to, and will use any excuse that will make it possible (the procurement bonuses depend on money saved). It's up to you to not accept that excuse.
Except, the company endpoint is a low status programmer.
Imagine how quickly the average programmer would get laughed out of the room if they went to their manager and asked for $100,000 to pay an external contractor to implement a feature they need. Oh, also the feature will be open source and other companies will be able to use it after it's written too.
The world doesn't operate on that level yet outside of maybe seven companies in the world.
If this comment implies that Docker is profitable, it would be nice if you expanded a bit, because your parent commenter and myself, while (obviously) being aware of Docker, aren't aware of how profitable they are or (speaking for myself) what they make their money on.
Success is subjective, profitability is not. we all have different metrics for success. Though I agree that metric for success for a company is probably profitability but you will find people disagree with you on that as well.
(2) The author's recommended approach of combining some OSS with proprietary enhancements (commonly called "open core") is certainly not the only way to make money from OSS, and I don't think there's even much evidence that it's a particularly effective approach. Some customers are "more than happy" to pay for an "enterprise grade" version. Others aren't, and that number goes up as the price for the proprietary version increases. They'll go it alone, hire consultants, or switch to competitors.
A recurring-revenue "subscription" model works surprisingly well. (This is where I should add a disclaimer that I work at Red Hat.) Customers will pay a modest amount, year after year, to get easy/timely updates, priority bug fixes, training, certification, indemnification, access to developers, and so on. People will be "more than happy" to pay for a safety net that they never actually use, and it's easier to keep TCO lower than competitors with this model than with the open core "freemium" model. Less immediate revenue per customer, but more customers and more loyalty. I guess "don't be greedy" is the lesson here. ;)