Spokes.wiki Search About

Synthesis — FOSS Applications

The evolving thesis. Spun out 2026-08-09 from six records that had sat in the hub _inbox for up to nine weeks under five different tentative tags, every one of them parked with a note saying no spoke owned software an end user runs themselves. Small corpus, one day old, and the shape below is provisional in the way a first draft is.

Current thesis — the posture is shared, the price is not

An Android keyboard, a macOS window manager, a Windows-compatibility runtime, a video downloader, a nine-module business platform and a directory of the whole field have no market, no user and no technology in common. What they share is who is in control: the software runs where its operator says (foss-application).

That is the whole of the agreement. On what the posture costs, the six sources disagree completely, and the disagreement is the more useful finding.

anysoftkeyboard pays nothing to a third party and everything in capability. Its guarantee, "multiple languages and NO internet access", holds because the network capability is absent, not because a vendor promises restraint. Nothing can leak what is never sent. The price is the entire feature set that needs a server: cross-device sync, cloud personalisation, the large models behind modern prediction. It is the strongest claim in the corpus and the one with the least left over.

hometube claims the same property and cannot have it. "No cloud dependencies, everything runs locally" sits a few paragraphs from an instruction to supply cookies, because the upstream platform still gates quality, access and "encrypted signatures." Storage and playback genuinely moved in-house. Acquisition did not, and cannot.

ever-gauzy shows where the argument runs out of road. Nine business modules, 27,198 commits, 414 open issues, self-hostable behind PostgreSQL, Redis, OpenSearch, MinIO and Jitsu. Declining to rent a keyboard costs nothing. Declining to rent an ERP means owning disaster recovery for a business system. And the vendor's own hosted version carries its own warning that it is "in Alpha version/testing mode," which inverts the usual open-core reading where the managed path is the mature one.

The first real finding: relocation sold as removal

The pattern that survives contact with all six sources is that self-hosting moves a dependency rather than deleting one, and that the marketing consistently describes the move as a deletion (self-hosting).

The test that separates the honest claims from the loose ones is simple, and this corpus supports it: name the resource the software needs that you do not own. AnySoftKeyboard has no answer, which is why it can promise the most. HomeTube's answer is an authenticated session on someone else's platform. Ever Gauzy's answer is nobody — and the price is that nobody is paid to notice when it breaks either.

The second finding: the category's own map cannot see part of it

openalternative catalogues 500+ projects, ranked by GitHub stars and nothing else. Two of this spoke's six sources are invisible to that ranking and one is badly misplaced by it. proton-wine-andrevto has 34 stars, daily automated builds, and a compatibility ecosystem depending on it, and it replaces no proprietary product, so the substitution taxonomy has no slot for it. omniwm is a window manager for a platform that ships none. ever-gauzy's nine modules rank below a list of links.

So the frame that sells this category (open-source-alternative) systematically underweights compatibility work and infrastructure, and rewards whatever is easiest to describe in one line. This spoke organises by who is in control instead, which is the reason proton-wine-andrevto is here at all.

A second map disagrees with the first, and that is the more interesting fact (added 2026-08-10). best-of-lists indexes 22 generated directories using a project-quality-score that puts stars in as one logarithmic term beside licence, semantic versioning, release recency, project age, contributor and commit counts, closed issues, downloads and dependent packages. It improves on star-sorting: hygiene points are free to earn at any size, so a small maintained project can out-rank a large abandoned one. It changes nothing about what neither map can see. Both rank repository metadata. Neither reads the code, runs the software, or asks who uses it. The generator's own docs concede the point: "There is no scientific proof that this really reflects the quality of a project."

Two biases in the better metric carry forward into how this spoke should read any ranking. Download and dependent-project terms are earnable only by things published to a package registry, so the score reads libraries better than the end-user applications this spoke is about; and the recency terms penalise software for being finished. Meanwhile 17 of the 22 lists in that index carry its own 💤/💀 inactivity markers — the machinery that measures abandonment is mostly documenting its own.

A pattern worth watching, not yet a finding

Substitution is hardest exactly where it is most constrained. Three sources replace part of the environment a platform vendor supplies — a keyboard, a shell, a window manager. All three run on platforms built to discourage that. The shapes their solutions take look like consequences of the constraint rather than design preferences: language packs as separate installable applications, an add-on app per capability, a GPL project paying for Apple notarization so its users can install it, and a store policy change that split Termux's user base into two incompatible installs (f-droid). One corpus, three cases, no counter-example yet — stated as a hypothesis.

The third finding: relocation can move the risk onto someone who never chose the software

Added 2026-08-10 with openpanel, and it is the first thing in this corpus that complicates the main thesis rather than confirming it.

Every privacy claim here until now protected the operator. anysoftkeyboard cannot leak your keystrokes because it has no network. Analytics reverses the direction: the people recorded are a site's visitors, and the person self-hosting is the one doing the recording. Moving the software in-house does not reduce the surveillance by one event. It changes who performs it, and it removes the vendor policy, the external audit and the data-processing agreement that sat between the visitor and the data.

So "self-hosting relocates a dependency rather than deleting one" has a second form: it can relocate a risk, and the party it lands on is not always the party that made the decision. Whether that is an improvement depends on which side of the software you are standing.

