Docs Plumego and Birdor

Plumego and Birdor

Plumego did not emerge in isolation.

It is part of a broader engineering ecosystem known as Birdor —
a long-term effort to build calm, predictable, and maintainable developer infrastructure.

Understanding Plumego’s relationship with Birdor helps explain why Plumego values certain tradeoffs and why it refuses others.

What Is Birdor (in Engineering Terms)

Birdor is not a single product.

From an engineering perspective, Birdor is a multi-layered developer platform with a consistent set of values:

  • Calm, predictable user experience
  • Minimal but explicit abstractions
  • Strong respect for underlying primitives
  • Long-term maintainability over short-term optimization
  • Clear separation between infrastructure and application logic

Birdor spans multiple domains:

  • Frontend tools and interfaces
  • APIs and backend services
  • Automation and workflow engines
  • Internal platforms and consoles

Plumego exists as the backend service skeleton within this ecosystem.

Why Birdor Needed Plumego

Before Plumego, Birdor services were built using:

  • Direct net/http usage in some places
  • Existing Go frameworks in others
  • Ad-hoc conventions shared informally

Over time, several problems became apparent:

  • Inconsistent service structure
  • Diverging middleware behavior
  • Framework-driven design leaking into business logic
  • Difficulty evolving services without rewriting foundations
  • Increasing cognitive load when switching between projects

These were not failures of Go or existing frameworks.

They were symptoms of missing a stable, shared engineering baseline.

Plumego was created to become that baseline.

Plumego as Birdor’s Backend Skeleton

Within Birdor, Plumego serves a very specific role:

Plumego defines how backend services are shaped — not what they do.

It provides:

  • A consistent request lifecycle
  • A shared mental model across services
  • Clear boundaries between framework and application
  • A predictable structure for long-lived systems

It deliberately avoids owning:

  • Business logic
  • Domain modeling
  • Data access strategy
  • Infrastructure choices

This separation allows Birdor services to:

  • Share structure without sharing constraints
  • Evolve independently while remaining familiar
  • Be maintained by different teams over long periods

Shared Values: Plumego as a Reflection of Birdor Philosophy

Plumego inherits Birdor’s core values almost directly.

Calm Over Clever

Birdor avoids designs that surprise users or maintainers.

Plumego mirrors this by:

  • Avoiding hidden behavior
  • Favoring linear, readable request flow
  • Making execution order explicit

Explicit Over Implicit

Birdor tools emphasize transparency and control.

Plumego applies the same principle to backend systems:

  • No implicit magic
  • No hidden dependencies
  • No silent behavior changes

What the system does is visible in the code.

Longevity Over Novelty

Birdor is designed for systems that last.

Plumego therefore:

  • Avoids experimental patterns
  • Favors proven primitives
  • Resists unnecessary abstraction layers

Stability is treated as a feature.

Why Plumego Is Open, Even Though It Is Opinionated

Plumego is opinionated — but it is not exclusive.

Birdor intentionally open-sources Plumego because:

  • The problems it solves are not unique to Birdor
  • The design philosophy benefits from external scrutiny
  • Long-term systems require shared language, not private frameworks

However, Plumego does not attempt to become a generic “community framework” driven by popularity.

Its evolution is guided by:

  • Real-world usage in Birdor systems
  • Engineering discipline
  • Clear non-goals

Plumego Is Not a Birdor Lock-In Mechanism

Plumego does not encode Birdor-specific assumptions.

It does not:

  • Depend on Birdor services
  • Require Birdor infrastructure
  • Assume Birdor conventions outside its core boundaries

This is intentional.

Plumego must remain usable — and replaceable — independently.

In Birdor’s view, framework lock-in is a form of technical debt, even when self-imposed.

Evolution Philosophy

Plumego evolves slowly.

Changes are evaluated based on:

  • Impact on existing systems
  • Effect on mental models
  • Long-term maintenance cost
  • Alignment with core principles

Breaking changes are treated seriously and introduced cautiously.

This mirrors Birdor’s broader platform philosophy:

Stability is more valuable than velocity at scale.

What This Means for Non-Birdor Users

You do not need to use Birdor to use Plumego.

But by using Plumego, you implicitly adopt a set of values shaped by Birdor’s experience:

  • Respect for underlying systems
  • Preference for clarity over convenience
  • Willingness to trade speed for trust

If those values align with your own, Plumego can serve you well — regardless of context.

Summary

Plumego is:

  • A standalone, minimal Go service framework
  • Shaped by real-world platform engineering needs
  • Designed as Birdor’s long-term backend skeleton
  • Open, but intentionally opinionated
  • Stable, but not stagnant

Its design is not theoretical.

It is the result of building and maintaining systems that are expected to last.

Next

You have now completed the Intro section.

If you are ready to start using Plumego:

→ Getting Started

If you want to understand how Plumego works internally:

→ Concepts

If you are still evaluating:

Revisit Tradeoffs and When Not to Use Plumego.

All paths are valid.