How we think about open source licensing, releasing open source projects, forks, and contributing upstream.
Arcjet isn’t an open source company - but we believe in open source. We maintain a small number of public projects we use and rely on internally. We also contribute upstream where it makes sense.
Here’s how we think about open source at Arcjet: where we participate, what we maintain, and why we’ve drawn a clear line between SDK and service.
Users of Arcjet interact with two core parts of the product:
How we’ve chosen to license these parts of the product reflects how they’re used. Code you bring into your application is licensed like any other library with minimal restrictions whereas our API is delivered as a service.
A big part of the value is how we maintain the service backed by our IP reputation data, threat intelligence, and real-time analysis engines, but paying customers also fund the development of the SDKs.
Our approach is to open source internal tools or projects that aren’t our core product, might benefit the community in some way, but that we will continue to maintain regardless.
We don’t want to open source something and then abandon it.
I’ve seen too many startups throw repositories open with the hope that “the community” will do the work of maintaining and promoting them. That’s often the last resort of a failing business. Open source is not a business model.
So far we’ve released one project: gravity, a host generator for WebAssembly Components. This was (and still is) something we make heavy use of internally, we think could benefit the community, and we could benefit from others helping to improve it. WebAssembly has had a lot of focus in the Rust and JavaScript communities, but other languages have less developed host support. We needed something for our Go server.
Gravity is still very focused on our own use case, but we've already seen several external contributions and talked to some interesting companies who want to help develop it.
We use open source projects internally, many of which we use directly without modification. Others we’ve forked as the foundation for our own changes which diverged enough from the original that we released them as new projects. We’ll do this if we think the changes are likely to be useful to others - we won’t if the changes are very Arcjet specific.
A good example of this is the well-known-bots directory that we forked from crawler-user-agents and added additional metadata we needed for our bot detection functionality. This included additional URLs for tracking the source as well as categorization and more specific crawler listings. We proposed the changes upstream, but they were rejected so we ended up with a hard fork.
We encourage our team to contribute upstream. Submitting a well written bug report is a good step, but if we can also propose a fix that’s even better. That’s the power of open source and I hope we'll be able to do this more over time.
We also contribute to some projects by sponsoring with money.
Open source isn’t a branding exercise for us - it’s a tool. When we publish something, it’s because we use it, we’ll maintain it, and we think others might benefit. When we fork, it’s because upstream didn’t fit. And when we contribute, it’s because we want the ecosystem to be better.
A huge company like Google has the resources to take a different approach, but that doesn’t mean a growing startup can’t contribute. This is our model.
How do you design a security product for developers when they allegedly don't care about security?
How we implement different layers to secure our developer laptops & environments: Devcontainers, outbound firewall, macOS Transparency Consent and Control framework, and SSH agent for Git keys.
Tips and tools for running a devtools startup remotely in 2025. Document everything. Async workflows. Periodic in-person.
Get the full posts by email every week.
