{
  "assumption_density": 0.16666666666666666,
  "assumptions": [
    "The 40K-line Go codebase can be meaningfully separated into a ~25K core engine and ~15K internal integration layer without requiring a ground-up rewrite",
    "Apache 2.0 licensing is appropriate given two competitors already using permissive open-source licenses with growing communities",
    "0.5 FTE is available and sufficient for first-year community management without starving the 3 internal teams of engineering support",
    "The deployment tool solves a sufficiently general problem that external contributors will emerge — it is not so niche that community never materializes",
    "The 3 internal teams can tolerate a 90-day period where the tool undergoes architectural refactoring while remaining functional"
  ],
  "confidence": 0.82,
  "id": "3609b996-d2d2-4612-b1c9-925fd61c7097",
  "next_action": "Run `go list -m all` and loov/goda import graph analysis on the 40K-line codebase to produce a dependency map showing which packages have circular dependencies on internal-only modules, and calculate the percentage against the 30% go/no-go threshold.",
  "question": "Should we open-source our internal deployment tool or keep it proprietary? 2 years of development, 40K lines of Go, used by 3 teams internally.\n  Two competitors have similar open-source tools with growing communities.",
  "question_fit_score": 0,
  "rejected_alternatives": [
    {
      "path": "Business Source License (BSL) instead of Apache 2.0 with simpler modularization",
      "rationale": "b006 proposed BSL to prevent hyperscaler commoditization, which is a valid concern. However, BSL significantly dampens community adoption — contributors are wary of license restrictions, and the two competing tools already use permissive licenses. For a 40K LoC tool trying to catch up to established competitors with growing communities, BSL creates an adoption headwind you cannot afford. The simpler modularization (refactoring into libraries vs. gRPC plugin interface) also underestimates the coupling risk that b003's extraction gate explicitly addresses."
    },
    {
      "path": "Dual-track licensing with enterprise version targeting paying customers",
      "rationale": "b005's dual-track strategy (Apache 2.0 core + commercial enterprise) is architecturally similar to b003 but adds premature monetization complexity. With only 3 internal teams as users and no existing external user base, targeting 3 paying enterprise customers within 18 months is speculative. b003's approach is more disciplined: prove community viability first, then layer monetization. b005's success metrics (500 stars, 50 contributors in 12 months) are also more aggressive than b003's without providing the extraction safeguards."
    },
    {
      "path": "Keep proprietary due to BSL/licensing risk concerns",
      "rationale": "b004 raised a legitimate concern about HashiCorp's 2023 BSL pivot, but this is a cautionary tale for successful OSS projects at massive scale, not a 40K LoC internal tool used by 3 teams. The tool has zero market presence while two competitors are building communities. Staying proprietary means the tool remains a maintenance cost center with no external leverage, and you lose the talent recruitment and ecosystem benefits that competitors are already capturing."
    }
  ],
  "reversal_conditions": [
    {
      "condition": "Dependency analysis shows \u003e30% of packages have circular dependencies on internal-only modules",
      "flips_to": "Keep proprietary — the extraction cost exceeds 6 engineer-months and the codebase is not architecturally ready. Revisit after a dedicated refactoring cycle to decouple internal integrations."
    },
    {
      "condition": "Legal review identifies that the tool embeds patented algorithms, third-party proprietary SDKs, or trade secrets in the core engine that cannot be extracted",
      "flips_to": "Keep proprietary or release only a subset of non-encumbered modules as standalone libraries rather than the full orchestration engine."
    },
    {
      "condition": "A competitor launches a managed service version of their OSS tool that captures \u003e60% of the addressable market before extraction completes",
      "flips_to": "Pivot to BSL licensing to preserve managed-service monetization rights, accepting reduced community adoption in exchange for commercial protection."
    }
  ],
  "unresolved_uncertainty": [
    "Apache 2.0 vs. BSL licensing tradeoff: b004 and b006 raised valid concerns about hyperscaler commoditization risk that b003 does not address. If the tool gains significant traction, the Apache 2.0 choice is irreversible and may require a HashiCorp-style re-licensing controversy later.",
    "The 30% circular dependency threshold and 6 engineer-month cost ceiling are synthetic estimates — no named benchmark or study supports these specific numbers. Actual extraction complexity could be significantly different.",
    "Whether 0.5 FTE is sufficient for community management is untested — comparable projects (e.g., early-stage CNCF tools) often require more investment to reach critical mass.",
    "Competitor response is unmodeled: two competitors with growing communities may accelerate feature development once they see a new entrant, potentially negating the community catch-up strategy."
  ],
  "url": "https://vectorcourt.com/v/3609b996-d2d2-4612-b1c9-925fd61c7097",
  "verdict": "Open-source under Apache 2.0, but ONLY after a 90-day extraction phase separating the core orchestration engine (~25K lines) from internal-specific integrations (~15K lines of auth, service discovery, secrets hooks) via a gRPC-based plugin interface modeled on HashiCorp's go-plugin library. Hard go/no-go gate: run dependency analysis using `go list -m all` and import graph tooling (loov/goda). If \u003e30% of packages have circular dependencies on internal-only modules, STOP — extraction cost will exceed 6 engineer-months and the project isn't architecturally ready. Do NOT publish the raw internal codebase under any circumstances. Post-release viability threshold: 100 GitHub stars and 10 external contributors within 6 months; miss both and reduce to passive maintenance. Allocate 0.5 FTE for community management (issue triage, contributor onboarding, security disclosure process). Key failure mode: extraction balloons to 180+ days due to deep coupling, burning engineering capacity with nothing shipped. Secondary failure: fewer than 50 external contributors at 12 months signals net-negative ROI.",
  "verdict_core": {
    "recommendation": "Open-source the deployment tool under Apache 2.0 after a 90-day extraction phase that separates the core orchestration engine (~25K lines) from internal integrations (~15K lines) using a gRPC-based plugin interface.",
    "mechanism": "Because the open-core pattern (à la HashiCorp go-plugin) lets you gain community contributions on the engine while retaining proprietary operational integrations, and the 90-day extraction gate with a 30% circular-dependency ceiling prevents the irreversible mistake of publishing a tightly-coupled internal codebase.",
    "tradeoffs": [
      "90-day extraction phase delays community benefits and consumes engineering time upfront",
      "Apache 2.0 permits competitors and hyperscalers to fork and offer managed services without revenue share",
      "0.5 FTE ongoing community management cost for at least the first year"
    ],
    "failure_modes": [
      "Extraction takes 180+ days due to deep coupling, burning engineering time with no release",
      "Fewer than 50 external contributors in 12 months means net-negative ROI on community investment",
      "Circular dependencies exceeding 30% of packages indicate the codebase is not architecturally ready for separation"
    ],
    "thresholds": [
      "30% circular dependency ceiling on internal-only modules (go/no-go gate)",
      "6 engineer-months maximum extraction cost before abort",
      "100 GitHub stars and 10 external contributors within 6 months (minimum viability)",
      "0.5 FTE allocated for community management in year one"
    ]
  },
  "verdict_type": ""
}