6 ms·

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 n

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 3y ago
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 3y ago
  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 3y ago
    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.
    - deleted 3y ago
      [deleted]
    - gjvc 3y ago
      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 3y ago
        With modern power scaling that is certainly not true.
- droopyEyelids 3y ago
  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.
cornercasechase 3y ago
[flagged]
- unmole 3y ago
  > It comes off like sour grapes. It does not. The comment is insightful and offers a business perspective. > You should refrain from speaking ill of prior employees. The comment did not speak ill of anyone. Quite the opposite: > Rui is a genius and an amazing programmer
  - cornercasechase 3y ago
    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?
    - deleted 3y ago
      [deleted]
    - unmole 3y ago
      > He doesn’t need to critique the market 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?
      - cornercasechase 3y ago
        [flagged]
        jchw 3y ago
        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.
mistrial9 3y ago
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
gavinhoward 3y ago
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.
- TAForObvReasons 3y ago
  The author of Zod had an insightful comment on FOSS and monetization https://twitter.com/colinhacks/status/1422222156340072456 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 3y ago
    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.
- bastijn 3y ago
  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.

makeitdouble 3y ago

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 3y ago
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 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - gjvc 3y ago
    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 3y ago
      With modern power scaling that is certainly not true.
droopyEyelids 3y ago
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.

cornercasechase 3y ago

[flagged]

unmole 3y ago
> It comes off like sour grapes. It does not. The comment is insightful and offers a business perspective. > You should refrain from speaking ill of prior employees. The comment did not speak ill of anyone. Quite the opposite: > Rui is a genius and an amazing programmer
- cornercasechase 3y ago
  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?
  - deleted 3y ago
    [deleted]
  - unmole 3y ago
    > He doesn’t need to critique the market 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?
    - cornercasechase 3y ago
      [flagged]
      - jchw 3y ago
        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.

mistrial9 3y ago

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

gavinhoward 3y ago

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.

TAForObvReasons 3y ago
The author of Zod had an insightful comment on FOSS and monetization https://twitter.com/colinhacks/status/1422222156340072456 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 3y ago
  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.
bastijn 3y ago
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.