6 ms·

> The plain truth is that developers expect to get their tools free of charge. This is an accurate, but damning indictment of how some of the most highly paid

by nsm 8mo ago

> The plain truth is that developers expect to get their tools free of charge. This is an accurate, but damning indictment of how some of the most highly paid workers on the planet won't pay for tools. Unlike nearly every other profession. Folks, if you can afford it, please pay for quality software, instead of relying on FAANG and VC money to keep the tools going!

ipnon 8mo ago
Paying for things that aren't worth it is noble, but not good economics in the long run. If people want to buy a tool not for what it produces but for the story it tells, this is fine. But just like startups need product-market fit, tools also need product-market fit, and if no one is buying, it could simply be that the alternatives are suitable replacements.
- fragmede 8mo ago
  In other markets, that is called dumping, and it is illegal. And in fact, Microsoft was convicted of being a monopolist and dumping.
HexDecOctBin 8mo ago
I agree. When people bemoan the death of lisp machines and RAD and whatnot, remember that we deserve it. We do not want to invest in good tools and treat "Worse is Better" as some twisted virtue, and then wonder why everything sucks and most developer experience is stuck in 80s-90s technology paradigm. We deserve this.
- throw10920 8mo ago
  > We do not want to invest in good tools and treat "Worse is Better" as some twisted virtue, and then wonder why everything sucks and most developer experience is stuck in 80s-90s technology paradigm. We deserve this. Not terribly surprising that one of the most true comments is at the bottom. The Stockholm syndrome by devs desperately wanting to believe that bad tools are good is insane. It's not even hard to see why Worse is Better is just worse - among many other tests, you can look at the number of production-grade systems and popular tools written in Perl (virtually non-existent) and bash (literally zero). Empirical evidence strongly contradicts the core value tenets of the ideology.
  - HexDecOctBin 8mo ago
    Yeah, the downvotes were expected. Developers do not like being called out for the miserly and self-destructive bunch that we are. I was building an advance IDE for C and gave up when I realised that no one would buy it because "lol vim is free". Finally, I am gathering the strength to resume working on it, but only for personal use and with no expectation of selling more than 100 copies. What bothers me the most is the hypocrisy. It's okay to make money by showing predatory ads to unsuspecting populace, but not by selling useful tools. No, that is immoral.
    - pjmlp 8mo ago
      Even worse is the entitlement, refusing to pay for the work of others while expecting to be paid for their own. Hence why I am a strong advocate of dual licensing GPL + comercial, only be allowed to earn as much as willing to give upstream.
thisislife2 8mo ago
But, as the article points out, developers do pay for the tools indirectly - "First-party IDEs like Xcode and Android Studio, popular integration frameworks, and essential dev tools are all given away at no (direct) cost. The platform vendors monetize through developer program fees, app store commissions, and cloud services. Framework providers typically monetize through complementary services." And note that the article points out two other hurdles / drawbacks to adoption - their product required a subscription and developers are unwilling to commit to product from a small company that they fear may go under.
- nsm 8mo ago
  This is only true for a subset of software like mobile apps. Web developers are not paying for anything except compute.
yencabulator 8mo ago
The fewer proprietary abandonwares are in my dependencies the more I can actually do things. It's less about the price and more about the freedom. From the link: > Beyond pricing, there’s a deeper concern about durability. Developers are understandably wary of building their entire app strategy on a small company’s paid, closed-source tool.
- nsm 8mo ago
  Would you pay for source-available products? GPL and paid license? Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)?
  - deleted 8mo ago
    [deleted]
  - cornstalks 8mo ago
    > Would you pay for source-available products? GPL and paid license? I'm not GP but I would at least consider it. I say that as someone who refuses to build on closed-source tooling or libraries. I'd even consider closed-source if there was an irrevocable guarantee that the source would be released in its entirety (with a favorable open source license) if the license/pricing terms ever changed or the company ceased to exist or stopped supporting that product. > Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)? I like that for personal tools but I wouldn't build my products or business on top of those. I've had too much trouble getting old binaries to work on new OS versions to consider these binaries to be usable in the long term.
  - cortesoft 8mo ago
    Personally, probably not, although I would be more likely to than if I couldn't access the source. I just don't have a good history with software created and sold by a company. Their incentives rarely seem aligned with mine, and I have had too many rug-pulls to fall for it again. Companies that start out with sensible and open policies too often struggle to make money, and then end up trying to pull back on their openness and suddenly important bits aren't able to be modified or controlled by the user anymore.
cortesoft 8mo ago
That's because open source tools are way better for software developers. I find quirks or bugs or limitations in my tools all the time, and when they are open source I can fix and augment the tools however I want, and I can share those changes with others. I can't do that for closed source software. Now, for most software users it doesn't really matter because they couldn't fix a bug or add a feature anyway. Closed and open source are functionally equivalent, and it makes more sense to pay for support and not care you can't change it yourself. I think this is kind of like cars; people who work on cars want to buy a car that doesn't have a bunch of electronic and proprietary parts that can't be worked on in their garage. On the other hand, people who won't work on their car anyway don't care.
- krisgenre 8mo ago
  +1. AI agents can also fix minor bugs easily in open source software (it already did in two of the apps I use).