Two smaller things arrive with the same source. It is the corpus's second AGPL-3.0 project selling its own hosted version (ever-gauzy is the first), which turns open question 5 from an anecdote into a pattern. And its self-hosting docs are the only ones here that write the recurring bill down — updates mean reading the changelog and applying the changes yourself — which is the first direct evidence for open question 2.

A third register, and it was always here (2026-08-13)

proot-distro arrives as the second source in a category the spoke has been carrying without naming: the compatibility-layer. proton-wine-andrevto runs Windows software on Android hardware; this one runs Linux distributions on Android without root, a kernel module or a Docker daemon. Neither replaces a proprietary product and neither declines a vendor's service, so neither fits the environment / service / map split the founding six produced — and neither is visible to openalternative's substitution taxonomy, which the spoke already knew about one of them and can now say about a class.

What the class shares is where the control comes from. Both work in user space: Wine reimplements the Win32 API, proot intercepts syscalls with ptrace and rewrites paths. On a device whose owner is not its administrator, that is the only available form of control — you cannot be given root, so you emulate the thing root would have let you do.

Relocation sold as removal survives, and gets one refinement. proot-distro deletes real dependencies: no root, no unlocked bootloader, no vendor permission, no daemon. Then it writes Google's DNS servers into every container it builds (/etc/resolv.conf replaced with 8.8.8.8 / 8.8.4.4) and pulls its images from Docker Hub by default. A user who installed Linux on their own phone so nobody else would run it now resolves every hostname through Google unless they change it. The finding holds; what is new is that this time the relocation is in the code rather than in the pitch — the README documents both defaults plainly.

It also breaks the corpus's evidence pattern in the good direction. The standing caveat here is that autonomy and privacy claims are self-reported and unaudited. proot-distro publishes a limitations section that enumerates what does not work — ptrace overhead, no systemd, no cgroups or namespaces, no nesting, no FUSE, no real root, no BuildKit directives, no zstd layers. That is not verification, and nobody has checked it independently either. It is the first source here that tells you exactly where to look.

One piece of evidence available nowhere else in the corpus: the wiki runs on it. The hub's host reports 6.17.0-PRoot-Distro … aarch64, so the overhead this page describes is the overhead every build in this repository pays, and "no background services" is why the hub runs no daemons. Every other source here is software this wiki has read about.

The same ambition, priced twice by the surface it chose (2026-08-17)

tuios is a tiling window manager by a single author, and so is omniwm. Both cite the niri and Hyprland layout tradition, both let a user decide how their windows are arranged, and the corpus should have read them as two entries in the same register. They are not comparable at all, and the reason is worth more than either program.

omniwm does it on macOS, against a vendor that never intended it: accessibility and private APIs, pinned to macOS 26+ on Apple Silicon, builds signed and notarized so Gatekeeper will allow them — a GPL project paying Apple's identity toll so its users can install it, and permanently one point release from breakage. tuios does the same job inside a terminal emulator, a rectangle that already belongs to the user's own process. Nothing to ask for, nothing to intercept, no signing authority, no OS update that can revoke it.

That is a fourth position on the control question, and the cheapest one the spoke has found. The founding six split into the environment you compute in, the service you host instead of renting, and the map of the category; compatibility-layer added control taken in user space by reimplementing or intercepting an interface (proton-wine-andrevto, proot-distro). TUIOS neither asks nor intercepts — it draws inside a space already granted. The cost difference between the two window managers is almost entirely which surface the author picked, not how good either program is, and that reframes the spoke's recurring complaint: the friction these projects meet is a property of locked platforms, not an inherent price of independent software.

The trade has a ceiling and it should be said plainly. What TUIOS arranges are terminal panes, not applications. It is a window manager for one kind of window, and the surface that costs nothing is also the one that contains almost nothing.

Distribution makes the same point from the other end. anysoftkeyboard and termux treat f-droid as their real channel because a vendor store degrades or refuses them. TUIOS is on Homebrew, the AUR, Nix, ghcr.io, go install and a shell script at once, because nobody polices terminal programs. Six channels for a one-person project, and no alternative store needed to exist.

It is also a useful control case. Nothing in its README argues about clouds, vendors, privacy or data; the pitch is entirely performance engineering — event-driven rendering, viewport culling, a claimed 40–60% allocation reduction, all first-party and unbenchmarked. In a corpus where every other project is selling control, here is one that reaches the same place without making the argument. The posture is not always a motive.

A directory that does not ask what anything replaces (2026-08-17)

The spoke's second finding says the category's own map cannot see part of it: openalternative ranks 500+ projects by GitHub stars, and proton-wine-andrevto and omniwm are invisible to it because they replace no proprietary product. best-of-lists answered with a better metric (project-quality-score) and changed nothing about that, because both maps rank the same thing — repository metadata about substitutes.

awesome-terminals is the first catalogue here that changes the axis instead. Its 403 entries are sorted by where a thing runs (129 emulators across seven platforms) and what it was written in (253 tools by language). Neither question is "what does this replace," so nothing in it can fall through the gap the other two sources fell through.

That reframes the second finding. The problem was never star-ranking; it was the substitution frame itself, which is a claim about a market position rather than about software. Change the axis to a category and the blind spot disappears — and a different one opens, because a category axis admits everything in the category. This list is not a FOSS directory: iTerm2 sits beside Alacritty and a dead commercial product sits in the macOS section. Useful to this spoke, and not evidence about open source, which is a distinction the other two catalogues did not force.

