Lean On OSS Standards
Before building custom machinery, reach for the battle-tested open standard that
already solves the problem. Most cross-cutting concerns — how a service emits
telemetry, flips a flag at runtime, types an API, gates CI — have a standard the
ecosystem has already hardened. Adopt it; spend your invention budget on the
domain logic that is actually yours.
The test
For any infrastructure-shaped decision, ask: is there a proven open standard for
this exact concern?
- Yes → adopt it, even if it is slightly heavier than a hand-rolled version
today. You inherit its tooling, docs, integrations, and bug fixes.
- No, but the repo already has a strong local pattern → follow the local
pattern; consistency beats a second standard.
- Genuinely no standard → only then build, and keep the surface small so a
standard can replace it later.
Examples of the standards to reach for
These are illustrations of the discipline, not the point:
- Observability: OpenTelemetry traces, metrics, and structured logs.
- Runtime knobs: OpenFeature or the repository's existing flag client.
- API typing: shared types and typed RPC clients.
- Infrastructure: declarative IaC, package-native charts, GitOps, managed secret
stores, keyless workload identity.
- CI/test policy: ecosystem-native test tools plus required status checks.
Anti-pattern: bespoke reinvention
The smell is a homegrown component that re-implements what a standard already
does — a custom metrics wire format instead of OTel, a hand-rolled flag service
instead of OpenFeature, a one-off secret loader instead of a managed store. It
costs nothing the day you write it and everything later: no ecosystem, no
integrations, and a maintenance burden only you carry. If you find yourself
designing protocol-level plumbing for a solved concern, stop and adopt the
standard.
1---2name: lean-on-oss-standards3description: Use when choosing implementation patterns for observability, runtime configuration, API typing, CI, auth, or infrastructure. Biases toward proven open standards before custom machinery.4---56# Lean On OSS Standards78Before building custom machinery, reach for the battle-tested open standard that9already solves the problem. Most cross-cutting concerns — how a service emits10telemetry, flips a flag at runtime, types an API, gates CI — have a standard the11ecosystem has already hardened. Adopt it; spend your invention budget on the12domain logic that is actually yours.1314## The test1516For any infrastructure-shaped decision, ask: *is there a proven open standard for17this exact concern?*1819- **Yes** → adopt it, even if it is slightly heavier than a hand-rolled version20 today. You inherit its tooling, docs, integrations, and bug fixes.21- **No, but the repo already has a strong local pattern** → follow the local22 pattern; consistency beats a second standard.23- **Genuinely no standard** → only then build, and keep the surface small so a24 standard can replace it later.2526## Examples of the standards to reach for2728These are illustrations of the discipline, not the point:2930- Observability: OpenTelemetry traces, metrics, and structured logs.31- Runtime knobs: OpenFeature or the repository's existing flag client.32- API typing: shared types and typed RPC clients.33- Infrastructure: declarative IaC, package-native charts, GitOps, managed secret34 stores, keyless workload identity.35- CI/test policy: ecosystem-native test tools plus required status checks.3637## Anti-pattern: bespoke reinvention3839The smell is a homegrown component that re-implements what a standard already40does — a custom metrics wire format instead of OTel, a hand-rolled flag service41instead of OpenFeature, a one-off secret loader instead of a managed store. It42costs nothing the day you write it and everything later: no ecosystem, no43integrations, and a maintenance burden only you carry. If you find yourself44designing protocol-level plumbing for a solved concern, stop and adopt the45standard.
selamy-labs