OkayPhysicist 8mo ago
The highest quality tools in the software development space tend to be FOSS, because unlike any other field, we are employed in the field that makes the tools our field uses, and distribution and manufacturing costs are zero. People build tools that they want to use, then share it with others because it's free to. If the rest of the economy worked like this we would be in full-blown utopia. Selling software to software developers is always going to have a pretty low ceiling, because you're always going to be competing with "I could build this myself" while dealing with a bunch of users who will have the nagging thought of "Why the heck does this bug exist/this feature not exist? I could fix this in an afternoon." Ironically, open source relieves this pressure for multiple orders of magnitude more people than actually contribute, because they're only grappling with their own laziness, rather than resenting you, the developer.
- aembleton 8mo ago
  > you're always going to be competing with "I could build this myself" Even more so these days with agentic coding
- NamlchakKhandro 8mo ago
  > distribution and manufacturing costs are zero. ???? citation needed
  - tekne 8mo ago
    Once the software is written, it is ~free to copy. People pay a lot of money to avoid the software getting copied... and it gets copied anyways.
    - stevefan1999 8mo ago
      The thing is that one software is easy to crack and copy, so it is cheap...but a lot of softwares to work together is not, so that's why we have SaaS and PaaS today.
  - OkayPhysicist 8mo ago
jchw 8mo ago
To be completely fair, this becomes significantly less mystifying when you trace back the origins of the free software movement... edit: To be a bit less opaque, a relevant quote: > In the late 1970s, Richard Stallman had an issue with a new printer installed in the MIT AI Lab, where he worked at the time, which ran proprietary firmware. Richard Stallman was frustrated that he could not receive a copy of the printer software and edit the code to solve his problem. This early experience made him realize limits of non-free software was a social issue. Importantly: it was never about cost. It was about the rights of users of software. It's just that the particular rights that GNU was concerned with also makes it challenging to have a moat on monetizing the resulting software.
- awesome_dude 8mo ago
  > Importantly: it was never about cost. It was about the rights of users of software. The cost (free) got me looking, but the rights, now that's what kept me. Costs - being a poor student meant I was not ever in a position to pay for products (even those massively subsidised by companies like Microsoft) - there was no way I could buy an IDE, or a compiler, or anything that I needed to /learn/. Rights - once I had the products, I was able to see how they worked, and, more importantly, make changes that worked for me, and, if desired, share those changes so other people could take advantage of them. None of that was possible under the other licences.
ppeetteerr 8mo ago
Engineers are happy to pay for tools (hello, Claude Code). Libraries are quite different and it's a little uncomfortable to build a business on a closed-source, proprietary library.
- NamlchakKhandro 8mo ago
  No one pays for Claude Code, they pay a subscription to access the Claude Models. lmao who even unironcally uses claude code when other harnesses exist that eclipse them ?