Liveness gets a second implementation, and it is a human one. best-of-lists derives 💤/💀 from repository metadata, which is why the machinery ends up mostly documenting its own decay. awesome-terminals has a maintainer typing [DEPRECATED] thirteen times. A threshold is consistent and blind; a judgement is inconsistent and can know that an author declared a project finished. The corpus now holds both and can stop treating automated inactivity marking as the only option.

It also declines to rank at all — a name, a link, a sentence, and the reader compares. For a category chosen largely on feel and platform, that may be the honest answer, and it is worth setting against project-quality-score's premise that a better number was what the field needed.

One thing the spoke should hold against it. 403 curated entries and no licence file, where both siblings are CC0-1.0. A directory's value is its data, so an unlicensed catalogue is the case where the missing permission bites hardest — sharper than for an unlicensed tool, whose idea stays free even when its code does not.

The users answer, and they are not who the pitch describes (2026-08-22)

Every finding above was read off repositories. self-host-user-survey-2025 is the first source here that asked the operators, 4,081 of them, and it moves two things.

The motive ranking is upside down. Hobby (3,862) beats privacy (3,520), and both beat cost (2,596). This wiki has been reading self-hosting through the claims its software makes — hometube's "no cloud dependencies", anysoftkeyboard's no-internet permission set, openpanel's substitution pitch. Those are privacy and independence arguments. The people running the software mostly say they are doing it because they enjoy it. That does not falsify the privacy claims; it says the claims are not what recruits.

The operations bill is measured, and it is being paid manually. self-hosting argues the cost of self-hosting arrives later, as upgrades and noticing breakage. The survey puts a number on the second half: 85% update containers by hand or case-by-case, only 15% automatically, and the stated reason is fear of breaking changes. 77% run no orchestration. 34% keep one copy of their data and 542 people keep none. So the population best equipped to automate the maintenance has looked at it and declined — the ongoing attention this wiki treats as the hidden price is not hidden from them, it is chosen.

Two smaller corrections to things this corpus assumed:

And the sample is the limit. 81% work in technology, 94% are male, and everyone found the survey through a self-hosting newsletter. This answers who, among enthusiasts, runs what. It is not evidence about the households and small businesses the open-source-alternative frame is sold to, and it should not be cited as though it were.

The platform sometimes just hands it over (2026-08-25)

Every control story in this corpus so far has been a story about resistance. omniwm takes window management from macOS through accessibility and private APIs, against a vendor that never meant it to be replaceable. proot-distro works around the kernel with ptrace because Android will not give it root. proton-wine-andrevto reimplements an interface Microsoft owns. tuios escapes the question by staying inside a rectangle it already had. Four positions, all of them shaped by refusal.

termux-launcher is the fifth and it did not have to fight anything. Android has always let any app declare itself the home screen and let the user choose between the candidates. So a terminal becomes the phone's primary surface through a documented extension point, with no entitlement to request and no API to abuse — and the result is the most invasive change any source here makes, because the home screen is the surface a phone is mostly made of.

That inverts the spoke's working assumption. The corpus reads as if locked platforms are uniformly locked and control must always be taken; the launcher slot shows the lock has doors in it, and that the price of control tracks which door you use rather than how much control you wanted. Which of the two a source is doing should be recorded from now on, because the failure modes are not alike: omniwm breaks when Apple ships an update, and nothing Google ships breaks a home launcher.

Reaching users by taking the upstream's name

The launcher's recommended edition ships under the package name com.termux — official Termux's own identity on Android — so installing it removes the official app. The README pairs that with a bold disclaimer of any affiliation and a request to file bugs downstream, and the two exist together because the package name makes them necessary.

The spoke has documented several answers to how does independent software reach a user on a locked platform: an alternative store (f-droid, for anysoftkeyboard and termux), many package managers at once (tuios), and repackaging someone else's build (proton-wine-andrevto). This is a new one and the most aggressive — inheriting the incumbent's identity, which buys the entire upstream package ecosystem and costs the user their existing install. It is legal under GPLv3 and socially fraught, which is exactly why the warning box is the first thing in the README.

A maintainer who stopped one part and said so

The same source deprecates its own VAJ edition. The reason given is that a hand-maintained APT repository carrying "only a small fraction of the Termux package set" cannot be kept current for security, and that packages without security updates are "a liability rather than a feature." A migration guide to the Nix edition follows — backup, side-by-side install, restore, repackage from nixpkgs.

Open question 2 asks what happens when a maintainer stops. This is the first evidence in the corpus and it comes from the supply side: one person hit the ceiling of maintaining a distribution's security updates alone, named the ceiling, and moved users onto an ecosystem that already carries the work. That is a partial and self-reported answer about one edition of one project, not the abandonment account the question wants. It does establish that the ceiling exists and roughly where it sits.

What a dead project leaves behind (2026-08-25)

TEL arrived the same day as termux-launcher and completes its story. TEL is the original terminal Android launcher: a termux-app fork from March 2020, a [TEL] leader key over tmux, fourteen applets that replace the dialer and the share sheet and the notification tray with shell commands, and a status bar assembled from whatever executable scripts sit in a directory. It is also dead — last commit and last release both 2021-11-25, 9,690 downloads of that release, no archive flag, no deprecation notice, no successor named.

