"Profit" is a strange and ambiguous term here.<p>I've been running an open source, libre project for closing in on 24 years now, and generating revenue from it for about 17 years. There's never been any "profit", but there has been revenue.<p>I regard profit as what's left of the revenue after you pay the people who work on the project and any expenses, which is the way most corporations and accountants would view it.<p>The only sort of open source project that needs "profit" defined this way is one funded by a capital investment of some kind, where the investor expects a "return". While there are some open source projects that fit this description, the vast majority do not.<p>Also, as is typical for things linked from HN, this whole article seems very web-y and SaaS-y. There are other kinds of open source projects, believe it or not.
The problem with this business model is it creates a tension between the OSS version and the paid versions - you want the OSS version to be good, but not such a good solution that nobody feels the need to pay for your SaaS/consulting/etc. That tension seems to inevitably lead to obvious features missing or functionality/knowledge that's needed to operate at any scale coistered away as closed source so the sponsoring entity can make some money.<p>If the product is more infrastructural you also now have an established pattern (Elastic, Hashicorp etc) of switching to look-but-don't-touch licences to avoid being obliterated as a one-click service for the major cloud providers.<p>Which isn't to say the article is wrong, I just wish they wouldn't pretend commerically backed OSS is some kind of kumbaya win-win for everyone instead of being effectively a trust growth hack for startups before the need to generate revenue inevitably leads them to turning the screws one way or another on the beloved community that helped them grow.
> Minio is a great alternative to companies mindful of who has access to user data. Of course, AWS claims that AWS personnel doesn’t have direct access to customer data, but by being closed-source, that statement is just a function of trust.<p>Can't a company claim to be hosting something via open-source software but using a closed-source in-house software masquerading with the same API endpoints as the open-source version? This still requires the same kind of trust as AWS.
The author calls out they are specifically talking about open source solutions that compete with paid offerings. IMO, the jury is very much still out on whether open source "wins" in this regard. In the past decade we've seen a huge rise of open source products, and in the last 5 years or so we've seen many of them move away from that. MongoDB, the Hashicorp stack, Elastic, Red Hat, MinIO, the list goes on.<p>There are not that many truly open source, commercially competitive products remaining and many of them are fighting to prove it's a viable business model.
Dumb title, of course it does<p>Author is trying to say Open Source <i>businesses</i> do not win by being cheaper.<p>Open source <i>codebases</i> win all the time by being cheaper, no one pays for compression algorithms or network time daemons or media transcoders. Open source obliterated those markets entirely.
For me as an engineer who influences technology acquisition, open source wins by being grokkable.<p>- If my colleagues and I can see the source, we can decide whether or not we think it will fulfill the claims it makes.<p>- Once we're using it, if we run into a bug or an unanticipated use case, we can, at a minimum, research a solution and suggest it in a bug report. Alternatively, we can open a PR.<p>(edited for formatting)
> <i>What is a transparency problem? It’s when a solution being closed source creates distrust between the client and vendor.</i><p>Eterprises don't care that much about code. And if they do, business continuity clauses may alleviate most of their closed source concerns. After all, how many financial firms switched to OpenOffice Calc from Excel?<p>> <i>She argues that Amplitude is pretty expensive, particularly prohibitive for some early-stage companies, and larger companies could save a fortune by using an open-source version. While this pitch might resonate with early-stage companies, those same price-conscious early-stage companies will either use an open-source version or a free tier.</i><p>AWS' go-to-market (GTM) hinged on attracting startups and individual developers by offering them low cost (metered) services. They got this part very right, because Airbnb, Stripe, Twitch et al went on to become large enterprises and grew alongside AWS. There's not many things that can compete with <i>low cost</i> / <i>free</i>. You can always move upmarket later. Just ask ARM and Intel.<p>For dev tool upstarts, open source has become the defacto GTM (it isn't, as TFA rightly points out, a business model). So, unless you're Snowflake level good (and you can fend off FOSS shops like Databricks), you're better off with an open core model.
Sort of related only in the realm of software sales:<p>A long time ago I sold a user interface update to a poorly designed game. I priced it at 2x the cost of the game ITSELF. And people still bought it, because it was professionally designed. That is, I as a professional designer, took time away from my full-time work to do what presumably this developer could not.<p>The primary complaint as clearly noted in the comments of the digital distribution platform I sold on at the time was that the update was too expensive. And people obviously commented on how I price-positioned the software.<p>But one point was obvious. The game itself was too cheap.<p>When people are complaining about your price alone and still buying, it’s means there was nothing else worth complaining about.<p>The birds will always want free food. Don’t cater to the birds.<p>As a flattering addendum, the update was distributed illegally and got around to pirates quite well! I was happy with that because most customers paid. It was also clear that I was fulfilling a desired feature set that otherwise wasn’t being delivered.<p>Some problems like that are nice to have as a symptom of creating something people want.
I think a lot of open source projects aren't made open source by choice but by necessity. Sometimes making a product open source is the only way for it to gain any adoption at all.<p>The author is focused on a tiny number of elite open source projects. They are not representative of the vast majority of open source projects.<p>Some companies have the right business and/or government connections and they can easily sell lucrative licenses for their products but they are a minority. Most people and small businesses do not have that kind of network. Without the right business network, you will struggle to earn any money at all. It doesn't matter how good your product is or how much money it could save someone. Nobody will believe you, nobody will even try it out. The adoption hurdle is too big, even if the long term benefits could be massive.<p>Making a product open source is the only way to get your toe in the door because it gives you a tiny chance of having your product noticed and that's really all that matters sometimes.
I think the key point which is missed here is - Open Source gives you the choice.<p>It does not necesarry mean cheaper (in a moment) but it means if you're not happy with vendor pricing, quality or there are other factors in play, you have alternatives.<p>With proprietary technology choosing technology means marrying vendor for life
For me, OSS is all about being able to edit to get some long-tail functionality in. For both Kong and Airbyte, I didn't have to wait for some internal prioritization pipeline to finish.
VLC trumps any sort of paid video player software, including the one provided by Microsoft. Been using it for years at work and its been flawless. In that scenario, it wins!
> For some, this might be a tough pill to swallow. But a for-profit business exists for profit.<p>No, a business usually exists to provide some useful good or service to its customers. FedEx delivers packages. Apple makes phones and computers. Etc.<p>> Definitionally and practically. Profit is what allows the company to hire employees, grow, and sustain itself—it is quite literally what funds ongoing development<p>That's <i>gross profit</i>. Regular (net) profit takes operating expenses (including R&D) and other business expenses (interest payments, etc.) into account.<p>It is certainly possible for non-profit businesses - as well as public benefit corporations - to fund R&D.
Counterargument: Linux is on most servers, smart phones, and information appliances. Primarily because its scaling cost is near $0/host, and some users feed useful resources back into the digital karma pool.<p>If the goal is to share an opensource project as widely as possible, than most will sell associated services to generate support revenue. Some operate as a nonprofit entity to offer tax breaks on supported project services.<p>Trying to cram a GPL/BSD/Apache project into a 1990's shareware license model will usually fail.<p>Beer is good...<p>Milkshakes are good...<p>A Beer-Milkshake is a terrible idea =)
<i>a typical open-source business needs profit to be the ultimate north star.</i><p>I totally agree. We're making profit our north star in BrowserBox at Dosyago. It's a hard balance to strike, but absolutely necessary.<p><i>Catering to the price-conscious is a losing battle.</i><p>As for competing on price being bad...I guess that's true if you go free, but aside from that, I think there's markets/segments where that works. And if you have the solution that can support a lower COGS then you have the room for that too.<p><i>A great case for an open-source solution is when a transparency problem is present. What is a transparency problem? It’s when a solution being closed source creates distrust between the client and vendor.</i><p>I totally agree with that too. It's one of the reasons I thought going full open source would work for our cybersecurity market.<p>But I think there's also the reliability concern: many companies are concerned that going with a small vendor may lock them into a dead end if the vendor goes out of business.<p>Open source is like an escape hatch for the pressure of those concerns, by providing a guarantee that if you do go out of business they can keep using your product.<p>I see this as less about licensing and more about access to the code. Breeding self-reliance in your clients is a recipe for scalability, and helps solves their reliability concerns. If you're the only source for updates and changes, you're a single point of failure. Open source is resilient in that way.<p>Come check us out: <a href="https://github.com/BrowserBox/BrowserBox">https://github.com/BrowserBox/BrowserBox</a>
I have always cringed at people calling open source "freeware", I had a boss many years ago who had this mindset, for him expensive software was a guarantee of success.<p>For me, open source is the power of collective wisdom, the propriety software that I have seen through the years has always seemed a bit sad, lonely and unread.
Fantastic article. I'd love to see more people championing statements like "Profit, not usage, is a measure of success".<p>I think there's a stigma about open source projects being run as commercial, profit-generating businesses, and I'm very happy to see more people championing the Commerical, Profitable OSS cause -- which everyone in the ecosystem benefits from. (More Profit == Keep Building More OSS).<p>I happen to like the Open Core model here, where businesses adopt OSI OSS licenses for the core, and Source Visible licenses for the rest - which gives the balance of visibility, auditability, etc, whilst still enabling the project to be revenue generating, delivering longevity as well.
Win what? TFA is published on a platform owned by Microsoft.<p>- - - -<p>I always thought that the whole point of computers and software was to make machines to do the scut work so we could all take a break and explore the universe Star Trek-style.<p>You don't win by making money, you win by obviating the need for money at all.<p>Science has delivered technology and wealth (it's not evenly distributed, of course, but that's not the problem I'm talking about.)<p>If we apply the technology we already have we can take care of everybody on earth (and mitigate the climate change) and you just sit around and write software or play video games or whatever you like.<p>That's how FOSS wins: "Let the robots do the work and we'll take their pay."
> Granted, MongoDB eventually switched to a special SSPL license to add specific restrictions on Cloud Providers from distributing a service without contributing to the project, which isn’t OSI approved, but is open-source practically<p>As an open source consumer (as well as author, but not as a business), I consider it "practically" a part of open source that I can choose to run open source software on any vendor or platform I want, not just ones who have a licensing deal with the software authors. This is a very practical matter.<p>It may well be that you can't actually build a succesful business on actual open source. The arguments about how you can succeed with an open source business seem to be mostly based on making the source code _available_, with no need for it to be actually open source. It may be that "source-available" without actually being open source can be a viable business model in many more cases than actual open source.<p>I think the sustainability/viabiilty of open source is indeed currently under question.<p>But the difference between source-available software without an open source license, and actual open source licensed software, really does make practical difference to the consumer.
When depending on open source projects it is harder to run into situations such as what happened to Adobe Flash, or Microsoft Silverlight.<p>Or the entire career of this guy <a href="https://blog.visionarycto.com/p/my-20-year-career-is-technical-debt" rel="nofollow noreferrer">https://blog.visionarycto.com/p/my-20-year-career-is-technic...</a>
My hypothesis about open source is that it's all about tax evasion. I can write some software for others to use, not charge them anything and thus no tax liability is generated. If they do the same, we've generated value for each other without the tax man getting a cut.
> While the core product is typically maintained by a central engineering team, integrations or plugins are often built by community developers and then occasionally merged into the main branch.<p>One of the things I really dislike about opensource deployments is plugins. Often the core team is happy to let something go to a plugin and 99.99% of the time plugins just get abandoned. It's worse when some projects "outsource" basic functionality like authentication (say via saml or oidc) to a plugin.
Posthog isn't truly open source as the author claims.<p>It's "too complex" to run natively and is only recommended for "hobby" projects. They basically say, yeah our source code is there but if you want to run it yourself, forget about it.<p>I was thinking of some clients I have that would benefit from this in their secure environments but was quickly chastened by their docs.<p>Fair enough, they have to make money but seems like the ole bait-n-switch method of customer acquisition.
Interesting post and would like to bring nuance as the founder of an open-source alternative to Retool and Airplane: <a href="https://github.com/windmill-labs/windmill">https://github.com/windmill-labs/windmill</a><p>Our enterprise edition is clearly cheaper (between 2-5x cheaper based on customers migrating away from those) than our competitors but we bet on volume and lack of sales team to make it up for it in terms of margins.<p>There are pragmatic reasons for it, our community/oss edition is featureful and include SSO so there is a temptation for our customers to just roll with the CE and we cannot be too greedy.<p>One could argue that support should be sufficient since the jobs ran by windmill are critical, but the main strength of a product like this is reliability and since we achieve near 100% reliability, it isn't sufficient. We are not gonna intentionally make our product less reliable on CE.<p>The other reason in my opinion is deeply rooted with the nature of open-source: software cost nothing to replicate and it would be a shame to have users not benefit from the right tools just so the pricing can extract as much $$$ as possible.<p>So ultimately it comes down to the tension between being VC funded (and we are but to a much lesser extent that our prop alternative) and the pricing of open-source. I am deeply convinced that there is a compromise that satisfies everyone by having the different force in presence being kept-in-check. VCs want small seed companies to scale to become global companies; customers and users want to invest in a platform they know they won't have to regret later because of rent-seeking or lock-in practices. True OSS helps companies achieve global scale as long as their product is better (which make me agree with the substance of the post, being cheap is not enough) and also ensure that company can never or hardly employ dark patterns otherwise OSS fork of company's product will be too competitive against itself.<p>Before being a founder, I was among the most skeptical of OSS with VC backing and I really understand why someone would have a hard stance on it. But I came to realize that good software takes not only lots of hard work, but a focus and a dedicated team that is hard to find without a core team that has strong incentives to make something that people want. So I see the future being dominated by companies that fall somewhere in the following spectrum:<p>1. OSS products that are public utilities and there are enough needs or the project is interesting enough to have a strong core team that doesn't require VC backing<p>2. OSS products that are more commercially oriented and have values but wouldn't exist without VC backing<p>3. OSS products that were able to bootstrap themselves completely and are COSS but without VCs<p>And proprietary software to slowly become extinct as the world of software become more competitive everyday as the potential grow larger and the number of VCs that will fund open-source grow larger (and the ability to bootstrap those businesses also get easier).
All very true. Price-conscious customers are not worth catering to. Non-price-conscious customers, well, don't care about price (to a (large) extent). Price is very rarely an issue.
I thought this was well understood. TCO is a big number, and license cost is typically a small portion of it.<p>FOSS can be a win because of stability and control; cost is rarely the driver.
I like that his blog is literally just pages on Github. It shows that there are so many free resources these days if you know where to look. That's cool to me.
The only reason to keep something closed source is if you're trying to hide questionable behaviors (e.g. NVIDIA drivers, M$ Windows) or your code's embarassing (most enterprise software).
I've always been annoyed that companies will pay 6 figures for a support contract, but won't consider hiring a full time engineer for the same or less pay to support an open source product that does the same thing.<p>The support contracts are often disappointing too, like you are paying $200,000+ a year for the stupid thing and they won't even fix your problems? "That product is not our current area of focus". So frustrating.<p>The multiplication of effort you would see if 5 or 6 companies did this is incredible. For example the Linux kernel is an example of this working. Everybody cooperates, everyone wins.
"Open Source" doesn't win, period, because it doesn't compete with anything. Open Source is not a business model or a product. It's an engineering widget. You can use it to build a product, or you can use it to make a jig to shore up an uneven table leg. Nobody cares about the license or whether they can read your code. They care if you build a product that solves their problem.<p>You know why companies use Open Source, for the most part? It's free. Not because it's better than the non-Open Source alternative, because very often, it is not. And not because they can read the source code, because companies need a working product much more than they need the ability to write their own patch for a bug. And not because of some feel-good notion of sharing with a community. It's just cheap and plentiful. Which is great, for the consumer. But it's not easy to build a company on a free product.<p>For the most part, Open Source products win by either being A) cheaper, B) Freemium, C) "Source-Available", D) being the incumbent, or E) a better product.<p>Sometimes "a better product" really does win out, if a product is able to provide features competitors don't. But incumbents have had the time and resources to establish lots of features, a solid track record, and lots of support and integrations, so <i>not</i> going with the incumbent tends to be a bad idea. People prefer Source-Available when it's completely free, and Freemium if it's not completely free. All things being equal, cheaper wins.
Disclosure: I work for a closed source product company, but write a lot of open source that pairs well with our product.<p>What a silly claim by the author.<p>Of course OSS wins by being cheaper (in terms of $$$ paid). I agree that cost is not the only way it wins, though. Points made by the author on how it can win:<p>* extensibility<p>* transparency<p>I'd also add:<p>* lower barrier to entry (for a subset of technical users, at least). If you want to try it, you download it.<p>* optionality: in the spirit of libre open source, you should be able to stand it up yourself. If things go sideways with the company providing you the OSS app, you've lowered your risk.<p>* if the user is a dev (the product is infra) "many eyes make for shallow bugs"<p>Those are all compelling arguments.<p>However, weighed against all of that is the profit motive and sustainability of a business. People, even software devs, like to eat :) . And businesses need to make money to employ people and push a product forward.<p>Honestly, I don't think we've figured out how to build a pure big open source business outside of the following business models:<p>* consulting/support (Redhat); pursuing this has poorer margins<p>* loss leader for another service (like VSCode for the MS ecosystem). this isn't really a pure OSS business model<p>* hosting/SaaS (but the clouds impinge; I opined a few years ago on this: <a href="https://www.mooreds.com/wordpress/archives/3438" rel="nofollow noreferrer">https://www.mooreds.com/wordpress/archives/3438</a> )<p>(I'm leaving out open core or SSPL companies because I don't consider them to be 'pure' OSS companies, myself.)<p>Maybe the answer is that we can't have a big open source business. Maybe smaller ones are just fine. I'd avoid VC though, in that case. Most don't like smaller businesses.<p>FYI, you can also have some of the beneficial attributes of OSS:<p>* transparency through clear communication and docs<p>* extensibility through clear, stable APIs and docs<p>even with a closed source company. Software companies have lots to learn from OSS as a development process.
We are also open Source community at Apache <a href="https://github.com/apache/age">https://github.com/apache/age</a>