AnkiDroid Postmortem: Keep Open-Source Apps Fundable

The coroner's finding

When a platform removes a donation link, the immediate injury looks like a policy dispute. The deeper injury is funding infrastructure. A project can survive a bad review, a slow appeal, or a hostile policy change. It cannot survive a silent cutoff to the only account that pays for maintenance.

AnkiDroid is a free, open-source Android flashcard app with over 10 million installs, used worldwide for various purposes, primarily in medical education and language learning. The app's donations go to Open Source Collective, a US non-profit which acts as its fiscal host and holds an IRS determination letter stating that it is tax-exempt under 501(c)(6). Nothing is sold in the app, and its Open Collective is the sole source of funding for maintenance and development.

Google rejected AnkiDroid Play Store updates beginning August 28, 2026, and warned that AnkiDroid would be removed from Google Play on September 11, 2026 in all regions except India and Russia if the issue was not resolved. Google support told AnkiDroid that, after reviewing submitted documentation, the app still violated Google's Payments policy. The project said it was forced to remove donation links from its Play Store build in version 2.24.X under protest to continue distribution to most users.

That sequence is the autopsy. The cause of death was not that the app asked for money. The cause of death was that the app's life support was plugged into a distribution platform whose payment rules can change without the maintainer's consent.

Why the wound matters

Open-source funding often looks like a moral choice: users donate because they value the work. In practice, it is a plumbing problem. The donation link is a pipe. The store listing is a valve. The payment host is a reservoir. If the valve closes, the reservoir does not help unless the pipe can be rerouted.

The maintainer's problem is not that users stopped caring. The maintainer's problem is that the most visible place where users can give is controlled by an external party that can decide, at any time, that the link is a policy violation. That is platform risk. It is not a rare edge case. It is the ordinary condition of publishing on a platform whose rules are not contracts you can read, negotiate, or enforce in advance.

A free app can be more exposed than a paid app. A free app with an external donation link has no transaction to tax, but it also has no protected channel. The platform can treat the external link as an attempt to circumvent its payment system, even when the app sells nothing. That asymmetry is the trap: the app is free, so the platform has no revenue share; the app is funded externally, so the platform can still decide the funding mechanism is out of bounds.

The generous reading is that the platform is trying to keep its ecosystem orderly. The unsentimental reading is that order is not the same as fairness. A maintainer should not have to choose between losing distribution and losing funding. If a project must make that choice, the funding architecture was already fragile.

Funding-Link Autopsy Checklist

Every open-source maintainer should treat donation infrastructure like emergency equipment. It is not enough to have a link. You need to know where the link lives, who can turn it off, and what happens when it is turned off.

1. Inventory every donation surface. List every place a user can give: app store listing, in-app screen, website, repository page, social profile, email footer, release notes, and any partner page. Mark each surface as platform-controlled or self-controlled. A link in a store description is platform-controlled. A link on your own website is self-controlled. If the only self-controlled surface is buried, it is not a fallback; it is a footnote.
2. Mark the platform that can revoke it. For each platform-controlled surface, write down the rule that could make the link disappear. Do not assume the rule is stable. Do not assume an appeal will be fast. The question is not whether the platform is reasonable. The question is whether your funding survives if it is not.
3. Test a platform-agnostic fallback. The fallback must be reachable without the platform's permission. A website page, a repository funding page, a direct payment link, or a community-hosted page can work. Test it from a user's point of view: can a donor find it, understand what it funds, and complete the donation without asking the platform for help? If the fallback requires the platform to display it, it is not a fallback.
4. Rehearse the takedown response. Write the response before the incident. Include the message to users, the message to the platform, the message to the payment host, and the message to the community. Decide who posts it, where it is posted, and what the first action is. A rehearsed response is not an admission of guilt. It is a way to keep the project alive while the dispute is unresolved.
5. Separate store distribution from funding infrastructure. The store can be the front door. The project should keep a way for users to support maintenance outside the store, rather than relying on the store as the only place to explain how the work is maintained.

The final rule is simple: if your funding depends on a platform's permission to display a link, you do not control your funding. You control your code, your documentation, your community, and your own pages. Build the funding path there, and treat the store as one channel among many.