Open question 2 has now been answered from both sides in one day, and the two answers do not resemble each other.

termux-launcher's author is retiring one edition deliberately: he names the constraint (hand-maintaining an APT repository for security updates), states the principle (packages without security updates are a liability), and writes a migration guide. Users get a route out.

TEL's maintainers simply stopped. Nobody archived it, forked it with a notice, or handed it on. What survived was the design, not the software — re-implemented five years later by somebody who had been using TEL, wanted sixel graphics it did not have, and wrote a new program rather than patch a still one. The corpus has been asking what happens to an install when its maintainer stops. Here the answer is that continuity reached the ideas and reached none of the roughly 9,700 downloads, who still hold a 2021 APK aimed at an Android that has moved four major versions since.

That is the shape worth carrying forward. In open-source folklore, abandonment is survivable because anyone can fork. Both halves of this pair show something narrower: the code stayed public and forkable the whole time, and what actually happened was a rewrite by a different person under a different name. Forkability preserved the possibility of continuity. It did not deliver any.

The likeliest cause of death is infrastructure, not interest

TEL built and signed its APKs on Travis CI — .travis.yml, APK names from TRAVIS_BUILD_NUMBER, and an encrypted signing keystore committed to the repository for the CI to decrypt. Travis ended its free open-source tier during 2021; TEL's dev builds stop that February and the final release lands in November. Inference, not fact — the commits stop too, so exhausted attention explains it equally well and nobody wrote a post-mortem.

Either way it names a dependency this spoke had not looked at. Every project here is studied for what it asks of its user — permissions, containers, operations, battery. TEL asks something of a build service, and that is where its distribution ended while its source code stayed perfectly intact. proton-wine-andrevto has the same exposure in better health: its whole value is APKs published by GitHub Actions "often daily." Ask of any future source that ships a binary who runs the machine that builds and signs it, and what happens to the project when that machine stops.

Forking Termux means forking its add-ons, and that is now a rule

TEL maintains TEL:API, a fork of Termux:API, and instructs users that "Only the API from the offical TEL website should be used with TEL." termux-launcher maintains its own Termux:API and Termux:Styling forks because official F-Droid add-ons "will not pair with any edition."

Two forks, five years apart, no contact between them, identical constraint. Android pairs companion apps by package family and signing key, so neither project chose this. Forking Termux means adopting its entire add-on family as maintenance, and both projects pay it. The corpus's earlier reading — that distribution friction comes from locked platforms rather than from the software — holds here in a sharper form: the lock is Android's app-identity model, and it charges a fork for something that has nothing to do with the fork's own code.

Twenty years is a different kind of evidence (2026-08-29)

Every source before this one was read as a snapshot: stars on the day, commits to date, a tag and a last-push timestamp. calibre cannot be read that way. It started 31 October 2006, it still ships, and its own About page carries a memoir signed November 2009 sitting unrevised above present-day marketing. The document is a record of survival, and survival is the axis this spoke had no source for.

Three consequences.

The install base and the repository metrics point in opposite directions. Calibre claims 3 million active installs in over 200 countries. It also ships as a desktop application with no package-registry presence, so it would score near the floor on projectrank and has no star count anyone quotes. The spoke's two ranking sources (openalternative by stars, best-of-lists by projectrank) would both rank it as marginal. That is not a flaw in either metric so much as a demonstration of what they measure: repositories, when the thing that decides whether software matters to an end user is an install base. Open question 3 gains its second data point and its first from the supply side — though the number is self-reported, undated, and the page never defines "active."

Longevity is not the same as abandonment, and this corpus now has both ends. TEL stopped in 2021 without archiving anything; calibre has shipped continuously for twenty years on donations. Neither tells us what happens in between, which is where open question 2 lives. What calibre does supply is the shape of a survivor: a single named maintainer since 2006, a volunteer translation base, a plugin system that lets other people add what he will not, and no company. Whether that is the pattern or one lucky project is unanswerable from one source.

The registers are not exclusive. calibre manages a local library, hosts it over HTTP (self-hosting), and grew out of reverse-engineering a device protocol (compatibility-layer). Three registers, one program, and it never chose between them because it outlasted the question. The taxonomy in foss-application still describes what a project does; it should not be read as describing what a project is.

The page argues with itself about its own size

Worth recording as a source-quality finding, not just a fact about calibre. The feature block says "hundreds of motivated volunteers develop calibre"; the founder's essay on the same page says "half a dozen developers and many, many testers and bug reporters." Both are kept on calibre. The corpus's other first-party claims came from repositories, where a contributor count is a number GitHub computes and nobody writes by hand — this is the first source where the project's own self-description is the only evidence, and it turns out to disagree with itself by a factor of fifty. It also never names its licence, in a corpus where every other project leads with one.

