Here's a weekend project for you. Take one developer, one repository and a credit card, and by Monday you can have a multinational open source company with offices in two countries, a seat at the standards table, an engineering team in several time zones and an enterprise support program.
None of it has to exist. That's the beauty of it.
I'm going to walk through the recipe, because once you've seen it you can't unsee it, and a lot of people are making real decisions about real infrastructure based on the stage set. At the end I'll hold it up against a real one, Stalwart Mail & Collaboration Server, with a link to every public record so you can check my work.
Step one: offices in two countries
Buy a registered-office address in London. It costs about what a nice dinner does, and it comes with a respectable postcode, a mail-forwarding service and tens of thousands of neighbors. One London building is the registered office of nearly fifty thousand active companies. Nobody works there. That's not the point of it.
Then form a US LLC in a state that doesn't ask who owns it, doesn't ask how many people work for it, and lets a filing agent sign everything on your behalf. Use the agent's address as your "principal office." A suite in a small Wyoming town works fine. Thousands of other companies already have.
Congratulations. Your footer now lists two addresses on two continents. You're international. Your total headcount, as reported to the one government that asks, is zero.
Step two: become influential at the standards body
Anyone can submit an Internet-Draft to the IETF. It's free, it takes an afternoon, and the IETF says plainly that a draft has no formal status. It's a document someone uploaded. Most of them expire after six months and nobody notices.
But "our work at the IETF" is a phrase that reads like "we are shaping the future of email" to anyone who doesn't know the difference between an individual submission and a working-group document. Never explain the difference. Post each one to a mailing list, link the Datatracker page from your homepage, and let people assume the rest.
Bonus points if yours is the only name from your company on any of them.
Step three: hire a team (in your copy)
This one is free. You just need the right words.
- Start with "we." Every solo maintainer says "we" (I do it constantly), so on its own it's a habit, not a lie. The trick is to build on it: "we" becomes "our engineers," and "our engineers" becomes "a professional, full-time team."
- Mention that the team works "across multiple time zones." Technically you do: whichever one you're in, and whichever one your laptop thinks it's in after a flight.
- Say your engineers "need salaries." They'd certainly enjoy one.
- List "enterprise customers" and offer references on request. Never name one.
- If the old About page said you started as one developer and were hiring, rewrite it. If you had a jobs page, let it 404 quietly.
Now look at the commit history. If one account wrote 94% of the commits and is the only public member of the GitHub organization, the copy and the record disagree. The record is usually right.
Step four: open source, mostly
This is the clever part, and it's where the money is.
Release the project under a real open source license, something with "GPL" in it so the people who care about freedom nod along. Put "open source" in the hero on the homepage. Then move the parts that organizations actually need into the same repository under a different license: multi-tenancy, branding for hosted customers, archiving and undelete, live telemetry. The features that make it usable at work.
Leave that code in the tree. Compile it behind a feature flag. When a customer pays, you send a license key that turns on code they already downloaded. You're not selling software. You're selling permission to use the software that's sitting on their disk.
Then tighten it, one release at a time:
- Pull your permissively licensed libraries into the main repository under the dual license, so new work on them lands under your terms.
- Make the test suite private, so anyone who forks has to rebuild the safety net before they can touch anything.
- Land new features in one big commit per release, so nobody can follow how they were built.
Each of those is legal, and you can defend each one on its own. Put them together and "open source" on the homepage is doing a lot of lifting. The open part is the bit people can't run a business on. The bit they can is a SKU.
Step five: the enterprise support contract
Sell it per mailbox, per seat or per node, with a nice table and the word "Enterprise" in bold. Then add the asterisk: priority support and bug fixes only apply above a certain size. Below that, the customer is buying a license key and the right to open a ticket that one person will get to when they get to it.
To be fair to everyone involved, read the asterisk. It's usually there. That's the whole trick. It's always there, in a font size chosen with care.
Step six: the whining
Here's where the act gets thin.
You picked a license that lets anyone fork your project. You said so on your own blog. Then someone does exactly that, does the work, rebuilds the paid features from scratch under the same open license you started with, and ships it.
Now you write the post about clones. Make it an eighteen-minute read, and make it a nature documentary.
Open with mutualism: the clownfish and the sea anemone, bees and flowers, the friendly bacteria in your gut. That's you and your community. Then bring on the parasites, which take from their host and give nothing back. Then the tick, which at least has the sense not to kill the dog. Then, for the big finish, the parasitoid wasp, which lays its eggs inside a living caterpillar so its young can eat their way out. Tell your readers you are not willing to be the caterpillar.
Be sure to say, near the top, that forking your project doesn't make anyone a parasite. It's a right the license grants, and you welcome it. Then spend the next four thousand words on wasps. Readers will remember the disclaimer about as well as they remember the license.
It helps to know who the wasp is. Rebuilding your paid features under the open license is fair game when you do it, but it's a parasitoid when someone else does, and doubly so if they used AI. That's an interesting complaint from a shop whose own forum explains how it runs AI over the codebase every day, and whose blog has a whole post on how it uses AI. Feel free to have a model help you with the wasp section. Nobody will hold it against you. You're the anemone.
And remember why you're doing all this: to protect the livelihoods of your professional, full-time team of engineers. Sorry. Your engineer.
I have some sympathy for the money part. Maintaining an open source project is hard, and getting paid for it is harder. But the license was your choice. Open core was your choice. Telling the world you're a team was your choice. When the model breaks, that's not theft. That's the model.
Empty enterprise contracts, a development team that doesn't exist, a whole lot of whining and a wasp: a business model do not make.
The real thing: Stalwart Mail & Collaboration Server
None of that is hypothetical, and I'm not going to be coy about where it comes from. Stalwart Mail & Collaboration Server is the mail server I forked to build inbuxa. It's good software: fast, written in Rust, and I forked it because I admired it. Nothing below is about the code. It's about the company around it, Stalwart Labs, and what it says about itself next to what the public record shows. I'm a competitor, so check every link yourself. Everything here is as of October 27, 2026.
The team. Stalwart's October 2026 post, Private Tests, Public Code, says "Stalwart is built by a professional, full-time team, not as a side project" and "our engineers work on Stalwart full-time, and they need salaries." On GitHub, one account has 1,742 of the 1,853 commits in the main repository. Apart from a dependency bot and the company's own account, nobody else has more than five. The same account is the only contributor to the web admin and the migration tool, and the only public member of the organization.
The UK company. Stalwart Labs Ltd, company 12124087, has had one director since it was formed in 2019. It filed dormant accounts until mid-2022, and its accounts report an average of zero employees for every year from 2022 to 2025. That figure doesn't count a director without an employment contract, contractors, or anyone paid by the US company.
The offices. The About page gives an address in London and one in Sheridan, Wyoming. Companies House lists 49,955 active companies registered at the London one. The Sheridan suite is a well-known registered-agent address. The US company, Stalwart Labs LLC, was formed in Wyoming in August 2023, and every filing on record was signed by a filing agent. It names no owner, manager or staff.
The time zones. Until April 2026 the About page said the project "initially started with one developer" and that the company was "actively hiring" (April 8 copy). By May 7 it said "the team works remotely, distributed across multiple time zones" (May 7 copy). The jobs page was last archived on April 20 and now returns 404. References are "available on request," and the site names no customers.
The standards work. This is the step that doesn't fit, and it's only fair to say so. Stalwart's maintainer has ten Internet-Drafts on record, and four of them are working-group documents, which means an IETF working group adopted them. Two were written with Bron Gondwana of Fastmail. That's real standards work, not theater. He's also the only Stalwart Labs author on every one of them.
The license. The community edition is AGPL-3.0. The Enterprise features (multi-tenancy, branding, archiving and undelete, telemetry, masked email, read replicas) sit in the same repository under the Stalwart Enterprise License. With v1.0.0 on October 26, 2026, the test suites went private, four libraries moved into the repository as "AGPL-3.0-only OR LicenseRef-SEL", and new features now land as a single commit per release.
The support. In August 2025 the Enterprise page said "Priority support and bug-fixing are only available for deployments with 150 or more mailboxes." The asterisk was there.
The AI. Stalwart's post How we use AI at Stalwart says they use AI for bug fixes, security analysis, benchmarks and documentation, and the repository's AGENTS.md says "Stalwart Labs runs current AI models over this repository regularly." Their stated line is no AI for architecture or new features. I mention it because the wasp post objects to forks built with AI.
What the record doesn't show. The US company files no headcount, private repositories don't show up on GitHub, and contractors don't show up anywhere. So "a full-time team" isn't disproved. It's unsupported by every public record I could find. If Stalwart Labs publishes a headcount, I'll update this article and say so at the top.
Why any of this matters
A one-person open source project is fine. Some of the best software I run every day is one person's work. The problem isn't the size. It's the costume.
When a company picks a mail server, a database or an identity provider, part of the decision is the bus factor. What happens if the vendor disappears? Who fixes the next critical CVE? Is there anyone to escalate to? The honest answer for a one-person shop is "one person, and good luck," and plenty of buyers would take that deal with their eyes open. Most of them won't take it with their eyes shut. Dressing one maintainer up as an engineering department doesn't make the project safer. It just moves the risk onto people who were told it wasn't there.
How to check before you buy
None of this takes more than an hour, and all of it is public:
- Commits and contributors. Look at the contributor graph and who's in the organization. A team leaves a trail. So does the lack of one.
- Company filings. UK companies file accounts that state their average number of employees. It's on Companies House for free. Zero is a number.
- The address. Search the registered-office address. If a few thousand other companies share it, it's a mail drop, not an office.
- The drafts. On the IETF Datatracker, check whether a draft is an individual submission or a working-group document, and whether it's expired. Count the authors.
- The Wayback Machine. Pull up the About page and the jobs page from a year ago. Notice what changed, and when.
- The license files. Don't stop at the top-level LICENSE. Grep for the SPDX headers and the feature flags. Find out which parts of the code you'd actually be allowed to run.
- The asterisk. Read the support terms to the last line.
For the record
I'd be a hypocrite if I wrote all this and left out the mirror.
Coffey Labs is me. One person, one Arizona LLC and more domains than is strictly healthy. I posted my first IETF draft this week, as an individual submission, and it says so. I also run a fork of an open-core mail server, so I'm not a neutral party here and I'm not going to pretend to be.
About those private tests. Stalwart's stated reason for locking up its test suites is that forks use them as an answer key to rebuild the paid features. inbuxa never had that key. The first time I imported Stalwart's code, a script stripped out every Enterprise file, tests included, before anyone worked on it. The tests for inbuxa's versions of those features are ours, written against our own specs, and they're public. The upstream tests we do run are the AGPL suites that were always public, and they're still in every 0.16 release. Locking them away now doesn't stop a fork like mine. It just makes it harder for anyone else to check Stalwart's work. I wrote up the work behind inbuxa separately.
The difference I'm trying to draw isn't between big and small, or between free and paid. It's between saying what you are and performing what you aren't. When something I make is open source, it's all of it. When it isn't, like the LINUXexpert platform, I say it's private. And yes, I say "we" all the time. Ask me how many engineers that is and you'll get a straight answer: one, plus whoever showed up in the commit log that month. I've never told anyone they're paying for a full-time team.
It's a cheaper costume. It also fits.