Open Source does not win by being cheaper
github.com
github.com
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.
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.
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.
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.
A corporation holds the profits (after expenses) on its books and they may (or may not) be distributed proportionally to shareholders. If it's not distributed, it is part of the value of the company.
It would be profit if I was organized as an LLC that agreed to pay me $X/year and took in $(X+Y) in revenue.
I'd rather profit. :p
You mean the rest of computing...
Of course, I am operating all those via an Open Source HomeAssistant app, connecting to an Open Source HomeAssistant instance running on an Open(ish) Hardware Raspberry Pi. But all of that means fuck all, when the malicious vendors make a cloud server a required control intermediary. Despite all that Open Source, my home appliances are still run as a Service. That's one of many cases of what I mean by "being implicitly a SaaS".
- There's approximately zero non-SaaS robot vacuums among the newer models. I gave up on this after a long search for something free of this insanity.
- With my A/C unit and thermostats, the brand and model choice was made by the people doing the installations. I'm not sure if there are non-cloud, network-controllable options anymore, and even if they were, I'd have to look for local HVAC companies that actually offer them.
- I spent much more time and money than is reasonable to have a fully-local networked baby cam, that doesn't leak videos to the cloud. Specifically, I had to buy a camera and two pieces of expensive network gear from Ubiquity (per HN advice, thank you), because that's apparently the only option in Europe (US folks have Amcrest), other than hacking something together from a spare Android phone, or webcams and Raspberry Pi. There's literally no other cloud-bullshit-free option I could find.
(The "baby cam" is at least made of professional, high-quality gear, so that's a silver lining, but I doubt normal people would be happy to spend €500+ just to keep the video stream in-house.)
I'll grant you those, though I've been hearing noise about DAWs starting to move to the browser. And, of course, you omitted image editing, which at this point is almost completely taken over by a small number of SaaS offerings (Adobe Creative Cloud, Figma, Canva).
> Your OS.
I'd wish. At this point Microsoft is, both explicitly and unironically, saying that Windows "is a Service". I literally saw that on a Win10 installer screen the other day.
> Most embedded systems found around your home and workplace and transportation.
Much good it does me if the control plane goes through a cloud server. See my other comment in this subthread.
> Air traffic control.
Hopefully, maybe, but I'm no longer certain of it. Web SaaS apps have been popping up in ground and maritime transportation for a while now, so aviation may be already affected too.
> Scientific data analysis.
That's cloud-dependent these days.
> Most video/computer games.
Most high-end video games are SaaS now. Even in single-player mode, as again, the vendor's servers are on the control path, and the game won't boot without at least acquiring a license from a server and checking for updates.
Just because it doesn't run in a browser, doesn't mean it's not SaaS.
SaaS means that a substantial portion of the compute task associated with "an application" can only be completed via a server request (whether it's to initiate the compute task, or fetch the code that will run it, or some combination of the two).
Does "ask for permission to run local code" count? Then modern video games, and quite a lot of other software, count. Per your "initiate the compute task", my robot vacuum is fully SaaS.
> It does not mean whatever Microsoft wants it to mean.
What Microsoft means fits your definition, they're just taking a soft approach - Windows now constantly fetches new code from the cloud, they're just not forcing it to be a required dependency, should you want to turn this behavior off.
Also remember I called out software being implicitly SaaS, not explicitly.
Related: forcing people away from Windows 7. Half a year ago, my wife was forced to upgrade her perfectly fine Windows 7 laptop to Windows 10, which she actively hates, because suddenly, third-party software like Spotify begun refusing to work, showing instead messages to the tune of "upgrade to newer Windows or GTFO". Yes, it's not Microsoft doing this per se, but the effect is the same. Implicit SaaS is a software ecosystem problem.
In that context profit is what's left once revenue is received and expenses paid.
Implicit in those expenses are (fixed) salaries, employee contracts, payslips and so on.
What a business does with the profit can be varied. Firstly it can be added to cash reserves, which can contine to pay expenses through poor-revenue months. It might be spent on assets, like new hardware. It might allow for another hire. In some cases, although less often than you might think, it pays out dividends to owners.
You don't mention too many details, so I can only presume your situation. I suspect it's a different kind of setup. If you are man-alone, and the project is small, (ie you have no desire or need to add a employee) then basically the revenue is just income to you. Some months you get more, some months you get less. In this context there isn't "profit" but revenue. This is especially possible for software where other overheads are trivial and the effort of tracking expenses for tax purposes meaningless. You may not even keep a set of books.
If you are indeed in this space, then I understand why the article feels unrelateable. It's discussing a very different situation.
As with all articles of this nature, context is important.
> To be clear, I’m talking about open-source projects that compete with popular paid solutions.
[ ... ]
> Excluding non-profit projects that are sponsored by donations or parent organizations, a typical open-source business needs profit to be the ultimate north star.
So, I think you've somewhat misinterpreted the space the author thinks they are referring to.
Ardour is a small project in terms of man-power - 2 full time paid developers, other individuals paid for media and other work, various commercial collaborations along the way, certainly dreaming of being able to use more paid development hours. We absolutely compete with at least a dozen popular paid solutions, with at least 3 on Linux alone.
The main reasons I think this article feels so unrelatable to me is (a) it's strange focus on profit (b) it's web/SaaS centric nature (c) it's B2B centric nature. It just doesn't have much to say about the "space" of writing native/desktop applications for individuals involved in creation workflows, free of VC influence.
We explain why we use PayPal over here: https://ardour.org/faq.html#why-paypal
People complain a lot about PayPal (especially on HN), but I have yet to see a viable alternative especially given (a) my status as a US citizen (which makes it harder to bank elsewhere (b) micropayment fee structure (PayPal is unique in offering something that makes $1 payments somewhat viable (saving around $0.25 per transaction, and there are LOT of them). The other well-known payment processors do not have the footprint nor the features that PayPal offers.
I think the quote marks around "profit" are appropriate here because the comment was about defining that specific word.
That's the guy who runs Ardour. It's a fundamental DAW on Linux, as familiar as Excel on Windows: it is the foundation of Harrison Mixbus. He's also fundamental to the JACK audio subsystem. It's possible you've heard of him as one of the two first programmers at Amazon.
His objection is mighty valid, here. You cannot say profit is a basic principle of open source. The whole point of open source is communication of ideas in the form of software and the ability to reformulate those ideas freely, leading to an empowering of communities of software users and the ability to DO THINGS.
That's the point. Making wealth for individuals isn't in the equation.
"The only sort of open source project that needs "profit" defined this way is one funded by a capital investment of some kind"
I guess this is what you chose to refer to... this is also a really weird take. The author finds himself in a position to define who needs profit and who doesn't because he's been participating somehow in open source for a few decades?! The OP's point seems much stronger to me, as they say something like "if you intend on growing and paying people to work on open source" you need to make a profit. If there's an argument against that, saying "you don't need it" is not at all a good one.
> Making wealth for individuals isn't in the equation.
So open source is only for people who are already wealthy enough to not need to make money? If you accept that working on open source is not feasible if you cannot make a living off it, and that you won't do it just for fun after day job, then you really should rethink this.
In practice, yeah. Counts for me: I inherited enough money to develop the world around my open-source work, though I began that work while I was still extremely poor.
Understand that what 'need to make money' means to a Silicon Valley tech bro, is one hell of a lot different than what it would mean to a normal person. If you live in a place where the cost of living isn't impossibly brutal, if you are willing to accept that if you get sick you'll die unless you are lucky enough that government healthcare comes through for you, if you're prepared to leave nothing behind you (like a Terry Pratchett wizard, dying drunk, happy and owing vast sums of money), then there is much less stopping you from getting into open source.
It's a bit like the music business, really (which I also work in, by virtue of my project). If you can afford to persistently do the work, you get to live the life and in the long run, be the guy who's done the work, to whatever degree of recognition that gets you. I know numerous sound engineers who've blown a fair bit of money doing it, and have no great financial security, but they were in the room when the magic happened, and when the echoes die away in the live room that's what they cared about.
When you die, your bank account is just numbers. I suppose you might want to arrange that it then does something. You could also do something while you're alive, and be there to see it.
Making wealth for individuals isn't in the equation… except when they're predatory vampires there to suck wealth FROM those who do the work. Being in the music business naturally I know about those stories. I'm given to understand this happens in Silicon Valley, and open source, too ;)
I've recently done a bunch of work on extending what's possible in slew clipping and slew softclipping, and I'm about to do my level best to provide legit big-analog-console sounds ITB as open source free software: that is through minimal but unorthodox DSP to target the end state of the sound rather than putting up GUIs and then using traditional DSP to imitate every last analog step in the process.
A recent milestone is Console Zero https://www.youtube.com/watch?v=rDAZTEUtSpk which is a bit of a radical experiment in applying only such mathematical calculations that preserve the mantissa of the floating-point value being worked on (where possible). This led to a 'switched' panner with a completely different (or absent!) pan law, in which every pan position retains the mantissa of the audio word, for an LCR-like effect where you also get a mid-right and mid-left position plus a whole array of increasingly hard-panned positions.
baconpaul from the Surge Synth project has helped me extend my codebase to things like VCV Rack support and is generally pleased with the relentless consistency of my code library (especially the VST2s which are all stereo and have no control variation beyond 0-1 inputs) and my ability to write notes and descriptions in such a way that he can write code to parse that and do things like bring all the plugins, INCLUDING what documentation they have, into a single package via elaborate scripting.
As a rule I put out a new open-source plugin under the MIT license every week. I am paid a bit over minimum wage by my Patreon, and if I didn't need or want to get studio gear to use and study, that would cover my cost of living handily :)
I'm far from a Paul Davis, but if there's anything you'd like, let me know. Worst that can happen is I'll go 'I have no idea how to code that' :)
I could setup a non-profit that explicitly doesn’t aim to profit, but it does so by paying my very comfortably. Profit‽
This disconnect is what causes many businesses that are successful (they earn enough for expenses and rainy days) to explode and die when sold, because they don’t earn enough for all that plus interest expenses plus return on capital.
You arrived at an employment contract with your employer. The contract is an exchange of value: your labor for some of their money.
If you are being paid more than the price your employer could otherwise obtain your labor for, then I suppose you could call some of that profit. But that is rather unlikely. Your employer is buying your labor, and is almost certainly paying you less than the value (to them) of whatever it is you do for them.
And people do enrich themselves via that method.
We would profit by focusing on what the author of TFA actually meant.
> 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. 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.
It removes a lot of pressure to not have pure investors expecting constant returns. Easier to do the right thing for the project.
But growth is likely to be necessary, and sensible, in any product space competing against ambitious corporations who are going to be strongly growth oriented.
Booking profits so you are prepared for downturns, opportunities, or large expenses isn’t just reasonable. The more people & customers involved, the more reason not to burn through all revenue as it comes.
Not a good way to get work done. At the end of the day you have to have done something.
I.e. aim for maximum growth of happy customers/users in the long term to best grow and thrive in the long term.
Short term worries about quarterly growth can seriously inhibit long term potential. Often without this huge opportunity loss being recognized.
Alternately, a rejection of profit as healthy can limit the ability of a non-profit focused project from achieving more also.
The key is, aim long term, for best positive impact, then work back from that to now, and use all constructive positive-sum tools available.
Better to, like Bezos, retain control and COMPEL them to deal with you over the long term. That guy is somebody who understands the value of power over profit.
Never underestimate the amount of chaos a homo economicus can run into when they're dealing with a fanatic, a prophet, or a vindictive businessman with a taste for vengeance. You don't only need to worry about self-interested idealistic hippies. You might also run into someone who is able to take a position using open source against you specifically to undermine you, and who can take a loss if it's for the purpose of taking you out.
This too is 'long term' in a sense. I like your 'long term' better, mind you. I'm just saying.
Perhaps one reason he retired, is Amazon got so big he couldn’t see any more significant long term growth, relative to its monstrous size, without enshittification:
Extorting income from partners, using sales data from third parties to compete with them, forcing ads and a gamed search onto customers.
He could only (or only wanted to) hold off Wallstreet for as long as he had a better plan.
Other than staying private, with stakeholders who care about the discipline & rewards of only finding quality growth (even if that path isn’t always clear), I don’t know of a way out of that trap.
I am no hippie, but I don’t think public ownership has found the perfect structure yet. There must be a way to better incentivize positive sum-only games. Keeping individual company growth tied more closely with customer improvement.
If you pay yourself 100% of your revenue as income you don't make any profit which is your choice.
Profit is needed to sustain periods when revenue decreases and to act when an investment is needed (for pivoting, adapting to evolutions in the market, scaling or whatever move the business has to make).
I don't see what is controversial here for a business, profit is like capitalism 101.
The article rather ambiguously says:
> Profit is what allows the company to hire employees, grow, and sustain itself—it is quite literally what funds ongoing development
There’s a key distinction between reinvesting profits - using accrued money to develop or acquire capital assets that can grow the company - and expenses.
Cash used to ‘sustain the business’, ‘grow’ (increase sales) and ‘hire employees’, as well as ‘ongoing development’ in the sense of business development, is largely going in the ‘operating expenses’ bucket. It doesn’t come out of profits, it comes out of revenue and it reduces your profits.
But in the case of a software focused organization, engineering staffing costs and ongoing product development can absolutely be reinvestment into developing software assets - but with a lot of caveats.
So it’s certainly a little ambiguous for the original article to claim that all those things are ‘what profit is for’. Often they are preprofit expenses.
As it is, your company (like mine) is just trying to generate as much revenue as it can within whatever other parameters matter to you.
What would you call the difference between a capital-dividends-driven organization and one that only cares about actual revenue?
I see loads of variety in things linked on HN.
Is there some sort of Hacker-er News that filters that stuff out?
Now you can make money running a nonprofit, by having the organization pay you, but few people do that, even in open source. Usually, you want your company to be worth something. A company often requires personal investment, and if you want to stop, you want to be able to sell the company and get some return on that investment, or at least, not lose everything. But in order to do that, you need profits. On a nonprofit, because obviously, you can't make profit, you can't get anything back from what you created.
> On a nonprofit, because obviously, you can't make profit, you can't get anything back from what you created.
I do not agree with your assessment. I do not want the "company" to be "worth" anything. The software is the value, and in keeping with the open source license, the software is a gift to the rest of the world. There merely has to be sufficient revenue associated with it to allow people to work on it at an appropriate level. Profit and "value growth" is not part of the goal.
But clearly, your goals are in the spirit of a nonprofit, and I think you are part of a minority.
You might also have "management profit," a catch-all term for unstandard & unregulated metrics. For example, A business graduates from "cash accounting" for tax and investor purposes... but it's still useful for the old management to track the old definition of profit. Maybe because habits. Maybe because it tracks cash flow or is useful some other way.
It's one of those pomo problems. The SEC, IRS or bank manager will not stand for "SEC Profit." They want "real" profit. It's like a naive local politician demanding to know what the hospital "really" cost the contractor.
Anyway.... like the SEC, IRS and such... author is using terms from their own perspective. When they say "Open Source does not win by being cheaper," "open source" specifically refers to an open source business modeled after MongoDB or similar. So yes, investors, growth goals and such are implied.
He clarifies himself on this point and there's no real point taking it into semantic growling.
But you certainly have profit.
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.
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.
I dont think this is a problem at all.
I maintain a small module, and have had many feature requests and support requests over the years. Until I am making enough money to pay my rent, I dont feel one bit guilty about charging for these things. even down to me clicking the Merge Pull Request button. anything that takes even one second of my time, I am charging for. I put months and years of works into the code. and I put the code out in the world for free. If you want an additional feature, or any of my time, pay up.
Forgive me if I'm off-base with my interpretation of your comment.
this is not guaranteed to be the case. if its a feature I dont care about, then likely I will just implement it privately and provide the modified code privately. It would only be if someone was going to be an ongoing donor that I would defer to their concerns regarding public release of any feature requests.
The entire codebase will be open-sourced a few years after a version is released.
You can use the old version and fix security vulnerabilities yourself. If you really want the latest features, you pay.
If they ever decide to enter your specific business they have an automatic kill switch on you.
I don't know how much of a moat this constitutes for vendors like Elastic, though. Those markets are inherently smaller than what they hoped to get out of managed Elastic cloud, and more labor-intensive to service. It's more of a moat for the big five defense contractors and why Raytheon is still writing all the software for spy satellites rather than Google and Lockheed does all the hardware rather than SpaceX. Of course, they're not open source, but the contracts usually specify the government owns your code, not you, and they can share it with any other contractor they choose if they want to replace you.
This is not inevitable at all. You're right that there's a tension there, but there are companies that manage to do this right, and please both OSS and commercial users.
The fact many companies don't is not an indication that this business model doesn't work, but that it's very hard to do correctly.
Do people honestly believe none of these projects compete with commercial solutions, or are they mostly oblivious these exist at all?
Also consider that a project needs to not only have existed, but to already have an established track record of being vendor-neutral before it can join.
Kubernetes joined CNCF on March 10, 2016. Prometheus joined May 9, 2016.
In 2017, these 10 projects joined:
- Linkerd
- gRPC
- CoreDNS
- Containerd
- rkt
- CNI
- Envoy
- Jaeger
- Notary
- TUF
Of those 12, only one (rkt) has been archived. Do you honestly believe the majority of these will be unsupported 10 years from now, let alone 10 years from when they were added (or started in the first place)?Can you please elaborate, how companies doing right, do things?
I totally get this. Pulling the rug out from users definitely feels a bit grimy.
I'd like to think most people are generally good, and in that light wouldn't it be worth considering that companies or people who do this are just approaching the market wrong? Incompetence vs. maliciousness. If they are transparent from day one about what will be free forever, and what will eventually be paid, then I wouldn't consider that shifting on their community.
That assumes they are true to the roadmap, and make adjustments based on feedback and contributions.
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.
I'm not sure if this is a strong enough argument. Given the state of maturity in companies, most companies should really worry about their own employees or security vulnerability than Amazon's.
Don’t assume self-hosted means security-conscious. For most businesses, on-premise IT is treated like HVAC or electrical only more annoying. Anyone with a work shirt could con keys to the server room off the front desk.
Same with security; quite a few of the S3 on-premises providers have backdoors that allow a person to bypass even the S3 immutable functions -- while I can understand that for specific customers who are using the S3 infra for Storage as a Service needing a way to clean up data from customers who left, such features are not advertised, and IMO, such S3 vendors should not be allowed to call their product "immutable", as it's anything but and most clients wouldn't even know about such backdoors.
The actual tech behind the providers might be pretty nice (this is arguable though...), but I would not say that this has any bearing on their trustworthiness as a provider.
See this fresh thread: https://news.ycombinator.com/item?id=37702095
For instance, if you write in your agreements that data goes into this bit of open-source code and leaves it and goes nowhere else, and you list out some processes you take to ensure this is true, and the whole thing is an outright lie, that's really bad for you in ways that are clear and enforceable. It's also hard to hide from your own employees, and people come and go. You're unlikely to make that claim unless it's true.
SOC2 may be kind of a tedious drudge to go through, and provide limited actual security, but a third-party auditor’s SOC2 attestation for a vendor goes some way to assuring you that they have some level of access controls and processes to protect your data. It’s not nothing. And the lack of a SOC2 attestation for a vendor is a red flag for sure.
Back in my proprietary SaaS days we used to regularly undergo third party security audits, code escrow processes, and numerous standards compliance hoops, to create sufficient assurance to clients to sign a contract.
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.
I just gave a talk about this a couple weeks ago at an internal company event and will be doing so again at GoWest in a few weeks. The premise is that open source licenses are what they are: they grant freedom, but not other things that companies would pay money for. Proprietary licenses do offer what companies need, but at the cost of freedom.
I believe there is a third model that works in the middle without compromising freedom or reliability. By staying open source and filling the gap of what companies need through sponsorships, I think this may work for some.
I'm currently redesigning the Caddy website to emphasize this and hope it will work!
There's also the Blender Foundation, which accepts donations and funds things too.
Looking at the MinIO repo, they seem to have changed from APL2 to AGPL3.
Is that the "move away" from Open Source you're meaning in relation to them?
Author is trying to say Open Source businesses do not win by being cheaper.
Open source codebases 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.
It is just annoying that the title is incorrect by literally one word.
- If my colleagues and I can see the source, we can decide whether or not we think it will fulfill the claims it makes.
- 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.
(edited for formatting)
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?
> 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.
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 low cost / free. You can always move upmarket later. Just ask ARM and Intel.
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.
If you're rolling Postgres on the metal, your funders will either not care or they'll ask hard questions about how much time you wasted, and you'd better have some decent answers or some sympathetic investors.
This is true of tools like excel, but for things like server infrastructure (at least in big tech companies) they are very hesitant to put something into production without at least source code access (much preferring being able to compile it themselves).
When I worked for Red Hat as an OpenShift consultant, I met with many execs who were concerned about vendor lock-in. Going with OpenShift for them was a no-brainer
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.
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.
But one point was obvious. The game itself was too cheap.
When people are complaining about your price alone and still buying, it’s means there was nothing else worth complaining about.
The birds will always want free food. Don’t cater to the birds.
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.
Some problems like that are nice to have as a symptom of creating something people want.
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.
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.
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.
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.
With proprietary technology choosing technology means marrying vendor for life
I learned the term Fear, Uncertainty and Doubt in the age that closed source would warn businesses to move to open source. I guess the roles have been reversed?
No, a business usually exists to provide some useful good or service to its customers. FedEx delivers packages. Apple makes phones and computers. Etc.
> Definitionally and practically. Profit is what allows the company to hire employees, grow, and sustain itself—it is quite literally what funds ongoing development
That's gross profit. Regular (net) profit takes operating expenses (including R&D) and other business expenses (interest payments, etc.) into account.
It is certainly possible for non-profit businesses - as well as public benefit corporations - to fund R&D.
What? If Apple or FedEx could get customers to (sustainably) pay them without actually providing a product in return, do you think they would have kept making phones and delivering packages just for the hell of it?
That's a strange counterfactual. Why would customers keep paying a company that doesn't provide any goods or services to anyone? They're not really "customers" anymore if all that is happening is money transfer to the company.
> incomplete
see "usually"
So "usually".
There's a lot of homo economicus in this Hacker News comments section. It's genuinely weird and unsettling, though I guess it stands to reason that here's where you'd see 'em. We're talking human paperclip maximizers, just generalized to 'profit'. Open source and free software are kind of kryptonite to this mindset, an active danger, therefore you're seeing a lot of pushback.
Wealth is for DOING STUFF.
Open Source maximizes DOING STUFF, not 'profit'. It can actually reduce the amount of profit in the world, through decentralizing power and undermining the ability to engage in profit-taking and the cornering of markets.
It is frequently engaged in by people who have reasonable amounts of wealth in their own right and have turned their attention to doing stuff rather than amassing more wealth the most efficient way they can. Sometimes, open source amounts to doing stuff in the most efficient way you can, directly competing with anybody who's stuck having to also make profit while doing stuff.
This is just reality.
That's just an avenue to make profit. If those activities weren't profitable, they probably wouldn't get done, outside of government regulation or subsidy.
Sure, some businesses are "labors of love", but they still would likely not exist if they were break-even, certainly not if they were money losers. Or at least they wouldn't exist for long.
And this is the problem with capitalism: I agree that things should be as you say, but they unfortunately aren't.
In fact I'd be hard-pressed to find such a mission statement for a non-financial firm - at least one that doesn't mention any other purpose for the company.[1]
It's a mistake to think that companies only exist for the benefit of their owners or shareholders. Realistically there are many stakeholders including employees, customers, and society at large.
[1] https://www.forbes.com/advisor/business/mission-statement-ex...
Unless you are an outlier, and manage to balance revenue with expenses every month [1], you will need to average positive cash flow or you'll run out of cash.
[1] of course if you are small, and tolerate fluctuating pay, then you can balance the books by not taking a salary but taking out all excess revenue each month.
But if a business doesn't make a profit over the long run, it will run out of cash and fail. In other words, it's no longer a business.
Of course most businesses do fail, and always for this reason. So every successful business is implicitly making a profit and has to do so.
So you are right. Businesses don't exist to make profits. People don't exist to breath air. But if you remove profit from the equation, the business will die.
At the end of the day, if a business isn't making money for the owners and isn't making them happy for other reasons, they'll find new owners or shut it down; without regard to the stakeholders.
You would have to be grossly naive to think mission comes before profit for 99% of companies.
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.
Trying to cram a GPL/BSD/Apache project into a 1990's shareware license model will usually fail.
Beer is good...
Milkshakes are good...
A Beer-Milkshake is a terrible idea =)
It could have been worse. (Also better)
I totally agree. We're making profit our north star in BrowserBox at Dosyago. It's a hard balance to strike, but absolutely necessary.
Catering to the price-conscious is a losing battle.
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.
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 totally agree with that too. It's one of the reasons I thought going full open source would work for our cybersecurity market.
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.
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.
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.
Come check us out: https://github.com/BrowserBox/BrowserBox
Now that I think about it, business north stars are also widely unknown and ignored so maybe the analogy is more apt than I thought...
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.
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).
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.
The best "open source " business is one that gets profit from doing something else and publishes some open source software on the side . Like react.
Open core are just companies that want to throw around the "look we are cool, open source" mantra , but in reality are dealers giving you the first dose free to hook you up in their business.
Where would we be if apache, linux, freebsd, openssl, firefox , and so many other 90s OSS had adopted that crappy model .
Strong disagree.
There are real material benefits to companies making their source code available - lots of them are espoused in this discussion. Things like Auditability, Debuggability, etc.
These aren't about appearances, it's about giving additional benefits to the users.
But it HAS to be backed by a sustainable business model. Otherwise, it's a hobby. Open Core, and other similar models, are about delivering the benefits of open source, with the security of knowing there's a viable business model sitting behind it.
Also, as a community - we should be far more open to paying open source companies than we are. Statements like:
> but in reality are dealers giving you the first dose free to hook you up in their business.
Exactly!
It's a business. They're paying salaries of people to create things to give you value. You should pay for it.
How is "Be a company that harvests personal data for profit, and publishes a javascript library on the side" a good model?
And, how is it better than:
"We build this thing. It's all we do. Here's the source. If you use some features, you gotta give us money?"
Now compare your “give us money” model, or open-core, to UNIX, Linux, Firefox, and the others mentioned.
- Firefox's primary income stream is embedding Google search.
- Linux is funded primarily through companies like Canonical and RedHat, which charge for premium features.
I'm sceptical that if either of those examples were to launch today, that they'd survive using the same strategies they used years ago. I'd wager that if Canonical launched today, it'd be as Open Core, which isn't far off what it's actual business model is.
However, those are great examples of companies whose primary focus is in shipping "The Thing", and finding a way to build a business around it. That's far better than making "The Thing" a side-hustle, which is what the React example was advocating.
React only exists thanks to FB money, even though so many like to hate on FB.
The "gets profit from doing something else" is a very narrow use case for most software.
When people use an open source project, they usually expect everything in the project to be open source and will go to great lengths to not pay you, including sabotaging any of your efforts to try to get paid.
I'd hate to see Open Source become even less commercially viable then it is today. I don't know the answer here, but I agree with the risks you've highlighted.
I think part of the issue is in mindsets of the community, where they see any Github source project, and immediately think "I'm entitled to use this without paying". I doubt that attitidue will shift, but I think it damages the ability for more companies to take a bet on being open.
Ultimately, when that happens - the users of the platform lose out.
Agree, this happens a lot. But the other side of that coin is the free publicity via Github and the exposure to an avid community of engineers. Something you would not get so easy with closed source.
I pity you.
Think again when you visit a public library, ride on a public road, walk through a public park, breathe the air that's been freed from most of the 90's pollutants... what terrible failures /s
If a company is wholey funded by the government through taxpayer dollars (as in your examples), then I agree - profit isn't the driving consideration.
But that's not what this conversation is about.
- - - -
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.
You don't win by making money, you win by obviating the need for money at all.
Science has delivered technology and wealth (it's not evenly distributed, of course, but that's not the problem I'm talking about.)
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.
That's how FOSS wins: "Let the robots do the work and we'll take their pay."
Yes, a post-scarcity society would be very nice indeed. That's why we need a total abundance of free and open source software not owned by corporations. If we don't make this software, we'll be subjected to their dystopian artificial scarcity where they charge you for nothing and create economies where there ought to be none.
Hopefully I'm missing some background long term trend that proves me wrong.
We made the software already, is my point. We have the technology. It's just a matter of getting the word out, and logistics. The computers can solve the logistics. (This is Bucky Fuller's idea: the World Game https://en.wikipedia.org/wiki/World_Game )
We're not subjected to artificial scarcity now except by choice.
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.
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.
I think the sustainability/viabiilty of open source is indeed currently under question.
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.
The MongoDB license prevents cloud providers from reselling a Mongo IAAS. It does not restrict you from hosting your own database on any infrastructure you want (cloud or otherwise). Is there a license that does prevent you installing on specific clouds?
Or the entire career of this guy https://blog.visionarycto.com/p/my-20-year-career-is-technic...
Lots of open source programs (IMO, pretty much all the good ones) grow organically out of community efforts or out of academic projects.
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.
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.
I was thinking of some clients I have that would benefit from this in their secure environments but was quickly chastened by their docs.
Fair enough, they have to make money but seems like the ole bait-n-switch method of customer acquisition.
Don't hate the player, mind.
Is there any open source alternative that focuses just on product analytics?
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.
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.
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.
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.
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.
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:
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
2. OSS products that are more commercially oriented and have values but wouldn't exist without VC backing
3. OSS products that were able to bootstrap themselves completely and are COSS but without VCs
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).
FOSS can be a win because of stability and control; cost is rarely the driver.
Mastodon.
99.999% of SaaS start-ups need to hear this
Excl. the rare case where the problem space requires a novel solution.
2. Even if it is a glorified wrapper, someone might want to pay so they don't have to do it themselves. Not everyone is a programmer, not every business wants to hire programmers (or their programmers are better used elsewhere).
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.
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.
Both of these situations are patently unpalatable for most businesses.
Meanwhile, if you pay someone for a support contract the liability is their problem.
You see, whether a problem that comes up is fixed is actually irrelevant. The real question is how much liability you can get rid of.
*IBM is a consulting firm now
"Oracle offers no financial compensation (e.g., credits, refunds or otherwise) in the event a Service Level Objective is missed." https://docs.oracle.com/en-us/iaas/Content/General/Reference...
The entire software stack from the bios up generally offers little guarantee, and if it does, it's often:
"The sole remedy shall be a refund up to the original purchase price."
Like, go try to make Oracle write you a contract where their base going down compensates your lost profits. You just won't get it, unless you throw some hideous amount of money their way (and they will just pay insurance company and pocket the rest).
"WE didn't bill your card 40 times draining your bank account -- STRIPE did! Go sue them, not us!"
E.g.: "We can just sue Microsoft" is a common one.
a) Their SLA literally states that they will compensate you only for the cost of the individual service they provided. The $1/month Azure DNS Zone outage caused your $100M/month business to vanish off the Internet? Here's $1 for your compensation!
b) The US Government sued Microsoft and failed to get very far. Are you the US Government? Do you have a budget for dozens of the best lawyers money can buy? Have you sued a multi-trillion dollar market cap org successfully ever? No? Why do you think you can... and win?
Generally this boils down to: "I haven't read the contract I signed, but I'm sure if things go bad I can just make the lawyers magically fix things for me."
You have to decide, as a business, if trustworthy vendors are available and select the right one. You can also decide that it's important enough to your value proposition that you want to "own" it.
The real reason companies hire vendors is that you don't need some mythical "FTE" that can do all the things. For the "price of a single FTE", a vendor can provide you access to a range of FTEs that are knowledgeable and capable in different domains, and you can flex between them. Thinking about RedHat, as an example, if you pay RedHat the equivalent of a single FTE, let's say $300k/yr, is that just one FTE working on maintaining Apache? A kernel contributor? GCC?
This is about fractionalization and labor specialization, not some direct 1:1 tradeoff between hiring some mythical person with commit bits in hundreds or thousands of OSS trees.
Not renewing a vendor contract is easy.
Firing the maintainer and author of 90% of the commits of the OSS project your company is relying on in a way that it is hard to migrate away? Who can replace them??
And I guess paradoxically, this is exactly how contracting firms form to begin with. So I guess startup culture isn't really that new.
Generally by asking the existing developers of the software project in question. Some of them might be the person you'd end up hiring anyway.
Open source wins because I don't have to involve the entire company to use it. I can literally just raise my voice to see if anyone in the group cares and then use it.
And even when it's free for small companies, not approving a license is holding up something that we think is already done, so the wheels grind a bit faster.
This can have a lot of red tape.
Not to mention how you configure the open source also affects if you could be vulnerable to a cve.
If a company says it is not their current focus even after paying 200k, you should looking into finding an alternative vendor who is willing to go above and beyond. A good vendor gets you by features and keeps you with exceptional service. I have seen vendors saying that those words when they are in extraction mode.
In my opinion orgs should have service contract. It is more important when you are responding to RFP and you are a b2b org. If you dont have a service contract for tools and service you use, you will run into liabilities that you don't own and can delegate it to the vendor.
These words were almost verbatim used this morning in a meeting. A small agile ISV was purchased by one of those big "holding companies" and now everything is "for consideration", "not on the roadmap", "not strictly required", or like you said "not their current focus".
We've been raising issues like: "You're using frameworks and SDKs that went end-of-life years ago for Internet-facing security-critical components, how is that not your current focus!?" and hearing crickets in response.
Support contract is in place, but there's no specific clause requiring them to do their job, so they're not doing it.
They can safely milk their customers for enough years to recoup the investment.
On the contrary, customers who keep paying them while they do the bare minimum to keep the thing limping along is probably exactly what the holding company is looking for.
And good luck getting the procurement department to approve your exception to not use the #blessed vendor for just your org. What happens is, everyone does that and then spends 20x more money on 5x vendors and then the other 15x is trying to integrate them all so you have a coherent business.
My experience has been, service contracts are a great way to feel a false sense of security and burn cash until you need service, and then they're a great way to sit on a phone call watching revenue burn while you say "they haven't gotten back to us yet" until they say "yeah it looks fine on our end, sorry."
Isn't the next part of this where the vendor receives an angry letter that contains the words "notice of default" and "filing suit to compel specific performance". If a vendor takes your money and says "JK we don't feel like doing that" and your contract let's them do that you need to fire you attorney (or who ever signed that contract)
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.
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.
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 not 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.
A good example of this would be open-core. It may be source available, like Grafana, but Premium features are paywalled (Grafana Enterprise for SAML, more datasources, ...). Other examples might include GitLab which is mostly source available but also has Freemium-ish model.
But that's the thing. Most large companies generally don't, not unless that product is truly battle-tested. They are usually fine throwing out money to another company as long as they can get support. Support around an open source product is very hard to do unless you structure your company this way
Nitpick: source-available is not open source, by definition.
What a silly claim by the author.
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:
* extensibility
* transparency
I'd also add:
* lower barrier to entry (for a subset of technical users, at least). If you want to try it, you download it.
* 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.
* if the user is a dev (the product is infra) "many eyes make for shallow bugs"
Those are all compelling arguments.
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.
Honestly, I don't think we've figured out how to build a pure big open source business outside of the following business models:
* consulting/support (Redhat); pursuing this has poorer margins
* loss leader for another service (like VSCode for the MS ecosystem). this isn't really a pure OSS business model
* hosting/SaaS (but the clouds impinge; I opined a few years ago on this: https://www.mooreds.com/wordpress/archives/3438 )
(I'm leaving out open core or SSPL companies because I don't consider them to be 'pure' OSS companies, myself.)
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.
FYI, you can also have some of the beneficial attributes of OSS:
* transparency through clear communication and docs
* extensibility through clear, stable APIs and docs
even with a closed source company. Software companies have lots to learn from OSS as a development process.