Skip to content

Latest commit

 

History

History
75 lines (46 loc) · 4.45 KB

File metadata and controls

75 lines (46 loc) · 4.45 KB

Open Source

Open source is not a side project at Zap Tech. It's how we prove we know what we're doing.

Why We Build in the Open

Every tool we maintain solves a problem we actually had.

Rapina exists because we needed a Rust web framework that was secure by default and didn't require a PhD to configure. Every route requires JWT auth unless you explicitly opt out. Convention over configuration. Standardized error responses with trace IDs. A CLI that catches issues before you deploy.

Sheen exists because logging in Rust was ugly. We wanted structured, colorful output with key=value pairs, multiple formatters, and sub-loggers with context. So we built it.

Open source also keeps us honest. When your architecture decisions are public, you make better architecture decisions. When anyone can read your error handling, you write better error handling. The code doesn't lie.

What We Maintain

Rapina

An opinionated Rust web framework built on Axum.

  • Protected by default — all routes require JWT auth unless marked #[public]
  • Convention over configuration — feature-first structure, standardized error responses, versioned routes
  • DI with State<T> extractors, Validated<T> for request validation
  • Rate limiting, compression, cookie extractors
  • CLI: rapina new, rapina routes, rapina doctor
  • OpenAPI generation

Links: GitHub · crates.io · Docs

Sheen

A polished logging library for Rust, inspired by charmbracelet/log.

  • Levels, colors, structured key=value logging, timestamps
  • Multiple formatters: Text, JSON, Logfmt
  • Global logger and sub-loggers with .with() for context
  • Simple initialization: sheen::init(); sheen::info!("started", port = 3000);

Links: GitHub · crates.io

Contributing Upstream

We contribute to the Rust language itself — the compiler, the standard library, the ecosystem tooling. When we hit a rough edge or a gap, we don't just work around it. We fix it for everyone.

Contributing upstream means understanding the language at a level most teams never reach. That depth feeds directly into the quality of the Rust code we ship for clients.

How We Maintain Projects

Open source maintenance is a commitment, not a hobby. Here's how we approach it:

  • Issues get triaged within a week. Not every issue gets fixed immediately, but every issue gets a response. Ignoring contributors is how projects die.
  • PRs get reviewed promptly. If someone takes the time to submit a PR, they deserve a timely review. We either merge it, request changes, or explain why it doesn't fit.
  • Releases follow semver. Breaking changes bump the major version. Period. We don't sneak breaking changes into minor versions.
  • Changelogs are maintained. Every release describes what changed and why. Users shouldn't have to read git logs to understand what's new.
  • CI must pass. No exceptions. If the tests break, the PR doesn't merge — whether it's from us or an external contributor.

Contribution Standards

For external contributors to our projects:

  • Fork, branch, PR. We don't accept pushes to main.
  • Every PR needs tests for new functionality and must not break existing tests.
  • Code must pass cargo clippy and cargo fmt (or the equivalent linters for non-Rust projects).
  • Commit messages should be clear and descriptive. We don't require a specific format, but "fix stuff" isn't going to cut it.
  • If the change is significant, open an issue first to discuss the approach. We'd rather align before you spend time coding.

How OSS Feeds Into Client Work

Our open source work isn't separate from our client work. It's the foundation.

When we build a client's backend with Rapina, we're not handing them an untested framework. We're giving them the same tool we use internally, maintained publicly, with a community of users who've already found and reported edge cases.

When a client project reveals a gap in our tooling, the fix goes upstream. The client gets the fix immediately, and every other user of the library benefits too. This is the cycle: client work finds problems, open source fixes them, everyone benefits.

It also means our tools stay practical. We don't build features nobody asked for. Every capability in Rapina and Sheen exists because a real project needed it.