Problems With Open-Source Business Models(medium.com) |
Problems With Open-Source Business Models(medium.com) |
First , most open source companies these days are Ventured Back ( Elastic , CockroachDB, MongoDB etc..) meaning the core of the issue isn't "AWS" not paying license fees or people creating tech on top of Open Source , it's VCs who want their money back times ten.
Companies like MongoDB/Elastic have raised hundred of millions and yet are still not profitable.
Who's fault is it ? Did the MongoDB community ever asked the company to go that way ? Did MongoDB presented a roadmap to the community saying that they would have to be "profitable by Month X" or they would change their licence to make more money ?
Nobody has forced those founders/companies hands to make their products open source nor to raise that much capital.
If the industry is turning that way it is essentially because those businesses have used Open Source as a mean to reach the widest possible audience in order to increase growth and show great metrics to VCs and investors to raise absolutely obscene amount of cash.
Vue.js and Laravel are two very well maintain and extremely profitable open source project.
Those projects did not asked for 150M$ in fundraising and then realized : "Ooops we won't meet our 100% YoY Growth to satisfy VCs promises".
If some companies are switching their licensing , it's mostly because they overestimated their technology value and can't show to investors the numbers they promised.
This isn't due the "AWS Problem" or because of a "wrong business model" with FOSS.
It isn't long-term sustainable and it will result in a major correction one day, but that's the game currently.
That is also why quite often they bring in (and sometimes replace founders with) "professional" executives before the IPO. Some of these people are not usually the best people to maximize the long term trajectory of the company but they bring more confidence to IPO investors.
If you want to have a successful relationship with them, you had better know their motives and timelines and make sure your company is one in the fund that looks is going to return enough for their game.
Explains why there was so much marketing hype behind open source; hundreds of millions of dollars of VC investment was being pushed into it.
Keep in mind that this is the market speaking, not a 'specific need of some group'.
If it costs money to productize and support something, and it's risky, it's going to be VC and there will be terms that take that risk into account.
Another way of saying it is that '10x' requirement is a function of the risk of the business model of those taking the money. (Which by the way, as you point out, might involved 'over estimating the worth of something)
Most VC's are not successful and even the 'obscene' amounts of money made by some actually don't make up for losses elsewhere. [1]
Also, it's a very risky proposition for most folks to do a 'true' open source project and as you say make it 'profitable' via sponsorships or whatever.
" it's VCs who want their money back times ten"
Keep in mind that this is the market speaking, not a 'specific need of some group'.
If it costs money to productize and support something, and it's risky, it's going to be VC and there will be terms that take that risk into account.
Another way of saying it is that '10x' requirement is a function of the business model of those taking the money. (Which by the way, as you point out, might involved 'over estimating the worth of something)
Most VC's are not successful and even the 'obscene' amounts of money made by some actually don't make up for losses elsewhere. [1]
Also, it's a very risky proposition for most folks to do a 'true' open source project and as you say make it 'profitable' via sponsorships or whatever.
[1] https://techcrunch.com/2017/06/01/the-meeting-that-showed-me...
I wonder sometimes, though, which market is being served.
I think in some ways, it is actually the VC market itself that is being served, not the customers of the company the VCs are investing in.
There is so much VC money floating around, and they are 'in the market' for investments to make with that money. The problem is sometimes there just isn't a downstream market that needs to be served by a company funded with all that money, so the VC needs to try to find one. And they often times reach pretty far to find that investment opportunity, and try to force a downstream market where there is none.
There might not BE any market for the 'productized and supported' version of the open source project that a VC wants to fund, but since they have so much money they decide to try to force it to fit that model. They put a ton of money in, grow the company, and then are forced to monetize to support that big of a company.
Maybe the community was being served just fine without that much investment, but now that the investment has happened, the company is forced to act in ways that AREN'T serving that community.
And by and large, giving software away in a combination of gratis and libre maximizes the gains of mindshare and experience from both the curious amateur and the intrigued professional; the intellectual and societal implications may be different, but it gets used by the bulk of users in the same manner as shareware.
For many of these newer projects, the libre aspect isn't a heartfelt belief -- it's a sort of loss-leader strategy to enable access to a particular type of audience, and unlock a particular type of language for marketing. Handfuls of people may exercise their rights to fork and/or redistribute, but plenty of intrinsic barriers exist to keep these from being a competitive threat -- until a sufficiently equipped and dedicated party like AWS or Google Cloud, that is.
It's no surprise then, that some offerings are drifting more towards traditional shareware, where restrictions on use are the norm. In this space, we're seeing a conflict unfolding about the ideology and terminology used to describe such split offerings.
With most successful software products, you are paying for the exclusive value that the software provides, with open source that value isn't exclusive at all.. I can simply copy your version and try to integrate it myself. So how does open source software make money?
I think freemium and consulting might be good models. Let's say I'm open source organization that builds product X, this product is really popular, has a great developer ecosystem, solid roadmap, lots of folks are using it, etc. If it's good enough large corporations will try to use this product within their systems, why not audit how your customers are building on top of your systems and try to skate to where the puck is going and add an additional layer of features to support those enterprise use cases?
The challenge with open source comes w/ integration, at a large scale your open source product is going to be changed to fit the needs of the customer. As the organization behind an open source product you are in prime position to be the leading consultant of this product and assist with integration. To me, this is the best model to make money on open source, however, it requires a really strong product. Something with very high adoption, not just a plugin that handles a very specific use case.
https://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity...
If the software is open source, the software itself is not scarce, so it makes it a bit trickier to figure out.
Careful about universal claims. https://vcvrack.com/ is an open-source business model and it works great for me.
The project website is cool as well. Very nice with the images of the rack in the mobile version :)
This is exactly how I feel as well. I am working on an open source to-do list + calendar (https://getartemis.app), source at (https://github.com/satvikpendem/Artemis), and I try to subscribe to the same philosophy as Sentry[1] and Ghost[2], two popular products that are also open source but do not avoid generating revenue because of that.
One must always strive to compete, whether it be through business model, or more often, product. You can release a good proprietary product, or similarly, a bad open source product; the quality of being open source does not necessarily add nor detract from the quality of the product itself. Sure, one can `git clone` the product, but due to the other factors in the business, the "soft skills" such as marketing, branding, sales and general business development, no one can reliably copy the company still generate substantial revenue [3].
This is not to say, however, that if your company is infrastructure such as a database, that no one will copy and monetize that better than you; they may, even in general usage of the product, but what is missing is the lack of vertical integration within the product. A database is just a part used in the whole of a new product, not the whole in and of itself. That is why if I desire to make substantial revenue from an open sourced product, I would make it a fully integrated product, just as any proprietary one, and that is what I am to do with Artemis.
[1] - https://github.com/getsentry/sentry [2] - https://github.com/TryGhost/Ghost [3] - https://ghost.org/about/
It's not clear to me that Open Core has really failed. Case in point, Elastic just IPO'd for billions and has an open core. In their case they completely develop their project. Their community is something of a user community, and the contributor community is heavily Elastic managed.
Sure those in the contributor community might complain about how hard it is to contribute, but 99.9999% of the community is more in the 'user' end of the spectrum and appreciate the stability of having a single company's vision and backing
I'm not sure its in the spirit of open source, but that's not the question. The question is about effective business models.
(more fundamentally 'open core' can mean so many different models it may be becoming meaningless)
0. produce something very widely useful
1. wait for it to become essential
2. create a consortium and profit from the dependence bred by #0
Paid open source development happens all the time. If you pay me, I will release open source to do such-and-such.
Despite decades of continuous doomsaying, new dual licensing companies pop up all the time. If you use my open source to build closed, pay me for an exception to my copyleft license's terms.
Those are just the simplest and best known. There are others, as well as all manner of hybrids, explored and unexplored. My latest work theorizing approaches---modelling business models, so to speak---is here: https://blog.licensezero.com/2018/10/17/mapping-models.html My outline of "purebred" models begins here: https://blog.licensezero.com/2018/10/17/mapping-models.html#...
> Amazon and Google are not going to use your software, particularly your management software, “out of the box”, proprietary or no. They’re going to build their own management UX and UI, because they have their own particular requirements to serve their needs, and they’re going to build them using existing platform APIs.
Licenses like MongoDB's SSPL leverage exactly this fact to address their business concerns. Mongo knows the big cloud providers are going to do their own custom service rigging, and that they'll keep it closed and proprietary. SSPL gives permission to use Mongo to offer Mongo as a service, but requires open release of the service rigging.
I don't think companies writing and adopting these new licenses want to sell cloud providers proprietary licenses through their sales funnels. I think they'd rather stop cloud providers from offering their databases as services, full stop, or cut special deals with the cloud providers to resell their cores (Mongo) or popular add-ons (Redis, Elastic, ...).
> You’re not going to resolve your own business mistakes by reverse-engineering a licensing solution to what was essentially a business model problem.
Business model and license do not inhabit separate domains. They always intertwine.
It works well both ways, in the sense that those who are capable coders may download and configure/install the software themselves.
Some others will just skip the hassle and buy the Marketplace version.
It is a win-win situation, insofar as someone does not take the time to repackage it and sell a competing version on the AWS Marketplace or some other sales channel.
I have not figured out that part yet. Any suggestions?
And where do the resources come from to hire people and build it?
Perhaps we need a middle-ground between open source and proprietary? Open source often becomes a signal to find business partners with similar potential needs. Perhaps you could share source with only 'approved partners', so you can together make "some money" instead of ($0 xor $1billion)
Decentralization takes the principles of open source and applies them to the very infrastructure on which software runs.
At Storj, for example, we have an Open Source Partner Program that attempts to solve the ‘Amazon Problem’ by enabling any open source project to generate revenue every time their end users store data in the cloud.
Storj tracks usage on the network and returns a significant portion of the revenue earned when data from an open source project is stored on the platform. Critically, this enables open source projects to derive sustainable revenue from usage, whether by commercial customers or non-paying open source users.
In my opinion, this can help drive and support the next wave of Open Source monetization models.
As I'm aware (personal experience) not only Amazon taking profit from open source, and there are more company use open source for their core product, but not giving any feedback to open source community.
Thanks
Are premium add-on and support/consulting the model? Any platform company that made it?
But for open source software itself, the success is not measured by money,but popularity and impact. Linus is successful on Linux work. People and history would remember him. Who cares about VCs in making history?
Than the business model instead of selling (cr)app and training and migration solutions, certifications, ... we can sell time&knowledge of programmers and operation.
Of course in this case many "administrative" & "marketers" will loose their job, but that's have a name: natural selection that it can be pushed a bit but sooner or later it will came by nature.
And really, the dichotomy contributes to the situation.
The ones who built useful tool and years later realized it may be monetizable are hemmed in difficult choices. Do they reneg on open source and go proprietary from this point forward, effectively forking their own product and leaving the gratis, libre one -- the one most people will have exposure to -- stuck on an old version? Do they split into an open core and proprietary enhancements? Do they write a novel license and hope consumers will self-select into tl;dr harmless amateurs and very handsomely paying corporations? And if SaaS providers take their old version, and that fork gains ground?
Meanwhile, the ones who used 'open source' chiefly as a customer acquisition lead will face the same set of challenges. In the end, any artifacts published under an open source license are forever -- as long as the interest is there, a sufficiently dedicated party can take it, use it, enhance it, try to build a business around it, and the like. And any past version is a potential competitor, so your business models must be tolerant of that fact. They rarely are.
Your point reminded me immediately of this article from late last year:
https://redmonk.com/sogrady/2018/12/21/cycles-oss/
The article's reasoning struck me as fundamentally sound, but it began with the false identification of open with the public, rather than private, interest.
As for your proposal, have a look at the Fair Source License: https://fair.io/
I blogged initial thoughts on Fair, line-by-line, when it came out: https://writing.kemitchell.com/2016/03/30/First-Read-of-the-...
I think Stephen probably coined the "There is no open source business model" expression a couple of years back.
I think what really happened is people didn't quite realize, or didn't think it would matter, what they were giving up when they open sourced their software. It sounds good and feels good but 5-10 years later when it's a core component at major companies it feels like you got ripped off even when you explicitly signed up for it.
A similar question exists for laborers that need to invest in learning tech stacks. Why spend time mastering something that certain companies are discouraged from using? Especially if a non-encumbered variant exists.
Wouldn't it be more practical to learn tech that employers can easily use?
You could frame this in a different way and come to a different conclusion. Instead of describing OSS as a "stack you lose the license for if you do too well" you could say "stack you don't have to pay for unless you're successful".
I'm not convinced personally, but I think that's the idea.
However, I understand the point being made. It's essentially a tragedy of the commons argument. Because the companies that get the most value from open source are also often the ones with the greatest resources to give back to open source projects if they chose to, they have a moral obligation to do so. There's also a sentiment one often hears along the lines of: I'm fine with people using my work for free but I don't want them making money off it. (This is essentially the basis for Creative Commons' non-commercial variant).
So it's not so much that large companies are actively hurting the projects--though you could argue that hosted offerings compete with the projects themselves. But that they often don't help in anything like the proportion that they benefit.
So all the examples you give are funded by big companies. Works perfectly.
In the end, they probably should have had those provisions to begin with, but were more concerned about early growth and first to market.
That's only sustainable for as long as there are those comparable and freer platforms to switch to. But if the argument being made here is valid, that is not guaranteed.
With that said, a commercial fork is being worked on this year that works in additional environments (i.e. as a VST/AU/AAX plugin) as the "normal" open-source Rack (i.e. a standalone application for Win/Mac/Lin). If I understand correctly, this is similar to the traditional open core model, although it's not really an enhanced version but a ported version.
The most profitable way appears to be to offer a cloud-hosted solution, and herein lies precisely the problem with AWS et al providing these services by taking the OSS software for free.
First, SQLite's developers are not an open source company funded by VCs. I don't know what funding they had originally, but they've leveraged their success into a well-funded consortium. Does it matter if it could or could not work in combination with VC funding? No: what matters is that the developers got funding, end of story.
Second, I don't see why a company (regardless of funding source) couldn't spin off a consortium to fund further development of some open source created by that company.
Your goal seems to be "profit", which is a fine business goal. Open source is a fine business tool, but not so much a fine business _goal_. It can help you profit, but it can also hinder. Open source is a business tool to be applied on a case-by-case basis.
Open source is not easy to use as a core business value. That's because the most important core value to any public corporation is profit, and open source does not intrinsically lead to profit. Building a for-profit business around open source projects with open source as a core business value is undoubtedly difficult. Indeed, the example I gave is of a non-for-profit organization that funds development of one project.
Open source is a tool with following costs and benefits (and risks), some of which are:
- cost: loss of confidentiality for "secret sauce"
embodied in open source
- cost: the cost of opening a code base and keeping it open
- cost: dealing with a community
- benefit: good will
- benefit: mind share (this is the big one)
- benefit: quality (hopefully) contributions from
the community
- benefit: credit (especially for developers, which
functions as a form of compensation and
recruitment incentives)
Edit: Strangely enough, I don't know anyone who did this on purpose.
My personal feeling is that developers are irrationally averse to paying for someone else to set up and reliably run software for them, but that it's usually a massively good deal to pay for that service.
Even a simple software project that takes an hour a month to keep running is well worth most companies paying $100/month to not have to worry about, for example.
But as soon as I'm deploying anything in a corporate setting, I would always prefer to pay rather than asking IT to setup and maintain a service. Or worse do it myself..
The combination is good. Because I would rarely try out something I couldn't run myself. But I would also never put it into production.
There are a few geocoding AMI's on AWS Marketplace. ( https://aws.amazon.com/marketplace/search/results?searchTerm... )
Some big companies on the list (Pitney Bowes, Mapbox, Here)
I've always held Mapzen in high regard as one of the best geocoding APIs to come out of the opensource camp. Mapzen would have been a nice addition to AWS for sure.
Some companies prefer having their own server rather than sharing access to an API.
Fun anecdote I heard from a very seasoned VC. He mentioned a trick VC funds use is to raise capital, then spend that fund before any of the companies can make a return (this varies from fund to fund, but imagine anywhere from 2-10 years, usually centering around 5-7). They then go back to their LPs saying "look how good our portfolio is doing, we just need more money to help them out!" without any truly meaningful metrics such as profitability, and essentially keep the house of cards afloat like this by cyclically raising capital before funds can show an ROI.
Also most VCs lose money, but nobody (by which I mean LPs) ever seem to care about that because they're excited about the potential without understanding the risk of the market.
So if VC wants to over-fund products and basically give away development and services, it's not all that bad.
I'd rather see more Engineers employed and learning than less.
For us, we've really been focusing on the customization of Pelias for people who have specific needs. We have Elasticsearch under the hood which is perfect for that sort of thing, and the nature of customization is that an AMI probably can't do what our clients need. But probably someday it will make sense.
The societal accomplishments of capitalism are effectively distraction and insulation from the side effects of complexity.
see https://en.wikipedia.org/wiki/The_Open_Source_Definition for what qualifies as "Open Source"
OSI approved open source that is. And you can tell users anything you want actually. What you can't do with OSI approved open source license is choose a license not approved by OSI, doesn't matter what it says.
But OSI approved open source is not true descriptive open source. SQLite, for example, is universally recognized open source, but not OSI approved. You can go this road and use a descriptive term and ignore OSI and its corporate backing.
So, yes, you can have an open source license that isn't OSI approved. However, leaving aside a few edge cases like public domain, there's pretty wide acceptance of OSI licenses as the population of significant open source licenses.
[ADDED:In practice, the FSF's list of free software licenses and the OSI approved license list line up pretty closely--with the exception of PD+source. If someone wants to argue that the FSF's list is the one we should go by, I'm not really going to argue.]
I do think it is potentially appropriate to have thoughtful discussion over whether the current open source definition is too narrow but I also think it is useful to have a generally agreed-on definition.