scotty79 8mo ago
> damning indictment of how some of the most highly paid workers on the planet won't pay for tools I'm gonna pay for work. I'm not gonna pay for copy of some bytes. Especially not because lawyers say so. Figure out a business model that doesn't require you to put a policeman behind my back to make it work. It's not that hard. Steam has one. GOG has one.
al_borland 8mo ago
I’ve paid for a few things for work, but I’m always living a bit outside of corporate rules when I do that. This makes it hard for me to justify if it’s only for work. In other cases, the licensing of the product doesn’t allow me to bring my personal license to work. I’ve paid for 2 text editors, that I used personally, but also took it to work. Now I use VS Code, because the company essentially mandated it with the way they rolled out GitHub Copilot and wanted to see metrics on it. This pushed me to VSCodium at home, so I don’t have to live 2 different worlds. I paid for the font I use in my editor, I assume that’s not something that will get flagged. Transmit (from Panic) and Kagi are the other two things I’m using at work with my personal account. I keep waiting for them to randomly stop working one day. Getting an actual license for software through work, that isn’t already approved, requires so much bureaucracy and red tape; I don’t even know where to begin. I sometimes daydream about working for myself or a small company, where I can use whatever I want.
RobotToaster 8mo ago
In most lines of work it's standard for the employer to pay for tools, not the worker. If anyone is cheap it's the capitalist bosses.
nine_k 8mo ago
This is a wrong framing. I don't want to depend on anything fundamental that would be limited by my ability to pay. The problem is not the money, but the enforcement, the licensing. It usually implies closed source, problems provisioning (a separate license for CI/CD?), and ultimately stuff like hardware crypto keys and online checks. This is acceptable for highly specialized software with hundreds or even dozens of installations (like some mega-CAD systems). It should rather not be the case for smaller-time, widespread tools. It just doesn't work well, like the maker of Skip noticed. It stunts the development of the tool, making it impossible to meaningfully contribute. With that, I'm all for paying open-source developers: via donations, sponsorships, hiring them for contract work, or full-time. I'd like this to be a socially accepted norm, expected behavior for corporations, but not a legally enforced requirement.
tonyhart7 8mo ago
this is simply not true, in tech "free" software actually one of the most expensive software you can buy
didibus 8mo ago
I've paid for tools in the past, but I think there's a difference, the value of a lot of our tools isn't that great, but more importantly, there is a huge cost to adoption. Going in blind on a paid tool, putting in the time to learn and train yourself to use it, that's a high cost for something that you need to pay for entry and recurring after, that maybe 50 hours into it you start to realize you don't like it. When I've paid for tools, it tends to be a tool that was free for me to start using, that is now part of my workflow and I love, and I am worried it won't continue to be maintained or updated so I pay for it.
Aurornis 8mo ago
> This is an accurate, but damning indictment of how some of the most highly paid workers on the planet won't pay for tools. Unlike nearly every other profession. This is just plain false. The total software and SaaS tool spend at every company I’ve worked for in the past decade has been incredibly high. Developers also commonly bring their own paid tools when it’s allowed: JetBrains is common. Many people have paid Git GUIs or merge tools. I think the hard truth is that getting adoption on a new paid tool is really hard, especially when you’re not sure if it’s even going to be around in a couple years. When there are open source alternatives it’s usually not about cost. We’d happily pay for something that was higher quality and helped us develop faster if it didn’t come with its own set of risks. The difference is that OSS is something we can pick up and carry along with the community even if the maintainers go a different direction. We don’t have to worry about sudden license price increases or unfavorable terms appearing at renewal time, which happens constantly now.
johnfn 8mo ago
> some of the most highly paid workers on the planet won't pay for tools Aren't we in the middle of literally the entire industry adopting 200/mo AI subscriptions? It seems to me like engineers will absolutely pay for tools if they justify their value.
- Aurornis 8mo ago
  Every company I know is lamenting their out of control SaaS spend for developer tooling. $200/month/user isn’t a big incremental cost, to be honest. SaaS and subscription tooling costs are high for developers.
- billllll 8mo ago
  It's less a binary pay/no pay, and more the value of accessing the dev tools. If you consider the fact that AI companies are most likely losing money running the models, then AI tools are incredibly cheap - they're in some ways paying you to use it. No model maker is going to try to generate a profit off users using their models, they're gonna try to generate it some other way - much like dev tools.
  - johnfn 8mo ago
    OP was saying "no one pays for tools", but AI tools are a clear counterexample. That the AI tools are themselves not profitable isn't part of the argument - "no one pays for tools which are profitable" is not an argument that anyone was making.
vips7L 8mo ago
Companies should be paying for tools not workers.
GuB-42 8mo ago
Software tools are not really tools like a knife. They are more like cooking recipes. Traditionally, people don't pay for cooking recipes, they may pay for cookbooks, that is a nice packaging around the recipes, or they may keep their recipes secret. Cooking recipes are like the software tools of chefs. The actual tools of developers are computers, which they pay for, like chefs pay for their knives. Software tools, like recipes cost nothing to copy and distribute, while actual tools, like knives and computers cost money per unit to produce.
- hahahahhaah 8mo ago
  I like the analogy. It is not perfect since recipes dont compose much (just a tiny bit) but a good analogy for the discussion.
keyle 8mo ago
There is a difference between paying and owning a tool, vs paying, and then the tool gets enshittified to hell and becomes unusable. I only buy licenses of software I can download the offline installer of; and a one time fee (per version is fine).
alt187 8mo ago
I love the lowkey vibe that if you want quality software, you either have to pay for it or wait for FAANG money. Just ignore the most widely used operating system!
- nsm 8mo ago
  What money do you think pays for most of the development of the Linux kernel? I assure you, it is not the altruistic goodwill of people around the world.
  - mfru 8mo ago
    How do you think did development of Linux work for the first many years until corporations saw the value Linux is providing? (and developers demanded they use their favorite operating system)
