[DannyBee]

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.

[makeitdouble]

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.

[gjvc]

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."

[jeffbee]

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.

[gjvc]

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.

[jeffbee]

With modern power scaling that is certainly not true.

[droopyEyelids]

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.

[jeffbee]

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.

[parentheses]

Why not containerize the build so you can cache these repeated steps?

I'm sure you already thought of it but curious what is in your way here.

[mike_hearn]

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.

[eikenberry]

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.

[jeffbee]

I'm just not in charge of build and release. The improvements needed seem obvious to me.

[makeitdouble]

> 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.

[mike_hearn]

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.

[jahewson]

> test times just expand to fill available capacity

This is something I have seen time and time again.

[gavinhoward]

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.

[bastijn]

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.

[gavinhoward]

Thank you for your answer!

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.

And if they are really that tight-fisted...

Maybe this is a bad bet.

[TAForObvReasons]

The author of Zod had an insightful comment on FOSS and monetization https://twitter.com/colinhacks/status/1422222156340072456

> 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.

[gavinhoward]

That rings true to me.

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.

Thank you.

[mistrial9]

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