Open questions

  1. Does any privacy claim here survive verification? Three sources sell one now and all three are self-reported. AnySoftKeyboard's is checkable in principle — permissions are inspectable and the source is public — and nothing in this corpus checks it. pocketpal-ai (2026-09-01) sharpens the question rather than answering it: it makes the strongest claim held here, lists its own exceptions honestly, and is the least verifiable of the three, because the app has the network capability its promise asks you to trust it not to misuse. The question is no longer only "is the claim true"; it is "can this kind of claim be checked at all from outside" — and the answer differs by architecture, not by honesty.

  2. What happens to a self-hosted install when the maintainer stops? — answered from both sides 2026-08-25, and only from the supply side. termux-launcher's author retired one edition deliberately, named the constraint and wrote a migration guide. TEL's maintainers stopped without archiving, deprecating or handing anything on; its design was re-implemented by a different person five years later and its ~9,700 downloads got nothing. Forkability preserved the possibility of continuity and delivered none of it. What remains open is the user side: no first-hand account from anyone who was running abandoned software when it broke, nothing on what a household does when a one-container service fails after an OS upgrade, and no numbers on how many installs outlive their upstream.

  3. Who actually runs any of this? — partly answered 2026-08-22 and again 2026-08-29 by self-host-user-survey-2025: 4,081 self-selected respondents, with per-application counts (Jellyfin 2,487, Nextcloud 1,236, Gitea 849) and a 340-application long tail. project-quality-score showed why the metadata route hits a ceiling — monthly downloads do not exist for software that ships as an app or a compose file — and asking people routes around it. What remains open is everything outside that community: the survey counts respondents rather than installations, 81% of them work in technology, and nobody who installed one container on someone else's advice is in the sample. calibre adds the other kind of number — 3 million active installs, claimed by the project rather than counted by a survey, for software that ships as an app and therefore has no download statistics anyone else can check.

  4. Does anything here survive its founder? New with calibre (2026-08-29). Twenty years of releases rest on one named person, funded by donations, with a plugin system carrying the work he declines. The corpus holds no case of a long-lived FOSS application changing hands, and no succession plan from any project in it.

  5. Does the open-source-alternative frame change what gets built, or only how it is sold? openpanel is the first case to look at — it applies the label to itself and carries Mixpanel's feature surface — and one ambiguous case is not an answer. Second case, 2026-08-30, and it is less ambiguous: alexandrie names three products in its own repository description before saying what it is, and each contributes a visible slice of the feature list — Notion the nested documents, Kanban and command palette; Confluence the teams, workspaces, five permission levels and SSO; Obsidian the markdown and offline mode. That is the frame setting a roadmap, observable from the outside. And it shows the frame's resolution limit, which neither case predicted: Obsidian's real proposition is a folder of markdown files you can open with anything, and Alexandrie keeps documents in MySQL. So the imitation copied the nameable feature (markdown) and not the architectural one (files on your disk). The open question narrows usefully: not whether the frame shapes the build, but that it transmits descriptions rather than designs — which would predict alternatives that match a product's bullet points and miss the property its users actually chose it for. That is testable against the next case and nobody has tested it.

  6. What does AGPL-3.0 mean in practice here? It appears on a household downloader, on an open-core business platform with three licence tiers, and on an analytics project selling its own cloud, doing a different job in each.

  7. Who bears the cost of a self-hosting decision when it isn't the operator? Raised by openpanel. Nothing in this corpus asks a visitor, a family member or an employee what they think of the switch.

The frame copies the description, not the design (2026-08-30)

alexandrie arrived as the corpus's purest instance of the open-source-alternative frame: a 2,633-star MIT knowledge base whose GitHub description is "The open-source, offline-first Notion, Obsidian & Confluence alternative" — three proprietary products named before the software says what it does. It is the second case for open question 4 and the first one clear enough to say something with.

The imitation is legible. Nested documents, Kanban and Ctrl+K come from Notion; teams, workspaces, a five-level permission model and OIDC/SSO from Confluence; markdown and offline use from Obsidian. Three roadmaps in one product, which is what open-source-alternative predicted a project measured against commercial software would do.

The interesting part is what did not copy. Obsidian's proposition is not "markdown" as a feature; it is a folder of files on your own disk that any editor can open, which is why it survives its own vendor. Alexandrie stores documents in MySQL and offers a ZIP export as portability. The frame carried the bullet point and dropped the architecture — and a user who chose the alternative because it said "Obsidian" would find the property they valued absent.

That sharpens the spoke's founding finding rather than repeating it. Relocation sold as removal was about dependencies: hometube moves a dependency and calls it deleted. This is the same shape one level up, about design: the substitution frame transmits what a product can be described as, and the thing that makes a product worth using is often not describable in a bullet. Both failures are invisible to openalternative's taxonomy, which files projects by what they replace and has no column for whether the replacement works the same way.

Its own numbers, for the record. Four containers to docker compose up, two of them stateful (MySQL, an S3-compatible store), on a README that promises "total ownership over your binaries, media streams, and backups" and never mentions a database. Between openpanel and hometube on the operational-cost spectrum, and one more instance of the standing pattern that the bill is stated nowhere the buyer reads.

Two autonomies, and they come apart (2026-09-01)

pocketpal-ai arrived as the corpus's strongest anti-cloud pitch — an MIT phone app, 8,137 stars, that runs quantized language models on the device and tells you your prompts never leave it — and the only installation route it offers is the App Store and Google Play. There is no f-droid entry (the F-Droid API 404s for com.pocketpalai, checked 2026-09-01) and the README never names the project's own APK, though every release attaches one and thousands of people take it: 6,154 downloads on v1.17.2 inside a week, 16,891 on v1.16.1.