itemize123 8mo ago
simply put - it should be a B2B biz, not a B2C. B2C is tough, B2C saas is even tougher
mdasen 8mo ago
It's not simply that developers expect to get their tools for free. So many developers have seen the rug-pulls and exploitation of non-free tools. Build on Oracle and your company will need to hire more lawyers than developers. Even in less-exploitive situations, we've seen a lot of situations where things become many times more expensive. Google AppEngine moved from charging based on usage to charging based on instance hours and some people saw their bills go up 10x. We saw the Unity price increase which proposed a runtime-install fee. We don't want to build off an ecosystem where we have no idea what the pricing will be going forward. We don't live in a world where we can just remain on an old version via a perpetual license. Security vulnerabilities will require upgrading at whatever price a vendor sets for the new version. Incompatibilities with changing environments (like iOS/Android upgrades) will mean having to pay for upgrades at whatever the new price is. We've seen so many proprietary dead-ends where we invest a lot of time and money into a platform and then poof it's gone. You don't want to have 10 devs spend a couple years building with a tool that just disappears on you. Something small like Skip could easily run out of funding. This gives you a chicken-and-egg problem: you can't be proprietary unless you're huge, but you basically can't get huge at this point unless you're open source because no one will choose you. Skip was ejectable. It was generating Kotlin so you could just start developing two separate codebases in the future, but if you want a cross-platform toolkit and you're worried about a dead-end, you're just going to choose Flutter or React Native or something. We also don't want a situation where devs are waiting on a vendor. With open source, I can go in and fix something at my company and put in a PR. Even if the PR doesn't get accepted for a while, we aren't stuck. And it's not just developers. If I'm working at a company and I want to use a paid tool, I'm going to need to get approval for that which can just be a pain. Higher ups are going to want to know that we aren't going to get a rug-pull in the future. Skip was $1,000/year per developer, but that could change in the following year. Companies have gotten rich by offering you a good deal, locking you into their ecosystem, and then raising prices. Higher ups are going to want answers that don't really exist. Finally, it's hard to know whether something is any good without putting a decent amount of time into it. We often learn things because they're free toys we can play with. I make something fun in my spare time with a free tool and I've learned something new. But I don't want to do that with something proprietary where I might have to deal with licensing. Yes, sometimes there's exceptions for non-commercial use, but sometimes the line is blurry on that - what if I have a tip jar. We don't want to deal with that. A development kit like Skip isn't a hammer. A hammer will continue to be a hammer even if the company goes out of business. When we're choosing tools, we're not just making a bet on what it is, but also what it will be in the future. If it's going to become abandoned in the future, it'll be a lot less useful. When you're comparing tools at a hardware store, you might not make the best choice, but you aren't going to find out 18 months later that your hammer is incompatible with all nails going forward. You're also generally only out the price of the hammer, not out the price of the hammer plus 18 months worth of work that you need to redo.
dillon 8mo ago
At previous companies, I was more than happy to use corporate money to pay for software I believed in. Tools like Hashicorp Vault were certainly worth paying for the Enterprise tier. What stopped me was climbing over huge bureaucratic hurdles cause someone at the company already spent millions on CyberArk which no one wanted to use and convincing anyone to spend a few thousand on anything else was out of the question. It’s not that devs don’t want to pay for it.
kabes 8mo ago
On the other hand, we're the only high paid workers that provide so much work for free through open source. Sure, there's lawyers and doctors that do the occasional pro bono, nut nothing on the scale you find in software development.
nurettin 8mo ago
I will never pay for anything intellij again. Not because I don't have the money, not because I prefer everything free like a happy little munchkin, but because I loathe them for creating the best IDE for ruby and keeping it paywalled for 10+ years despite java/kotlin and python editors having community versions. IMO it basically killed the language. Now that ruby is uncommon, they released a community edition like a joke.
- pjmlp 8mo ago
  What killed the language is being so married to Rails that no one else thinks of Ruby in another use cases. And the performance, that has made people migrate to JIT powered platforms like Elixir/Phoenix on Erlang.
sixtyj 8mo ago
The last paragraph is so accurate. Thanks. Just a small note: Developers, add your photo (mug shot) to your code, you receive more money. People do business with people. In some book about behavioral economy there was a test with people in company kitchenette. Above the coffee machine, there was a sign asking people who drink coffee at work to contribute to a jar for the next cpurchase. One sign was just text, while the other was also made with eyes. The one with eyes raised more money.
csomar 8mo ago
I can't find a solid source to link to but the few I found shows that IT and Healthcare tops per employee spend on SaaS. The reality is nobody wants to spend for SaaS.
dustingetz 8mo ago
Jetbrains
gdiamos 8mo ago
Here’s another perspective. Developers aren’t budget approvers in engineering organizations by choice. If you are a budget approver then your inbox and calendar are full of sales teams. I find that experience is too distracting to concentrate on writing good code.
dirkc 8mo ago
It's not that I don't want to pay for good tools. I don't want to invest time and effort into tools that I have to pay for. If a tool requires payment, someone is gatekeeping access to that tool. Even if prices and terms seem reasonable today, there's no guarantee that they will be in the future.
deleted 8mo ago
[deleted]
ninalanyon 8mo ago
Employees don't pay for tools and usually have no say in which tools are bought. Car mechanics don't pay for spanners, their employers do.
- kstrauser 8mo ago
  The mechanics I’ve know all had to buy their own tools. That may be different if you’re at a specialist shop, like a place that only fixes specific parts expensive makes of cars. The guy at the local auto shop fixing whatever drives in that day almost certainly had to buy all of his.
  - ninalanyon 8mo ago
    I'm fairly sure that's not the case in most of Europe unless you are a one man company of course.
