Have you ever wondered how companies pick what they use? No? Too bad I’m telling you anyway, because it has implications for people wanting to make money in b2b off of open source. Spoiler: it’s very hard but not for the reasons you might think.
Common Case #
Let’s start with the most common case. This is why, for example, seemingly every company under the sun uses Palo Alto / Fortinet, or JFrog, or MS Teams. The bigger they are the more likely they are to be on that juice. Here’s how it works.
- Someone from one of these companies figures out through magical means (usually salesforce or internal contacts or whatever) who the guy with direct access to the company credit card is.
- They cold call them and say “you should use our thing, all the cool kids use it”.
- If this doesn’t work, they will invite them to one of their conferences that they assure them will have many important people.
- If they cave before the conference and the client is big enough they may be offered a speaker position. If they caved on step 2 nothing has actually changed since they want these people to speak in this context.
You might ask “but at what point do the people that have to deal with this get involved?” which would be a good question if it mattered. The answer is after the sale happens. The way it goes is the person with the credit card will walk up to the technical or otherwise involved staff, will say “we have an X license now, please use it”, and will depart.
As more and more companies use these products, the sales pipeline gets easier, because they can back up their claims of “all the cool kids use it”.
Breaking In #
You may be asking “wait so how do I use this for my benefit?” and the answer is you don’t. You are fundamentally not cool. Cool is when there’s an air of mystery and proprietary secrets and exclusivity. Free software is none of those.
Furthermore, you do not know who (they are many) holds the credit card at various large firms, do not know their phone numbers, nor have the power/funds to treat them to expensive champagne dinners. You are in fact uncool and will be arrested by corporate security before you get to their building, and your emails will be filtered out by the IT team plugging all incoming emails into their AI with the prompt “filter bad people like I would”.
You could approach this like your competitors do and hire a traditional sales person. They will (rightfully) demand a salesforce subscription, start calling people, demand a champagne budget, get confused that you do not run and mass advertise your own events, drag you to trade shows where you will have many good-feeling conversations that do not gain you clients, be asked to fill out a call for offers (that they will lowball and ask a % cut off, as is industry standard), and run out of money years before you even get to that stage.
Technical People #
You may be protesting now saying “but the technical workers will not suffer this, they will want to change” and you are right, except they do not hold the credit card. If they want a change, they cannot simply oopsie spill the numbers on the back, they have to justify it. First they will collect complaints over the current solution, then make a study to determine what to replace it with. This will be collected as an ADR (Architectural Decision Record) that needs enough people to sign it to count as the Declaration of Independence of a small nation. Then next time the contract lapses, they will be able to ask to switch solutions, which may be rejected by the credit card holder.
“Ok so I just have to be so much better on paper that when they run their analysis they have no choice to conclude that I am the best”, you may be thinking. Unfortunately, this is where corporate priorities come into the picture, or in other words, what those mentioned technical people are actually like.
You see, they will basically make a big design-by-committee wishlist. This wishlist will be full of things nobody else actually cares about, like SAML, or being able to “link things back and forth”, or perhaps “keeping track of the back-office” (a kind of cousin of the backrooms that every executive has nightmares about, we’ll talk about those later). The name of the game here is integrations. Not like “you can make this do anything” integrations but “I press the salesforce button” integrations.
“Wait but my project has nothing to do with salesforce” correct but one guy on the team saw a salesforce integration on one of your competitors and has added it to the design document as an evaluation metric and what you have to offer (if they even know it exists) is looking mighty red there. Just imagine a room of people having no idea what you’re doing or what salesforce does saying “hm but without the salesforce integration how will it be approved when the neighboring department is onboarded?” (they will never be onboarded of course but it’s poor form to suggest this is the case).
Market Fit #
Ok so all you have to do then is figure out exactly what they will be evaluating and making sure they’ve heard of you and then this 1% occurrence (rather than the common case) is yours, right? Not so fast cowboy. Literally, that’s a lot of development. Who are you really making this for? Do you have any idea how long this stuff takes to do properly? You probably do actually, and you should shudder at the thought. “But how do those competitors do it, what does their salesforce integration do?” so basically they just show up in the UI somewhere and that’s it. They have money so they throw a bunch of people at the problem and if it sucks it doesn’t matter because there’s literally not enough time to evaluate quality, it’s all about whether it “does the thing at all”. You can probably do that but like, do you really want to? Is this what free software is about for you? If it is, well, you’re just a less successful proprietary solution, giving them tools to copy you in a cheaper way (nowadays you can set agents to copy functionality, poorly of course, but thus having all of the same “feature sets”).
Side channel #
Ok we can talk the side channel I’ve alluded to earlier. No, you won’t make money off of it.
So all of the above is true when it comes to institutionally picked products but in some cases things can sneak in separately. For example, if you’re a library that has an open source and a support model (like Qt) or a small tool (like curl, which is also a library but is used almost as often as a cli, I always cringe when I see system()-like calls to curl in software rather than just linking to it), people might just start using your stuff in the technical teams. This applies to a LOT of stuff, since almost all modern business runs on free software.
“Aha, so I’m already in, they already know I’m good and important, so I can just offer them stuff they want and I’m good, right?” No.
You see the problem is they are currently getting all of your benefits for free. To introduce any cost would be to make it not so. Free is very hard to beat and now you’re on the losing side. We’ll do a case study shortly, but this is hard even for an individual person to grasp. Imagine you have a free email account and the SAME EMAIL PROVIDER says “you can pay me for the same stuff but also I’ll answer your support tickets”. No one cares, they’ll live, and also pressure you for support anyway. If you want to make it in that way you have to REALLY twist their arm, which you probably can’t.
Even if you could, like RedHat used to (they also were considered cool back then), the moment you lose any of that it's over. Nowadays RHEL is only used where it has been used historically, and people are migrating away, because it's more expensive than windows, and Microsoft has a sales team that knows what Windows is (while the RedHat team doesn't seem to really know what RHEL is nowadays).
Case Study: Qt #
Let’s talk about the CRA real quick. The EU Cyber Resilience Act basically says that companies have to treat vulnerabilities seriously, have to produce an SBOM and so on. The details don’t matter and I hear enough of it at my day job. What matters is that the end seller is responsible for their product, they can’t say “oh well the customer may not know my product contains LibFoo but LibFoo is responsible for any vulnerabilities”. This is also related to a desirable thing called the CE marking.
Anyway, now they have to produce SBOMs except their product stack looks like the fever dream of a prehistoric shaman teleported to the modern day and given a combination dose of LSD and MDMA. They want to delegate as much of it as possible and ensure that their “suppliers” are also compliant.
Qt is a C/C++ library useful for writing UIs that also does a LOT of other stuff like networking, xml parsing, etc. Because of how much it does, it’s actually very common in business applications that think “embedded” means “running on a Linux system running on a raspberry pi”. Now they’re a “supplier”, so you have to check in with them. They gleefully tell you that they’re aiming to gain the CE marking (basically golden standard) as long as you get their support package. Also your version is from 15 years ago and you will not be legally able to publish it, their support package comes with porting help, and also you can just contract them for porting separately. All of this is essentially golden news to the business customer. It’s exactly what they want to hear. However, you COULD also just not do that and let it rip on the open source edition and give the team 10 000 tickets. That proprietary vendor wants more money and is willing to offer champagne so… well think about it, ok?
Tl;Dr #
In the vast majority of cases, you will not make money off of free software.
If you do, it will likely be in exchange for your soul making your project very similar to all the proprietary options but technically open source, with everything that implies (nothing good), ensuring its slow enshittification.
There are other paths available, including in b2b but they are so minoritary that you can presume they’re not real.
Outside of b2b is a whole other can of worms. My recommendation?
Don’t try to make money off free software (at most donations, which are also a can of worms).
It is my belief that it will be better software that way.
Credits #
A warm thank you to:
- bigachu, upon whose mighty belly I was resting while writing this in a packed ICE
- helene, tricky, and tosti irc members for proofreading and suggestions