Every earlier source made both refusals together or neither. anysoftkeyboard and termux treat F-Droid as home; termux-launcher ships bare APKs and no store at all. This one splits them, and the split is coherent once named: where computation happens and who controls distribution are different questions, and a project can take a maximal position on the first while treating the second as a packaging detail. Nothing in the founding six suggested those could separate — which is why the f-droid node, paged to describe what a project pays for leaving the store, now also holds the case of one that never tried.

The unadvertised APK is the part to keep. A distribution channel can exist, work, and carry thousands of installs while being invisible to everyone who does not already know to look — which means counting a project's channels from its README, as this spoke has been doing, undercounts them.

And the honesty runs the other way from the corpus's founding finding. Relocation sold as removal describes hometube: a claim of no cloud dependencies, with the cookie requirement several paragraphs down for the reader to find. PocketPal states the claim and its exceptions in adjacent paragraphs — opt-in benchmark submission and in-app feedback are named by the project itself, and model downloads, Hugging Face tokens and the PalsHub marketplace are legible elsewhere in the same README. It is the first source here that does the subtraction for you.

Which leaves an uncomfortable pairing: the most honest privacy claim in the corpus is also the least checkable one. AnySoftKeyboard can promise more than it says because the network capability is absent — an inspectable fact. PocketPal downloads models, calls a marketplace and posts benchmarks, so its promise is a discipline inside code that does have the network, and no permission list can confirm it. Honesty and verifiability are independent here, and the corpus had been treating them as the same axis.

A third split, and a third posture (2026-09-01)

ceefax-station arrived the same day and splits a different pair. PocketPal separated where computation happens from who controls distribution; Ceefax Station separates transport from content. Its radio half is the most autonomous thing in the corpus — AX.25 packets station to station over 2m, no server anywhere in the path — and its content half is a single hub run by the same one person, from which every news, sport, lottery, TV and weather page is downloaded pre-built.

The two halves ship in one alpha, and the README is not hiding either. What it does is frame the dependency as a convenience: the headline promise is "You do not need API keys," and the glossary explains why — "shared pages hosted on ceefaxstation.com so stations don't need API keys." The fallback sentence completes the picture without meaning to: if the hub is down the app builds pages locally and "some pages then need API keys." The keys were never removed. They are held by the maintainer, and the user is being sold the absence of a chore rather than told about a dependency.

That gives the corpus a third posture on its founding finding. hometube omits the exception and puts it several paragraphs down; pocketpal-ai names its exceptions in adjacent paragraphs and does the subtraction for the reader; Ceefax Station states every fact plainly and inverts the framing, so the reader has all the information and none of the conclusion. Honesty of disclosure and honesty of framing turn out to be separate axes too — a project can be fully forthcoming in a glossary and still leave the reader with the wrong picture.

The default upload is the part to keep. After any transmit or receive session the app posts its log to ceefaxstation.com with the operator's callsign and Maidenhead grid, to appear on a public map — opt-out via CEEFAX_AUTO_UPLOAD=0, documented, and never called telemetry. A callsign is a legally registered identity and a grid is a location. Every privacy claim this spoke has recorded is self-reported and unverified; this is the first case where a default that would fail most people's privacy expectations is documented in plain sight and simply not labelled.

And it breaks the utility pattern. self-host-user-survey-2025 found hobby outranking privacy and cost as a motive (3,862 selections against 3,520 and 2,596), and the corpus had no application that matched: a keyboard, a downloader, an ERP, a window manager, a phone LLM all answer a need. Nobody needs teletext in 2026. This is the survey's dominant motive with no utility argument attached — which makes it the first source that tests whether this spoke's autonomy framing even applies to the majority case, or whether the framing only fits the software people run for a reason.

The fourth posture, and this one has a meter (2026-09-04)

The founding finding — relocation sold as removal — has been read three ways so far. hometube omits the exception and buries it. pocketpal-ai names its exceptions in adjacent paragraphs and does the subtraction for the reader. ceefax-station states every fact plainly and inverts the framing. All three are about disclosure: what the README says, and where.

locally-uncensored is not a disclosure case. Its README says "Free forever… no subscription, no credits, no rate limits" in the headline, and describes LU Cloud — a credits meter, per-second music billing, three cloud-only lanes, prices in the model picker — in the changelog beneath it, in plain words. Both are true. They are true of different modes of the same application, and the product ships a switch between them.

Which is why the case is new: the seam had a failure mode, and the failure mode cost money. From the project's own 2.6.4 notes — "flipping to Local with no local model running used to keep the cloud model silently active and kept billing credits." A user who believed the headline, and set the switch to the mode the headline describes, was billed. The same release fixed a music price that quoted per-minute while billing per-second, "so a 3 minute song looked three times cheaper than it was."

So the axis is not honesty at all. Every earlier source in this spoke could be scored on how forthcoming it was, because there was one product and one claim about it. Here the claim is accurate and the product is dual, and what decides whether the user gets what the headline promised is a piece of state — a toggle — that was wrong for at least one release. Disclosure cannot reach that. Reading the README perfectly would not have protected the user in 2.6.4; only the code could.

