open-source-company-strategy

Decides which company assets to open source and which stay proprietary with named owners and commitments.

2|Updated Sep 6, 2026
One-click install
npx skills add https://github.com/samber/developer-relations-skills --skill open-source-company-strategy-samber
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: open-source-company-strategy
Source: https://github.com/samber/developer-relations-skills/tree/main/skills/open-source-company-strategy
Command: npx skills add https://github.com/samber/developer-relations-skills --skill open-source-company-strategy-samber

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Companies debate "should we open source this?" as one question and get it wrong: they open the wrong asset, pick a license instead of a value-capture mechanism, publish with no maintainer, or reverse course later and pay the reputational cost in forks. This Skill turns that debate into an asset-by-asset decision with a named motive, a named decider, and a public non-reversal commitment. ## Core Features & Use Cases - Asset-by-asset verdicts: Inventories SDKs, specs, infrastructure, tooling, and product cores separately, then runs each through five gates (irreversibility, differentiating-vs-context, value capture, contribution viability, ownership) to produce Open, Closed, or Not-yet verdicts. - Candidate line ranking: Presents and ranks interface-open, infrastructure-only, and buyer-tiered open-core boundary options, calibrated to company type (startup, public software company, non-software company) and B2B versus B2C buyers. - Decision rights and commitments: Separates the business call from compliance review, names who decides and who can veto, and drafts a published commitment stating what the company will never close. - Use Case: A Series A founder asks whether to open source the core product before a board meeting. The Skill interviews for motive and constraints, rejects decorative motives like "competitors did it", ranks candidate lines, deletes buyer-tiered open core on the stated irreversibility constraint, and delivers an executive brief with verdicts, owners, annual cost, and a re-evaluation trigger. ## Quick Start Ask the assistant to decide what your company should open source, describing what you sell, the candidate assets, and who can approve the decision.

Frequently Asked Questions about open-source-company-strategy

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide what my company should open source?

Inventory each candidate asset separately rather than asking one yes/no question, then run each through five gates: irreversibility, differentiating versus context, value capture, contribution viability, and ownership. Assets failing irreversibility, value capture, or ownership stay closed regardless of other scores.

What is the difference between open core and source-available licensing?

Open core publishes a genuinely open source core with paid tiers defined by buyer persona, while source-available instruments like BUSL restrict competitive use and are not open source. Source-available answers only the competing-managed-service risk, at the cost of procurement allowlists, distro packaging, and contributors.

Should we open source our product because a competitor did?

No. A competitor's release served a value-capture mechanism you cannot see, so copying the move copies none of the protection. Name your own primary motive first and test whether it survives its own evidence requirement before drawing any line.

Can we open source something now and take it back later?

No. Every released version stays licensed forever, and re-licensing needs every copyright holder's consent for future code while past code remains open. The practical outcome of a reversal is a fork of the last open version plus a public trust cost, as the HashiCorp, Elastic, and Redis cases show.

Why did nobody contribute after we open sourced our project?

The usual cause is an accessibility failure, not a visibility failure: no path to commit rights, no external roadmap input, and unanswered pull requests. Corporate-sponsored projects reliably offer transparency while withholding participation, so fix the contribution path before investing in promotion.

Who should approve open sourcing a company asset?

Split the decision: whoever owns the business case makes the release call, while legal and security run licensing, patent, and privacy review as parallel approvers who can block only on those grounds. An open source program office should not make the strategy call because it lacks the business context.