How dotcommoners builds
Six principles shape every project — from the license we choose to the way processes talk to each other. They add up to one idea: infrastructure you own, not rent.
dotcommoners software is open source (MIT), self-hostable by default, performance-first (Rust and Zig, with Python where a control plane wins), brokerless and horizontally scalable, free of vendor lock-in, and written to be read.
Open source, permissively
Everything is MIT-licensed. Fork it, patch it, ship it — no proprietary control plane, no licensing fees.
Self-hostable by default
On-premise deployment is the design goal, not a paid tier. Run it on a laptop, a homelab, or a fleet of edge nodes.
Performance-first
Rust and Zig where microseconds and memory matter; Python where an ergonomic control plane and rich ecosystem win.
Brokerless & scalable
Brokerless architectures with no central bottleneck and no single point of failure. Horizontal scale is built in.
No vendor lock-in
Nothing phones home. If dotcommoners vanished tomorrow, you would still have the full source and could run it forever.
Readable & documented
Real docs at docs.dotcommoners.com, clear architecture notes, and source you can actually follow and contribute to.
What ownership actually gets you
The practical difference between running dotcommoners software and subscribing to a managed SaaS equivalent.
| Property | dotcommoners (own it) | Managed SaaS (rent it) |
|---|---|---|
| You own the source | ✓ Yes | ✕ No |
| Runs on your hardware | ✓ Yes | ✕ No |
| No per-seat / per-request metering | ✓ Yes | ✕ No |
| Fork and modify freely | ✓ Yes | ✕ No |
| Nothing phones home | ✓ Yes | ✕ No |
| Managed for you by a vendor | ✕ No | ✓ Yes |
Why brokerless, and why it matters
A central message broker is the classic single point of failure: everything routes through it, so when it saturates or falls over, the whole system does too. dotcommoners projects use a brokerless NNG mesh instead — instances talk to each other directly, with no central node to become a bottleneck. That is how RevenProx is designed to hold 10M+ concurrent connections across 100+ instances, and how Machineuse coordinates browser workers across a fleet.
Why performance-first languages
For the load-bearing parts of a stack, microseconds and memory add up. That is why the performance-critical projects are written in Rust and Zig — predictable, low-overhead, no garbage-collector pauses in the hot path. Where an ergonomic control plane and a rich ecosystem matter more than raw throughput, we reach for Python, as in Machineuse's scheduler and MCP interface.
Every principle points the same direction: give operators software they can run, read, and keep — with no vendor between them and their own infrastructure.
Get involved
These principles are easiest to judge by reading the code. Browse the GitHub organization, read the documentation, or reach the team at contact@dotcommoners.com.