Hacker News Reader

Comment by ysavir | Hacker News Reader

That's applicable to websites, where you have to handle requests from all your users, and more users means more requests to handle.

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?

View on HN

> how different is the impact on the manufacturer when the software is used by 1k users, 1M users, and 1B users?

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

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

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.

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

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

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.

> But do those scenarios impact the quality of the product for other users?

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.

Beyond bugs, scaling your MVP to 1B users will mean expanding your userbase beyond English speaking Americans. This requires upgrades to internationalization, accessibility, possibly compliance with international laws and 3rd party licensing changes per region. Multilingual support staff and international payments processing. With a userbase this large, expect to be sued by people around the world, so you'll need region-specific legal services. Some of these issues just require money and non-technical staff and don't directly impact the user experience aside from diverting resources away from building features and fixing bugs for your original userbase.

There are apparently 2B English speakers in the world, so you could in principle get away with no internationalization and have 1B users. The other things are more a cost of operating a multi-national business, and not a marginal cost of the software as such. You could also in principle scale to ~300M users (or ~100M households) without worrying about international issues by sticking to the US only.

Just because someone speaks some English, doesn't mean that they wouldn't prefer to use software in their native language.

Try selling English-only software in Europe and you generally won't get very far.

You can tell the people who have never run a business or have worked at one small enough that they see everything. Support staff are not free. Project managers and salespeople can’t keep up with meetings and start sprouting assistants and coworkers. Customers are expensive, especially upset customers. So then the developers have to spend a lot more time making sure customers don’t get upset.

Sure, but these aren't business model problems, they're business growth problems. The concern wasn't how to find 1B users in the world (and what do you have to do to get their money), it's whether scaling to 1B users inherently breaks the product, not just for individual users, but for all users.

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?

>But if we're talking about plain old regular software, something that needs no server to operate, and functions perfectly fine offline

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.

Even when customers run software on their own machines, you have to deal with bugs that only occur in rare occasions because your giant user base finds them all. Plus now you’re running in unknowable environments that you have to debug via telephone (the object or the children’s game or both).

Reply on news.ycombinator.com