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.
The article is talking about businesses being on Open Source foundations, not the myriad of other possible Open Source projects.
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.
Hi Paul, I've been a long time user of Ardour and would love to send some bread your way, but I'm absolutely allergic to Paypal, is there a way for EU users to send you funds directly via SEPA or something like that?
Sorry, there's no way for us to interface with SEPA at this time. It would not be that hard to setup a way to just receive money via SEPA (probably using Wise's multicurrency account system), but integrating it into the rest of our payment system would be gigantic, because of the totally different interaction model inherent in SEPA-based transactions (i.e. a bank would have to notify us of a payment). While I'd love to do this as a matter of principle, we think it better for our users that we focus more on features and bugs in the software.
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 am kind of amused to see someone here on HN, of all places, who allegedly runs a business use scare quotes around the word profit and make it sound like there's something ambiguous about it.
Is the word "allegedly" meant to cast doubt on the story? The user mentioned working on "Ardour" in the comments, and it wasn't hard to find what he was talking about from a quick Google search that led me to Wikipedia [0].
I think the quote marks around "profit" are appropriate here because the comment was about defining that specific word.
Allegedly because I don't have time or interest to check it, and because if you're running a for-profit business and you need someone to clarify for you what profit means, I feel like there's something weird going on.
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.
Fair enough, but saying ""Profit" is a strange and ambiguous term here." is bonkers regardless. It's not strange nor ambiguous, anyone reading this post should know exactly what those terms mean and the way an open-source company trying to make money would use the term. Whether you find it obscene or whatever that people want to make profit off open source seems like an unrelated discussion: profit is a basic concept everyone understands without ambiguity.
"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.
>So open source is only for people who are already wealthy enough to not need to make money
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 :)
Profit has many meanings. The IRS considers my wages to not be profit to my company, but they are profit to me.
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.
Your wages are not profit by any definition I've seen.
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.
If the owners overlap with the employees, then what part of the revenue is divided between salary, benefits and profit is often a tax-optimization question, which I think is the point in the GP. A single-person company paying themselves 200k in yearly wages or 100k in wages and 100k in dividends from 200k in revenue can look like a “non-profit” or a high-margin company with the same effect for the owner.
> 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's certainly profitable to me to be employed, I get money. It's one way you can "profit" from an activity. You can also profit via other things, but it's a wider meaning of "profit" than the financial one.
You don’t need VC’s to be organized as a corporation and/or have a growth/profit mindset
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.
The basic problem here is HN posters unable to conceptualize the idea 'right thing for the project'. They're stuck in 'investor mode' so to them, anyone interacting with the project (or the world) can only be interested in extracting profit from the system, rendering what the project does, meaningless.
Not a good way to get work done. At the end of the day you have to have done something.
My view, for ambitious projects likely to be in a competitive space, is that “right thing” converges in the long term for profit-seeking and non-profit-focused paths.
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.
That's fair. Good luck selling investors on this 'long term' thing.
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.
I presume you pay yourself, so you rely on profit. The profit is nullified in the books but in practice it's no different than using the profit for dividends.
Money used for business expenses like salary is not profit. Profit is (roughly speaking) what's left over after you deduct all your business expenses from your revenue.
And if you don't take a salary that money becomes profit, so the profit is effectively used for salaries. Claiming my company is not profit-driven because I use 100% of the surplus revenue for my salary is of course nonsense.
Were your company (partially or wholly) owned by capital, there would almost certainly be different decisions made (in many different areas) because of capital's desire for a return on its investment. If you were lucky, capital would be interested only in long term value (i.e. eventually selling it, and making a profit on the stock at that time). If you were unlucky, all the short term decisions would be made with an eye to generating profit that can be returned to the shareholders as dividends. Either way, that scenario would be a "for-profit" company.
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?
Profit is an accounting term, so ambiguous. To be actually clear, it would be useful to qualify it as "taxable profit" or "investor profit," for example. In practice, these are two unrelated numbers for most big companies. Each one is defined by who you are communicating to, and what the rules are for this communication.
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.
Are you in the US? Do you report that revenue as personal income on your taxes? If yes, then I think it’s fair to call it profit (since you’re also presumably deducting expenses).
The Net Income you report on your Schedule C is your businesses profit whether you like to think of it that way or not. The opposite of this would be a loss where your business generates negative Net Income.
Perhaps you think it is trivial. I don't. Open source has the potential to bring lots of benefits to society, but if coupled to a particular conception of what "profit" is and the way in which companies "doing" open source should relate to it, I believe that a lot of those benefits will be squandered.
That's true if it is a sole proprietorship, but not if it is a corporation of some kind.
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.
If you don't make profit, you are a non-profit organization, or at least, you should be. Companies of all kinds, including open source companies are for making profit.
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.
In the USA, a 501c3 organization that sees revenues of over about $10k needs a fairly extensive board, officer insurance (to protect board members from claims about misappropriating funds) and other legal stuff. I considered this years ago, but decided that it was not worth the effort.
> 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.
You can be a non-profit and not a 501c3. A 501c3 is an exempt purposes non-profit, specifically "charitable, religious, educational, scientific, literary, testing for public safety, fostering national or international amateur sports competition, and preventing cruelty to children or animals."
Ok, I don't live in the US, I didn't realize a nonprofit involved so much paperwork and bureaucracy. I shouldn't be surprised, it is a way to avoid taxes after all and governments like taxes.
But clearly, your goals are in the spirit of a nonprofit, and I think you are part of a minority.
> 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.
Your browser. Your OS. Your video editor. Your DAW. Most embedded systems found around your home and workplace and transportation. Air traffic control. Scientific data analysis. Most video/computer games.
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 does not mean "the software opens a socket and communicates with a server for brief portions of its runtime". It does not mean "cloud-based". It does not mean whatever Microsoft wants it to mean.
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).
> 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.
Everything. Like e.g. my robot vacuum that I couldn't operate between 1600 yesterday and noon today, because the Internet was down and the robot insists on being able to talk with servers in China to be able to vacuum the floor. Same with my A/C and floor thermostats, except those at least have IR remotes or wall panels for local control.
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".
Worst thing is, you have little choice. In my case:
- 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 mean, you answered your own conundrum here. Profit is an overlay of Revenue, minus some other overlay. In this case, your profit is 1:1 with your revenue.
It's not really a matter of filtering. Web and SaaS are interesting topic. But it is irritating and frustrating how many articles, and commenters, refer to web programming as the whole universe of software development.
Profit is one of the least ambiguous term possible.
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.
If profit was completely unambiguous, accountants wouldn’t have had to invent the word ‘EBITDA’.
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.
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.
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.
> 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.
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.
With all due respect, your model as described is different: the way I read it is that you're charging for work, not charging for a product incorporating your work. The same tension doesn't exist, because you don't have an incentive to paywall a feature; if someone pays you, everyone benefits.
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.
> 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.
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.
One of the main reasons to donate a project to a foundation, such as the Cloud Native Computing Foundation (CNCF), is to protect the community against this type of rugpull. A requirement for them to even consider adopting a project is that it isn’t under majority control of one single commercial entity.
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.
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)?
The whole point that I failed to fully express on my sentence, was how many of those projects are still relevant in 10 years from now, without the funding of commercial entities.
>...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 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.
There is a very easy distinction that so many projects make: target group business or home user. Paid support, scaling features can be reserved for commercial world where most software makes its profit anyway. Doesn't fit every use case of course, but it doesn't have to. Most computing should be personal.
If your product is sufficiently complex, you may have organizational expertise in running it that the cloud providers can't match, though I can't think of any examples of this. There security requirements like fips-validation and released STIGs that make organizations depend on your product. Off the top of my head, other than these, I can't think of anything RHEL offers that Amazon Linux doesn't, but plenty of orgs still choose the RHEL ami for their EC2s. Some orgs may want or be required to self-host. Some orgs may use your cloud but only in a FedRamp-accredited or classified enclave, where many managed services available in the commercial enclave are not available or not yet approved by your sponsoring agency.
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.
HashiCorp is the latest big name to do it—they switched to the BUSL, which more or less says you can only use the product if you aren't offering it for sale in competition with HashiCorp:
Doesn’t this turn on the definition of competition (in the license). I remember reading about a bunch of game and server tech being in very murky water following the license change.
If they ever decide to enter your specific business they have an automatic kill switch on you.
> 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.
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.
A company can also genuinely state that it hosts customer data on-premise to protect it from the big bad cloud, but elide the part where everyone and their brother in the local IT consulting ecosystem has domain admin credentials for them & half the town in a KeepassX on a network drive.
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.
The major cloud providers are serious engineering shops whose business and reputation actually depend on technical and operational competence. And the Silicon Valley community is full of current and former employees who will tell you what it's like inside.
At some level in the infrastructure this may be true, but this is not my experience working directly with the RND/Engineering teams and Infrastructure teams on a lot of the big cloud providers. They will undoubtedly have many tricks to get whatever you have on their cloud working again, but there should not be an expectation that they aren't going to just get a fast and dirty fix going. It might work, but it will be a kludge in many cases.
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.
Nobody wins every single time against the most sophisticated attackers in the world. Microsoft put up a very respectable fight here. When a random small-to-medium enterprise IT department gets owned, it’s for some braindead stupid low-hanging-fruit reason. Attacks like this don’t happen because they are unnecessary.
There was no respectable fight. They used the same signing key for all customers AND own corporate mail. It's a stupid rookie mistake. Exactly the type you would expect from a small-to-medium IT department.
Yeah, this particular argument makes no sense, even though it's surprisingly common. "Open source" doesn't mean a thing in SaaS. It means the vendor is sharing what they tell you is the source code running behind their service. Even if it's exactly the code - which it may not be - it's unlikely to be the only code running behind the "official" service. And you ain't gonna build your own copy and deploy on their servers. Open source really means something only when you self-host, otherwise it may just as well be proprietary, as everything depends on trust you have in the vendor (and possibly the contract you have with them).
Maybe "trust" in a purely technical sense, but we live in a society. If a vendor has a part of their contract that would put them under penalty of fraud, customers don't usually worry whether they can independently verify it's true.
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.
Yes - people here talk like vendors are inscrutable black boxes, which suggests to me they have never been through a serious vendor selection process (on either side). This is not a problem businesses are unaware of, and solutions and enforcement mechanisms exist.
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.
I don’t understand your comment. Isn’t it the same if Amazon falsely claims to not have access to the data and if another company falsely claims to use some specific software?
> 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.
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.
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.
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.
The Caddy project is fighting to show it can work. We are having moderate success.
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!
I love Caddy and have shilled to everyone I know, so thanks for your great work. I'm keen to hear more about your model, because I think the influx of companies abandoning their open source roots has shown the problems with the current approach. I am rooting for you folks!
Isn't that the point of this article? Its not that open source will neccesarily win, just that if it does, it will do so based on the strengths the author enumerated, not by undercutting the competition on price.
Yeah that’s what I was referring to. Still open source, but the move was controversial because it was taking away some freedoms from users of the previous license.
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.
Yes, the switch of context at the ‘Profit not usage is the measure of success’ heading, from talking about open source tools to open source businesses was so abrupt it gave me whiplash. I went back and reread the first paragraphs to check I hadn’t missed some words.
For me as an engineer who influences technology acquisition, open source wins by being grokkable.
- 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.
This is definitely valuable. It must be once a week that I read the source of a dependency to see what it is doing. Then I can make a quick workaround and usually a bug report.
> What is a transparency problem? It’s when a solution being closed source creates distrust between the client and vendor.
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.
> 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?
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).
Every day companies put stuff in production on iOS, macOS, watchOS, Windows, SQL Server, Oracle, INTEGRITY OS, AEM, SAP, Sitecore, and a myriad of closed source enterprise products.
I have not yet participated in an early-stage startup that cares about cost; they have mostly cared about time, and buying Amplitude/Segment/AWS/Heroku/etc is just seen as being faster than the alternatives, rightly or not.
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.
Agreed. This isn't just a trivial point either. As a decision maker this is one of my top considerations. Every org and person is different of course and there are plenty of people that don't care about lock-in as long as it's a company they trust, but it's definitely not a zero either.
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
Sort of related only in the realm of software sales:
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.
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.
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.
I think the key point which is missed here is - Open Source gives you the choice.
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
Only open standards with multiple interworking implementations give you that choice, though. The cost of moving to something else is no different with commercial SW as it is with F/OSS when you have to start from scratch, as opposed to being able to switch to alternative implementations (such as a database or message middleware).
> 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?
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!
And ffmpeg too. It is also used by commercial video editing tools, thunbnail generation, etc. Not many people use proprietary encoder software. And HW encoders in cpu/gpu are often awful (generating big files for good-enough quality).
> For some, this might be a tough pill to swallow. But a for-profit business exists for profit.
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.
>No, a business usually exists to provide some useful good or service to its customers. FedEx delivers packages. Apple makes phones and computers. Etc.
You would have to be grossly naive to think mission comes before profit for 99% of companies.
If profit is the determining motive then every business would be a hedge fund (at which point hedge funds would not be possible, but that's a different point). A business exists to do something specific, profitably; the worst companies I've ever worked for (and these tend to fail quickly) just existed to make a profit but didn't care how. Disney didn't become a world-striding media colossus by wanting to become a world-striding media colossus; they became that by making sure every girl who wants to be a princess wants to be a Disney princess.
> No, a business usually exists to provide some useful good or service to its customers. FedEx delivers packages. Apple makes phones and computers. Etc.
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?
Apple began as people making home computers in their garages, so they could have computers. How on earth can you, on Hacker News, not understand the compelling allure of having a computer in your home in an era where that was just about unthinkable?
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.
> 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.
I was considering that there could potentially be exceptions, perhaps some non-public facing investment or trading firms without traditional "customers".
> No, a business usually exists to provide some useful good or service to its customers. FedEx delivers packages. Apple makes phones and computers. Etc.
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.
Apple's mission statement isn't "try to extract as much money from our customers' wallets as possible" or even "deliver the highest profit and value to our shareholders." (Recall Tim Cook's comment on the "bloody ROI.")
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.
You don't put that in the mission statement in the same way you don't write 'try to get as much salary as possible' in the objective statement of a resume.
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.
True. The same can be said for employees - eventually they might unionize or quit en masse, regardless of what the owners want. Or for customers - they might decide to quit buying the company's products or services. Or for society as a whole - perhaps laws will be passed to strictly regulate a business or to ban its core activities - even if the company is profitable and has lots of enthusiastic employees and customers.
You are incompletely right. Businesses benefit multiple stake-holders. Products and services are created to provide value, that value being sold for cash.
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.
I think the point is that the stated mission is window dressing on top of the underlying truth. Following POSIWID, all for profit enterprises have making money as their core mission.
I'll caveat your comment with "existing". 90% of businesses will fail inside 5 years and always got the same reason, because they run out of cash.
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.
Except that doesn't really work, because plenty of businesses start in low-margin industries, but if profit is actually the first motivation then every business would be a hedge fund. Ray Kroc wanted to get rich making burgers, not just get rich.
Making burgers is the activity; getting rich is still the first motivation. Besides, I'm not sure Ray Kroc is the best example, and I doubt he personally made a lot of burgers; he bought the national franchise rights to the McDonald's restaurant chain after it was well established, and set about getting rich by making a more efficient burger-restaurant process.
I would not call it a problem with capitalism, I would call it capitalism's greatests feature. A free enterprise system ensures that resources are used to create the greatest value for consumers. If firms did not need to seek a profit, why would you expect to get anything from them that you value.
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.
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.
a typical open-source business needs profit to be the ultimate north star.
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.
Perhaps off-topic, but "north star" is such a hilarious business euphemism. The actual north star is ignored by 99+% of people on the northern hemisphere, not visible at all to people on the southern hemisphere and I bet most people would be completely unable to actually identify it in the night sky if asked.
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...
Hahaha. Yeah I guess so. Well what it means for us is it's a priority. I guess that word harkens back to navigation on ships. I suppose nobody ever does that anymore. Hahaha
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.
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".
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 .
I'm happy for those companies that become commercially viable through pure open source - and those are some great examples - although they're not financially viable on their own:
- 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.
> 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.
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.
Open Core is a really risky bet. Any dedicated developer can fork your project and add the Premium feature they like the most, and then there's nothing your company can do about it.
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.
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
Win what? TFA is published on a platform owned by Microsoft.
- - - -
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."
> You don't win by making money, you win by obviating the need for money at all.
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.
There is already an abundance of free and open source software, so much that it would take a lifetime even to catalog it. (One of the most inexplicable things to me is how people prefer to pay for proprietary software rather than learn to use free FOSSoftware. "Bigfoot lives on Endor.")
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.
> 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
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.
> 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.
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?
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.
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.
Also it's really weird that in a open source business, contributions come from people who never get a cent of the benefits which the founders receive. This to me feels very disingenuous. Profit sharing should be built in as part of these "open source" projects.
Posthog isn't truly open source as the author claims.
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.
I keep saying this: open-source projects that promote self-hosting BUT earn their money by having their users NOT self-host their product (i.e. cloud offering), always end up crippling the open-source version or making it as hard to install as possible, especially if the product is built by a large corporation or VC-funded that requires constant growth.
Not open-source, but self-hosted, check out UXWizz[0], I try as much as possible to keep the features count to a minimum and work just on improving them instead of adding new ones.
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).
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 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).
Or you know, if you're trying to make a profit on sales of the software itself. All the working open source business models work on selling service, not the software. Which is fine, but not everyone wants that business model.
1. That's not what most closed source software is. It's kind of weird that you're equating closed source software to glorified open source wrappers, because most software (closed or open source) has a significant amount of work besides just "include some libs".
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).
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.
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.
- Vendor contracts are hard
- So we avoid doing them
- So we never get good at them
- So every contract is a painful lesson in trying
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.
Yes. Yes. Absolutely. This can stop adoption right in its tracks, and it depends entirely on one or two personalities. Who's at the wheel in office InfoSec. One guy had a strict "Open Source is Inherently Unstable" red line, sooooooooo . . well, we went two levels above him to get OSS signed off on, because the parent org was all about OSS. Doing that was a bad career decision, but it was the right one. This article gets it right almost exactly; transparency was a huge part of adoption, but the extensibility thing is also a big deal for a niche industry. Also, our vendor was unspeakable, disappearing for years on end, re-appearing as another company, asking fifty times the money for no reason.
This is why a SaaS offering is a must. For open source, a security review might be needed. For a SaaS, checkbox SOC2 and we’re on our way. Leverage to reduce the B2B sales cycle as you scale.
I wonder if there’s a business model around sharing the results of security reviews. Even if Company A can’t fully trust the review of Company B, you could A could provide a lot of context for B to reduce the cost of starting an evaluation from zero.
Not in the projects I am involved, there are clear guidelines, CI/CD pipelines are connected to internal repos only, and there is always a legal and security assement required before anything gets added to those repos.
By that line of reasoning software companies should not be a thing at all and everyone should hire engineers and write all their software in-house. Hiring and maintaining a team of developers is hard, especially if the problem they are solving is not in your domain. Contracting a problem out to specialists is most often the more sensible option for both parties.
Buying off the shelf software is reasonable. Outsourcing for expertise - whether that's having an external party write software for you, customize existing software for you, or something else - usually fails, IME.
I am engineer, now trying to sell enterprise software. May be I can shed some light.
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.
I respect your position but it doesn't sound like you've worked for any company that's decided to "buy in to the ecosystem" for any sufficiently large ecosystem. Get all your data in DataDog and try to leave. Build your business on IBM and see how agile you are in 25 years. Same goes for pretty much any large enterprise software, even the free ones. Good luck leaving git. Good luck de-kubernetesifying someday to a higher or lower level of abstraction.
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."
Your purchasing folks and CXX people are doing it for other reasons, like a convenient scapegoat, liability shift, etc, if things go wrong. "We experienced a day-long outage due to a problem with a third party vendor". Or plain old job security...it's hard for them to accept a process where something gets selected without their input.
You are absolutely try. No I haven't worked for company like this. Also, I don't even know how these massive companies sell their product in a hyper competitive enterprise market.
> saying that those words when they are in extraction mode.
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.
I think you are not the target customer that the holding companies is looking for. I would try to see an out and look for another vendor, tool or alternative.
> I think you are not the target customer that the holding companies is looking for.
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.
engineers who work in large teams on some component, talk about the design with their managers? Yes you can replace them.
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??
Employees gets legal protections that contractors can only dream of. Also, most contracts have specific terms of completion and duration. If the contractor screws up, you can sue them, withhold payments for lack of specific deliverables, or just let the contract run out.
"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.
"
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)
Your company needs the maturity to manage that engineer. Companies with products have customer success and sales etc and their own engineering management and product hierarchy to translate your end user issue into a software fix. That doesn't happen automatically by staffing and engineer in house. How would a company even figure out the profile they need?
I hear logic like this and suddenly I 100% understand how a startup can "disrupt the industry", even if 90+% of the time that is a huge exageration, if not an outright lie someone promises in a pitch. I guess if they can't find that lead, the lead will find, or rather found, a company for such a need.
And I guess paradoxically, this is exactly how contracting firms form to begin with. So I guess startup culture isn't really that new.
Good luck trying to get any actual liability out of them...
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).
It's a theoretical benefit, not a real one, and the scenario is so rare that most people don't think of it critically. It's like buying insurance against "damage by asteroids".
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."
Most customers won't sue you. They'll terminate their business with you and go elsewhere.
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.
I understand the full time engineer thing. But it was never explained to me at any of the places I have been at that it was a liability thing. At every place they thought we would leak trade secrets. Was always frustrating that technically we could never even contribute the most minor of bug fixes.
Component breaks due to bug, deployment misconfiguration, scaling failure, etc., and your company loses $1M during the outage. If it's a vendor with an SLA, you can (sometimes) get them to cover the $1M. If it's in-house, you're eating it. It's often cheaper to build/run stuff yourself (unless it's so commodified that you're benefiting from amortization across the vendor's many clients), but then you have to be self-insured for problems.
I don't think liability payments are that common. As someone who helps in analyzing software purchase decisions, it's certainly not something I hear people bring as a major factor.
Maybe size of enterprise matters? I work in $LargeCorp and legal was very aggressive about insurance and liability redlines on the last contract I had to deal with.
Why would a SaaS provider expose themselves to catastrophic risk of reimbursing a large enterprise for the enterprise's lost profits due to downtime? I think refunds of the cost of the SaaS are sort of common, but that's quite different and capped.
Look beyond SLAs to topics like cyber security incident liability. SmallSaaS selling to BigCorp, like Oracle, are in a wildly different negotiating position than BigCorp selling SaaS to SmallCorp.
I usually find a derivative of this in the fine print for software contracts: "No Warranty on Software. You and your end users use the Software and any derivative works you may create based on the Software at your own risk."
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."
Whatever anyone else is saying this is the real reason. I’ve seen it first hand many time. The only thing that matters is being able to blame somebody else when problems arise.
"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.
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.
> You know why companies use Open Source, for the most part?
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
I guess I'm lucky that the open source things I deal with are far and away better than the proprietary options. I'd choose Clang or GCC any day of the week yet another 7 figure proprietary toolchain with licensing terms with obvious bugs, for one recent example.
We ended up paying for people to host stuff for us. the free OS aspect attracts us because we know we can host ourselves down the line when the team grows and also, that the people behind it aren't douche bags and want to make the world better in some small way.
> 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.
Nitpick: source-available is not open source, by definition.
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.
Disclosure: I work for a closed source product company, but write a lot of open source that pairs well with our product.
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
(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.
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.