But if we're talking about plain old regular software, something that needs no server to operate, and functions perfectly fine offline, something like, say, Photoshop, how different is the impact on the manufacturer when the software is used by 1k users, 1M users, and 1B users?
Yes, having 1M or 1B users means more opportunities for the bugs to surface and for people do be upset with the product. But do those scenarios impact the quality of the product for other users? Does they introduce unseen costs to the manufacturer? Do they make the product unprofitable or unsuccessful in anyway? Or does it mean that the manufacturer will have to refund 0.1% of their sales, and only benefit from the 99.9% of sales where the product worked as expected?
_very different_, when the user's environment is different. And 1) you haven't seen shit if you think you can perfectly control the user's environment. 2) every new user is a chance for the environment to bite you.
> Do they make the product unprofitable or unsuccessful in anyway?
You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to.
Can you provide some examples of this? I'd like more info here, because off of the top of my head, I can think of the following counter-examples:
1. This isn't a new problem. User environment has been an issue ever since software as an industry was born. Specifying minimum specs is a pretty typical thing. And while I don't have depth of knowledge on these challenges or their history, my understanding is that it's only become less of a factor over time. So why is digital software different in this regard? If the industry was able to sustain itself before it went digital, what about the change to digital makes it unsustainable now?
2. Computer games, which are probably a good candidate for the most resource-heavy programs that need an appropriate environment, still largely adhere to a pay once business model. Doesn't this indicate that offline experiences aren't affected by environment to such a degree that a single payment business model isn't problematic?
> You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to.
It surely has a marginal cost. But is that cost significant, is the question. In particular, significant enough to warrant a recurring payment business model.
I think you're assuming more of my answer than what I gave. That's fair given that this is the point of the article, but it's not mine. I'm very specifically only responding to "is there a per-user marginal cost on software?", and my answer is most definitely yes.
To warrant a recurring payment business model, I think the right question to ask is "Is there a per user-year marginal cost on software?", and now the answer is in my view, much more complicated and domain-specific. Worse yet, I think that there's perverse incentives at play here in recurring payments.
Fair, but I feel it's disingenuous to ignore the context the original comment was written in (the context of the article) and try to argue against a specific point in the post as if it was made without that original context. The sentence may have lacked inherent context, but it was supporting the key points the GP was making in response to the article. It wasn't designed to stand alone.
Given, I'm not the author of that post so entirely possible they were intending for it to stand alone, but I think it would still be better to see if that was intent rather than to assume so and antagonize what they were saying.
Try selling English-only software in Europe and you generally won't get very far.
If a company was only able to sell 2.6M copies of their digital software before running to expansion problems... good for them! That's a lot of sales and they probably made a great deal off of those sales. Sure, they can grow to 1B users, but they don't have to. There's no requirement for them to do that other than choosing to expand into those markets, and that's strictly optional. The business model is doing fine, there's no need to adopt a recurring payment system for ongoing maintenance.
And let's be honest, even if they do choose to expand into those other markets, the cost to convert the existing product to work in those markets is most likely less than the money they'll earn from selling in those markets, so... is there really a need for recurring payments to support maintenance? Will one-payment sale structures inherently fail to make the product profitable in a given market?
Absolutely. Anything involving internationalization is an open invitation for very weird edge cases. Some languages (Hebrew!) are written right-to-left, some require more than one byte to store (Japanese, Chinese), time formats and time zones vary, some write currencies with the symbol in the front (US dollar) and some at the end (Euro).
If all your testing was done by Americans speaking English, the only thing you may stumble upon is timezones. If you're in Europe, timezones won't be much of an issue (as almost everyone is on CET), but you may find out that, whoops, Windows localizes certain path elements like C:\Users.
On top of that, a constant pain point in support is displays. Most Windows users are on a 1080p screen on their laptop, but may plug in their new 4K monitor and notice that your UI is completely illegible because it doesn't respect DPI settings. Or you thought you supported variable DPI, but never planned on a user stretching your window across two screens with different DPI settings. Or monitors use different color profiles or gamma settings and users complaining about that.
The main product at work is a desktop application. That means that every OS version / hardware configuration of every platform that any user might install it on can have its own bugs. It means that we support multiple major versions rather than being able to just always deploy the latest version. It means that a user might want to have multiple versions of the software installed side-by-side on the same machine. It doesn't change the fact that more users means more use cases.
I don't believe such software exists. (And, to be clear, I'm writing from direct, day-job experience.)
EDIT: I take it back. SQLite, cURL. Maybe.
EDIT2: I can't reply to the SEL4 response, so here goes. I'm a huge fan of verification tools, but consider the Spectre class of bugs. Verification is always done wrt a mathematical model that you've defined after inspecting the world and writing down the properties you want to track. But the world changes, and the chance that the world changes increases with the number of users of your software. That's the nature of the beast.
When I had a reply I couldn't reply to, I opened the reply separately in a new tab, and there I could reply to it, try this.
It's a bug in the processor that causes a bug in the software. It's not a bug in your idealized mathematical model, but try telling that to the people who paid you not to leak private keys.
I see my job as an engineer to be to create a product that satisfies the user's expectations (which in this case are eminently reasonable). It matters not one bit that I can point the finger to the chipmakers. I'm still selling something that I now learned doesn't do what I said it would. It's still on me to fix it the best I can. If I care about the product quality, that is.
Not my business to decide what you think is reasonable. That's just what happens in the world, and what (in my view) good engineers sign up for.
Why do you think so?
What choice? I have to fix bugs today as they come.
I think that this is a bad analogy to hardware, though. Polished steel roads are unreasonable to ask for, but bugless processors are reasonable to ask for.
I’m software we deal more with curses than miracles. Those happen every day too.
Software use cases experience combinatorics, and almost all useful algorithms have log(n) runtime. Even when Knuth says they are O(1), physics or EE say he’s wrong. There are no economies of scale. Racks don’t get cheaper when you run out of network ports. Cooling doesn’t get cheaper when you run out of roof. Things that failed one time in a million calls now happen every hour instead of twice a month, and actually have to be fixed.
It’s death by a million cuts.
Maybe you've never experienced the difference between writing software for 1000 people and writing software for 1M people, or (I imagine) 1B. The marginal per-person cost of software is not on shipping. It's on "what kind of weird shit will I now have to do because 1M is a lot of chances for my software to break weirdly, and people have paid for it"
> You don't have to worry about quality control and returns.
You don't have to worry about quality control and returns if you don't care about quality control or returns.