[tcmart14]

On the scale f-droid runs at, with a fraction of a fraction of a fraction of a fraction of a percent of android users, yes. As much as I would love it, I don't think f-droid could scale in such a way to really be competitive against the google playstore, eat a serious portion of Google's market share in android app stores. I hate it, but we see it time and time again. Open project requires infrastructure, which relies on donations. When its a small set of users its fine. When the user balloon up, the donations don't and the project has to shut down. Unfortunately, its only a hard core subset of users who donate.

[dlubarov]

What kind of costs are you thinking of? Payment processing could be significant, maybe 3% or a bit more if the average amount is small. But isn't that about it?

Like bandwidth becomes essentially free at a certain scale, but even if we're paying s3 retail prices, that's under $0.001 to transfer the average (~40mb or so) iOS app. Compute should be less than that.

There would also be fixed costs to develop the service etc, but Apple earns something like $80 billion / year in App Store revenue, so if a competitor could capture a nontrivial portion of that, any reasonable development costs should be pretty negligible by comparison.

[tcmart14]

Assuming you want to compete with Apple at scale or Google with roughly similar quality of service. You would probably need to stand up multiple servers around the world. Deal with the regulatory bits that each country would require to operate in. Probably also development to develop your own APIs. For instance, your gonna distribute the apps, but the apps still need to rely on Google's payment API for in-app purchases? So you need developers, if its FOSS and you get enough developers, may not be a cost sync. Authentication?

Could you do it cheaper than Apple and Google. Yes, in theory. But probably need quiet a bit of upfront capital to get it going, which might require investors who are eventually gonna wonder why they arn't collecting that sweet 30% while their competitors are.

I do wonder how that would work regulation wise. Is the store PCI compliant? How do you manage PCI compliance in a FOSS project? I do a little work on payments processing and what happens when VISA makes up a new rule on the fly that they force the payment gateways, issues a fine and the gateway companies (like World Pay) want to pass that fine on to the developers using the payment gateway? This almsot happened at my shop, we almost got hit with a $25K fine because Visa made up a new rule, tried to fine WorldPay and WorldPay tried to pass that fine onto us.

Edit: If anyone has some answers or experience to the last paragraph, please let me know! I've only dealt with payment processing on the proprietary software side and doing integrations for brick and mortar stores. So working with physical cards and payment terminals. I would be very interested to learn how this works or would work in a FOSS project.

[dlubarov]

A new entrant wouldn't necessarily need to compete worldwide; they could exclude any jurisdictions with regulatory or payment integration challenges.

The easy path to PCI compliance would be to use something like the Stripe iOS SDK and never see any payment card data. Agreed there are still some risks with card processing, but it's nothing unusual, millions of businesses deal with card processing.

Overall I agree it's not easy, but the challenges seem like normal ones that many startups deal with, mostly in smaller and/or more competitive markets which could never dream of the revenues or profit margins that would be possible here.

We could also look to the PC market to see that quite a few businesses do find it worthwhile to avoid the 30% charged by some stores. E.g. Epic Store undercuts it with 12% fees (7% if using UE), and larger companies tend to sell to consumers without using third-party stores, like EA, Blizzard, Adobe, etc.

[flemhans]

I totally agree, but I do think a few percent would cover it, still. Mostly would go towards payment processing and payout bureaucracy rather than the IP traffic and servers.