duskdozer 8mo ago
Paid tools are in my experience much more likely to engage in practices that make them less useful or more frustrating for me, like: - repeatedly changing UIs in often deleterious ways - wasting my/CPU time on analytics and engagement - upselling tactics - focusing on making the most money, not providing the best tool - preventing or making difficult the use of old versions - reducing customization for the sake of reducing customer support or branding - preventing me from making minor tweaks to code that would improve or fix something

by nsm 8mo ago

ipnon 8mo ago

Paying for things that aren't worth it is noble, but not good economics in the long run. If people want to buy a tool not for what it produces but for the story it tells, this is fine. But just like startups need product-market fit, tools also need product-market fit, and if no one is buying, it could simply be that the alternatives are suitable replacements.

fragmede 8mo ago
In other markets, that is called dumping, and it is illegal. And in fact, Microsoft was convicted of being a monopolist and dumping.

HexDecOctBin 8mo ago

I agree. When people bemoan the death of lisp machines and RAD and whatnot, remember that we deserve it. We do not want to invest in good tools and treat "Worse is Better" as some twisted virtue, and then wonder why everything sucks and most developer experience is stuck in 80s-90s technology paradigm. We deserve this.

throw10920 8mo ago
> We do not want to invest in good tools and treat "Worse is Better" as some twisted virtue, and then wonder why everything sucks and most developer experience is stuck in 80s-90s technology paradigm. We deserve this. Not terribly surprising that one of the most true comments is at the bottom. The Stockholm syndrome by devs desperately wanting to believe that bad tools are good is insane. It's not even hard to see why Worse is Better is just worse - among many other tests, you can look at the number of production-grade systems and popular tools written in Perl (virtually non-existent) and bash (literally zero). Empirical evidence strongly contradicts the core value tenets of the ideology.
- HexDecOctBin 8mo ago
  Yeah, the downvotes were expected. Developers do not like being called out for the miserly and self-destructive bunch that we are. I was building an advance IDE for C and gave up when I realised that no one would buy it because "lol vim is free". Finally, I am gathering the strength to resume working on it, but only for personal use and with no expectation of selling more than 100 copies. What bothers me the most is the hypocrisy. It's okay to make money by showing predatory ads to unsuspecting populace, but not by selling useful tools. No, that is immoral.
  - pjmlp 8mo ago
    Even worse is the entitlement, refusing to pay for the work of others while expecting to be paid for their own. Hence why I am a strong advocate of dual licensing GPL + comercial, only be allowed to earn as much as willing to give upstream.

thisislife2 8mo ago

But, as the article points out, developers do pay for the tools indirectly - "First-party IDEs like Xcode and Android Studio, popular integration frameworks, and essential dev tools are all given away at no (direct) cost. The platform vendors monetize through developer program fees, app store commissions, and cloud services. Framework providers typically monetize through complementary services." And note that the article points out two other hurdles / drawbacks to adoption - their product required a subscription and developers are unwilling to commit to product from a small company that they fear may go under.

nsm 8mo ago
This is only true for a subset of software like mobile apps. Web developers are not paying for anything except compute.

yencabulator 8mo ago

The fewer proprietary abandonwares are in my dependencies the more I can actually do things. It's less about the price and more about the freedom. From the link: > Beyond pricing, there’s a deeper concern about durability. Developers are understandably wary of building their entire app strategy on a small company’s paid, closed-source tool.

nsm 8mo ago
Would you pay for source-available products? GPL and paid license? Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)?
- deleted 8mo ago
  [deleted]
- cornstalks 8mo ago
  > Would you pay for source-available products? GPL and paid license? I'm not GP but I would at least consider it. I say that as someone who refuses to build on closed-source tooling or libraries. I'd even consider closed-source if there was an irrevocable guarantee that the source would be released in its entirety (with a favorable open source license) if the license/pricing terms ever changed or the company ceased to exist or stopped supporting that product. > Along with a guarantee that you get to keep access to older versions (Jetbrains and Sublime Text models)? I like that for personal tools but I wouldn't build my products or business on top of those. I've had too much trouble getting old binaries to work on new OS versions to consider these binaries to be usable in the long term.
- cortesoft 8mo ago
  Personally, probably not, although I would be more likely to than if I couldn't access the source. I just don't have a good history with software created and sold by a company. Their incentives rarely seem aligned with mine, and I have had too many rug-pulls to fall for it again. Companies that start out with sensible and open policies too often struggle to make money, and then end up trying to pull back on their openness and suddenly important bits aren't able to be modified or controlled by the user anymore.

cortesoft 8mo ago

That's because open source tools are way better for software developers. I find quirks or bugs or limitations in my tools all the time, and when they are open source I can fix and augment the tools however I want, and I can share those changes with others. I can't do that for closed source software. Now, for most software users it doesn't really matter because they couldn't fix a bug or add a feature anyway. Closed and open source are functionally equivalent, and it makes more sense to pay for support and not care you can't change it yourself. I think this is kind of like cars; people who work on cars want to buy a car that doesn't have a bunch of electronic and proprietary parts that can't be worked on in their garage. On the other hand, people who won't work on their car anyway don't care.