That reframes the corpus's standing complaint. "Every privacy and 'no cloud' claim here is self-reported and none is independently verified" has been a note about evidence. This source shows it can be a note about implementation: a project can mean its claim, document its exceptions, and still ship a build in which the claim is false, because the claim is enforced by a conditional rather than by an absence. anysoftkeyboard sits at the other pole and the contrast is now exact — it cannot leak what it never has the capability to send; Locally Uncensored has the network, the keys and the billing relationship, and promises not to use them unless you ask.

Two smaller things worth keeping.

The platform split is measurable and lopsided: on v2.6.7, the Windows installer took 8,563 downloads against 576 across every Linux artifact, about fifteen to one, with latest.json at 11,308 behind them as the auto-updater's own check-in count. This spoke's sources have been Android, macOS, Termux and Linux almost throughout; the first Windows-first FOSS application here is also the first whose audience is legible from the release page rather than inferred.

And it takes a third distribution position. f-droid is a repository that signs on the developer's behalf; termux-launcher ships bare APKs with no store and no update channel; this project ships bare installers with a signed auto-update channel it runs itself, and answers antivirus flags with a reproducible-build argument and a published minisign key. Self-attestation as a distribution strategy — no third party anywhere in the trust path, by choice rather than by exclusion.

The dependency shrinks to a rendezvous (2026-09-07)

syncthing is the largest project this spoke has held — 88,364 stars, MPL-2.0, a repository dating to 2013 — and it arrives as the hardest case for the founding finding, relocation sold as removal.

Because it very nearly does remove. No host to rent, no account, no server to administer: two of your own machines find each other and sync. Every earlier source answered name the resource you do not own with something substantial — someone's platform session, someone's store, a machine you now maintain. Syncthing's storage answer is genuinely nobody.

What survives is smaller and a different shape. Global discovery maps a device ID to an IP address, and relays — "run by volunteers all over the world," enabled by default, used only when two devices cannot connect directly — carry the encrypted stream. The relay "only retransmits the encrypted data much like a router," and it still "knows your IP and device ID," while the operator "can see the amount of traffic flowing between devices." So the residue is metadata held by a stranger, on the connections that need help — not files, not always, and not nobody.

That is worth naming as its own category. The corpus has been treating the dependency as one axis (present or removed) when it has at least two: what the third party holds (files vs. metadata) and when it is involved (always vs. on failure). Syncthing is the first source that scores well on both and non-zero on either.

Two smaller findings ride along.

The strongest instance markets itself least. The README is a ranked goal list — data integrity above security, security above usability, "for individuals" at position six — with no privacy claim and no mention of the cloud. hometube, pocketpal-ai and locally-uncensored all lead with what they refuse. A project can be this spoke's subject and decline the pitch entirely, which weakens any reading of the corpus that treats the anti-cloud framing as the thing being studied.

And the honesty failure here is the ordinary one. The loose sentence is on the marketing page and the precise one is in the manual, in more detail than a user would ask for. hometube buried its dependency; this one documents it thoroughly and summarises it too well. The spoke should distinguish those, because only the first is a claim anyone is being misled by.

Funding gets a third shape. Kastelo Inc. sells commercial support around software it does not own, and the project stays MPL-2.0 and community-governed. Against ever-gauzy's nobody and the store-mediated apps, that is a maintenance answer the corpus had not seen — and it is unquantified, since the sponsorship is described by the sponsored project.

Two minimalisms, and only one of them is about the phone (2026-09-10)

olauncher is the third Android launcher here and the first that is not a terminal. Plain-text app names instead of an icon grid, GPL-3.0, on F-Droid and the Play Store, 3,803★ against termux-launcher's 239 and tel-termux-expert-launcher's 154, running since 2020.

The three agree on the diagnosis and split on the cure. All say the stock home screen is the problem. The terminal launchers answer by deleting the GUI: your dialer and your share sheet become shell commands, and the user they serve is one who wants more control at a higher price in expertise. Olauncher keeps the GUI and deletes almost everything inside it, and its repository topics say what for — digital-wellbeing, reduce screen time. One branch is about capability, the other about attention. Filing them under "minimal launcher" hides that, and the star counts say which minimalism has an audience.

It also inverts this spoke's usual configurability instinct. "To maintain the simplicity of the launcher, a few niche features are available but hidden." The features exist; the interface refuses to mention them, and the list lives off-app. Every other application here treats options as the point — anysoftkeyboard's settings, the terminal launchers' panes and workspaces. This one treats an option as a cost charged to the default user, and hides it rather than removing it, which is a third position between shipping a knob and refusing one.

And it is the corpus's cleanest small-scale open-core specimen. The free app is GPLv3 and complete; the same author sells Pro Launcher — widgets, weather, folders — on the Play Store with no repository anywhere, and asks for donations to buy a test phone. ever-gauzy shows this shape at company scale with an AGPL core and enterprise tiers; here it is one person, six years, 3,803 stars, no governance document, and a commercial product whose customers are the free app's users. That is growth edge 6's question — what happens to widely-installed FOSS when its single maintainer stops — with an unusually well-documented subject and still no answer attached. The risk this spoke keeps naming now has a face; it does not have a study.

A third way to run software somewhere it wasn't built for (2026-09-27)

