A better takeaway would be - there are not a lot of things that move the needle enough for people to want to pay a lot for them when they have alternatives.
mold isn't one of them for the majority of customers, and developer tools overall is a tough business to make money in.
Rui is a genius and an amazing programmer, but even within Google, the llvm ld work was done for particular reasons (I was Rui's director for many years, and was responsible for approving and funding the work). Speed was one of them for sure. But it wasn't the only one, and more importantly, we had particular use cases and clients where the work would move the needle. We had lots of data and knew where and when we could improve things, whether through LLD or other things.
Otherwise we would not have done it.
For a random customer to want something like mold, and to pay for it, they'd usually have to have data that suggests it's worth it. Most of them don't even have data at all, let alone the ability to say "if we use mold, it will move the needle for us overall". Sure, you can spitball the time you will save in compilation, but as lots of research shows, that doesn't mean the overall process necessarily gets any faster.
Some will buy it anyway - some people will take it on faith, some will think it's cool, some are specialized enough that it matters.
But overall, if you want people to pay for things, at a minimum, for most people, you'd have to be able to help them see that it will enable them to do something like "get features out faster", not something like "link your programs faster". The latter is a means to achieve the former, not an end unto itself.
Developer tools is also not a large market overall in the relative scheme of things (look at devops market sizing and CAGR compared to anything else), and never has been. It has consistently missed estimates, too, no matter whose numbers you use. It's not even a 10 billion dollar market yet, or is just barely one, depending who you ask (estimates are 8-10.4 billion). Most of this money is eaten by large players (Atlassian, etc).
So you are also already working at a disadvantage.
Trying to see where else we have the same dynamic, CI came to mind.
CI is often pretty slow, and I've had jobs where it take 20 min for the full results (lint, compile, tests, etc) to come out. It was a pain point raised to management, we complained of lost productive hours against it, and tbe answer was to trim down tests and split the cose base, instead of "just" paying for faster CI instances.
I'd expect other orga to take more sensible choices, but in general getting budget for tooling feels hard.
I'm reminded of the cartoon with the caveman pulling a cart with square wheels, and guy waving circular wheels at him, only to be told "No thanks, we are too busy."
Getting build times down is a difficult project because it's a cross functional task.
Like everything where you're involving a bunch of teams with no free space on their roadmaps, you have to be able to demonstrate that your team has done everything it can, and now the pressure needs to fall on the other teams. Like have a wiki or presentation to show how you have already trimmed the tests as much as possible, and the codebase is as small as possible, and you're not making 100 unnecessary docker layers, etc.
Thats your ammunition in the fight to get something like resizing the build instances on the other team's roadmaps and out of their budget.
I was on the other side of that a few years ago as a tech lead/manager, and of course the team complained about CI speed because everyone always does in every software company. We staffed a team to work on build time improvements. It was the sensible choice. Why not just throw money at it? Well, because:
a. We'd already done that, more than once.
b. The tests weren't parallelized over multiple machines in a single test run anyway.
c. There was a lot of low hanging fruit to make things faster.
d. Developer time is not in fact infinitely expensive compared to cloud costs.
CI can easily turn into a furnace which burns infinite amounts of cash if you let it. Devs who set it up want to use cloud because that's hip and easy and you can get new hardware without doing any planning, but, cloud hardware comes with a high premium over the actual hardware. Optimizing build times feels non-productive compared to working on features or bugs. Also, test times just expand to fill available capacity. Why optimize, even a little bit, when you aren't paying for the hardware yourself? Better to close a ticket and move onto the next, which is transparent to managers and will look impressive to them. In contrast CI times are a commons and it leads to tragedy, where everyone complains but nobody will fix things as the incentive are mis-aligned.
There are often some quick wins. For non-urgent relatively stable use cases like CI it makes more sense to use dedicated hardware, as the instant scaling of the cloud isn't that important, but to a lot of devs (especially younger ones?) it seems like obstructionist conservatism to use that. They'd rather add lots of complexity to try and auto scale workers, shut them down at night, etc. Maybe dedicated machines are coming back around in fashion now, as the cloud premium gets to absurd levels. I see more talk about Hetzner than I used to. In my new company the CI server runs in Hetzner+own hardware, and that works fine. It also has the advantage that the hardware itself is a lot faster because it's not being overcommitted by the cloud vendors, so build times and tests will just magically get faster and (just as importantly) performance will get more predictable.
In other cases enabling caching and fixing any bugs that reveals can also be a big win. Again it can make sense, especially if this work can be assigned to junior devs.
Unfortunately, it's also around developer tools.
My value proposition is going to be support through real-time chat to employees of my clients. I want to cut out the middle man of a client employee being a de facto expert in my software and make myself the expert that employees can talk to.
In general, could this be a better value prop than Rui's?
Sorry if asking is inappropriate; you just seemed like someone who would know.
In addition, big corp knows the cost of an FTE and they will be translating your support offering back to FTE/hours, a unit they can put a price on. In turn, procurement will make your contract negotiation a living hell.
Better build and sell something they know they need but can only translate to how much value it will bring them / how much costs it will save at the bottom. Negotiating percentage(points) of a large sum of money is easier to sell than cash numbers that they translate to a human being being available to them.
Of course, if you really expect zero support is required and you can get many to sign it can still work out. It doesn't sound like a get rich quick scheme though.
> whether an OSS project lends itself to monetization is a really interesting and subtle question. rule of thumb, be at least two of these: big, boring (roughly correlates with "infrastructural" as @patio11 puts it), and lacking obvious substitutes
The monetization strategy is only a part of the viability story.
Civilization including specialists developed in many, many ways.. not just this overtly-fuedal manner (pun intended).
Significant groups, guilds, economies, academic institutions, militaries, drunken bro frat guys at a resort with poker chips.. all of those and more, are possible in a diverse world. People given tools and access build amazing things, sophisticated things, among the ordinary "coffee mug warmer" projects.
please consider this, manor dwellers
part II - sophisticated tools developed on company premises with advanced inputs over long time.. then BIG_EVENT happens and the situation changes.. anything from "investors pull the plug on expensive operation" to "C-suite drama" to "invasion" .. can change things very quickly. What happens to $TOOLS ? is the real value going to survive long court proceedings, or "code is locked up, lawyers are not available" .. Google Inc has not gone out of business, but these things do happen. Open Source License has to adopt to economies from Viet Nam to USA and everything in between. Practitioners must make the changes and norms because non-specialists rarely will. The norms have to change from economy to economy yet the value carries forward. This is years of work from specialists we are discussing, with a short half-life. waste is not optimal
The parent-post here focuses on "point of sale" dynamics, like a retail store or car lot, in order to make a statement about business transactions involving Open Source sophisticated tooling. There is no way that shows the life-cycle or player roles for this situation, therefore is wholly inadequate to use to extrapolate all possible value transfer scenarios
But as the time went on - more and more restrictions were put on the purchase: can’t install on multiple computers in a household, the key cannot be reused when reinstalling, immediate absolution when continuous operation requires paid updates, and finally - full on subscriptions that don’t result in ownership. As the result of all this my desire to buy software ran out.
I’ve always seen software development and maintenance as a service. The idea of free lifetime updates always struck me as unsustainable. Having a reasonable bug-fix and free update lifetime for a given version doesn’t strike me as unfair.
A company offering free lifetime updates raises a red flag in my mind re: their long-term viability.
It’s not all that different to how some game producers continue to update and bug-fix the game, as well as on occasion introduce new features - while releasing expansions that you need to pay for if you want to play it. Example - Diablo 3 which saw 3 or 4 expansions since it was released a decade or so ago. Or Fallout 4.
That model obviously works for some - and the makers of FL Studio celebrated their 20th anniversary a while ago. One of the benefits to them - is that they don’t need to support old versions of their software, all customers have the latest version available to them free of charge.
If you let people install the software easily, they'll just pirate and won't buy the software. If you lock things down you'll irritate people and they won't buy the software. If you make it open source they'll just build it themselves and won't buy the software. If you make it open source with a license that restricts commercial use (or is even too copyleft e.g. AGPL) people will bash you for having a "non-free license" and won't buy the software.
There's really only one method that's working broadly: SaaS. The cloud is the ultimate DRM. You don't even give people the binaries or their own data. You keep it in the cloud and charge rent.
SaaS works. People won't buy software that they can run themselves, but they'll rent it and give up all privacy and control of their own data.
SaaS even lets you pretend to be open source by "supporting open source" (tossing a few bucks in sponsorships or employing one or two open source authors) or having an open source client for a closed source SaaS platform. Nobody seems to care about that. They just look at the license on the source, not the holistic picture of the ecosystem that it works within. At the same time you can build your SaaS on the shoulders of open source, using all those dumb hippies as free labor.
I love making software but I absolutely despise the way this market works. It's completely perverse.
It's hard to make money in software by doing things to make peoples' lives better or increase their freedom. It's easy to make money with rent extraction schemes, addictionware, dark patterns, and outright scams. It's like this market is full of people who want to be screwed and refuse to pay for anything that doesn't screw them.
The reality is that we painted ourselves into a corner with free-as-in-beer, "information wants to be free," etc. without considering how incentives work in large systems. You get what you incentivize. By making anything that is pro-user and pro-human free (as in beer) and educating the customer base to expect it to be free, you remove all incentive and resource base for the development of that kind of software. The only incentives left are for things that make the world a worse place. The best way to make money is to con, dark-pattern, lock in, addict, surveil, or outright scam the user.
I've spent years trying to build useful software. I'm not doing too bad. I've somehow made it work. But with the same knowledge that underlies my current work (cryptography, distributed systems, network protocols, infosec) I could have become incredibly rich scamming people in cryptocurrency or doing dozens of other shady-but-not-illegal (or illegal-but-hard-to-prosecute) things.
Half the time I'm proud of not doing those things. The other half the time I feel like a big fat sucker.
Personally I kind of view it the other way around. We weren't the painters here, just observers. "Information wants to be free" is phrased that way because, whether we want it to be or not, it is just a fundamental fact that it is very easy to copy bits. And - while you can make it damn annoying to be sure - if you want a user to be able to see the bits on their screen, there is going to be a way to break DRM. So - we can either acknowledge this, embrace reality, and figure it out from there, or we can shove our heads in the sand and wave our arms about yelling "intellectual property!!" and ask the local monopoly on violence to help us do so.
I agree that SaaS is often used to skirt the piracy stuff. I also agree that SaaS encouraging you to give up ownership of your data is bad. But also I think SaaS being on the other side of a network forces a function that's actually useful - they're assuming the risk, the ops burden, and so on. You get to just shoot IP packets at them, which I find is typically a comfortable position to be in. And frequently I find that that is actually why SaaS is so valuable. Part of the reason that enterprises pay for SaaS is because it lets them offload business complexity, operational burden, etc. So i think SaaS isn't just a categorical moral hazard.
"It's hard to make money in software by doing things to make peoples' lives better or increase their freedom. It's easy to make money with rent extraction schemes, addictionware, dark patterns, and outright scams. It's like this market is full of people who want to be screwed and refuse to pay for anything that doesn't screw them."
This is absolutely an accurate take on the current B2C software ecosystem. If it's not B2B software, it's probably predatory in at least some way. And if it's not "productivity" software, it's probably a literal horror of bad actors. Humans just weren't ready to have nightmare rectangles in their pockets 24/7 and our monkey brains are far too easy to game into exchanging money for dopamine microdoses at far too egregious of an exchange rate.
Baked in DRM platforms like App Stores, Steam, etc. seem to be reasonably effective at blocking casual piracy (at least during launch windows) without becoming completely unusable. Some of the DRM pain is compensated for by the convenience of somewhat streamlined access to your software library on multiple devices, with relatively easy download and installation. This doesn't scale well though if you have more than a couple of app launchers/installers to deal with.
Game stores tend to have the nice feature that you can log in on any PC or console and immediately get access to your software library.
Something I'm less enthusiastic about is games (Diablo 4) that require an internet connection even in single player mode (and even if you "own" the physical game disc.)
As a customer I'm not a huge fan of DRM, but as a developer I'm probably OK with outsourcing it to Apple, Valve, Nintendo or whoever as long as it doesn't create usability nightmares.
This market and every market, people don't value things they can get for free.
When money is spent emotions get involved and so does sunk-cost fallacy, tricking us into believing the thing is worth more.
I don’t consider it a trick at all and am not sure why being able using something that was perfectly usable when you bought it is “a trick” as soon as a newer version of that thing comes out?
> Between 2013 and 2019, I was at Google developing the "LLVM lld linker". lld linker as open source software is kinda successful, and if you have a very large development scale, you definitely need to use it as a standard tool.
> [...] I could've got several hundred thousand dollars from the engineer job I retired (I was a Google Staff Engineer)
Software in general, open source or not, is not good business. If salaried job is not for you then consulting/freelance is pretty much the way to go for software engineers. Either way, you are selling your expertise and time instead of the end result.
Not sure I have an answer but that shareholders and executives get the vast majority of the gains points to an extremely broken system.
Not giving away the software for free would be a good start. There are many ways to charge people for software.
Of course Pikettys r>g still applies insomuch it applies to anything, but that is not really related to software anymore.
Developer tooling is also just a very difficult business to be in [2].
[1] https://codecodeship.com/blog/2023-04-19-parker-selbert
[2] https://www.softwaremaxims.com/blog/economics-developer-tool...
The issue seems to be with the approach taken to have a single AGPL license. I've heard of other similar businesses that would just use double licensing and would sell copyrighted "parallel copy" of the product to the blue chip customers. This way the company gets a proper license but publicly you still maintain AGPL for the masses.
mold is a product, not a business.
In the end, it doesn't matter if it is open source or not. As an engineer, you're stuck trying to sell the product, which isn't a service.
The service would be support and that's what he was rather successful with, given it was only one single niche product.
If he had taken mold and built it into some sort of larger service (maybe a CI/CD system? or something that did analytics on how mold improved developer happiness), I think he might have seen something closer to the 'big profits' because then it would be easier to justify paying for.
When you model things from first principles, this is how it ought to be.
Unencumbered symbols are strictly better for most people than enchained symbols. The exception is there is a certain class, the "Royal" class, (who receive revenue from royalties either directly or via stock ownership greater than the royalty taxes they pay others), who have historically derived great monopoly profits from software.
But I think it's now gotten to the point where there is no denying that open source, freely distributed software is strictly better (in the long run). No one is clamoring to put Windows instead of Linux on their phones or deep space satellites.
So the question is: do we continue to make ideas worse for 99% so 1% can have monopoly-level royalties, or do we change the laws?
I used to work at Microsoft and it was fantastic. But I couldn't help but keep in mind that the utopia in Redmond was made possible only because of the Microslavery that IP laws put on everyone else.
It's not that much different than other fields—there is an endless supply of businesses/orgs for which for which it is almost an insurmountable obstacle to get them to acknowledge something that they could be doing to better serve their own self-interests and then get their approval to take appropriate action.
(In limited circumstances, it can be easier with software, because devs can coast on the desire of SMBs to feel like they're on the forefront of progress because they're buying in to an app for something that didn't have an app before—or if there was an app, then a newer, shinier sort of app—no matter how shitty and regressive the new app actually turns out to be...)
It's consistently missed total market value estimates and been revised down, too, no matter whose numbers you use.
Depending who you ask, it's not even a 10 billion dollar market yet (or has just reached it).
Most of that money is also concentrated in people like Atlassian. It's a remarkably small pie.
This is a major issue for anyone considering offering their software with an open source license. There are many licenses to choose from and you have to get the first one right. You can't just pick one and later switch it to something more suitable.
The most successful OSS business model is the service model. Release your core product as OSS, and build the best commercial SaaS around it.
The author is wrong when they say:
> Some enterprises make open source projects then provide cloud services. [...] But, regarding this business model, it is weak because it is vulnerable to the other services like AWS providing the open source software as a service, and actually that is happening a lot.
Licenses like the AGPL level the playing field, so any competitors must also publish their changes to your software. The crucial aspect, then, is to make your SaaS objectively the best on the market, which should be easier for you, since you're the primary expert of your software. It also drives innovation by keeping you on your toes to always innovate and improve both the core and SaaS around it.
You can also go the Redis and Nginx way and use a separate commercial license, but this is a murky legal topic.
The important part of this open core model is to truly offer a compelling OSS product. Don't try to swindle users with crippleware, nagware, or prioritize business features over OSS ones. Give the best support you can, have great documentation, and make the OSS tool easy to use, with clear market advantage over the competition. Then your SaaS offering should be the icing on the cake that includes premium features that are mostly relevant for businesses. This is how you attract those huge corporate contracts.
The main issue with mold is that a service can't be easily built around it, and that it's a very niche and technical tool. The product needs to be something that's appealing to a large audience. Even if it's a developer tool, an improved linker is not something many developers will flock to.
The author is clearly smart and talented. But this product failing to be monetized is not related to OSS business models. Monetizing OSS is more difficult, sure, but there are many companies that have done it successfully. I'd suggest looking into what they've done differently.
The way to make a lot of money is to be an owner.
However, open source mainly makes you a laborer. Support contracts are paying you for labor. It is similar to starting your own plumbing business. Yes, you can make a comfortable lifestyle, but you don’t really own anything apart from your labor, and if someone else comes in offering a better or more convenient deal, businesses will go with them.
* There's no stakeholder but the user and the maintainer.
* Nobody holds back features to go into "the Enterprise product".
* Nobody prioritizes features that the whale customers are asking for.
* There's often no "contributor agreements" or "team consensus" required to take a contribution, so it's often much faster to merge in new work.
* People from all over the world that have a passion and desire for the product, that actually get shit done, with no concern for their resume or title, become the maintainers.
* The project's design can change frequently with major overhauls, versus carrying one codebase along indefinitely because it would be too costly to overhaul it.
* It's not subject to the whims and needs of a profit motive, or growth at all costs; it can stay dinky and small or grow as contributors arrive.
* Ends up smaller and more composable, and are easier to replace when they die than big commercial Open Source offerings with a million features.
* is a Bazaar, not a Cathedral; an organic mix of different components that evolves naturally, survives longer as a whole and fits together better.
The only thing you gain from an Open Source business is marketing. If you do it right, you'll hire more committed nerds and can sell B2B to other nerdy businesses. But that's not a super consistent revenue or hiring stream.
I’m assuming Rui could get some sweet contracts now that his skills are plain for all to see, that would afford him the lifestyle he may be looking for that a salaried job couldn’t offer.
Single, small, niche product with no investors to pay back and no employees pulling in $78k/year after only a few years is a pretty good result and the reaction should be to try to grow it (second contract, more sponsors, second product, etc) not write it off as a failure.
In any case, if you're trying to get developers to pay for your software, you're targeting the wrong crowd. Developers know the per-call cost of your service, they know that you're scamming them at some level of your product. If you sell a fart button app for a dollar, you better believe someone will make their own version out of spite. If you want to get paid for your software, sell to the business and not their employees.
The frugality of software developers is ultimately just a force of good, giving less fortunate developers better tools and keeping the paid options honest.
Dual-license it to where all code in an ee/ directory [0] falls under a non-open-source enterprise license, and all other code is open-source.
[0]: https://github.com/search?q=%5C%22ee%2F%5C%22+directory+path...
The really sad part is that LLMs are eating up the knowledge and give nothing back.
the underlying problem is digital assets, their lack of natural exclusivity, and the users and makers of the digital assets in a capitalist market environment.
i.e. this is not about 'the business of open source software'. the real problem is about 'digital assets in a (capitalist) marketplace'
meaning this won't get fixed by considering how to do open source software into a business. we must consider a much larger perspective: "how to have digital assets in a marketplace?" and a preceding hopefully obvious "but why do that in the first place?"
some possible 'viable' options that I've seen that explore this question in a more full sense:
- NFTs ( but I have a weird taste in my mouth 'saying' this)
- API economy (redefining 21st century api-culture? ahhaah get it? it's bee joke)
neither is overwhelmingly convincing... however I do know what I want: megaupload of all culture. we have the technology, but not the social-political capacity
I've seen only one free software that solved the puzzle completely perfectly* It does mean it can be done but it seems hard enough that one should probably explore picking B before A.
* IIRC It was a desktop Payroll software that only displays ONE advertisement for a lone but only when you have insufficient funds to pay your employees, it does a credit rating based on previous salaries paid and previous financing, there are no forms to fill out as your info is already in the application. I think one can also pay the installments from the application.
In that situation the offer seems completely perfect. A button to press that completely solves your problem when you have it.
Open source, public domain products are better. Lots of engineers understand that and want to make those things. But the laws currently incentivize doing things the wrong way.
We can either change the laws, or go back to first principles and see if there might be open source business models that haven't been tried yet.
Even if you make more laws, it'd be super hard to find people violating said laws, and even harder to bring them into court as a company struggling to get started. Big and even medium size companies play these games all day.
The only monetization it has is basically a big sign saying "please pay something if you want to", and not enough people want to.