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. Two competitors have similar open-source tools with growing communities.
Open-source under Apache 2.0
Confidence
82%
Risk
unknown
578s
Open-source the deployment tool under Apache 2.0 after a 90-day extraction phase that separates the core...
Decision
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 >30% 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.
Next actions
Run dependency analysis using `go list -m all` and loov/goda to produce import graph and calculate circular dependency percentage against the 30% threshold
Design gRPC-based plugin interface boundary between core engine (~25K lines) and internal integrations (~15K lines) using HashiCorp go-plugin as reference architecture
Based on dependency analysis results, make go/no-go decision on 90-day extraction phase — abort if >30% circular dependencies on internal modules
Set up community infrastructure: GitHub repository, CONTRIBUTING.md, security disclosure process, issue templates, and contributor onboarding documentation
Track GitHub stars, external contributors, and community PRs against 100-star/10-contributor 6-month threshold; trigger passive-maintenance fallback if both missed
This verdict stops being true when
Dependency analysis shows >30% of packages have circular dependencies on internal-only modules → 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.
Legal review identifies that the tool embeds patented algorithms, third-party proprietary SDKs, or trade secrets in the core engine that cannot be extracted → Keep proprietary or release only a subset of non-encumbered modules as standalone libraries rather than the full orchestration engine.
A competitor launches a managed service version of their OSS tool that captures >60% of the addressable market before extraction completes → Pivot to BSL licensing to preserve managed-service monetization rights, accepting reduced community adoption in exchange for commercial protection.
Full council reasoning, attack grid, and flip conditions included with Pro
Council notes
Socrates
Vulcan
Daedalus
Loki
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
Operational signals to watch
reversal — Dependency analysis shows >30% of packages have circular dependencies on internal-only modules
reversal — Legal review identifies that the tool embeds patented algorithms, third-party proprietary SDKs, or trade secrets in the core engine that cannot be extracted
reversal — A competitor launches a managed service version of their OSS tool that captures >60% of the addressable market before extraction completes
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.
Branch battle map
Battle timeline (3 rounds)
Round 1 — Initial positions · 2 branches
Branch b002 (Vulcan) eliminated — b002 is structurally vacuous — it says 'open-source ONL...
Round 2 — Adversarial probes · 2 branches
Branch b001 (Socrates) eliminated — This branch assumes a staged release strategy is viable w...
Loki proposed branch b004
Loki
Both b001 and b003 fixate on partial OSS under Apache 2.0, but overlook HashiCor…
Round 3 — Final convergence · 4 branches
Socrates proposed branch b005
Vulcan proposed branch b006
Socrates
Evaluate open-sourcing with a dual-track licensing strategy: offer a permissivel…
Vulcan
Open-source the deployment tool, but opt for a Business Source License (BSL) ins…