How to make app stores friendly to Open Source

Microsoft recently seemed to propose that Open Source software didn’t belong in the Windows app store. Excuse me?

After the news broke, Giorgio Sardo, Microsoft’s General Manager of the Microsoft Store, argued on Twitter that it wasn’t Microsoft’s intent. “We absolutely want to support developers distributing successful OSS apps. In fact, there are already fantastic OSS apps in the Store! The goal of this policy is to protect customers from misleading listings.”

Predictably, confusion results. And the kerfuffle over FairEmail and the Google Play Store earlier this year is a good example of how this sort of confusion is not entirely new, leading to questions about intent.

I’ve talked with developers and business managers about their experience in preparing software packages for commercial app stores. Universally, everyone reports having issues with app stores’ packaging. These include:

• It’s specialized work beyond the normal delivery for the platform in question;
• It requires administrative and bureaucratic steps, which are not normal for an open source project or for a developer; and
• Comes under legal terms that need professional advice to review and could place the developer and their community at risk.

None of this work is normal for Open Source developers. This is all extra work in service of the store. Specifically, it simply is not viable to demand that Open Source developers constantly jump through ever-changing hoops. This is an unsustainable demand for Open Source developers and businesses.

Fortunately Microsoft pulled back from its proposals to prevent communities recouping their costs, but it raises the whole issue of maintaining apps in “walled garden” app stores. Here are my thoughts on the work needed to place apps in app stores and its impact on Open Source communities.

Increasingly necessary

App stores are a mixed blessing. They copy the experience of simple package selection and installation that revolutionized Open Source software twenty years ago. But, they also use access to the package repository as a control point. This works both to users’ benefit and to their detriment. Beneficial effects include excluding malware, limiting dark patterns by software providers, and allowing easy fee payment. Detrimental effects include discouraging Open Source software from the app store, intruding on user privacy,  censoring applications and their content.

As desktop platform owners are gradually shifting towards a “walled garden” approach for desktop software, it is increasingly necessary for Open Source projects to offer more than just downloads.

If they don’t, users face increasing barriers to installing mere downloads. This has been a significant barrier to Open Source desktop apps on the Mac for years. Now, it threatens to  become a barrier on Windows as well. Users may face warnings that Open Source downloads are risky or contain malware, and even face denial of installation unless complex technical steps are taken. Those complicated steps may make the system less safe by opening it to malware from other sources.

If the software freedom benefits of Open Source software are to be made more widely available, communities have no choice but to engage app stores. Some have already done so to great effect (Krita, for example); others continue to be challenged by the issue.

Layers of extra effort

The extra work required to post a working desktop package in all the commercial App Stores is significant as they have specific initial sandbox requirements on top of the publishing workflow. On Windows it’s relatively straightforward once you’re familiar with the restrictions and framing, but on Apple’s store the difference between a user app and a store app is significant and constantly changing. On Google you’re writing for the Play Store anyway so only the process/SEO challenges really apply – but they remain significant.

On top of that, there are legal review costs. The licensing terms for app stores are unusual because they are minutely enforced. Since they are designed to regulate relationships with commercial entities, many of which may be assumed to be generating large incomes that justify SEO and other forms of market manipulation, communities are rightly cautious about these agreements and frequently feel the need to get expensive legal advice about them. Since the agreements change often, this is a significant ongoing cost for no return.

On top of those commercial counsel costs, communities with copyleft licensing may face pressure from extreme interpretations of copyleft that result in the app store being sent allegations or complaints by community members about license and/or contract infringement. Whether this is headed off in the community or dealt with as it arises, the costs of doing so in both financial and emotional terms are non-trivial.

All the stores suffer from onerous iterative acceptance processes for each new version as well as capricious takedowns by the app store’s management. These are very hard for communities to triage both in terms of engaging the corporate process (which assumes a commercial developer willing to allocate staff to contractual change-tracking, wrangling and SEO) and in terms of performing iterative uploads and publication to clear the issues.

Sustainable development

Since the work involved is specific to the package being uploaded, the usual Open Source project experience of contribution being made in parallel with work for employment does not apply, so it is a direct cost for an employer to have their staff contribute this work – which may compete with their own app store offerings, making it less attractive to contribute.

Desktop Open Source projects have different economics to server software, components and stack layers. The desktop’s decline has meant that proprietary desktop software has mostly switched to a subscription model with a broad multi-capability platform rather than the sale of an added-value version of a single program. That has meant that participation in desktop open source projects has become less viable as an adjunct to selling a desktop product.

The usual ways desktop Open Source projects monetize – donations and supportive purchases – are taxed just as heavily as commercial software. There are additional restrictions for some permutations that work for donations, related to stopping the use of certain payment modes by scams and shells.

There is no doubt that fake uploads are a problem that leeches contributions away from Open Source communities to individual parasites. Communities with sufficient staff routinely use trademark complaints to have them removed if they use the variant of the project trademarks reserved for official uploads, but the app store processes are not especially approachable and the process is costly in time and thus staffing (since it is not especially amenable to volunteer work).

Conclusions

To ban payment for Open Source projects that are free elsewhere would be a travesty for communities, and it’s good it hasn’t yet happened. Even if app stores weren’t extra technical work, they remain extra administrative work.

But even without a change to monetization, placing apps in app stores is effectively a subsidy for the app store by the community since no developer needs to do all that extra work for their own use. App store owners should take steps to offer simplified or even subsidized access to all bona fides Open Source communities.

An Open Source friendly App Store would:

• Offer free processing for charities, especially small payments.
• Provide a lightweight and stable legal arrangement that has no terms conflicting with the most frequently-used Open Source licenses, together with independent legal assessment of red-lined changes.
• Offer an easy entry point for community-owned trademark management, reserving registered trademark use only to the community approver.
• Provide a rapid resolution channel for dealing with copyright and trademark takedowns, both of fake uploads and when valid uploads are falsely accused.

The Open Source community needs to formulate a set of best practices and then work with app store owners to implement them. OSI together with its large community of Affiliates is ready to facilitate this. OSI invites App Store owners to get in touch so we can together build best practices for Open Source projects to work within commercial app stores. Please reach out via your sponsor contact or using the contact form if you are not yet an OSI Sponsor.