quickemu wraps QEMU/KVM: quickget fetches an OS image, quickemu reads the host's own hardware and boots a tuned virtual machine, no elevated permissions required. 16,330 stars, MIT, active since 2020 and pushed within the fortnight this was read — the spoke's most conventionally healthy project by commit cadence, and its first with no privacy or autonomy pitch of any kind. quickget reaches the upstream OS vendor for every image on the record; there is nothing here to disclose or bury.

It does not fit compatibility-layer, and the miss is informative: Wine reimplements the Win32 API and proot intercepts syscalls — both fake part of an interface so foreign software believes it is somewhere it is not. Quickemu fakes nothing: KVM virtualizes real hardware and the guest's own unmodified kernel boots on it. That is why it can support macOS, Windows, most BSDs, and a shelf of systems with no binary relationship to the host at all — FreeDOS, Haiku, KolibriOS, OpenIndiana, ReactOS — where Wine only ever reimplements one interface and proot only ever intercepts one kernel ABI. The price moves from "what has the reimplementation not covered yet" to "you are now running two complete operating systems."

It also reopens the corpus's permission question, from the side that ignores it. omniwm pays Apple's toll to run on macOS at all — signed, notarized, Gatekeeper-approved, one point release from breakage. Quickemu tags itself hackintosh and lists macOS among its guests, which is exactly the use Apple's own licence restricts to Apple-branded hardware. It does not ask and does not pay; the licence becomes the host operator's problem to have or not have, and the project's README does not mention it. Three sources, three postures toward a vendor's permission: reimplement around it (proton-wine-andrevto), pay for it (omniwm), or hand the guest the real hardware and skip the question (quickemu).

Held as an adjacency to the register, not folded into it — the same treatment calibre's device-protocol history got on 2026-08-29. Two mechanisms sharing one question is a pattern; whether a third makes it a taxonomy is a call for a fourth source, not this one.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

  1. An independent audit or teardown of a privacy-claiming FOSS application — a permissions analysis, a network-capture study, or a security review of an Android IME or self-hosted service. Closes open question 1 and would give the spoke its first non-self-reported evidence. T1/T2. Sharper since 2026-09-01: with pocketpal-ai the corpus now holds a networked app whose promise is about what it does not send rather than what it cannot send, so a network capture would be worth more than a manifest reading — and would settle a claim no static inspection can. Sharper again 2026-09-04: locally-uncensored proves by its own changelog that such a claim can fail in a shipped build while the README stays accurate, so the target is now a teardown of a dual-mode application — one that checks whether the local/cloud boundary holds under the states a user can actually put the app into. That is a test no reading of any document can substitute for.
  2. A survey or dataset on self-hosting practice — who runs what, for how long, why they stop. Half-closed 2026-08-22 by self-host-user-survey-2025 (T2, n=4,081): it answers what is running now and nothing else. It has no tenure question, no churn question and no abandonment question, so open question 2 is untouched. — still needs: numbers on retention or abandonment — a longitudinal survey, a churn dataset, or a study of what happens to a self-hosted service after its maintainer stops. 2a. Anyone outside the enthusiast sample. The one survey this spoke holds recruited from a self-hosting newsletter: 81% work in technology, 94% male, 8 enterprise respondents. — needs: a general-population or SMB dataset that counts self-hosted deployments, or a study of non-technical operators. T1/T2. 2b. A user-side account of running abandoned software. Both 2026-08-25 sources describe maintainers stopping; neither describes anyone affected. — needs: a first-hand report, a forum or support-tracker study, or a dataset on how long installs outlive their upstream. T1/T2. Closes the half of question 2 that the supply side cannot reach.
  3. A serious treatment of FOSS licensing in practice — open-core mechanics, AGPL as commercial strategy, what the tiers actually change. Closes question 5. T1/T2.
  4. A comparison of a self-hosted platform against its proprietary incumbent on completeness rather than price — the Odoo/ERPNext/Gauzy question. Would test question 4 from the product side.
  5. A long-lived project's own numbers, from something other than its marketing page. calibre's 3 million installs, twenty-year run and developer count all come from a page the project wrote about itself, and two of those figures contradict each other. — needs: a release history, a contributor graph, a download or update-check dataset, or an outside history of a FOSS application that has run for more than a decade. T1/T2. Bears on questions 3 and 7.
  6. Governance and succession in a single-maintainer project. Question 7 has no source at all. — needs: a project's own governance document, a maintainer-transition postmortem, or a study of what happens to widely-installed FOSS when its founder stops. T1/T2.

Cross-spoke adjacency

Index — FOSS Applications Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Spun out of the hub _inbox on 2026-08-09 from six records parked under five different tags over nine weeks — all declined by the same neighbours for the same reason: nobody owned software an end user runs themselves. Star counts, licences and release tags are dated snapshots — cite and date them. Privacy and "no cloud" claims here are the projects' own — none is independently verified.

DefinedTerm (concepts)

SoftwareSourceCode (sources)

SoftwareApplication

Report

Organization

Synthesis

Bridge nodes (live in sibling wikis, linked cross-wiki)

termux · termux-commands-site (../osint-wiki — Termux is paged in full there as an OSINT enabler; refreshed 2026-08-09 with the repository's own numbers rather than duplicated here)

Notes

Related pages

Links to

Linked from