Every few weeks someone looks at our GitHub organization and asks, in a tone that suggests they have already spotted the mistake, why a company this small ships this many separate things, and the question deserves a real answer because the alternative they are picturing, one suite with everything bolted on, is not a neutral default that we deviated from but a specific historical choice with specific economics attached, and once you see why suites existed at all, the question inverts itself and becomes why anyone still builds one when the constraints that produced them are gone. At the September census the organization held 140 public repositories, 66 original and 74 forks, and the original side breaks down into a dozen product-grade apps, the 36-repo MongrelDB client family, the hardware bring-up trees, and the small libraries, which is how a team this size ends up well past thirty single-purpose projects without ever needing a suite, so this post is the reasoning written down once, with the costs included, because the philosophy is not free and pretending otherwise would make the rest of it suspect.
Suites were a distribution strategy, not an architecture
The suite was born from shelf space, not from engineering judgment, and it is worth saying that plainly because the bundling decision got retroactively dressed up as a user benefit once the real reason became embarrassing. Microsoft Office existed because Word, Excel, and PowerPoint in one box took one slot at Egghead instead of three and came pre-installed through OEM deals that a standalone product could not negotiate, Adobe Creative Suite existed because upgrading four products at once moved more units per transaction than upgrading one, and Netscape Communicator stuffed a mail client and an HTML composer into the browser because the bundle was the weapon in a platform fight, not because anyone’s browsing improved when the composer shipped alongside it. The user-facing story was always integration, but the integration was frequently just shared splash screens and a common installer, and the people who lived through that era remember the actual experience, which was a word processor that took nine minutes to install a clipart gallery nobody opened.
We did it that way because the physics of boxed software forced it: duplicating a CD and printing a manual per product cost real money, so amortizing the distribution cost across a bundle was rational, and nobody should apologize for the 1998 decision on 2026 grounds. The modern equivalent is the subscription suite and the hundred-megabyte Electron monolith that updates a text editor’s spelling dictionary by downloading a new browser, and the physics that justified bundling are simply gone, because distribution is now a hyperlink, installation is a package manager transaction, and uninstalling a thing you dislike is free, which means the suite survives on inertia and bundle pricing rather than on any remaining technical argument.
What splitting buys when the scope is honest
A small app can tell the truth about itself in a way a suite module never can, and that honesty compounds into engineering properties that are hard to get any other way. Foxden manages Firefox workspaces and nothing else, the Realistic Mouse Jiggler moves your cursor convincingly and nothing else, SpiderTypes teaches a kid home-row typing with no backend, no account, and no telemetry because a static page is the whole product, and each of those scopes fits in a sentence, which means the README can be accurate, the issue tracker stays legible, and the test suite can pin the one invariant that matters, the way Arte-Ogre pins a byte-identical round-trip and lets everything else hang off that guarantee.
The operational benefits follow from the same smallness: each app releases on its own cadence without a train schedule that holds a finished feature hostage to an unfinished sibling, each failure domain is one app wide so a bad release of a typing game cannot take down a PDF editor, the packaging can match the audience instead of the bundle, which is how the mouse jiggler ends up with Arch and CachyOS packages and signed Windows artifacts while underskrift ships as a library with no installer at all, and a user who wants one thing installs one thing, which sounds trivial until you remember the suite alternative, where wanting the spreadsheet meant feeding the word processor 400 megabytes of disk for a decade. Licensing stays clean per repo as well, GPL-3.0-only on the apps with the libraries and components under permissive terms, the split laid out in the licensing post, and a per-repo license statement is one line instead of a matrix.
The bill for splitting, itemized
None of this is free, and the invoice has real line items that suite builders get to skip. Discoverability is the obvious one, because thirty repos do not cross-promote the way one product page does, and the fix we settled on is this blog and the what we open source census rather than a merger, which is a deliberate bet that writing about the criterion beats compressing the catalog. Packaging multiplies per app instead of per suite, so the per-release artifacts, the signed pacman packages, and the Windows signing pipeline each carry N entries rather than one, and shared plumbing has to live somewhere, which is why the shared code concentrates in libraries and forks that exist precisely to keep the small apps small, the MongrelDB-Kit core for schema-aware client logic, the cxx-qt fork for the Qt-to-Rust bridge, the self-contained workspaces described in the workspace layout post for keeping a seven-crate app maintainable, because splitting the products only works if the common machinery is extracted honestly instead of copied thirty times and left to drift.
There is also a user-experience cost that suite fans are right to point at, which is that a person who wants five of our tools runs five installs and learns five tray icons, and we accept that trade because the alternative is a person who wants one of our tools getting four they did not ask for, and in a world of free installation the asymmetry favors the user picking, not the vendor bundling. That is a genuine judgment call and reasonable people land on the other side of it; the important part is knowing which side you are on and why, rather than drifting into an architecture because the installer framework defaulted to it.
When a suite is the right answer
The honest version of this philosophy has to name its own exception, and ours is Mongrel, the paid workbench, which is exactly the integrated multi-system surface the rest of the catalog refuses to be, and the reason is that Mongrel’s product is the seams. As the engineering post laid out, the workflow it serves starts with a query and escapes immediately into SSH, Kubernetes, containers, and logs, and when the seams between systems are where the user’s time actually goes, integrating those systems into one surface is the value rather than the bloat, so a database client, a terminal, an SFTP pane, and a cluster view earn their shared process because removing any one of them reintroduces the context switch the product exists to eliminate. The rule underneath both halves of the catalog is the same rule: split until the seams are the product, then stop, because past that point integration is what the user is buying and splitting would be ideology instead of engineering.
The other half of the exception is that Mongrel is the thing that stays closed, per the one-sentence criterion from the census post, and the open catalog stays split precisely because none of it needs to protect a seam, which lets each repo be as small and as public as its actual scope demands, so the two structures, dozens of small open repos and one integrated commercial workbench, are not a contradiction but the same principle applied to two different shapes of problem.
The point, since the question keeps coming back
Small apps are not a branding quirk or a failure to merge, they are the architecture that remains when you remove the distribution economics that forced suites into existence, and the catalog looks the way it does because each piece carries an honest scope, an honest license, an honest test suite, and an install footprint no bigger than the problem it solves, with the shared machinery extracted into libraries instead of smeared across a monolith, and with one deliberate suite at the center where integration is the thing being sold. Twenty years ago we shipped suites because cardboard and CDs made us, and the modern equivalent is a repo per problem and a package manager doing the distribution work for free, which is a trade we would make again without hesitating, because the bugs we chase now are one app wide, and that is the whole philosophy in a single sentence: keep the blast radius the size of the problem.