krisgenre 8mo ago
+1. AI agents can also fix minor bugs easily in open source software (it already did in two of the apps I use).

OkayPhysicist 8mo ago

The highest quality tools in the software development space tend to be FOSS, because unlike any other field, we are employed in the field that makes the tools our field uses, and distribution and manufacturing costs are zero. People build tools that they want to use, then share it with others because it's free to. If the rest of the economy worked like this we would be in full-blown utopia. Selling software to software developers is always going to have a pretty low ceiling, because you're always going to be competing with "I could build this myself" while dealing with a bunch of users who will have the nagging thought of "Why the heck does this bug exist/this feature not exist? I could fix this in an afternoon." Ironically, open source relieves this pressure for multiple orders of magnitude more people than actually contribute, because they're only grappling with their own laziness, rather than resenting you, the developer.

aembleton 8mo ago
> you're always going to be competing with "I could build this myself" Even more so these days with agentic coding
NamlchakKhandro 8mo ago
> distribution and manufacturing costs are zero. ???? citation needed
- tekne 8mo ago
  Once the software is written, it is ~free to copy. People pay a lot of money to avoid the software getting copied... and it gets copied anyways.
  - stevefan1999 8mo ago
    The thing is that one software is easy to crack and copy, so it is cheap...but a lot of softwares to work together is not, so that's why we have SaaS and PaaS today.
- OkayPhysicist 8mo ago

jchw 8mo ago

To be completely fair, this becomes significantly less mystifying when you trace back the origins of the free software movement... edit: To be a bit less opaque, a relevant quote: > In the late 1970s, Richard Stallman had an issue with a new printer installed in the MIT AI Lab, where he worked at the time, which ran proprietary firmware. Richard Stallman was frustrated that he could not receive a copy of the printer software and edit the code to solve his problem. This early experience made him realize limits of non-free software was a social issue. Importantly: it was never about cost. It was about the rights of users of software. It's just that the particular rights that GNU was concerned with also makes it challenging to have a moat on monetizing the resulting software.

awesome_dude 8mo ago
> Importantly: it was never about cost. It was about the rights of users of software. The cost (free) got me looking, but the rights, now that's what kept me. Costs - being a poor student meant I was not ever in a position to pay for products (even those massively subsidised by companies like Microsoft) - there was no way I could buy an IDE, or a compiler, or anything that I needed to /learn/. Rights - once I had the products, I was able to see how they worked, and, more importantly, make changes that worked for me, and, if desired, share those changes so other people could take advantage of them. None of that was possible under the other licences.

ppeetteerr 8mo ago

Engineers are happy to pay for tools (hello, Claude Code). Libraries are quite different and it's a little uncomfortable to build a business on a closed-source, proprietary library.

NamlchakKhandro 8mo ago
No one pays for Claude Code, they pay a subscription to access the Claude Models. lmao who even unironcally uses claude code when other harnesses exist that eclipse them ?

scotty79 8mo ago

> damning indictment of how some of the most highly paid workers on the planet won't pay for tools I'm gonna pay for work. I'm not gonna pay for copy of some bytes. Especially not because lawyers say so. Figure out a business model that doesn't require you to put a policeman behind my back to make it work. It's not that hard. Steam has one. GOG has one.

al_borland 8mo ago

I’ve paid for a few things for work, but I’m always living a bit outside of corporate rules when I do that. This makes it hard for me to justify if it’s only for work. In other cases, the licensing of the product doesn’t allow me to bring my personal license to work. I’ve paid for 2 text editors, that I used personally, but also took it to work. Now I use VS Code, because the company essentially mandated it with the way they rolled out GitHub Copilot and wanted to see metrics on it. This pushed me to VSCodium at home, so I don’t have to live 2 different worlds. I paid for the font I use in my editor, I assume that’s not something that will get flagged. Transmit (from Panic) and Kagi are the other two things I’m using at work with my personal account. I keep waiting for them to randomly stop working one day. Getting an actual license for software through work, that isn’t already approved, requires so much bureaucracy and red tape; I don’t even know where to begin. I sometimes daydream about working for myself or a small company, where I can use whatever I want.

RobotToaster 8mo ago

In most lines of work it's standard for the employer to pay for tools, not the worker. If anyone is cheap it's the capitalist bosses.

nine_k 8mo ago

This is a wrong framing. I don't want to depend on anything fundamental that would be limited by my ability to pay. The problem is not the money, but the enforcement, the licensing. It usually implies closed source, problems provisioning (a separate license for CI/CD?), and ultimately stuff like hardware crypto keys and online checks. This is acceptable for highly specialized software with hundreds or even dozens of installations (like some mega-CAD systems). It should rather not be the case for smaller-time, widespread tools. It just doesn't work well, like the maker of Skip noticed. It stunts the development of the tool, making it impossible to meaningfully contribute. With that, I'm all for paying open-source developers: via donations, sponsorships, hiring them for contract work, or full-time. I'd like this to be a socially accepted norm, expected behavior for corporations, but not a legally enforced requirement.

