Dosu Logo
Home
Documents
Open Core Implementation Roadmap
Open Core Implementation Roadmap
Type
External
Status
Published
Created
Apr 19, 2026
Updated
Apr 19, 2026
Source
View

Overview#

This document captures the implementation plan for transitioning opnDossier from a single open-source CLI to an open core product with tiered licensing. The core architectural decision is a two-binary model (modeled on GoReleaser's approach): opndossier (Community, open-source) and opndossier-pro (Professional/Enterprise/Gov-IC, source-available). The pro binary defaults to Community behavior without a license and unlocks tier-specific features when a valid license blob is present. Airgap users who only need Community features get a clean binary with zero licensing code or pro dependencies.

Key Architecture Decisions#

Two-binary distribution (GoReleaser model). Each repo produces its own binary via goreleaser:

  • opndossier — Community edition from the open repo. No licensing logic, no pro dependencies. This is what airgap-only users and homelabbers download.
  • opndossier-pro — Professional/Enterprise/Gov-IC edition from the pro repo. Imports the open module as a dependency. Without a license it degrades gracefully to Community behavior. With a valid license it unlocks tier-specific features.
    This means two goreleaser configs, two sets of GHCR images, two sets of deb/rpm/apk packages — but both use the same release tooling and infrastructure patterns. The tradeoff vs. a single binary is worth it: airgap users get a smaller, simpler binary without dead pro code, and the open repo stays completely free of licensing concerns.
    Asymmetric license validation. A public key is embedded in the binary. Licenses are JSON blobs encrypted (signed) with the matching private key. The binary decrypts with the public key and reads enablement values. The private key never leaves EvilBit Labs infrastructure. License blobs can be delivered via email at registration.
    License blob structure (draft):
{
  "license_id": "lic_xxxxxxxx",
  "licensee": "Acme Security Consulting",
  "email": "ops@acmesec.io",
  "tier": "professional",
  "features": ["stig", "topology", "red-blue-reports"],
  "issued_at": "2026-04-01T00:00:00Z",
  "expires_at": "2027-04-01T00:00:00Z",
  "offline": false
}

The features array allows granular control beyond tiers — useful for demo licenses that enable a subset (e.g., STIG only for 14 days) or custom Gov/IC arrangements. Community-tier features (Cybersecurity Best Practices, SANS/NSA) are always available and do not appear in the license blob.
Two-repo model with Go module dependency. The open repo (EvilBit-Labs/opnDossier) is published as a Go module. The pro repo (EvilBit-Labs/opnDossier-pro) imports it as a dependency and registers additional plugins, commands, and compliance checks at compile time. The open repo contains zero licensing logic.
License duration model. Fully licensed tiers (Professional, Enterprise, Gov/IC) are perpetual per major version — buy once, use for the life of that major version. Demo and trial licenses are time-bounded (e.g., 14-day Pro trial). Future option: time-bounded Enterprise licenses bundled with support, but not the initial model. This keeps the value proposition simple for consultants and small shops: pay once, use it until the next major version.

Phase 1: Open Repo Stabilization (v1.3.0)#

Goal: Create the clean extension points that the pro repo needs to import and build on.
Critical path items:

  • CommonDevice abstraction — currently blocking compliance plugins and blue/red team reports per product strategy. This is the gating item for everything downstream.
  • DeviceParser registry (#302) — the interface the pro repo uses to register additional platform parsers (pfSense, Cisco, Fortinet, etc.)
  • Public schemas / CommonDevice as public packages (#301) — the pro repo must be able to import these as a Go module dependency
  • Finding type unification (#280) — currently duplicated across compliance, processor, and audit packages. The pro repo shouldn't have to deal with three different Finding types.
  • Shared analysis package extraction (#321) — eliminates the converter/processor duplication that would otherwise be mirrored in the pro repo
    Nice-to-have (non-blocking):
  • FormatRegistry (#325) — good architecture but the pro repo can work around scattered format routing initially
  • File-splitting refactors (#318-320) — code hygiene, not API surface
  • Performance optimizations (#286-292) — valuable but don't affect the pro repo boundary
    Milestone tag: v1.3.0
    Estimated scope: The 5 critical items above. Everything else stays in the backlog.

Phase 2: Pro Repo Scaffold + Licensing#

Goal: Stand up the pro repository with a working build chain and license validation before writing any features.
Tasks:

  1. Create private repo (EvilBit-Labs/opnDossier-pro or chosen name)
  2. Initialize Go module that imports github.com/EvilBit-Labs/opnDossier as a dependency
  3. Implement the license package:
    • Embed public key at compile time
    • License file discovery (config directory, --license flag, OPNDOSSIER_LICENSE env var)
    • JSON blob decryption and validation
    • Tier and feature flag checking
    • Expiration date enforcement with graceful degradation to Community
    • Demo/trial license support (same mechanism, short expiration)
  4. Implement conditional feature registration:
    • Pro plugins register only if license tier permits
    • Pro CLI commands appear only when licensed
    • Unlicensed binary behaves identically to open-source community build
  5. Set up goreleaser config for opndossier-pro binary
    • Same target platforms as community
    • Same packaging formats (deb/rpm/apk, Docker via GHCR)
    • Binary name: opndossier-pro (distinct from community opndossier)
  6. Generate an Ed25519 or RSA keypair; store private key securely, embed public key in binary
  7. Build a simple license generation CLI tool (internal only) for creating and signing license blobs
    Validation gate: Build opndossier-pro, run it without a license, confirm it behaves identically to opndossier (community). Then create a test license, run it again, confirm gated features appear. Also verify that the community binary from the open repo builds and runs with zero awareness of the pro repo or licensing.

Phase 3: First Pro Features (MVP)#

Goal: Minimum viable Professional tier — enough to sell to the consultancy market.
Feature set for first pro release:

  • pfSense parser (#197) — second platform, in the Phase 1 milestone, high demand from the pfSense community
  • STIG compliance plugin — currently in the open repo (internal/plugins/stig), needs to be moved to the pro repo. The STIG plugin code is removed from the open repo and lives exclusively in the pro repo, registered only when the license permits.
  • SANS/NSA best practice checks — remain in the open repo as a Community-tier feature. This strengthens the free offering (Community ships with both Cybersecurity Best Practices and SANS/NSA) and keeps STIG as the clear differentiator for Professional tier.
  • Structured remediation guidance (#206) — adds concrete fix-it instructions to findings, high value for consultants writing reports
    Deferred to second pro release:
  • Topology mapping (substantial engineering, flagship differentiator but not MVP)
  • Red/blue dual-output reports (depends on topology for full value)
  • Wails desktop app (big effort, separate skill set)
  • Additional platform parsers (Cisco ASA, FortiGate — valuable but pfSense is sufficient for MVP)
    Why this MVP works for year-one revenue: A consultant doing a firewall assessment gets multi-platform parsing (OPNsense + pfSense covers a huge chunk of the SMB market), professional compliance reporting (STIG + SANS), and actionable remediation guidance. That's a tool worth paying for today, without waiting for topology mapping.

Phase 4: Product Website + Sales Infrastructure#

Goal: Make it possible for people to discover, evaluate, and purchase opnDossier Pro.
Website requirements:

  • Landing page: what opnDossier does, the open-source story, why Pro exists
  • Tier comparison: Community vs. Professional vs. Enterprise vs. Gov/IC
  • Pricing page: Professional pricing (annual individual license), Enterprise as "contact us", Gov/IC as "contact us"
  • Download page: Community binary download (open-source, no license needed) and Pro binary download (requires license activation). Clear instructions for both paths.
  • Documentation: hosted mkdocs site (already exists, needs Pro feature docs added)
    Sales infrastructure (minimal viable):
  • Stripe checkout or similar for Professional license purchase
  • License generation triggered on purchase (can be semi-manual initially — webhook triggers license gen CLI, emails blob to customer)
  • Demo license request form (generates 14-day Pro trial blob)
  • Contact form for Enterprise/Gov-IC inquiries (routes to Krystal per product strategy)
    Note: This phase can run in parallel with Phase 3. The website doesn't need pro features to exist yet — it needs to describe them and accept pre-orders or waitlist signups.

Phase 5: First Pro Release#

Goal: Ship it.
Release checklist:

  • Pro binary builds and passes all tests (community + pro test suites)
  • License validation works end-to-end (purchase → generate → email → activate → features unlock)
  • Demo license flow works (request → generate → email → 14-day trial)
  • Product website is live with tier comparison, pricing, and download
  • Documentation covers Pro features and license activation
  • Announcement: GitHub release notes, Reddit posts (r/OPNsense, r/PFSENSE, r/homelab, r/netsec), product blog post

Future Phases (Post-First Release)#

These are captured for planning purposes but are not on the critical path for first revenue.
Pro v2 features:

  • Topology mapping (Mermaid/Graphviz/JSON output)
  • Attack path analysis and trust boundary identification
  • Red/blue dual-output reports
  • Additional platform parsers (Cisco ASA, FortiGate, Palo Alto)
  • PDF report generation (#207)
  • SARIF export for CI/CD integration (#209)
    Enterprise tier:
  • Go/HTMX server deployment
  • Multi-user with shared analysis history
  • Persistent topology history
  • Custom rule authoring engine (#205)
  • API access
  • Compliance cross-reference mapping (PCI-DSS, SOC 2, ISO 27001, NIST)
    CIS Benchmarks integration:
  • Triggered when revenue justifies ~$6K/year CIS SecureSuite Product Vendor Membership
  • Internal check metadata already designed to map to CIS Benchmark IDs (per Option C strategy)
  • Upgrade path: flip feature flag to expose CIS-branded checks once licensed

Resolved Decisions#

  • Pro repo name:EvilBit-Labs/opnDossier-pro (already created)
  • Binary names:opndossier (Community) and opndossier-pro (Pro/Enterprise/Gov-IC) — two distinct binaries
  • Distribution model: Two-binary, modeled on GoReleaser. Airgap users get the clean community binary; pro users get the pro binary which degrades to community without a license.
  • License duration: Perpetual per major version for fully licensed tiers. Time-bounded for demos/trials. Future option for time-bounded Enterprise + support bundles, but not initial model.
  • STIG plugin migration: Move from open repo to pro repo (code removed from internal/plugins/stig in open repo). SANS plugin stays in the open repo as a Community-tier feature.

Remaining Open Questions#

  • Pricing: What's the Professional tier price point? The strategy targets consultancies with procurement challenges — needs to be low enough for a solo consultant's expense account.
  • Demo scope: What does the demo license enable? Full Pro for 14 days? Or a subset (e.g., STIG checks only on a single config)?
  • Major version upgrade path: When v2.0 ships, do v1 license holders get a discount? Grace period? This doesn't need answering now but should be decided before the first major version bump.
Open Core Implementation Roadmap | Dosu