3 ms·

This is the worst argument I've ever seen. "Bikes are physical but software is not, therefore it doesn't cost significant resources and manpower to be used". B

This is the worst argument I've ever seen. "Bikes are physical but software is not, therefore it doesn't cost significant resources and manpower to be used". Building and maintaining software costs money. The cost of hiring one engineer and paying them mid range income in Bay Area would equate to about 1000 hobbyists paying the ~$300 licensing fee per year. And it DEFINITELY costs more than one engineer to build and maintain good software. For years companies tried to squeeze the enterprise customers more so that they can fund hobbies for others. And when finally they can't anymore and decide to charge for SOME FEATURES, while still keeping a freemium tier alive, everyone starts talking about the big evil corp. You have to realize that companies like Autodesk keep so many products alive even when they are losing money on them (look up their financials) for years, quite thanklessly.

XMPPwocky 6y ago
Sorry- my argument must have been very easy to misunderstand. My point is that the marginal cost of a hobbyist user, who receives no support, is approximately zero. At no point did I say developing Fusion must have been cheap or easy! What I was trying to say is that those costs are unrelated to the number of hobbyists using the software- Autodesk does not need to hire extra engineers to let me use Fusion. (Support is the big catch here- but I don't expect support from a free tier!). This is distinct from, for example, a mass-produced bicycle- there, yes, you still have NRE up front (design, hopefully testing, molds/tooling...), but a significant part of the cost of each bicycle is related to the cost of the input materials plus labor. That's not the case with software! With software, practically everything (again, support aside) is a sort of NRE- it's a fixed cost, no matter how many copies you make. Thus, if you somehow definitively knew that a particular customer will not pay for your software, and that their usage of it has benefits for you (greater adoption, the chance to convert them (or their employer) to a paid user later, etc) it would make sense to allow them to use it without paying- the cost to you is ~0 (mostly just bandwidth), but the benefit is non-negligible. This is not true for a bicycle. If somebody cannot pay for a bicycle, and I am manufacturing bicycles, it generally doesn't make sense to give them a free bicycle unless I'm getting something else out of it that's worth at least as much as the cost to build one additional bicycle - i.e. the cost of parts and labor. But note that the cost to design the bicycle is not part of the calculation there- because it doesn't depend on how many bicycles I build from that design. The distinction between rival and non-rival goods is very interesting, and I don't blame you at all for not understanding it. It can be counterintuitive! Does that make more sense? Again, sorry if I was unclear!
- darth_avocado 6y ago
  Right. But there's a couple of things I'd like to point out. 1. These days, for Softwares, development costs are fixed, but there are also marginal costs associated with operations, especially when the product is on cloud. Yes, support is part of the equation, and different users get different amount of support, but that's not the only marginal cost. (Trust me even free ones get some support) 2. This move probably isn't about recovering back marginal costs. It's about recovering the fixed costs. The pricing model limits newer features like generative design to paid users, which is expected, because they need to hire engineers to build new features and maintain existing product. So they're limiting that functionality to paid customers. In the bike analogy, it would be something like buying accessories for your bike. 3. The change in pricing model does reflect what you're actually saying. There is still a free tier which allows for basic usage. But all the things that contribute to additional costs to the company are being taken away. You get 10 documents, but for more you'll have to pay. Because with cloud products, to store more data, they would probably either have to maintain servers additional servers or pay cloud providers for storage, in either case, it costs money.
  - supportlocal4h 6y ago
    Why would you move your product into the cloud if it only increased your marginal costs? You move into the cloud to increase your marginal revenue. You've got this argument by the wrong end. You don't raise your prices because you had to because, well, cloud. You move to cloud specifically so you can raise your price. You might also argue that you move to cloud to reduce marginal costs of distribution, but that's arguable.

XMPPwocky 6y ago

Sorry- my argument must have been very easy to misunderstand. My point is that the marginal cost of a hobbyist user, who receives no support, is approximately zero. At no point did I say developing Fusion must have been cheap or easy! What I was trying to say is that those costs are unrelated to the number of hobbyists using the software- Autodesk does not need to hire extra engineers to let me use Fusion. (Support is the big catch here- but I don't expect support from a free tier!). This is distinct from, for example, a mass-produced bicycle- there, yes, you still have NRE up front (design, hopefully testing, molds/tooling...), but a significant part of the cost of each bicycle is related to the cost of the input materials plus labor. That's not the case with software! With software, practically everything (again, support aside) is a sort of NRE- it's a fixed cost, no matter how many copies you make. Thus, if you somehow definitively knew that a particular customer will not pay for your software, and that their usage of it has benefits for you (greater adoption, the chance to convert them (or their employer) to a paid user later, etc) it would make sense to allow them to use it without paying- the cost to you is ~0 (mostly just bandwidth), but the benefit is non-negligible. This is not true for a bicycle. If somebody cannot pay for a bicycle, and I am manufacturing bicycles, it generally doesn't make sense to give them a free bicycle unless I'm getting something else out of it that's worth at least as much as the cost to build one additional bicycle - i.e. the cost of parts and labor. But note that the cost to design the bicycle is not part of the calculation there- because it doesn't depend on how many bicycles I build from that design. The distinction between rival and non-rival goods is very interesting, and I don't blame you at all for not understanding it. It can be counterintuitive! Does that make more sense? Again, sorry if I was unclear!

darth_avocado 6y ago
Right. But there's a couple of things I'd like to point out. 1. These days, for Softwares, development costs are fixed, but there are also marginal costs associated with operations, especially when the product is on cloud. Yes, support is part of the equation, and different users get different amount of support, but that's not the only marginal cost. (Trust me even free ones get some support) 2. This move probably isn't about recovering back marginal costs. It's about recovering the fixed costs. The pricing model limits newer features like generative design to paid users, which is expected, because they need to hire engineers to build new features and maintain existing product. So they're limiting that functionality to paid customers. In the bike analogy, it would be something like buying accessories for your bike. 3. The change in pricing model does reflect what you're actually saying. There is still a free tier which allows for basic usage. But all the things that contribute to additional costs to the company are being taken away. You get 10 documents, but for more you'll have to pay. Because with cloud products, to store more data, they would probably either have to maintain servers additional servers or pay cloud providers for storage, in either case, it costs money.
- supportlocal4h 6y ago
  Why would you move your product into the cloud if it only increased your marginal costs? You move into the cloud to increase your marginal revenue. You've got this argument by the wrong end. You don't raise your prices because you had to because, well, cloud. You move to cloud specifically so you can raise your price. You might also argue that you move to cloud to reduce marginal costs of distribution, but that's arguable.