tonyhart7 8mo ago

this is simply not true, in tech "free" software actually one of the most expensive software you can buy

didibus 8mo ago

I've paid for tools in the past, but I think there's a difference, the value of a lot of our tools isn't that great, but more importantly, there is a huge cost to adoption. Going in blind on a paid tool, putting in the time to learn and train yourself to use it, that's a high cost for something that you need to pay for entry and recurring after, that maybe 50 hours into it you start to realize you don't like it. When I've paid for tools, it tends to be a tool that was free for me to start using, that is now part of my workflow and I love, and I am worried it won't continue to be maintained or updated so I pay for it.

Aurornis 8mo ago

> This is an accurate, but damning indictment of how some of the most highly paid workers on the planet won't pay for tools. Unlike nearly every other profession. This is just plain false. The total software and SaaS tool spend at every company I’ve worked for in the past decade has been incredibly high. Developers also commonly bring their own paid tools when it’s allowed: JetBrains is common. Many people have paid Git GUIs or merge tools. I think the hard truth is that getting adoption on a new paid tool is really hard, especially when you’re not sure if it’s even going to be around in a couple years. When there are open source alternatives it’s usually not about cost. We’d happily pay for something that was higher quality and helped us develop faster if it didn’t come with its own set of risks. The difference is that OSS is something we can pick up and carry along with the community even if the maintainers go a different direction. We don’t have to worry about sudden license price increases or unfavorable terms appearing at renewal time, which happens constantly now.

johnfn 8mo ago

> some of the most highly paid workers on the planet won't pay for tools Aren't we in the middle of literally the entire industry adopting 200/mo AI subscriptions? It seems to me like engineers will absolutely pay for tools if they justify their value.

Aurornis 8mo ago
Every company I know is lamenting their out of control SaaS spend for developer tooling. $200/month/user isn’t a big incremental cost, to be honest. SaaS and subscription tooling costs are high for developers.
billllll 8mo ago
It's less a binary pay/no pay, and more the value of accessing the dev tools. If you consider the fact that AI companies are most likely losing money running the models, then AI tools are incredibly cheap - they're in some ways paying you to use it. No model maker is going to try to generate a profit off users using their models, they're gonna try to generate it some other way - much like dev tools.
- johnfn 8mo ago
  OP was saying "no one pays for tools", but AI tools are a clear counterexample. That the AI tools are themselves not profitable isn't part of the argument - "no one pays for tools which are profitable" is not an argument that anyone was making.

vips7L 8mo ago

Companies should be paying for tools not workers.

GuB-42 8mo ago

Software tools are not really tools like a knife. They are more like cooking recipes. Traditionally, people don't pay for cooking recipes, they may pay for cookbooks, that is a nice packaging around the recipes, or they may keep their recipes secret. Cooking recipes are like the software tools of chefs. The actual tools of developers are computers, which they pay for, like chefs pay for their knives. Software tools, like recipes cost nothing to copy and distribute, while actual tools, like knives and computers cost money per unit to produce.

hahahahhaah 8mo ago
I like the analogy. It is not perfect since recipes dont compose much (just a tiny bit) but a good analogy for the discussion.

keyle 8mo ago

There is a difference between paying and owning a tool, vs paying, and then the tool gets enshittified to hell and becomes unusable. I only buy licenses of software I can download the offline installer of; and a one time fee (per version is fine).

alt187 8mo ago

I love the lowkey vibe that if you want quality software, you either have to pay for it or wait for FAANG money. Just ignore the most widely used operating system!

nsm 8mo ago
What money do you think pays for most of the development of the Linux kernel? I assure you, it is not the altruistic goodwill of people around the world.
- mfru 8mo ago
  How do you think did development of Linux work for the first many years until corporations saw the value Linux is providing? (and developers demanded they use their favorite operating system)

itemize123 8mo ago

simply put - it should be a B2B biz, not a B2C. B2C is tough, B2C saas is even tougher

mdasen 8mo ago

