Show HN: Dorkly – Open source feature flags

Original Article ↗ Hacker News Discussion ↗

Role & governance of feature flags

  • Most experiences describe developers owning flag changes.
  • Some see value in empowering non-engineers (product, sales, marketing), e.g., unlocking features per customer.
  • Others argue that “unlocking features” is more like licensing than feature flags, though several note it is the same underlying toggle mechanism.
  • Governance needs vary: some organizations require peer-reviewed PRs; others give on-call engineers broad latitude to flip flags during incidents, with auditing.

Git-based flags vs UI-based systems

  • Pro-Git arguments:
    • Git acts as a database with history, diffs, reviews, and rollback via commit SHAs or git bisect.
    • Separate “flags repo” improves visibility, coordination, and accountability without building custom tooling.
    • Branches allow testing flag states at specific points, and PRs help build consensus for risky changes.
  • Concerns:
    • PR-based control slows emergency responses and removes the “instant toggle” benefit.
    • Non-engineers may struggle with Git workflows and repo permissions.
    • Some prefer a UI with validations, rollout analytics, and emergency overrides, backed by an audit trail (possibly still stored in Git).

Storage & architecture choices

  • Options discussed: separate Git repo, same repo as code, RDBMS, config files + DB, Consul, or dedicated flag services.
  • Debate over GitOps vs RDBMS: Git brings natural history; RDBMS may scale differently and can reuse existing audit frameworks.
  • Some teams avoid RDBMS for control-plane concerns or scale; others see it as sufficient.
  • For Dorkly specifically, multiple servers behind load balancers can provide HA; it relies on LaunchDarkly’s relay in offline mode and can integrate with OpenFeature via LD SDKs.

Use cases, limitations & patterns

  • Effective for UI features, beta opt-ins, staged UI changes for large customers, and gradual rollouts (percent-based).
  • Harder when many services, APIs, schemas, and dependencies must change together; patterns like expand–contract and running old/new side by side are still required.
  • Some feel most businesses can just use an internal admin panel or simple API rather than a third-party flag service.

Tech debt & cleanup

  • Flags accumulate and complicate code.
  • Engineers often want to remove stale flags, but product/priority constraints block this.
  • Suggestions: treat cleanup as part of “done,” integrate into process (e.g., Kanban/WIP thinking), use type-safe or generated code so deprecated flags fail builds, and give new hires cleanup tasks to learn the codebase.

Ecosystem, UX & naming

  • Many alternative open source tools are mentioned (GrowthBook, Unleash, Flagsmith, Flipt, etc.), leading to some fatigue.
  • Some commenters dislike Dorkly’s lack of a dedicated UI (relying on GitHub) and feel the name is hard to advocate for in professional settings, with potential SEO confusion.