Looking at the stats, the Win:Mac ratio is 4:1 but Android:iPhone only 2:1 so it might hurt Windows. But if iPhone users are more likely to use Mac or don't use computers much already, then expanding iPhone capabilities would cannibalize Apple business.

This is based on the observation that people, including police, tolerate taxi drivers stopping at places where it's technically illegal.

In case the supply chain breaks, preppers don't want to be the ones that starve. They don't claim they can prevent mass starvation.

(Very off topic from the article)

I guess it's an obvious thing to sell, if you go through the process of PCI-DSS compliance. We were definitely considering splitting the company to a part that can handle these data and the rest of the business. The first part could then offer the service to other business, too.

Yes

> I can see how this significantly increases complexity for tracking

Not really. You just track at some prefix level. In general, the ISP will hand out a /64 per consumer so that's what you can track. From there, you can build more complex and more precise grouping rules for tracking.

I'd say the spirit of open source is that others are free to modify the code and that's it. This requires a good license, the possibility to fork, some documentation and a way to build the project yourself.

But why would accepting contributions be required?

You asked whether some of the reasons are technical. Not in the sense that you can't do it in a simpler way, no.

Look at it from the perspective of a company that has a product and a few developers working on it. It's successful. Now a lot of requests pops up. Some are small, some are related to an obscure integration, maybe a few custom development requests from important customers, bug fixes... The company can now either say no to a big chunk of them (a fine choice), or, if it has money, it can hire more people.

Now, with more people, for them to be somehow effective, you need to create internal APIs and narrow down the focus areas of your teams. Backend/frontend is a separation layer, you're right. But I'd argue it's not that useful for this problem. If the backend emits HTML, what's the frontend work then? Styling? On the other hand, running a thick client in the browser that consumes an API makes it possible to decouple even the release cycle of the frontend from the backend.

Mind you, there are companies that are/were successful with a small team. But most often, the success is supported by large teams at the cost of technical perfection.

It's a trade-off.

The downside is that it's much easier for me to overstrain my muscles. My muscles can really hurt without much effort if I lift weights and I'm not focused on preventing that.