We publish a lot of our work as open source. Seventy-plus packages are live on our GitHub organization, and we add new ones as we build them. This post is the argument for why, because we get asked about it regularly.
The short version: we write a lot of infrastructure code anyway. It would take roughly the same amount of effort to keep that code proprietary. There is no commercial advantage to hiding it. Making it open gets us better code, better distribution, and better collaborators. The tradeoffs genuinely favor open in our case, and we think that is not fully appreciated by most teams we talk to.
Let us go through those reasons in turn.
Better code. When code is public, it gets reviewed by people who are not on your team. That is an enormous multiplier on quality. We have had issues filed, pull requests opened, and subtle bugs pointed out by strangers who took the time to dig into our codebase. We would not have caught most of those ourselves, or we would have caught them much later. The hit rate on useful external contributions to any individual package is low, but the absolute volume across seventy packages is meaningful, and the cost of accepting a good patch is almost zero.
Public code also forces a discipline internally. When you know people might read your code, you write it better. Variable names get more thought. Functions get better docstrings. Tests get taken more seriously. APIs get designed with the assumption that someone else will use them, not just someone on your team. That discipline compounds. A codebase written with the expectation of external readership ages better than one written for internal consumption.
Better distribution. We do not have a sales team. We do not run paid marketing. The way people find us is: they hit a problem, they search for a library that solves it, and sometimes one of ours comes up. From there they install it, use it for a while, eventually look at the project page, and decide whether to use our commercial product too. Open source is our marketing, and it happens to be the only kind of marketing we both enjoy doing and respect when other companies do it to us. Engineers are highly allergic to most forms of advertising. Engineers like good libraries. Publishing one is the most direct way to reach them.
Better collaborators. People we have hired from the open-source community tend to be exceptional. They self-selected into caring about our problem area enough to contribute before anyone was paying them. They already know the codebase. The onboarding curve for someone who has shipped pull requests against your code is measured in days, not months. The same dynamic applies to partners and customers — the ones who find us through open source tend to arrive with a clearer picture of what we do, which leads to much better conversations.
The objection we hear most often is "won't your competitors use your code against you?" The short answer is: no, mostly they will not. Copying code is easy; copying an actively maintained project is very hard. If a competitor forks one of our repos, they now have a static snapshot of code that is moving every week. They either maintain it themselves, which is expensive, or they fall behind, which defeats the purpose. More importantly, the commercial value we capture is not in the code itself. It is in the hosted product built on top of it, the operational maturity of running it at scale, the specific integrations we have, and the relationships with customers. Open-sourcing the code leaks none of that.
The second objection is "won't this cannibalize your paid product?" Also no, mostly. The paid product is valuable because it solves problems the open-source pieces do not — reliability, observability, team features, hosted infrastructure, support. Anyone technical enough to run the open-source stack themselves is not the customer for the paid product anyway. We publish both because they serve different people well.
The criterion we use for what to open-source. Everything unless there is a specific reason not to. Specific reasons include: security-sensitive code that would make our own customers less safe if public, code that is genuinely tied to our commercial IP in a way that matters, and a very small amount of operational glue that only makes sense inside our deployment. That is it. The default is open.
Licensing. Almost everything we publish is under the MIT license. We thought about this and decided that the permissiveness was a feature, not a bug. Other licenses — GPL, AGPL, various source-available licenses — have their uses, and we respect the reasoning behind them. For our work, though, we would rather have the code in as many hands as possible with minimal friction, even if that means a fork could theoretically be used by someone we would prefer not to have used it. That tradeoff has been fine in practice.
Maintenance. This is the hidden cost of open source and the one most companies underestimate. Publishing code is trivial. Maintaining it over years, responding to issues, reviewing pull requests, managing breaking changes, handling security reports — that is the actual work. We take it seriously. Every package has an assigned maintainer on our team. Issues get triaged within a couple of business days. Breaking changes are rare and carefully communicated. If you use our libraries in production, you can count on that.
What we do not open-source, and why. Commercial product code that is specific to Alumia. Some internal tooling that would require too much context to be useful outside our company. Security-sensitive pieces. That is about five percent of what we write. The other ninety-five is public.
What to do with our code. Use it. Build on it. Fork it. Contribute back if you have improvements. Email us if you have questions. The whole point of open source is that the code is yours to use; we are just shipping it.
The list of packages is on the public page of this site and on our GitHub org directly. If you are starting a project and think one of them might save you time, give it a try.