It's not simply that developers expect to get their tools for free. So many developers have seen the rug-pulls and exploitation of non-free tools. Build on Oracle and your company will need to hire more lawyers than developers. Even in less-exploitive situations, we've seen a lot of situations where things become many times more expensive. Google AppEngine moved from charging based on usage to charging based on instance hours and some people saw their bills go up 10x. We saw the Unity price increase which proposed a runtime-install fee. We don't want to build off an ecosystem where we have no idea what the pricing will be going forward. We don't live in a world where we can just remain on an old version via a perpetual license. Security vulnerabilities will require upgrading at whatever price a vendor sets for the new version. Incompatibilities with changing environments (like iOS/Android upgrades) will mean having to pay for upgrades at whatever the new price is. We've seen so many proprietary dead-ends where we invest a lot of time and money into a platform and then poof it's gone. You don't want to have 10 devs spend a couple years building with a tool that just disappears on you. Something small like Skip could easily run out of funding. This gives you a chicken-and-egg problem: you can't be proprietary unless you're huge, but you basically can't get huge at this point unless you're open source because no one will choose you. Skip was ejectable. It was generating Kotlin so you could just start developing two separate codebases in the future, but if you want a cross-platform toolkit and you're worried about a dead-end, you're just going to choose Flutter or React Native or something. We also don't want a situation where devs are waiting on a vendor. With open source, I can go in and fix something at my company and put in a PR. Even if the PR doesn't get accepted for a while, we aren't stuck. And it's not just developers. If I'm working at a company and I want to use a paid tool, I'm going to need to get approval for that which can just be a pain. Higher ups are going to want to know that we aren't going to get a rug-pull in the future. Skip was $1,000/year per developer, but that could change in the following year. Companies have gotten rich by offering you a good deal, locking you into their ecosystem, and then raising prices. Higher ups are going to want answers that don't really exist. Finally, it's hard to know whether something is any good without putting a decent amount of time into it. We often learn things because they're free toys we can play with. I make something fun in my spare time with a free tool and I've learned something new. But I don't want to do that with something proprietary where I might have to deal with licensing. Yes, sometimes there's exceptions for non-commercial use, but sometimes the line is blurry on that - what if I have a tip jar. We don't want to deal with that. A development kit like Skip isn't a hammer. A hammer will continue to be a hammer even if the company goes out of business. When we're choosing tools, we're not just making a bet on what it is, but also what it will be in the future. If it's going to become abandoned in the future, it'll be a lot less useful. When you're comparing tools at a hardware store, you might not make the best choice, but you aren't going to find out 18 months later that your hammer is incompatible with all nails going forward. You're also generally only out the price of the hammer, not out the price of the hammer plus 18 months worth of work that you need to redo.

dillon 8mo ago

At previous companies, I was more than happy to use corporate money to pay for software I believed in. Tools like Hashicorp Vault were certainly worth paying for the Enterprise tier. What stopped me was climbing over huge bureaucratic hurdles cause someone at the company already spent millions on CyberArk which no one wanted to use and convincing anyone to spend a few thousand on anything else was out of the question. It’s not that devs don’t want to pay for it.

kabes 8mo ago

On the other hand, we're the only high paid workers that provide so much work for free through open source. Sure, there's lawyers and doctors that do the occasional pro bono, nut nothing on the scale you find in software development.

nurettin 8mo ago

I will never pay for anything intellij again. Not because I don't have the money, not because I prefer everything free like a happy little munchkin, but because I loathe them for creating the best IDE for ruby and keeping it paywalled for 10+ years despite java/kotlin and python editors having community versions. IMO it basically killed the language. Now that ruby is uncommon, they released a community edition like a joke.

pjmlp 8mo ago
What killed the language is being so married to Rails that no one else thinks of Ruby in another use cases. And the performance, that has made people migrate to JIT powered platforms like Elixir/Phoenix on Erlang.

sixtyj 8mo ago

The last paragraph is so accurate. Thanks. Just a small note: Developers, add your photo (mug shot) to your code, you receive more money. People do business with people. In some book about behavioral economy there was a test with people in company kitchenette. Above the coffee machine, there was a sign asking people who drink coffee at work to contribute to a jar for the next cpurchase. One sign was just text, while the other was also made with eyes. The one with eyes raised more money.

csomar 8mo ago

I can't find a solid source to link to but the few I found shows that IT and Healthcare tops per employee spend on SaaS. The reality is nobody wants to spend for SaaS.

dustingetz 8mo ago

Jetbrains

gdiamos 8mo ago

Here’s another perspective. Developers aren’t budget approvers in engineering organizations by choice. If you are a budget approver then your inbox and calendar are full of sales teams. I find that experience is too distracting to concentrate on writing good code.

dirkc 8mo ago

It's not that I don't want to pay for good tools. I don't want to invest time and effort into tools that I have to pay for. If a tool requires payment, someone is gatekeeping access to that tool. Even if prices and terms seem reasonable today, there's no guarantee that they will be in the future.

deleted 8mo ago

[deleted]

ninalanyon 8mo ago

Employees don't pay for tools and usually have no say in which tools are bought. Car mechanics don't pay for spanners, their employers do.

kstrauser 8mo ago
The mechanics I’ve know all had to buy their own tools. That may be different if you’re at a specialist shop, like a place that only fixes specific parts expensive makes of cars. The guy at the local auto shop fixing whatever drives in that day almost certainly had to buy all of his.
- ninalanyon 8mo ago
  I'm fairly sure that's not the case in most of Europe unless you are a one man company of course.

duskdozer 8mo ago

Paid tools are in my experience much more likely to engage in practices that make them less useful or more frustrating for me, like: - repeatedly changing UIs in often deleterious ways - wasting my/CPU time on analytics and engagement - upselling tactics - focusing on making the most money, not providing the best tool - preventing or making difficult the use of old versions - reducing customization for the sake of reducing customer support or branding - preventing me from making minor tweaks to code that would improve or fix something