This document defines the announcement, community, and marketing sequencing for the opnDossier open core transition. Each phase has explicit prerequisites and gates so nothing ships out of order.

Guiding Principles#

• Ship substance before announcements. Never telegraph features that aren't buildable yet.
• Protect open-source credibility. The community edition gets stronger, not weaker, during this transition.
• Let the work speak first. No marketing language until the product backs it up.
• Respect the three audiences differently: homelabbers (free evangelism), consultancies (year-one revenue), gov/IC (inbound only, never solicit).

Phase A: Ship v1.3.0 (Community) — No Pro Mention#

Prerequisites: Phase 1 critical-path issues closed (#280, #301, #302, #321, #279).
What happens:
Release v1.3.0 of the open-source opnDossier with the clean extension points (CommonDevice abstraction, DeviceParser registry, public schemas, unified Finding type, shared analysis package). If the pfSense parser (#197) is ready, include it. If not, it ships in v1.3.1.
What you say:
Standard release notes on GitHub. Emphasize the architectural improvements: cleaner interfaces, public API surface, better extensibility. Frame it as "making opnDossier easier to extend and contribute to." Post to r/OPNsense and r/homelab as a normal release update.
What you do NOT say:
No mention of Pro, commercial plans, licensing, or paid tiers. This release stands on its own merit as a community improvement. The architectural work happens to enable Pro, but the community doesn't need to know that yet.
Why this order matters:
If you announce Pro before shipping v1.3.0, the community will see the architectural refactoring as "they're just doing this to sell us stuff." Ship the improvements first, let people use them, then explain the broader vision.
Gate to Phase B: v1.3.0 is tagged, binaries are published, release notes are posted, and at least one community member has used the new parser interface or public API.

Phase B: Announce Open Core Direction#

Prerequisites: v1.3.0 shipped and stable. Pro repo scaffold is functional (Phase 2 issues at least partially complete — Go module imports open repo, license validation works in testing).
What happens:
Publish a blog post (on the EvilBit Labs site) explaining the open core model. This is the "state of the project" post. Key messages:

1. What's staying free: All parsers (every platform, forever), single-config analysis, security findings, dead rule detection, multi-format export, Cybersecurity Best Practices checks, SANS/NSA checks. The community edition is getting more capable, not less.
2. What's going Pro: STIG compliance, topology mapping, red/blue reports, remediation guidance, desktop app, enterprise server. These are features that cost significant engineering time and serve professional use cases.
3. Why open core: Sustainability. One maintainer (Ken) building tools for a community that needs them. Open core lets the project survive long-term without VC funding, without ads, without selling user data.
4. What happens to existing code: The STIG plugin moves from the open repo to the pro repo. This is the only thing being removed. Everything else stays or gets added to the free tier.
5. Timeline: Honest about where things stand. "Pro is in development. We'll share more when there's something to download."
   Distribution:

• Blog post on evilbitlabs.io (primary source of truth)
• GitHub Discussion in the opnDossier repo (link to blog post, invite questions)
• Reddit posts: r/OPNsense, r/PFSENSE, r/homelab, r/netsec (link to blog post)
• Update the opnDossier README to mention the open core model with a link to the blog post
  Simultaneously:
• Open the opnDossier-pro repo as source-available (read-only public access). This demonstrates transparency and lets people see the code they'd be licensing.
• Add a waitlist/interest form on the product page (the Astro page at /products/opndossier). Simple email capture: "Interested in opnDossier Pro? Leave your email and we'll notify you when it's ready." No pressure, no marketing automation.
  Tone guidance:
  Write this like a fellow practitioner explaining a decision, not like a company announcing a product. No "we're excited to announce" language. More like "here's what we're building and why." The EvilBit Labs brand is practitioner-first — the blog post should read like a thoughtful forum post, not a press release.
  Gate to Phase C: Blog post published, community feedback collected and addressed (at least 1-2 weeks of discussion), no major credibility concerns raised, waitlist has at least some signups.

Phase C: Soft Launch (Demo Licenses + Community Feedback)#

Prerequisites: Phase 3 MVP features are functional (pfSense parser, STIG plugin in pro, structured remediation guidance). Pro binary builds, runs, and degrades correctly without a license. License generation CLI works internally.
What happens:
Offer free 14-day demo licenses to waitlist subscribers and community members who express interest. This is a testing and feedback phase, not a sales push.
Mechanics:

• Email waitlist subscribers: "opnDossier Pro is ready for testing. Reply to this email for a 14-day demo license."
• Generate demo licenses manually using the internal CLI tool
• Collect feedback via GitHub Issues in the pro repo (or a dedicated discussion thread)
  Community touchpoints:
• Post in r/OPNsense, r/PFSENSE, r/netsec: "opnDossier Pro demo is available. Here's what it does, here's how to try it."
• Engage with feedback directly — Ken responding to comments as a fellow practitioner
• If people find bugs or have feature requests, triage them openly
  What you're validating:
• Does the license activation flow work smoothly? (File placement, CLI flag, env var)
• Are the Pro features (STIG, remediation guidance) actually useful to real users?
• Is the community reception positive, neutral, or hostile?
• What questions do people ask that the docs don't answer?
• What's the conversion signal — do demo users want to keep using Pro after 14 days?
  Duration: 2-4 weeks of demo period with active feedback collection.
  Gate to Phase D: Demo feedback is net positive, critical bugs are fixed, license flow works reliably, at least a few demo users indicate they'd pay for Pro.

Phase D: Commercial Launch#

Prerequisites: Phase 4 sales infrastructure is in place (Stripe or equivalent, license generation on purchase, product page with pricing, documentation for Pro features). Phase C feedback is incorporated.
What happens:
Professional tier goes on sale. Enterprise and Gov/IC tiers are "contact us."
Pricing page goes live:

• Professional: $X/year individual license (price TBD, but targeting "expense account" range for solo consultants — probably $99-299/year)
• Enterprise: "Contact us" (routes to Krystal)
• Gov/IC: "Contact us" (inbound only, routes to Krystal, Ken provides technical support)
  Download page goes live:
• Community: direct download, no license needed (link to GitHub releases)
• Professional: download binary, purchase license, activate
  Announcement (bigger push this time):
• Blog post: "opnDossier Pro is available" with pricing, feature breakdown, and link to buy
• GitHub Release: tag the first Pro release with detailed notes
• Reddit: r/OPNsense, r/PFSENSE, r/homelab, r/netsec, r/blueteamsec
• Consider: Hacker News "Show HN" post (opnDossier as a whole, not just Pro — lead with the open-source story)
• Consider: YouTube demo video (screen recording of a real assessment workflow using Pro features)
  Post-launch cadence:
• Monitor sales and support requests for the first month
• Respond to community feedback quickly
• Start planning Pro v2 features (topology mapping, red/blue reports) based on actual customer demand
• Write case studies if early customers are willing (anonymized if needed)

Parallel Tracks (Not Sequenced)#

These activities run alongside the main phases and don't have strict ordering dependencies:
Documentation (ongoing from Phase 2):

• Pro feature documentation in mkdocs (extends existing docs site)
• License activation guide
• Tier comparison page
• Migration guide for STIG users (community → pro transition)
  Product page (Phase B onward):
• The Astro page at /products/opndossier already exists
• Add tier comparison section
• Add waitlist form (Phase B)
• Add pricing and purchase flow (Phase D)
• Add demo request form (Phase C)
  SEO/content (Phase B onward):
• Blog posts about firewall security analysis topics (not product-focused, but establishes expertise)
• "How to audit your OPNsense firewall" style content that naturally leads to opnDossier
• Comparison content: "opnDossier vs. RedSeal" or "affordable alternatives to Tufin" (only after Pro is purchasable)

Risk Scenarios and Responses#

Community backlash about STIG removal: The STIG plugin is the only thing moving from free to paid. Mitigation: emphasize that SANS/NSA checks stay free, Cybersecurity Best Practices stay free, and the STIG move is funding the project's sustainability. If backlash is severe, consider keeping a reduced STIG check set in Community and putting the full STIG suite in Pro.
Zero demo conversions: If nobody wants to pay, the MVP feature set might be wrong. Before cutting price, validate whether the features are useful. It might mean topology mapping needs to ship before Pro is sellable.
Gov/IC interest before Phase D: If a government buyer contacts EvilBit Labs before the commercial launch, handle it manually. Generate a custom license, negotiate terms with Krystal, and use the engagement to validate the Gov/IC workflow. Don't let process prevent revenue.
Competitor launches similar tool: The moat is the open-source parser ecosystem and the practitioner credibility. If a competitor appears, accelerate the community-building aspects (more parsers, better docs, more engagement) rather than racing on features.

Timeline Estimates (Rough)#

These are sequencing estimates, not commitments. Adjust based on actual development velocity.

• Phase A (v1.3.0 release): When critical-path issues are closed. Depends on current development pace in the open repo.
• Phase B (open core announcement): 1-2 weeks after v1.3.0 ships and pro repo scaffold is functional.
• Phase C (soft launch): When MVP features are functional. Could be 4-8 weeks after Phase B depending on STIG migration and remediation guidance work.
• Phase D (commercial launch): 2-4 weeks after Phase C demo period, assuming positive feedback and working sales infrastructure.
  Total estimated time from v1.3.0 to first sale: roughly 2-4 months, depending on development velocity and feedback cycles.

Decision Log#

Decisions that should be made before each phase gate:
Before Phase B:

• Final pricing range for Professional tier (needed for blog post messaging, even if not published yet)
• Demo license scope: full Pro for 14 days, or subset?
• Whether to open-source the pro repo as source-available immediately or wait
  Before Phase C:
• Exact Professional tier price
• Demo license duration and feature scope
• Support expectations for demo users (GitHub Issues only? Email?)
  Before Phase D:
• Payment processor choice (Stripe, Paddle, etc.)
• License generation automation level (fully automated vs. semi-manual)
• Refund/cancellation policy
• Whether to offer annual-only or add monthly option