This is not really the right takeaway. It's true, but sort of misses the key issue.
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.
This hits pretty hard, but reasonates as true in many orgs.
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.
The problem is that most people don't know any better. Right now I'm working on getting a greater-than-90-minute build down to ~10 minutes using distcc, ccache, and mold. It's painful to hear management ask "when is it going to be done and we can move on?" because that really telegraphs they don't value the increased quality of life this decreased cycle time will deliver to the developers and users.
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."
If you were using a service to run those builds, reduced build time would translate directly to lower costs.
Even if you are using a wasteful, low-utilization capital plant to run your build, more efficient use of those resources should become lower energy bills, at least.
The only way you get lower energy bills is by switching things off, not using them at full whack, but as I said, people don't know any better than the mess they're in.
the other side of this is that once you have the faster instances, the pressure will be off to do anything to improve build efficiency, and everyone will add more to the build till it's 20 minutes again.
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 currently wait twenty minutes for CI to package a Go program that can be built on a laptop in ten seconds, because the “CI pipeline”—and every time I have to say that I choke on the words a little —involves twenty dependent steps, each of which installs Ubuntu. And this is a large, valuable company with thousands of engineers. I think having a development environment where the speed of the linker is even remotely relevant is a problem faced by a few special companies.
Sounds like it already is containerized, and that's the problem? A lot of places have CI setups that don't cache things anymore for various reasons. A while back there was a new YC startup announced whose product was essentially a SaaS for building Docker containers where they cache things for you.
Another cause of this problem is when CI workers are spun up and down on demand in the cloud, so VMs are constantly being set up from scratch.
The same reasons you can't just inline everything in a program, but break things into functions, modules, etc. Complex CI systems are, in my experiences, built up from components that are reused across multiple project builds and need to be encapsulated in a way that they can be plugged into any of those. Each component is containerized and caches as much as possible at each step, but that is still a lot of overhead.
> the pressure will be off to do anything to improve build efficiency, and everyone will add more to the build till it's 20 minutes again.
To rephrase this in a way that was not your intention, "developper laziness would only increase if the company paid for the beefier CI".
And I think that's often the crux of the discussion, at the base of it there's a perceived neglect and lack of effort, and it's only if all possible efforts have obviously been done that money should be attributed.
Thαt's where it feels less like a cut and dry ROI calculation, and there's a moral judgement aspect that is baked in but not often properly surfaced.
20 minutes is nothing. Some orgs have CI times where it takes hours or even days. And I'm pretty sure that all orgs go through the same set of tradeoffs and decisions, it's not unique to yours.
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.
I've been following Rui's journey with curiosity because I am also trying to build a FOSS business.
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.
Unfortunately, your time doesn't scale. Selling your own hours whilst also having to build and maintain a product and/or company is not a great idea. Hiring people to answer the questions is expensive as well. Things that get you a good chunk of money are based on being able to scale ridiculously well. Make once, sell many kind of things. People are not a good product to sell.
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.
I don't need to get rich; a living is good enough.
However, your other points give me pause. While I do expect that over time, I will need to give zero support (after initially educating users, like [1]), that may also work against me since they'll now have the in-house "experts" I'm supposed to replace.
> 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.
Unfortunately, my software is only one of the three things: boring. Sure, it can become big over time, and my plan was to make it big by getting my software in the hands of developers first, but that will take time I probably don't have.
this is telling and insightful, thank you for posting directly. However, in the "I am in the great castle on the hill" ELSE "you are alone in your cottage kitchen" trying to sell "amazing-craft-thing" to "someone" .. is blind in important ways.
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
I never spoke ill of Rui, i love him and supported him as best I could. Like I said, he's a genius and an amazing engineer.
I spent time trying to convince Google to pay for mold, as well as pushed other companies to it where i could, etc.
I'm actually pretty sad this business didn't work out (and that he left!).
In the end, whether someone works for Google or not i care less about than whether they are happy and able to do something they love. Work is work. If people are happy doing what Google has to do, awesome. If not, i want them to find somewhere they can be, whether self-employment or whatever.
Plenty of people leave to chase a different kind of happiness, and more power to them. I hope they all succeed, and try to help however I can.
Life is short, everyone deserves to be happy.
Beyond that, he's the one who wrote a critique of his idea, not me!
I only pointed out that the conclusion i would draw is a little different than his.
Perhaps you should also consider that you don't know me, him, or our relationship, and that i may have a good idea how he will take what I write after working with him for years?
On the contrary I found it quite amazing to get such insight here. The author put himself out there both with his company and this blog post, admitting failure. I don't find it unprofessional. Those opposing the director's post don't seem to grasp business very well (nor did the blogger, seemingly).
It’s not whether you or I get value out of it. It’s unethical to talk about people you’ve managed publicly. Most managers won’t even get into details in a private reference check for liability and ethical reasons.
It's not unethical to talk about anyone publicly. It IS unethical to keep secrets that could help people, to talk about someone behind their back, or to speak dishonestly about someone, or to criticize someone from an anon account.
The OP is doing none of those things. He his both offering FREE highly thoughtful feedback to Rui (which I'm guessing is exactly what Rui was looking for by posting something publicly), and offering all of us who care about open source business models another perspective.
> It's not unethical to talk about anyone publicly.
If you’re a manager, it most certainly is unethical to talk about someone you’ve managed publicly. I’m hardly the first person to say this. There’s tons of information out there coaching managers on how to talk about ex-employees. Maybe it doesn’t bother you, but I assure you a lot of people care about this and don’t want their ex-boss chiming in on their new projects.
Do you realize how you took a kind and genuine comment, made the worst possible interpretation out of it and completely derailed an otherwise interesting thread.
From the HN guidelines -
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
Please do better next time. Glad that your current thread has been flagged and disabled by the community.
> Do you realize that what I said is completely valid and true?
No, it is not.
> Managers: Do not discuss your ex-employee’s work in public. It’s risking their reputation and unprofessional.
Do not discuss your ex-employee’s work in public without consent. You missed the consent part. What if both the manager and ex-employee are ok discussing it in public?
You have your own value system and rules. But they apply to you. You do not decide for me as an employee what kind of relationship or interaction I should have with my boss.
> Maybe it doesn’t bother you, but I assure you a lot of people care about this
I think you are right on both points: 1) It doesn't bother me 2) a lot of people care about this.
Everyone I know has part of their brain that rapidly recoils from criticism. That could be universal.
Training your mental muscles to instead be grateful for all feedback, no matter whether it is delivered kindly or poorly, is a good skill, IMO, if you care about the truth.
I think the word you should use is "impolite". I would never call someone who speaks a public truth "unethical". Impolite? Maybe (not in this case as I found their comments quite kind). But I prefer ethical people to polite people 10 times out of 10.
I'll admit, I had a similar initial reaction as you when I read OP's comment, but the perspective shifted once I actually read the post
The post wasn't talking about his success, Rui was dissecting his company's _reason for failure_.
OP took that and shifted the needle to point the blame for that failure to a different sector. He's not bashing on Rui, but that might not be clear unless one actually reads Rui's post!
The only thing that might be questionable in OPs post is if there was any need to mention that he was Rui's director. The pros in favor of it is that it gave the post more credibility and attention (meaning it will help more people), and the con against it is that some folks might incorrectly interpret it as Rui-bashing and hurt OPs reputation.
Given that the only people who that con would apply to would have no idea who OP was before this post (and are likely to quickly forget about him the next day), perhaps the director didn't choose poorly.
He doesn’t need to critique the market. He’s also wrong. MS is doing fine with dev tools (VS Code, GitHub…). Maybe this attitude is why Google has fallen so far behind in dev mindshare?
MS is not making money on dev tools, and roughly never has.
They even say that in their reporting. What possible source of data are you using to say that MS is making money at devtools?
The only way to do it would be to mix it with cloud stuff or services.
Github is the closest devtool thing that they get the most money from, and
1. It was never profitable prior to MS buying them.
2. MS does not report profit, only ARR. Which is small (1B). That suggests it is not profitable, and at the very least, not profitable to matter (it's revenue is <1% of MS revenue, it's profit is probably an order of magnitude smaller).
Heck - if you talk to the people there, they would tell you the same - for many years their dev tools headcount and budget was stable or declining because it is considered a cost center and not a profit center.
Github changed some of that but they are still not profitable, AFAIK.
Overall, this 'don't try to make money from tools' approach is intentional - as i said, the market is small and they know that. So they really don't try to make direct profit at dev tools anymore (at best, they try to get it to pay for itself), instead using it to generate indirect revenue.
There are a very small number of exceptions to this (attempts at enterprise revenue for github, which, again, are not succeeding yet).
VSCode is a very explicit recent example of this approach - they don't even charge for it.
The only reason they still charge for VS and subscriptions is to defray costs at all.
You are both making a lot of weird assertions with no data, and lots of attacks on people and things. This is not particularly helpful?
You don't need to critique his comment and I don't need to critique your comment. Yet here we are
> MS is doing fine with dev tools (VS Code, GitHub…)
GitHub has a revenue of about a billion. That's less than 0.5% of Microsoft's revenue. And like the comment pointed out, behemoths capture the bulk of the revenue. What exactly is he wrong about?
The valuation of the companies is not necessarily great evidence that it's a fertile market; it's pretty saturated. The problem is most people don't need a new GitHub or Visual Studio because theirs works just fine and everyone else also uses it, so it's easier to just do that.
And sure, a billion dollars is an unfathomable amount of money to the average person, and a handsome exit for entrepreneurs depending on how it's structured. But when it comes to entire industries, it's pocket change.
It was one of the most insightful comments in this thread.
Note also he was a director, not the author's manager. That's a very different thing - he has a view of this as a strategic business decision, not as a personnel issue.
I think his perspective on that adds value in understanding why the idea can simultaneously be awesome in an internal context at one highly-instrumented company and hard to market outside of that context.
I don't read it as "bashing" at all; I read it as constructive and informed criticism from someone who obviously cares both about Rui as a person and mold as a project.
Personally, in the past I never had a problem with paying a reasonable price for software if I end up “owning” it as the result of the payment, allowing me to use it in perpetuity. I especially liked some products that came with “lifetime updates”, eg FL Studio, where a purchase entitles you to future updates providing bug fixes and new features free of charge. I also like Jetbrains subscription model that allows me to use the current version forever even if I stop paying subscription.
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’d be fine with just “let me run the software in perpetuity”, ideally without automated updates. Software that matters enough for me to pay for is going to become part of my workflow, and a tool in my toolbox. I don’t want my tools disappearing or changing arbitrarily.
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.
In case of FL Studio - there’s a core product that remains free and receives updates, and there various add-ons and content that you can pay for if you choose to.
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.
"The reality is that we painted ourselves into a corner with free-as-in-beer, "information wants to be free," etc."
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.
These are good points, but I disagree somewhat about the ops burden issue of SaaS. The ops burden issue is due to problems that are all solvable, and if people paid for software there would be a strong incentive to solve them. Instead we've revived the technicians in white coats tending a mainframe model because that turns out to be what people will pay for, and I think this is mostly because the model doesn't give them other options.
Edit: also while there is a marketing distinction between B2C and B2B ultimately everything is B2C. B2B is just B2C at least one level removed.
It is definitely true that the safest-for-user model is to use web software - it's the most secure sandbox that's commonly available and has good hardware access. The safest-for-company model to monetize is SaaS. It kind of makes sense that we are where we are.
There's a perverse dislike of delivering software over the web because we want binaries, but the same is true with hardware. You only license the proprietary hardware, so you can't do anything with it. The fact that it's a physical object you hold is purely how it's delivered.
We see companies that protect revenues while charging users for real services as somehow criminal. I spend about $100 per month on various subscriptions and I feel I benefit from those services immensely! I don't like not having MP3s which I can hold and copy, but I also like having all of the Spotify library to enjoy. It's all trade offs.
> 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.
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.
Jetbrains doesn't allow you to use the current version forever if you stop paying. It allows you to use the version YOU CURRENTLY FULLY PAID FOR, which is a year old version. That's a very clever trick, and also shows that in the end it's really just about providing a feel-good factor.
I misused the word “current” to mean the version as of the time of the purchase.
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?
I see you still don't get how it works. There are two options:
You buy it outright. Then this version belongs to you, and there are no subscriptions.
Or, you buy a subscription. After 12 months, you are using the current version of Jetbrains, and the version from 12 MONTHS AGO belongs to you forever. With a subscription, the version belonging to you will always be 12 months older than the current one you are using right now.
Most people don't seem to understand that, do the subscription, and as they never understood what they really signed up for, are happy.
It's not even unethical by Jetbrains, it's perfectly fine and OK. But it IS a clever trick.
Funny how the author found out how to make big bucks from OSS but then just decided to quit that
> 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.
It is a strange twist that Google, Microsoft, and Amazon are some of the best places to work on aspects of software that many people don't care about enough to pay for. A 1% improvement in the memory wasted by malloc is a cool thing that no small company or consumer would pay for. At Google or another hyperscaler, it saves literally millions of dollars per year.
End users are capturing the value. But of course that's the point of open source; you're voluntarily avoiding the proprietary software strategies that let you capture more value from your users. I don't think it has much to do with shareholders or executives.
Software doesn't create value by itself, people using software creates value. With open source software anyone is free to use software to create value for themselves.
Of course Pikettys r>g still applies insomuch it applies to anything, but that is not really related to software anymore.
Let's be clear that it is a successful model that generates an amount of revenue ~78k per year. It definitely works but the yield is a bit low it seems. It is hard to definitely nail down the amount to hours worked but the money is there. A couple of more similar products would be the way to increase the profits.
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.
I read the comments and I think that people are missing the crux of the issue:
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.
The consolation, if any, is that monetising any type of software is actually hard and getting harder no matter what business model. Otherwise the profitable "big tech" companies of today would not be mostly advertisers or infrastructure providers.
> monetising any type of software is actually hard and getting harder
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.
> monetising any type of software is actually hard
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...)
You are saying that monetizing software is not particularly different than other things.
I"m saying one difference is that lots of other things have a bigger market in which to operate. It is easier in a big market to get a small slice of the pie and be okay.
(it may not be easy to get the slice, but once you do, it's enough).
In developer tools, getting that small slice will still not be enough to be okay.
In other words, it is different from other fields - you say "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."
That's true, but in other fields, to have a viable business, you don't have to get as many of these folks + whoever is left, to be successful enough.
In developer tools, you do, because the overall market is worth a lot less, and so are individual customers.
You are narrowly focusing on developer tools. (Or not—there are places where you keep saying "software" where it only makes sense to interpret it as "software (sold to other software developers".) The article is about mold, but I specifically replied to the claims of someone commenting about the difficulty of "monetising _any_ type of software".
(I had a whole paragraph about how selling developer tooling to developers is hard, but that doesn't account for all software markets. I took it out, because it made the post too long and was already belaboring a point that was out of scope. I maintain that there are circumstances where selling software to SMBs is way easier than what's on the other side of the fence. Consider: developing a payments app for coin-operated laundromats that allows them to issue credits for people who want to pay with a card instead of quarters vs the business comprising the laundromat itself. The laundromat has geographical constraints that just don't apply to the app developer—who can sell as many copies as they're able to to anyone pretty much anywhere. They can also rip out a huge chunk and repurpose it for a different type of payments app that has nothing to do with laundromats—and the app can be shitty, like most enterprise software, because the laundromat owner is not the user and is only thinking about the fact that the app enables something now that was not possible before. In contrast, the laundromat itself is affected by not just whether there are enough people in the city to carry the business forward, but the specific location within the city where the laundromat is placed.)
>The period is not fixed for the open source licenses, so if you change the license for the latest version, the old versions are still under AGPL. Therefore, even if I change the license for mold, anyone can just fork the old open source version and continue to develop it easily.
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.
You can just pick one later as long as you understand that you are doing it for it's future impact and not it's current impact. Of course people who want the old license will just fork your old version as they are pretty much the same as you just re-licensed. But 5 years down the road your forking your old version won't be meaningful as your product will have evolved significantly and not be the same product anymore.
Copyright licenses are long term by their nature (ridiculously long term) and their impact is best understood in those terms.
It’s a tough product to monetize. Sadly many of the most important, highly-technical OS projects (like this) are hard to monetize, while many less-important, yet highly valuable to some niche (e.g., a job queue) might make money.
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.
A rough English translation of the original Japanese note by Rui Ueyama, the creator of the mold linker. A reflection about trying to build a profitable business on open source.
The way this economic system works is that there are owners and laborers.
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.
I don't believe there's such a thing as an Open Source business. Open Source is a license style. It's not a business plan or a commercial industry. I also believe that good Open Source software requires not operating as a business. In "true" Open Source:
* 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.
A true business product needs a value proposition, a problem to solve, marketing/advertising/sales, and support that's worth paying for. Getting the source code is never the problem somebody has. Even if they have it, often a better product will solve what they need. OSS is more of a distraction to the business than a competitive advantage.
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.
intentionally reducing the scope of possible scenarios and declaring analysis completion .. does not fit and is counterproductive to others that are engaged in alternatives to that scenario.
The way I would play this is use my potential skills in open source to boost my reputation, experience, and credibility, and then be able to charge more for consulting gigs after the fact. Not profit from the OSS directly, but build up my image and business from it indirectly.
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.
This reads like they're maybe just not ready to be an entrepreneur, unrelated to open source or not.
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.
people generally don't want to pay for anything, so it's difficult. though there are some success stories like Gitlab, most open source businesses end up changing their licensing to not be pure "open source", e.g. CockroachDB and MongoDB. Though at least in the former case they have a time provision that converts it back to AGPL IIRC.
I am not so sure about GitLab anymore. It is open core model, not totally open source.
They have ended up creating new features which are closed source, and they have had to increase prices a lot. It is still not profitable.
If it weren't for all this freely licensed software, maybe the paid alternatives would be more attractive. Proprietary UNIX was all well and good, but ultimately a cancer to businesses and users. Businesses and users funded an alternative, and the people selling proprietary UNIX all gave up the ghost.
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.
The pivot to macOS/iOS was interesting, but then he got semi-Sherlocked (technically not since Apple had already been trying to solve the same issues) which is a huge risk for any Apple developer tool - if not any app on Apple platforms.
Slap an "Enterprise" tag onto the name, e.g. "Mold Enterprise" with a few features directly applicable to larger orgs and you have yourself a business.
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.
IMO this problem is bigger that software, their licenses, and the users
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
You need a second product or service that can't be given away for free. It needs to fit perfectly: Buying B with A should make sense in some sub set of cases. B must not be required to use A.
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.
You're being downvoted but I think this is good harsh feedback.
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.
I don't care if I get down voted for my opinions on the internet :). My view on it is simple... The way the current internet is set up, it'd be really difficult to make these types of projects profitable.
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.
To be clear I think we need fewer laws. Specifically I think IP laws need to be abolished.
Software development, academic research, et cetera should be done in the open and public domain. Less monopoly profits for a few, better information and software for all.
open source doesn't necessarily mean you're giving it away for free. often the product is actually a service and having the source isn't necessarily useful to consume said service.
Sure but in this particular case the product is absolutely being given away for free. There is no service attached to having a faster linker, you just grab the code and off you go.
The only monetization it has is basically a big sign saying "please pay something if you want to", and not enough people want to.
If people can't grab the source and use it to run the service, where is the incentive to improve the source? So this may be "open source in name only" - it has an open license, but it doesn't actually build an open ecosystem around it.
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.