samber/developer-relations-skillsチェック済み
SKILL DETAIL
open-source-company-strategy
samber/developer-relations-skills/open-source-company-strategy
Decides what a company open-sources and what stays proprietary, names the strategic motive for each side of the line, says who owns the decision, and states what the company commits never to close. Use whenever someone asks "should we open source this?", "what should we open source", "where do we draw the open-core line", "which features stay paid", "who signs off on open sourcing this", or wants a company-level open source strategy rather than a plan for one project - even if they frame it as a licensing question. Produces an asset-by-asset open/closed verdict, a value-capture and irreversibility check, a public non-reversal commitment and a re-evaluation trigger. Not license selection - use samber/developer-relations-skills@oss-license-strategy.
インストール · 425出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill open-source-company-strategy
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "open-source-company-strategy",
"evals": [
{
"id": 1,
"prompt": "I'm the founder of Halyard Systems. We sell one thing: a time-series storage engine, licensed on-prem at $4,200 per core per year, about $6.1M ARR across 38 customers. I want to open source the storage engine itself. The logic is commoditize your complement - if the engine is everywhere and free, demand for the engine goes up and we hold price. Three of my seven engineers have been pushing for this for a year and one of them said he'd look elsewhere if we don't. Two of our direct competitors published their engines last spring. And honestly the engine isn't really the core of what we do anymore, the ops tooling around it is where the work goes. Give me a recommendation.",
"expected_output": "A run that refuses the stated motive because the opened complement and the product whose demand rises are the same asset, rejects the three decorative motives, inventories the assets separately, and does not issue one verdict over the whole codebase.",
"files": [],
"expectations": [
"States that one primary motive must be named and ranked, not averaged across several co-equal motives",
"Rejects 'commoditize your complement' for this asset because the complement being opened and the product whose demand rises are the same thing",
"Names Sun's Java as the counter-example where a company commoditized the wrong complement, the hardware it sold",
"States the evidence test for commoditize-your-complement: name the product whose demand rises and name the complement being opened",
"Rejects 'two competitors did it' as a motive, on the ground that their line served a value capture Halyard cannot see",
"Treats the engineers' desire to open source as retention pressure rather than strategy, and routes it into the talent motive or a sanctioned contribution policy",
"Rejects 'the engine isn't really the core anymore' as a reason to open, noting not-core argues against keeping it closed, not for paying to run it in public",
"Applies the talent motive's evidence test: the asset has to be work an engineer would want to be seen doing",
"Inventories candidate assets separately rather than returning one yes/no verdict over the whole codebase",
"States that the signal for a commoditization motive is growth in the paid product, not adoption of the opened component",
"Asks what would still capture value if the engine were opened, rather than accepting a license as the answer",
"Does not recommend a specific open source license"
]
},
{
"id": 2,
"prompt": "Corvid Metrics here, we do distributed tracing. Our core is Apache-2.0 and has been for four years, roughly 19k stars. Six weeks ago one of the big three cloud providers launched a managed tracing service that is very obviously our codebase with their control plane bolted on. Our self-serve revenue is down 11% quarter over quarter and two enterprise renewals are stalling. Our board wants us to move to BUSL at the next release and our GC thinks AGPL would have prevented this. Which license do we switch to?",
"expected_output": "A run that diagnoses a missing value-capture mechanism rather than a wrong license, writes the adversarial scenario, refuses to call source-available instruments open source, and hands the instrument choice to the license skill.",
"files": [],
"expectations": [
"Diagnoses the underlying problem as a line drawn with no value-capture mechanism, rather than as the wrong license choice",
"States explicitly that no license retrofits a value-capture mechanism",
"Writes an adversarial scenario naming the specific competitor, what they would run as a managed service, and what Corvid Metrics still holds",
"States that if nothing is held, the correct response is to move the asset, not the license",
"Names at least two concrete value-capture mechanisms from hosting and operations, proprietary data, network effects, trademark and brand, support and SLA, certification, a paid tier, or integration with a closed system",
"Rejects 'the license' as a value-capture mechanism because it stops no competitor willing to comply",
"States a license cannot substitute for a trademark, and that the name and logo need their own registration and usage policy",
"Refers to BUSL and similar instruments as 'source-available' and never as 'open source'",
"States that source-available instruments answer the competing-managed-service risk and only that risk",
"Names the costs of going source-available: procurement allowlists, downstream distribution packaging, and contributors",
"Hands the actual license or instrument selection to samber/developer-relations-skills@oss-license-strategy rather than picking one",
"Notes that a relicensing is reversible but the fork it causes is not",
"Does not claim that AGPL would have prevented a cloud provider from operating the software"
]
},
{
"id": 3,
"prompt": "Brantwell Foods, we're a cold-chain logistics company, 2,800 staff, about 40 of them engineers. We built a route-optimisation service internally over five years and it works better than anything we could buy. Our CTO wants to publish it on GitHub, mainly because recruiting engineers to a food logistics company is brutal and he thinks this would change how candidates see us. When I asked who would look after it he said the platform team will maintain it. We'd want it out before the careers-site refresh in Q1. Is this a good move and what do I need to have in place first?",
"expected_output": "A run that fails the ownership gate on the stated answer, calibrates to a non-software company's primitive and authority, and ties the talent motive to signals other than stars.",
"files": [],
"expectations": [
"Rejects 'the platform team will maintain it' as failing the ownership gate",
"Requires a named individual, an hours-per-week figure, a release rhythm and a stated issue-response commitment before the asset ships",
"States that ownership is a veto gate: failing it keeps the asset closed regardless of how well the other gates score",
"Identifies Brantwell Foods as a non-software company and names its boundary primitive as enabler versus differentiator inside the product",
"States that decision authority at a non-software company sits with a governance board spanning engineering, business and legal, rather than with the CTO alone",
"Flags the timescale mismatch: the company plans in roughly three-month spans while maintainers organize around neither quarters nor fiscal years",
"States that dump-and-run publishing turns the talent motive into evidence against the company",
"Applies the talent evidence test: the asset must be work an engineer would want to be seen doing",
"States that the talent motive tolerates a small, well-run project and does not need ecosystem scale",
"Measures the talent motive on candidates citing the project, contributor-to-hire conversions and retention of the maintainers, not on stars or downloads",
"States the success objective must be declared at decision time rather than retrofitted later",
"Names a backup maintainer or an explicit succession arrangement",
"States that the open source program functions must be assigned even when one person carries them part time, rather than left unassigned"
]
},
{
"id": 4,
"prompt": "Nyx Robotics - we build warehouse picking robots, Series C, we sell the robots plus a per-arm software subscription. Our perception stack is the thing customers notice: it's the reason our mis-pick rate is 0.4% against an industry 2%. Inside it there's a sensor-abstraction layer, a point-cloud pipeline, a calibration toolkit, a grasp-planning model and a simulation harness we use for regression. Our head of software wants a verdict: is the perception stack open or closed? Give me the answer.",
"expected_output": "A run that refuses the asset-level framing, splits each asset into differentiating layer and enablers, and recommends actively contributing enablers while the differentiating layer stays closed.",
"files": [],
"expectations": [
"Splits each candidate asset into a differentiating layer and its enablers, and runs the differentiating-or-context gate on each separately",
"States that most decisions happen at that inner split rather than at the asset boundary",
"Recommends actively contributing to the enabling frameworks even while the differentiating layer stays closed",
"Gives the reason: a competing open solution adopted outside the company's control erodes the differentiating edge and forces a costly redesign",
"Cites Sony contributing multimedia frameworks while keeping camera-effect features such as smile recognition closed",
"States that failing the differentiating-or-context gate does not force a closed verdict, but usually means opening a smaller piece or opening later",
"Distinguishes the differentiating-or-context gate from the veto gates of irreversibility, value capture and ownership",
"Produces one row per candidate asset, with each asset appearing exactly once",
"Applies a second read that assigns each asset a dominant objective, naming at least two of the strategic, platform or leverage, products or bottleneck, and standard positions",
"Assigns a dominant objective per asset rather than a single objective covering the whole portfolio",
"Notes that this classification does not capture how fast an artifact drifts from differentiating to commodity, and recommends re-running the evaluation each product planning cycle",
"Does not issue one verdict covering the whole perception stack at once"
]
},
{
"id": 5,
"prompt": "Lindgren Health Data. We sell a clinical-data normalisation platform to hospital groups, around €14M ARR. Our largest account, a Nordic hospital network at €480k a year, raised it in the last QBR: they want our HL7 connector published under an open licence. It's not written into the contract and their renewal is in October regardless. Our account manager says we should just do it because it's goodwill and the connector is 6,000 lines of glue code nobody here enjoys maintaining. Two other customers in the same regulated segment would benefit. Should we ship it open?",
"expected_output": "A run that separates a request from a requirement, tests what refusal costs, and runs the full gate pass regardless, including ownership and value capture.",
"files": [],
"expectations": [
"Distinguishes a customer asking from a customer conditioning a renewal on it, and asks what happens if the company refuses",
"States that if refusal costs nothing, the real motive lies among the internally chosen motives rather than external demand pull",
"Treats external demand pull as a first-class motive rather than an excuse, when the requirement is genuine",
"Cites the finding that customer demand pull is the initial trigger for selective revealing far more often than internal deliberation",
"States that a customer requirement is a trigger, not a verdict",
"Runs the full gate pass anyway, explicitly including value capture and ownership",
"Names the specific failure mode: a repository opened to close a deal and then abandoned becomes the same customer's complaint months later",
"Asks whether the other parties subject to the same requirement would co-maintain or carry a share of the maintenance",
"Names the party imposing the requirement and the stated consequence of refusal in writing",
"Declares a success objective for the connector at decision time",
"Rejects 'nobody here enjoys maintaining it' as sufficient justification for opening it",
"Requires a named maintainer with an hours-per-week figure if the connector is opened",
"Does not answer with a license recommendation"
]
},
{
"id": 6,
"prompt": "Tessellate Analytics. We open sourced our Python SDK 14 months ago under Apache-2.0. It has 900 stars and about 3,000 weekly downloads, so people clearly use it. But we have had exactly zero external pull requests merged. Median time to first response on an outside issue is 19 days. The roadmap lives in our internal tracker. Nobody outside the company has commit rights and we have never discussed giving any out. I want a plan to get contributors - I'm thinking a blog post series, a Discord, maybe sponsoring a podcast. What would you do?",
"expected_output": "A run that diagnoses an accessibility failure rather than a visibility failure, and prescribes commit path, roadmap input and answered pull requests instead of promotion.",
"files": [],
"expectations": [
"Diagnoses an accessibility failure rather than a visibility, awareness or promotion failure",
"Distinguishes transparency, meaning visibility into what is happening, from accessibility, meaning the ability to participate",
"Cites the finding that corporate-sponsored projects are far readier to offer transparency than accessibility",
"States that a public repository with no route to commit rights, no roadmap input and no answered pull requests fails the contribution-viability gate",
"Recommends concrete accessibility changes: a published path to commit rights, external roadmap input, and answered pull requests",
"States that code failing this gate is published rather than open source, and cannot claim the shared-maintenance return",
"States that this gate is a standing check rather than a one-time pass, and that contributors are lost when governance direction turns ambiguous",
"Notes that external participants take on leadership roles only once a structured, collectively determined process replaces single-sponsor control",
"Declines to treat the star count or download count as evidence the decision succeeded",
"Does not make a blog series, Discord or podcast sponsorship the primary fix",
"Requires a named owner with hours per week and a stated issue-response commitment",
"States that most published repositories never receive an external contribution, so expecting free contributors is the motive that fails most often"
]
},
{
"id": 7,
"prompt": "Ferro Queue, Series A, $3.1M raised. We make a message broker sold to platform engineers - they self-serve, they try it in a sandbox, they expense it later. Right now nothing is public. Our board meets on the 30th, three weeks out, and my investors want a decision on open source by then. My CTO's position, which I share, is that we have very little appetite for anything we cannot undo - if this goes wrong in a year we need to be able to walk it back. This is a one-off call about the broker, we're not writing policy for everything we ever build. What line do we draw?",
"expected_output": "A run that enters brainstorming mode, presents and ranks candidate lines, deletes the buyer-tiered line on the stated irreversibility constraint, and says which interview answer moved which candidate.",
"files": [],
"expectations": [
"Presents 2 or 3 candidate lines rather than a single recommendation",
"Ranks the candidate lines explicitly rather than listing them flat",
"Names the candidate lines as interface-open, infrastructure-only and buyer-tiered open core",
"Enters an explicit brainstorming mode and says so before proposing any verdict",
"Deletes buyer-tiered open core outright because of the stated low appetite for irreversibility, rather than ranking it last",
"States which interview answer moved which candidate line",
"Promotes interface-open on the basis of the hard board date, because it is the line needing no tiering matrix and no executive sign-off",
"States that a one-off decision rather than an inherited policy removes the argument that would have promoted buyer-tiered",
"Gives each surviving line what it opens, what captures value, its cost per year, the risk it accepts and the motive it serves",
"States that interface-open and infrastructure-only genuinely tie on irreversibility because neither publishes anything the company sells",
"Raises the strongest argument against drawing a line at all, that the value sits in the totality of the product rather than a proprietary sliver, and answers what the closed part captures that the totality does not",
"States a recommendation and lets the user choose before detailing the chosen line further",
"Describes each line's effort as an order of magnitude, such as a week per repository or a standing job, rather than as a currency amount"
]
},
{
"id": 8,
"prompt": "Ostrava Mobility, we're a listed fleet-telematics company, about 4,000 people, 600 engineers across six business units. We stood up an open source programme office last year - two people plus a part-time attorney. Business units keep asking to publish things and every request turns into a three-week negotiation. My proposal to the exec team is to make the OSPO the single approver for what we open source, so there's one consistent answer. Write me the decision-rights model.",
"expected_output": "A run that refuses to give the program office the business call, splits it from compliance review, and specifies escalation, default posture and auditability.",
"files": [],
"expectations": [
"Separates the business-context call of whether to open something from the specialist review of whether it is compliant to open",
"Assigns the business call to whoever owns the business case, such as the proposing team's manager or director, rather than to the open source program office",
"Gives the stated reason that the open source program office frequently lacks the business context to make that call",
"Runs licensing, patent and privacy review as parallel approvers that can block only on those grounds",
"Names an escalation path for larger launches, to a director or VP",
"States the default posture is to approve unless there is a good reason not to",
"Requires the decision to be recorded so it is auditable afterwards",
"Names the model in which large tiering decisions route through a published matrix with the CEO as final decider",
"Names the classification of contributions as trivial, medium or major, with trivial needing only the relevant business manager",
"Recommends frame agreements pre-authorizing contribution to ecosystems already judged non-competitive so routine cases never reach the board",
"Writes down who plays each part even where two parts are the same person",
"States that the open source program office should not make the strategy call at any company size",
"Rejects a decision-rights statement that has no split between business and compliance, no escalation path and no stated default posture"
]
},
{
"id": 9,
"prompt": "Solvent Labs - we run an open-core workflow engine, MIT core, paid enterprise tier. Two things landing next quarter. First, we're moving audit-log export and SSO out of the community edition into the paid tier; both have been in the open edition for about two years but the enterprise buyers are the only ones who care and we're leaving money on the table. Second, we're renaming the main repo from solventlabs/solvent to solventflow/solventflow because the new brand launches the same week - no licence change, no code removed, purely cosmetic. Anything we should watch out for?",
"expected_output": "A run that flags the feature move as the reputational event, warns that the rename carries reversal cost on its own, and produces a published non-reversal commitment with named accountability.",
"files": [],
"expectations": [
"Identifies moving already-open features into a paid tier as the reputational event",
"States that adding new features above the line is not the reputational event, distinguishing it from moving existing ones down",
"Cites the 2017 rename of docker/docker to moby/moby as evidence that governance surprise is priced on its own",
"Notes that in that case no license changed and no code was withdrawn, and the backlash was still severe",
"Warns that the rename alone carries reversal cost even though nothing is being taken away",
"Recommends announcing any boundary change before it lands, with the reasoning and the effective version",
"Proposes a published non-reversal commitment including never moving an already-open feature into a paid tier",
"Names at least two further commitments from: no artificial limits on repositories, users, size or throughput; no re-licensing away from an OSI-approved license; shipping tests alongside open features; pre-announcing boundary changes",
"Pairs each promise with the role that has standing to break it",
"Rejects a commitment phrased so loosely that nothing could violate it",
"States that hiding where the line sits is the credibility failure, not having a line",
"Names an exception path with a single named approver and a pre-release announcement",
"States that fork speed is the real cost signal, with forks appearing within days in the documented reversal cases"
]
},
{
"id": 10,
"prompt": "I'm VP Engineering at Pelago, a consumer travel app - 30 million installs, we make money on booking commission and a €6.99/month subscription. Our recommendation engine is the best thing we've built; it's why our conversion beats the big OTAs. I want to open source it. The pitch to our CEO is credibility in the developer world plus free contributors improving the ranking quality. He's asked me to come back with how we'd know it worked. What's the case and what's the metric?",
"expected_output": "A run that states the B2C case, refuses to open the consumer-facing differentiator, redirects to realistic consumer-company motives, and sets an objective at decision time.",
"files": [],
"expectations": [
"States explicitly that this is a B2C case rather than leaving the buyer implicit",
"States that consumer companies open source, but almost never the consumer product itself",
"Names the B2C moat as data, network effects and brand, none of which the code carries",
"Redirects to realistic consumer-company motives: talent, trust, and cost sharing on infrastructure the company already runs",
"States the decision should be judged on hiring and reputation signals, never on adoption of the opened component",
"Rejects free contributors as a motive, noting most published repositories never receive an external contribution",
"Runs the value-capture gate on the recommendation engine and identifies the proprietary data and network effects as the question it turns on",
"Recommends an infrastructure component the company already runs as a better candidate than the consumer-facing recommendation engine",
"Declares the success objective per asset at decision time rather than retrofitting one later",
"States that no widely adopted framework exists for judging whether one specific open-sourcing decision succeeded",
"Notes that community-health metric vocabularies measure health, not strategic return",
"Does not propose stars or downloads as the success metric"
]
},
{
"id": 11,
"prompt": "Kestrel Grid, we do grid-balancing software for utilities, 90 engineers, private equity owned. We're taking an open source strategy to the board in six weeks and my CFO wants one number: what does this cost us annually. We plan to publish three repos, join one industry foundation, and we already consume a lot of open source with no formal policy - engineers just pull what they need. We also carry around 40 patches against an upstream scheduler project that we rebase every release. Give me the budget and the operating model.",
"expected_output": "A run that puts maintainer time first, treats the published foundation-membership band as an order of magnitude, makes upstream-first a default, and warns about circumvented inbound policy.",
"files": [],
"expectations": [
"Names maintainer time as the dominant cost line and the one usually left out of the budget",
"Breaks maintainer time down into review, releases, issue and pull-request response, and security-report handling",
"Lists further cost lines including legal review at release, inbound audit tooling, training, foundation memberships, community presence and security response",
"Treats the published foundation-membership band of roughly $5,000 to $250,000 or more per year as an order of magnitude",
"Directs the company to check the target foundation's current fee schedule before putting a number in the budget",
"Does not state a single precise membership figure as though it were current and authoritative",
"States the annual total in the brief, inside a budget someone has agreed to",
"Makes upstream-first a stated engineering default with a documented exception path",
"Gives the upstream-first reason: a private patch is re-paid at every upgrade while an upstreamed patch is maintained by the project",
"States that skipping upstream-first invalidates the maintenance motive that justified the strategy",
"Warns that rigid inbound policies get circumvented, and that circumvention is where the security exposure appears",
"Assigns all the program functions even if one person carries them part time, rather than leaving any unassigned",
"Ranks engagement depth by return per engineer-hour, leading with contributing fixes upstream, and does not count plain consumption as a rung"
]
},
{
"id": 12,
"prompt": "Auburn Ledger, fintech infrastructure, Series B, $9M ARR. I need verdicts on six things: our Java SDK, our ISO 20022 message schema, our ledger reconciliation engine, our internal chaos-testing harness, our fraud-scoring model, and our conformance test suite. My CTO's framing on the reconciliation engine is that we should just put it out and see what happens - if it doesn't help adoption in a year we pull it back in and go proprietary again. Structure the whole thing for me as a document I can take to our exec team.",
"expected_output": "A run that refuses the reversible-experiment framing, converts that asset to a Not yet verdict with a named flip condition, and produces the brief section by section with a re-evaluation trigger.",
"files": [],
"expectations": [
"Rejects the framing of the release as a reversible experiment",
"States that every released version stays licensed forever",
"States that re-licensing later needs every copyright holder's consent for future code and cannot touch code already released",
"Describes the practical outcome of a reversal as a fork of the last open version plus a public trust cost",
"Gives the reconciliation engine a 'Not yet' verdict rather than Open or Closed, because the decision changes under permanence",
"Names the specific event that would flip that 'Not yet' verdict",
"Places every one of the six candidate assets exactly once across Open, Closed and Not yet",
"Produces a brief whose sections cover what the company sells, the motive, open assets, closed assets, not-yet assets, the competitive case, decision rights, commitments, the operating model and measurement",
"Presents one section at a time and seeks agreement before writing the next",
"Gives the reason for validating section by section: a wrong motive propagates into every row below it and is cheaper to catch early",
"Names a re-evaluation trigger consisting of the next planning cycle plus events forcing an early re-read",
"Lists at least three such events from: a competitor's managed service, an acquisition, a funding round, a fork, the maintainer leaving",
"Names supply-side reversal, where a contributor withdraws components they maintained, as a residual risk no boundary framework covers"
]
},
{
"id": 13,
"prompt": "Wharfline - self-hosted CI product, open core since 2021. Right now we decide tier placement feature by feature in roadmap planning and it's a fight every quarter. Two proposals on the table. One: cap the open edition at 25 users and everything above that is commercial, which is clean to enforce and matches where our money comes from. Two: keep doing it case by case but write down the criteria. Separately our marketing site describes our enterprise repo, which is under our own source-available licence, as 'open source' - our head of marketing says everyone does this. Which boundary rule should we adopt?",
"expected_output": "A run that ranks the boundary shapes, rejects the user cap as both a weak rule and an artificial limit, and flags the marketing claim as open-washing.",
"files": [],
"expectations": [
"Ranks the boundary shapes with buyer-tiered ahead of scale-tiered ahead of feature-by-feature judgment",
"States that durability per quarter of upkeep is the ranking axis because all three shapes cost about the same to adopt",
"Recommends a buyer-tiered rule and gives the reason that 'whose problem is this?' has a stable answer while 'how valuable is this?' does not",
"Warns that a scale-tiered rule prices out exactly the large community deployments that generate contributors",
"States that feature-by-feature judgment is the least durable shape because it re-litigates the line every quarter and invites taking features back",
"Flags a 25-user cap on the open edition as an artificial limit the company should instead commit never to add",
"Describes the buyer-tiered rule as a persona test rather than an asset test: who cares most about a feature",
"Notes that under the buyer-persona model every proprietary feature still has an individual contributor who wants it, just not enough to be the buyer",
"Flags describing a source-available repository as 'open source' as open-washing",
"States that the audience the claim was meant to attract is the audience that notices first",
"Requires publishing where the line sits",
"Cites the published re-audit that moved eighteen features across seven lifecycle stages into the open tier as evidence the model is a live process rather than a manifesto",
"Notes that the same published model carries acceptance criteria for the reverse case, a community contribution opening an existing paid feature"
]
}
],
"trigger_queries": [
{ "query": "Should we open source our agent SDK?", "should_trigger": true },
{ "query": "We're a Series A observability startup - what should we open source and what stays closed?", "should_trigger": true },
{ "query": "Draw our open-core line for me", "should_trigger": true },
{ "query": "which features go in the paid tier and which stay in the community edition", "should_trigger": true },
{ "query": "Who should sign off on open sourcing our internal deploy tool?", "should_trigger": true },
{ "query": "I need a company-level open source strategy, not a plan for one repo", "should_trigger": true },
{ "query": "our biggest customer wants the connector open sourced before they renew - do we do it?", "should_trigger": true },
{ "query": "A hyperscaler just launched a managed version of our project. What do we do?", "should_trigger": true },
{ "query": "where do we draw the line between the free and paid parts of the product", "should_trigger": true },
{ "query": "Can we publish part of the codebase and keep the rest proprietary?", "should_trigger": true },
{ "query": "my cofounder wants to open source everything and I think that's insane, help us decide", "should_trigger": true },
{ "query": "What should a 12-person infra startup publish under an open licence?", "should_trigger": true },
{ "query": "We want to open source our internal tooling. Is that a good idea?", "should_trigger": true },
{ "query": "Should the query engine be open or does that kill our business?", "should_trigger": true },
{ "query": "help me decide what to publish and what to keep", "should_trigger": true },
{ "query": "how much of our codebase should be open", "should_trigger": true },
{ "query": "is open sourcing our SDK going to cost us revenue", "should_trigger": true },
{ "query": "we keep arguing about whether to open source the core - settle it", "should_trigger": true },
{ "query": "what do we commit to never putting behind a paywall", "should_trigger": true },
{ "query": "we want to publish a promise about what stays free forever", "should_trigger": true },
{ "query": "The board wants a recommendation on open sourcing by Thursday", "should_trigger": true },
{ "query": "our CTO says we can always close it again later if it doesn't work out", "should_trigger": true },
{ "query": "should our OSPO decide what we open source?", "should_trigger": true },
{ "query": "who owns the decision to publish code written by an internal team", "should_trigger": true },
{ "query": "we open sourced a library 14 months ago and nobody contributes", "should_trigger": true },
{ "query": "our repo has 900 stars and zero outside pull requests - what went wrong", "should_trigger": true },
{ "query": "Is there a framework for deciding what a company open sources?", "should_trigger": true },
{ "query": "We sell hardware. Would publishing the firmware toolchain help us?", "should_trigger": true },
{ "query": "should a consumer app company open source anything at all", "should_trigger": true },
{ "query": "what parts of our product could we publish without losing the moat", "should_trigger": true },
{ "query": "we want to move two free features into the enterprise tier next quarter", "should_trigger": true },
{ "query": "can we take an already-free feature back and put it behind a licence", "should_trigger": true },
{ "query": "planning to rename our main repo and org - any risk with the community?", "should_trigger": true },
{ "query": "how do other companies decide the open/closed boundary", "should_trigger": true },
{ "query": "I'm writing an open source strategy doc for the exec team", "should_trigger": true },
{ "query": "what does running an open source programme cost a 90-engineer company", "should_trigger": true },
{ "query": "we need to justify the open source budget to the CFO", "should_trigger": true },
{ "query": "should we contribute our patches to the framework we depend on or keep them private", "should_trigger": true },
{ "query": "our competitor open sourced their agent. Should we match them?", "should_trigger": true },
{ "query": "does giving away our code actually help us hire?", "should_trigger": true },
{ "query": "we want to publish something for recruiting reasons - which project", "should_trigger": true },
{ "query": "a regulator is asking us to make the scoring algorithm auditable", "should_trigger": true },
{ "query": "a partner wants the spec published so they can implement against it", "should_trigger": true },
{ "query": "should we publish the wire protocol or keep it private", "should_trigger": true },
{ "query": "open or closed for our new data connector?", "should_trigger": true },
{ "query": "how do we stop a cloud provider reselling our software as a service", "should_trigger": true },
{ "query": "is AGPL enough to protect us from AWS running our thing", "should_trigger": true },
{ "query": "we're thinking about BUSL - talk me out of it or into it", "should_trigger": true },
{ "query": "what actually stops someone forking us and selling it", "should_trigger": true },
{ "query": "what do we still hold if a competitor runs our code as a service", "should_trigger": true },
{ "query": "put together an asset by asset verdict on what we publish", "should_trigger": true },
{ "query": "should the conformance test suite be part of the open release", "should_trigger": true },
{ "query": "we have six candidate repos and no idea which to publish", "should_trigger": true },
{ "query": "is it worth publishing something nobody is ever going to contribute to", "should_trigger": true },
{ "query": "our engineers want to release a side project they built on company time", "should_trigger": true },
{ "query": "how do we tell whether open sourcing the SDK actually worked", "should_trigger": true },
{ "query": "what should we measure after we publish a component", "should_trigger": true },
{ "query": "we opened the code and revenue didn't move - what now", "should_trigger": true },
{ "query": "do we need a policy for future decisions like this or is this just one call", "should_trigger": true },
{ "query": "establish a repeatable rule for what we publish going forward", "should_trigger": true },
{ "query": "we're a bank - can we release our internal risk library publicly", "should_trigger": true },
{ "query": "a logistics company wanting to publish its route optimisation code, thoughts?", "should_trigger": true },
{ "query": "what's the strategic reason for a company to give away software", "should_trigger": true },
{ "query": "why would a profitable company publish its source at all", "should_trigger": true },
{ "query": "our VP says open source is a distribution strategy - is that right for us", "should_trigger": true },
{ "query": "help me pick between opening the SDK, the spec, or the whole core", "should_trigger": true },
{ "query": "we want the developer community but not to lose the enterprise revenue", "should_trigger": true },
{ "query": "which of our components are safe to publish?", "should_trigger": true },
{ "query": "is our connector a differentiator or just plumbing", "should_trigger": true },
{ "query": "how do I know if a component is core or context for us", "should_trigger": true },
{ "query": "we're pre-seed - does publishing now hurt us later", "should_trigger": true },
{ "query": "thinking about releasing our internal feature flag system", "should_trigger": true },
{ "query": "our customer's procurement team requires an OSI-approved licence - what do we publish", "should_trigger": true },
{ "query": "should self-hosting be allowed but a managed competitor not", "should_trigger": true },
{ "query": "can we let people run it themselves but block competing SaaS on top of it", "should_trigger": true },
{ "query": "MIT or Apache-2.0 for our new Go library?", "should_trigger": false },
{ "query": "Do we need a CLA or is a DCO sign-off enough?", "should_trigger": false },
{ "query": "How do I relicense an existing project from BSD to AGPL?", "should_trigger": false },
{ "query": "Which SPDX identifier goes in the LICENSE file?", "should_trigger": false },
{ "query": "Is GPL-3.0 compatible with the dependencies we already ship?", "should_trigger": false },
{ "query": "Write me a NOTICE file for our Apache-2.0 release", "should_trigger": false },
{ "query": "What's the difference between the SSPL and the Elastic License text?", "should_trigger": false },
{ "query": "Do contributors need to sign anything before I merge their PR?", "should_trigger": false },
{ "query": "Our dependency is LGPL - does that affect how we ship our binary?", "should_trigger": false },
{ "query": "Draft the CLA text for our project", "should_trigger": false },
{ "query": "Write a GOVERNANCE.md for our project", "should_trigger": false },
{ "query": "How do I promote a contributor to maintainer?", "should_trigger": false },
{ "query": "Our project has a bus factor of one - how do we fix succession?", "should_trigger": false },
{ "query": "Two maintainers are deadlocked on a decision, what's the escalation rule?", "should_trigger": false },
{ "query": "Should we donate the project to a foundation like the CNCF?", "should_trigger": false },
{ "query": "How do maintainer voting rules usually work?", "should_trigger": false },
{ "query": "We need to remove an inactive maintainer - what's the process?", "should_trigger": false },
{ "query": "What does a technical steering committee actually do day to day?", "should_trigger": false },
{ "query": "We're pushing the repo public on Tuesday - what's the launch plan?", "should_trigger": false },
{ "query": "How do I get onto GitHub Trending?", "should_trigger": false },
{ "query": "Writing a Show HN post for our new CLI tool", "should_trigger": false },
{ "query": "Our launch fell flat, what should we have done differently?", "should_trigger": false },
{ "query": "Plan a launch week for our open source release", "should_trigger": false },
{ "query": "How many stars should a launch realistically get?", "should_trigger": false },
{ "query": "Which awesome lists should we get our library added to?", "should_trigger": false },
{ "query": "Adoption flattened six months after launch - how do we get found again?", "should_trigger": false },
{ "query": "How often should we cut releases just for visibility?", "should_trigger": false },
{ "query": "Should we get packaged in Homebrew and apt?", "should_trigger": false },
{ "query": "Optimise our npm package metadata for discovery", "should_trigger": false },
{ "query": "Should we run open core or a managed cloud to make money?", "should_trigger": false },
{ "query": "What's the right business model for a developer tool?", "should_trigger": false },
{ "query": "Per-seat or consumption pricing for our API product?", "should_trigger": false },
{ "query": "Where should our free tier limits sit - requests, seats or projects?", "should_trigger": false },
{ "query": "How do we raise prices without a backlash?", "should_trigger": false },
{ "query": "Our adoption is high and revenue is flat - fix our monetization", "should_trigger": false },
{ "query": "Design the tier ladder up to enterprise for our dev tool", "should_trigger": false },
{ "query": "What should we charge for the hosted version?", "should_trigger": false },
{ "query": "Should we take our spec to the IETF or keep it on GitHub?", "should_trigger": false },
{ "query": "A competitor published a rival protocol - do we join their spec or compete?", "should_trigger": false },
{ "query": "What patent licensing mode should a consortium spec use?", "should_trigger": false },
{ "query": "How do we run a conformance certification programme for our protocol?", "should_trigger": false },
{ "query": "Which open source maintainers should our company sponsor?", "should_trigger": false },
{ "query": "How much should we budget for funding the dependencies we rely on?", "should_trigger": false },
{ "query": "Set up an employee-nominated FOSS fund", "should_trigger": false },
{ "query": "I maintain a popular library - how do I get companies to sponsor me?", "should_trigger": false },
{ "query": "What tiers should I put on my GitHub Sponsors page?", "should_trigger": false },
{ "query": "Should our product open extension points for third-party apps?", "should_trigger": false },
{ "query": "Nobody builds on our public API - why?", "should_trigger": false },
{ "query": "Should partners build the integrations or should we build them ourselves?", "should_trigger": false },
{ "query": "Our issue backlog is 400 deep - how do we triage it?", "should_trigger": false },
{ "query": "Write a CONTRIBUTING.md that gets first-time contributors to a merged PR", "should_trigger": false },
{ "query": "How should we label good first issues?", "should_trigger": false },
{ "query": "What's a reasonable stale-issue bot policy?", "should_trigger": false },
{ "query": "Rewrite our README so people understand what the project does", "should_trigger": false },
{ "query": "Optimise my GitHub profile page", "should_trigger": false },
{ "query": "Our docs information architecture is a mess - audit it", "should_trigger": false },
{ "query": "Write the quickstart page for our SDK", "should_trigger": false },
{ "query": "Turn these 60 commits into release notes", "should_trigger": false },
{ "query": "Write the v3 upgrade guide covering the breaking changes", "should_trigger": false },
{ "query": "Should I publish our MRR publicly every month?", "should_trigger": false },
{ "query": "Start a weekly devlog for our project", "should_trigger": false },
{ "query": "Draft an engineering blog post about our storage rewrite", "should_trigger": false },
{ "query": "How many DevRel people should we hire this year?", "should_trigger": false },
{ "query": "What metrics should our developer relations team report to the exec team?", "should_trigger": false },
{ "query": "Build a developer relations strategy for next year", "should_trigger": false },
{ "query": "Should we sponsor KubeCon or run our own event?", "should_trigger": false },
{ "query": "Write a CFP abstract for a conference talk", "should_trigger": false },
{ "query": "How do we make our engineering brand attractive to senior candidates?", "should_trigger": false },
{ "query": "Set up an open source compliance scanner in our CI pipeline", "should_trigger": false },
{ "query": "Generate an SBOM for our release artifacts", "should_trigger": false },
{ "query": "Audit our dependency tree for licence violations", "should_trigger": false },
{ "query": "Find open source alternatives to the SaaS tools we currently pay for", "should_trigger": false },
{ "query": "How do I contribute my first patch to an open source project?", "should_trigger": false },
{ "query": "Review this open source project before we adopt it as a dependency", "should_trigger": false },
{ "query": "Explain what the OSI open source definition actually requires", "should_trigger": false }
]
}
references/boundary-tests.md›
# Drawing and defending the open/closed line
Contents: the five gates · the CAP quadrants · the asset scoring table · open-core boundary shapes · a worked brief · weak vs strong rows.
## Table of Contents
- [The five gates, in order](#the-five-gates-in-order)
- [The CAP quadrants - a second read on the same assets](#the-cap-quadrants-a-second-read-on-the-same-assets)
- [The asset scoring table](#the-asset-scoring-table)
- [Open-core boundary shapes](#open-core-boundary-shapes)
- [A worked brief (fragment)](#a-worked-brief-fragment)
- [What we sell](#what-we-sell)
- [Motive](#motive)
- [Open](#open)
- [Competitive case](#competitive-case)
- [Weak vs strong rows](#weak-vs-strong-rows)
## The five gates, in order
Apply them in this order. Gates 1, 3 and 5 are vetoes: failing any of them keeps the asset closed no matter how well it scores elsewhere.
### Gate 1 - Irreversibility (veto)
Every released version stays licensed forever. Re-licensing later needs every copyright holder's consent for future code and cannot touch past code, so the practical outcome of a reversal is a fork of the last open version plus a public trust cost.
Ask: if this can never be closed again, does the decision change? A "yes" is not a failure - it is the discovery that the honest verdict is **Not yet**, with a written condition that would change it.
### Gate 2 - Differentiating or context
Riehle's split: generic components move outward to shared maintenance, differentiating assets stay in-house. In his distributor example the code is open while the test suites, configuration databases and compatibility matrices - what customers actually pay for - stay closed. Moore's core-versus-context is the same cut in general-management vocabulary.
Ask: does the company win deals _because of_ this asset, or does it merely need the asset to exist? Losing this gate does not force a closed verdict; it usually means opening a smaller piece, or opening it later.
**Run this gate twice per asset - once on the differentiating layer, once on its enablers.** Linåker et al. argue enabling frameworks must be actively contributed even when the differentiating layer stays closed, because a competing open solution adopted outside the firm's control erodes the differentiating edge and forces a costly redesign (Sony's media frameworks vs. its camera effects, step 1). Treating "the asset" as the unit hides exactly this decision.
### Gate 3 - Value capture (veto)
Name the mechanism that still stops a competent competitor from taking the opened asset and reselling it: hosting and operations · proprietary data · network effects · trademark and brand · support and SLA · certification · a paid tier · integration with a closed system.
"The license" is not a mechanism. It cannot stop a competitor willing to comply, and it cannot substitute for a trademark - the name and logo are what stop a fork calling itself your product, and they need their own registration and usage policy.
Henry Chesbrough's Open Innovation (2003) names the same substitution at the level of the whole firm: Closed Innovation holds that "we should control our IP, so that our competitors don't profit from our ideas," while Open Innovation holds that "we should profit from others' use of our IP, and we should buy others' IP whenever it advances our own business model." The business model, not the IP boundary, is what captures value - this gate applies that same swap to one asset instead of the whole company. Chesbrough's argument is general R&D and IP management, written before open-core SaaS existed; it grounds the substitution, it does not evaluate any specific open-source business model.
### Gate 4 - Contribution viability
Would an outsider ever contribute? That needs a buildable repository, a visible issue tracker, a contribution path and code legible without internal context. Code failing this is _published_, not open source: it carries the publishing cost with none of the shared-maintenance return, so the maintenance motive cannot be claimed for it.
Separate the two things this gate covers, because companies reliably supply one and not the other. West and O'Mahony compared twelve corporate-initiated projects and found sponsored projects far readier to offer **transparency** - visibility into what is happening - than **accessibility** - the ability to participate.
A public repository with no route to commit rights, no roadmap input and no answered pull requests passes the transparency half and fails the gate. When a user reports "we open sourced it and nobody came", check accessibility first.
O'Mahony and Karp (2022) track that same gap over time rather than at one moment: across four governance phases of one platform, outside participation rose as access widened and fell again once governance direction turned ambiguous, and external participants only took on leadership roles once a structured, collectively-determined process replaced single-sponsor control. Passing gate 4 at launch is not a permanent result - an accessible project that drifts into ambiguous governance loses the contributors it opened for, which is why the operating model in step 8 needs a named owner, not just an open repository.
### Gate 5 - Ownership (veto)
A named maintainer, an agreed release rhythm and a stated issue-response commitment - or it does not ship. Dump-and-run publishing is the fastest way to turn a talent or trust motive into evidence against the company.
## The CAP quadrants - a second read on the same assets
The gates give a verdict. Linåker et al.'s Contribution Acceptance Process model, documented at Sony Mobile, gives each asset a _dominant objective_ instead, by placing it on two axes - business impact and control complexity:
| Quadrant | Position | Dominant objective | Typical posture |
| --------------------- | ------------------------------------- | ------------------------------------ | -------------------------------------------------------- |
| Strategic | High impact, high control complexity | Ecosystem control | Contribute selectively, hold governance influence |
| Platform / leverage | High impact, lower control complexity | Time-to-market | Contribute actively; the ecosystem carries the load |
| Products / bottleneck | Lower impact, but damaging if absent | Cost reduction or alliance formation | Open it and share the maintenance, even with competitors |
| Standard | Low impact, low control complexity | Cost reduction | Fully open, let the ecosystem own it |
This adds two things over a gate list:
- a **per-artifact success definition**, valid only if declared at decision time rather than reconstructed afterwards
- a re-evaluation rule: the authors note the model does not capture how fast an artifact drifts from differentiating to commodity, and recommend re-running the evaluation every product planning cycle
The same paper validates the quadrant classification at three further firms beyond Sony Mobile, anonymized for confidentiality: an agriculture-tech firm's grain-marketing platform (CTO interview), a mobile games studio (founder interview), and a large telecommunications firm's internal infrastructure project (cross-functional workshop). Each firm's feature set was mapped onto the same four quadrants with percentage breakdowns, so the classification's external applicability rests on four organizations, one named.
Sony's authority model is worth copying at scale: contributions classified trivial, medium or major; trivial needs only the relevant business manager, the rest go to a cross-functional board of engineers, business managers and legal. Frame agreements pre-authorize contribution to ecosystems already judged non-competitive, so routine cases never reach the board.
## The asset scoring table
Score every candidate asset on one row. Verdicts: **Open**, **Closed**, **Not yet** (with the condition).
| Asset | Motive served | G1 irreversible | G2 differentiating | G3 value capture | G4 contributable | G5 owner | Verdict |
| ----- | ------------- | --------------- | ------------------ | ---------------- | ---------------- | -------- | ------- |
Rules that keep the table honest:
- every candidate asset appears exactly once, since an asset left off is a decision made by omission
- G3 holds a mechanism, not a license name
- G5 holds a person's name and an hours-per-week number, not a team
- a **Not yet** row is complete only when it names the event that would flip it (a hire, a revenue threshold, a shipped paid tier, a spec stabilizing)
## Open-core boundary shapes
When the verdict is "core open, some features paid", the boundary needs a rule that survives roadmap churn. All three cost about the same to adopt, so durability per quarter of upkeep is the ranking axis - efficiency: `buyer-tiered > scale-tiered > feature-by-feature judgment`:
- **Buyer-tiered.** Tier features by _who buys them_: the individual contributor's features stay in the open tier, the manager, compliance and executive buyer's features go paid. GitLab publishes this model on its stewardship page, along with eleven commitments and a documented 2020 re-audit that moved eighteen features into the open tier. It is the most durable rule because "whose problem is this?" has a stable answer while "how valuable is this?" does not.
- **Scale-tiered.** The open tier serves a single team or a bounded deployment; multi-tenant, HA, or fleet-scale operation is paid. Durable, but it prices out exactly the large community deployments that generate contributors.
- **Feature-by-feature judgment.** Decided case by case at roadmap time. Least durable: it re-litigates the line every quarter and invites taking features back.
Whichever shape is chosen, publish where the line sits. Having a line is not the credibility failure; hiding it is.
## A worked brief (fragment)
No company publishes a gate-by-gate table, so this is constructed: a hosted observability product, B2B, self-serve entry tier plus enterprise contracts. The numbers are illustrative - use the structure, not the figures. GitLab, Confluent, Sony Mobile and Google each publish a real line; read one of those before writing your own.
```markdown
## What we sell
Hosted ingestion, storage and query of telemetry, plus the on-call workflow around it.
Customers pay for operations at scale and for retention guarantees, not for the code.
## Motive
Commoditize your complement. The complement is instrumentation: every hour a customer
spends wiring up telemetry is an hour they are not sending us data. Cheaper, more
ubiquitous instrumentation raises demand for storage and query, which is what we bill.
Evidence: 4 of our last 10 lost deals stalled at instrumentation effort, not at price.
## Open
| Asset | G1 | G2 | G3 | G4 | G5 | Verdict |
| Language SDKs (6) | permanent, fine | context | hosting + retention | yes, users patch their own language | A. Rivera, 10h/wk | Open |
| Wire format spec | permanent, fine | context | hosting + retention | yes, third parties implement it | A. Rivera, 2h/wk | Open |
| Query-plan optimizer | permanent, NOT fine | differentiating | nothing left | no | - | Closed |
| Terraform provider | permanent, fine | context | hosting | yes | J. Okafor, 4h/wk | Open |
| Anomaly-detection models | permanent, NOT fine | differentiating | data volume, weakly | no | - | Not yet - revisit if a competitor ships an open equivalent |
## Competitive case
A hyperscaler forks the SDKs and points them at their own backend. We keep: managed
ingestion at scale, 13-month retention, the on-call workflow, and the trademark. We lose
nothing we bill for. Verdict: acceptable.
```
## Weak vs strong rows
**Weak - value capture**
> We'll open the core and stay ahead through faster development.
Speed is not a mechanism; a well-funded competitor is faster. This row fails gate 3 and the verdict must be Closed or Not yet.
**Strong - value capture**
> We'll open the core. Value capture is operations: multi-region ingestion with a 13-month
> retention guarantee, plus the trademark. A competitor can run the code; they cannot run
> our fleet or call it by our name.
**Weak - ownership**
> The platform team will maintain it.
No name, no hours, no response commitment. Fails gate 5. **Strong:** "A. Rivera, 10h/week, monthly releases, first response to issues within 3 business days, backup maintainer J. Okafor. Reviewed at the next planning cycle."
**Weak - motive**
> Open source is how developer tools grow, and it will help with hiring and credibility.
Three motives, none tested, none measurable; it will be measured on stars. **Strong:** "Primary: commoditize the instrumentation complement. Secondary (not measured): talent. Success signal: paid ingestion volume, not SDK downloads."
**Weak - demand pull**
> Our largest customer asked for the connector to be open source, so we're opening it.
A request is not a requirement, and the row skips every other gate. Ask what happens on refusal; if the renewal is not conditional, this is a preference dressed as a mandate. Even when it _is_ conditional, the ownership and value-capture gates still apply - a repository opened to close a deal and then abandoned becomes the same customer's complaint six months later.
**Strong - demand pull**
> The renewal (€480k ARR) is conditional on the connector shipping under an OSI-approved licence
> before Q3. Two other customers in the same regulated segment will inherit the benefit, and one
> has agreed to co-maintain. Gate 3: we still hold the managed control plane and the trademark.
> Gate 5: M. Duarte, 6h/week, monthly releases. Declared objective: cost sharing - at least one
> external organisation landing connector fixes within 12 months.
references/company-type-and-authority.md›
# Company type, decision authority and the non-reversal commitment
Contents: the company-type table · GitLab's published mechanics · Google's published mechanics · what to commit never to close · the six reversal cases · a weak and a strong commitment.
## Company type changes the answer
The same gates produce different verdicts depending on who is asking. Ask which row applies before drawing a line.
| Dimension | Venture-backed startup | Public / late-stage software company | Non-software company |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Dominant motive | Distribution and adoption ahead of monetization - Open Core Ventures frames the open core as a distribution and R&D strategy, with proprietary features as the monetization arm | Defending an existing revenue line against a hyperscaler - HashiCorp's stated 2023 trigger was vendors commercializing without material contribution back | Cost sharing, talent, and requirements imposed from outside - Bloomberg's open source office sits inside the CTO Office and frames open source as infrastructure and culture |
| Boundary primitive | Buyer persona: individual-contributor features open, manager and executive features paid | Deployment mode: self-hosting stays permitted, a competing managed service does not - Confluent's restriction targets competing SaaS specifically | Enabler versus differentiator inside the product - Sony contributed multimedia frameworks while withholding camera-effect features |
| Who decides | Founder or CEO, effectively unilaterally | Cross-functional with executive sign-off; GitLab names the CEO as final decider on large pricing decisions | Governance board spanning engineering, business and legal, with IPR review |
| Reversal exposure | Low near-term, extreme once adoption is large | Highest: fork risk plus a shareholder-visible narrative | Low on the product axis, real on the talent and customer-requirement axis |
| Timescale trap | Founder-speed decisions outrun the community's ability to absorb them | Quarterly reporting pressure | A Linux Foundation practitioner notes companies measure in three-month spans while maintainers organize around neither quarters nor fiscal years |
## GitLab: the boundary published as promises
GitLab's stewardship page publishes eleven explicit promises rather than a principle. Among them:
- an open-sourced feature will never move to a paid tier
- features landing in both editions ship simultaneously with no fixed delay
- all tests for an open source feature are released too
- the open source codebase carries no artificial limits on repositories, users, size or performance
- every stage of the DevOps lifecycle has at least some open source feature
The criterion is a **persona test, not an asset test**: who cares most about a feature - if the likely buyer is an individual contributor it is open source, otherwise source-available. GitLab states there are no features useful only to managers or executives; every proprietary feature still has an individual contributor who wants it, just not enough to be the buyer. Sid Sijbrandij attributes the framework to a 2008 formulation by Adam Lampitt about segmenting by user base rather than feature, and says he has used it since 2015.
Two details make this a live process rather than a manifesto:
- GitLab publishes acceptance criteria for the _reverse_ case, a community contribution opening an existing paid feature
- in 2020 a named executive reviewed every feature in every tier and moved eighteen features across seven DevOps stages into open source, framed as correcting tier placement under the buyer-based model
Large tiering decisions route through a named matrix:
- the Senior Director of Pricing is responsible
- CPO and CRO agree
- CMO and CFO give input
- the **CEO decides**, the only publicly named final decider found for the open/closed question
## Google: strategy call separated from compliance review
Google's release documentation assigns the "is this okay to release" call to the **launch creator's manager**, not the open source programs office, on the stated ground that the office "frequently lacks the business context to make it." Larger launches escalate to a director or VP. The office runs licensing, patent and privacy review as parallel approvers on the same launch record, routed through a launch-management system, so the decision is auditable afterwards.
The published rejection criteria are unusually candid: does the release touch Google's "secret sauce" (ranking, filtering)? Does sharing help users, or only competitors?
Named examples of things not okay to release include a proprietary algorithm kept for business reasons and a project competing with other Google interests undesirably. The stated default is **approve unless there is a good reason not to**.
The pattern worth copying from both: the business-context call belongs to whoever owns the business case, the compliance call to a specialist reviewer, and neither substitutes for the other.
## What to commit never to close
A commitment is only worth writing if breaking it would be visibly embarrassing. Each costs the same to publish - a sentence - so strongest first is also the efficiency order:
1. Never move an already-open feature into a paid tier (GitLab's promise, and the one most likely to be tested).
2. Never add artificial limits - repository count, user count, data size, throughput - to the open edition.
3. Never re-license already-open components away from an OSI-approved license.
4. Ship the tests for open features alongside the features.
5. Announce any boundary change before it lands, with the reasoning and the effective version.
Pair each promise with the role that has standing to break it. A promise nobody is accountable for is a marketing line.
## The six reversal cases
Every case below narrowed or renamed something already given. The cost concentrated in the reversal event, priced in forks.
| Case | Reversal | Documented response | What it reveals |
| ----------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| HashiCorp, 2023 | MPL-2.0 to BUSL-1.1 across all products | The OpenTF fork emerged within days and became OpenTofu under the Linux Foundation | Fork speed is the real cost signal - days, not quarters |
| Elastic, 2021 then 2024 | Apache-2.0 to SSPL/ELv2, then AGPL added back | Banon acknowledged the 2021 change knowingly caused a fork with a different trajectory, and said three years later that Amazon was "fully invested" in OpenSearch | The relicensing was reversible; the fork was not |
| Redis, 2024 then 2025 | BSD to RSALv2/SSPLv1, then AGPLv3 in Redis 8 | AWS and Google backed Valkey before the AGPL return; the CEO stated the move achieved its goal but "hurt our relationship with the Redis community" | A licensing win and a community loss, conceded in one sentence |
| Red Hat, 2023 | RHEL sources restricted to CentOS Stream | Oracle, SUSE and CIQ formed OpenELA; the company blog called part of the demand "disingenuous" | Attacking the objector's motive escalates rather than resolves |
| Docker, 2017 | `docker/docker` renamed `moby/moby` - no license change, no code withdrawn | Overwhelmingly negative; the announcing pull request sat at 7 upvotes against 110 downvotes | The cleanest natural experiment: nothing was taken away and the backlash was still severe |
| Chef, 2019 | Open core to fully Apache-2.0 - a third to half the codebase newly opened | RedMonk noted the binary builds stayed proprietary, prompting public questions about the "100% open source" claim | Opening _more_ still draws credibility attacks if a proprietary edge exists and is not disclosed |
These cases expose two residual risks that no framework resolves:
- governance surprise as a cost independent of scope (Docker)
- supply-side withdrawal: opening an asset creates a dependency on people who can withdraw their own contribution
## Weak and strong commitments
**Weak**
> We're committed to open source and will always have a strong community edition.
Nothing here can be violated, so nothing here can be trusted. No promise, no scope, no owner.
**Strong**
> We will never move a feature that has shipped in the open edition into a paid tier. Adding
> new paid features above the line is in scope; moving existing ones down is not. Only the CEO
> can approve an exception, and any exception is announced before the release that contains it.
> Reviewed at each annual planning cycle; the current text is published at /stewardship.
**Decision rights, weak and strong.** "Engineering leadership will review open source proposals" has no split between business call and compliance review, no escalation path, no default posture - every proposal becomes a negotiation. The strong version: "The proposing team's director makes the release/no-release call and owns the business case. Legal and security review licensing, patents and secrets in parallel and can block on those grounds only. Anything touching the ranking pipeline escalates to the CTO. Default is approve."
references/operating-model.md›
# The operating model behind a company open source decision
Contents: the function set · inbound policy · outbound policy · upstream-first · where to participate · cost lines · scaling by company stage.
The line drawn in the strategy is only real if someone runs it. This file covers the company-side machinery. Project-side operation - decision rights, maintainer ladders, succession - belongs to `samber/developer-relations-skills@oss-governance`.
## The function set
The TODO Group describes an Open Source Program Office as "a designated place where open source is supported, nurtured, shared, explained, and grown inside a company", with six functions:
- communicate the strategy internally and externally
- oversee its execution across business units
- facilitate consumption of open source inside products
- ensure release quality for published code
- engage communities and manage contributions
- maintain license compliance review
Their staffing picture at scale:
- an executive-level program manager
- legal representation (a dedicated attorney for larger organizations)
- a review board spanning engineering, product and legal
- developer advocates
- tooling administrators
- compliance
Assign the **functions** regardless of company size; headcount is what scales. A twenty-person company runs all six as one engineer at 20% plus outside counsel on retainer. What it cannot do is leave them unassigned - the observed failure is not a missing office, it is a release nobody reviewed and a repository nobody answers.
**Do not let this office make the strategy call.** Keep step 7's split at any size: whoever owns the business case decides, a specialist reviews compliance, and neither covers for the other.
## Inbound policy - code the company consumes
- A license allowlist and denylist, with the escalation path for anything on neither.
- A third-party audit procedure at dependency-introduction time, not at audit time.
- An approval workflow proportionate to risk: automatic for allowlisted licenses, reviewed for the rest.
State the TODO Group's warning to executives: rigid policies get circumvented, and circumvention is where the security exposure appears. A policy engineers satisfy in minutes beats a stricter one they route around.
## Outbound policy - code the company publishes
- A contribution policy covering what employees may contribute on company time and equipment, and to which projects.
- A release checklist for new repositories: license file, notices, secrets scan, dependency licenses, trademark check, security contact, maintainer named.
- The CLA-versus-DCO decision - hand it to `samber/developer-relations-skills@oss-license-strategy`, but record that the choice exists, since dual licensing later is impossible without collecting the rights up front.
## Upstream-first
TODO Group's phrasing: "Submit patches upstream first, and consume in your own products downstream." Skipping it silently invalidates the maintenance motive that justified the strategy (step 8). Make it a stated engineering default with a documented exception path - a fix needed before upstream can review it ships downstream _and_ opens the upstream pull request in the same week.
## Where to participate
The TODO Group's engagement triage: assess which projects are strategically critical - critical business infrastructure, development and deployment tooling, customer-facing software - and engage deeply with the most important ones rather than contributing to everything the company consumes.
Rank the depth ladder by return per engineer-hour, not by price - efficiency: `contribute fixes upstream > report issues > maintain a component > hold a governance seat > fund a membership`, against effort: `maintain a component > hold a governance seat > fund a membership > contribute fixes > report issues`. Upstreamed fixes lead because they delete maintenance the company would otherwise re-pay at every upgrade; plain consumption buys nothing, so it is not a rung. The order starves maintaining a component - highest value on anything the company genuinely depends on, and a standing job - so promote it when the dependency is critical business infrastructure and nobody upstream maintains it. Pick a rung per project and write it down; undeclared ambition to reach the top rung on ten projects is how open source budgets get spent with nothing to show.
## Cost lines to budget
- Maintainer time - the dominant cost and the one usually left out. Count review, releases, issue and pull-request response, security-report handling.
- Legal review at release, plus inbound audit tooling.
- Training on licenses, governance and conflict resolution.
- Foundation memberships. The TODO Group's published band is $5,000–$250,000+ per year, undated in their guide and moving - an order of magnitude; check the target foundation's current schedule before it enters a budget.
- Community presence: conferences, sponsorships, travel.
- Security response: a contact address, a disclosure policy, someone on the hook.
State the annual total in the brief. A strategy whose cost was never added up gets cut mid-year, producing exactly the abandoned repositories it was supposed to avoid.
## Scaling by company stage
- **Pre-product-market-fit.** One person, part time; two artifacts only - a release checklist and a license allowlist. Open SDKs and specs, defer the rest.
- **Growth.** A named part-time owner with legal on call, published inbound and outbound policies, an upstream-first default, one funded maintainer per open repository.
- **Enterprise.** The full function set, a review board, compliance tooling, foundation memberships, a public position on the open-core line.
## Measuring the program
Measure against the motive first - per-motive signals live in the motives reference. Program-health signals underneath it:
- repositories with a named owner and a release in the last quarter
- median first response on issues from outside the company
- external contributor organizations
- upstream patches landed versus private patches carried
- time-to-approval on the inbound workflow
Red Hat's open source office adopted **CHAOSS** as its definition of community health - a ready-made metric vocabulary, but it measures health, not strategic return. Pair that with the TODO Group caution the skill's measurement section states, pick the two or three signals your motive implies, and ignore the rest even when a dashboard offers them.
The one documented company-level success criterion found for an individual project: Spotify spins successful open source projects into separate business units launching commercial products, with the open source office identifying candidates (Linux Foundation/TODO, "Business Value of the OSPO"). One company's model, not a benchmark.
references/published-findings.md›
# Published findings on open source strategy
Contents: strategy sources · empirical studies · company-published mechanics · reversal record · operating guidance.
What each source establishes and - the part that matters more - what it does _not_ prove. Cite the source when you use its claim, and drop the claim rather than upgrading it when the user needs something the source cannot carry.
Three labels appear below:
- **Sourced**: traceable to a named author, company page or peer-reviewed paper
- **Via trade press**: a publication reporting what a company or founder said, directionally reliable, not quotable as that company's own words
- **Self-set**: a baseline, never an industry standard
## Strategy sources
- **Joel Spolsky, _Strategy Letter V_ (2002)** - "demand for a product increases when the prices of its complements decrease", with IBM's PC add-in cards, Microsoft's non-exclusive PC-DOS licensing, Netscape's browser, Transmeta hiring Torvalds and Sun/HP funding GNOME as examples, and Sun's Java as the counter-example. _Sourced._ Does not prove commoditization works reliably; it is a strategic argument with selected illustrations, not a study.
- **Dirk Riehle, _The Innovations of Open Source_** - the cost-sharing motive, the block-a-competitor motive (Linux against Windows, Eclipse against Visual Studio) and the differentiating-versus-context split, illustrated by a distributor keeping test suites, configuration databases and compatibility matrices closed while the code is open. _Sourced._ An analytical framework, not measured outcomes.
- **Geoffrey Moore, core versus context** - the same cut in general-management vocabulary. _Sourced as terminology._ Adds a vocabulary, not evidence.
- **Adam Jacob, "The war for the soul of open source", OSCON Portland 2019** - the strongest available argument _against_ boundary-drawing: the value sits in the totality of the product, not in a proprietary sliver. _Sourced._ Use it as the steelman when a user is set on open core, not as a prediction that open core fails.
- **David Cramer (Sentry), "Open Source is not a Business Model"** - founders face a practical binary: AGPL deters competitors but scares some customers, MIT protects nothing, so many choose closed source and the technology is never adopted. _Sourced._
- **Chad Whitacre (Sentry), the Fair Source essays** - open source as a distribution and development model rather than a business model; licensing terms limit which business models are available at all. _Sourced._
- **Stephen Walli (Microsoft), "There is NO Open Source Business Model"** - open source as engineering economics, argued in a slide deck. Delivered at LinuxCon + ContainerCon + CloudOpen China, Beijing, 19 June 2017 (session schedule listing; SlideShare listing, 65 slides, matches).
## Empirical studies
- **Henkel (2006), Research Policy 35(7)** - firms in embedded Linux reveal on average about **half** the code they develop, with strong heterogeneity across firms. _Sourced._ Use it as a base rate that makes "how much" a legitimate question; it does not prescribe a target, and it is one industry at one point in time.
- **Henkel, Schöberl & Alexy (2014), Research Policy 43(5)** - customer demand pull is the _initial trigger_ for selective revealing, followed by a positive feedback loop, with openness becoming a dimension of competition. _Sourced._ Supports treating demand pull as a first-class motive; does not say externally triggered decisions turn out better.
- **West & Gallagher (2006), R&D Management 36(3)** - four firm strategies for engaging open source: pooled R&D, spinouts, selling complements, attracting donated complements. _Sourced._ Commoditize-your-complement is one of four, not the general case.
- **West & O'Mahony (2008), Industry & Innovation 15(2)** - across twelve corporate-initiated projects, sponsors offered _transparency_ far more readily than _accessibility_. _Sourced._ The sharpest available diagnostic for "we open sourced it and nobody came"; it explains a gap, it does not quantify how much accessibility is enough.
- **O'Mahony (2007), Journal of Management & Governance 11(2)** - five principles of community-managed governance and how hybrid corporate/community models differ. _Sourced._ Useful for stating what a company gives up under community governance.
- **O'Mahony & Karp (2022), Strategic Management Journal 43(3), "From proprietary to collective governance: How do platform participation strategies evolve?"** - across four governance phases of one platform, participation rose as access widened and fell again once governance turned ambiguous; leadership passed to outsiders only under structured, collective governance. _Sourced (published abstract; full text paywalled)._ Extends gate 4 into a standing check, not a one-time pass. One platform, one trajectory - no general timeline or maturity bar.
- **Linåker, Munir, Wnuk & Mols, the CAP model (arXiv 2208.00308)** - the one industrial, artifact-level decision model with a documented instantiation (Sony Mobile): two axes, four quadrants, a dominant objective per quadrant, a cross-functional governance board, and the enabler-versus-differentiator split inside one asset. _Sourced._ The same paper validates the quadrant classification at three further, anonymized firms (agriculture-tech, mobile games, telecommunications), so the classification itself rests on four organizations across four industries, though only Sony Mobile is named; the model's own authors note it does not capture how fast an artifact drifts from differentiating to commodity, which is why they recommend re-running the evaluation each planning cycle.
- **Henry Chesbrough (2003), _Open Innovation_ (Harvard Business School Press), excerpted as "The Logic of Open Innovation," _California Management Review_ 45(3), Spring 2003** - Open Innovation firms profit from others' use of their IP and buy others' IP, rather than relying on controlling it. _Sourced (read directly)._ The base model West & Gallagher and the CAP model build on, and gate 3's grounding for treating the business model, not the license, as the value-capture mechanism. General R&D and IP management, not open source licensing, and predates open-core SaaS.
## Company-published mechanics
- **GitLab stewardship page** - eleven promises, the buyer-persona test, reverse-direction acceptance criteria, and the 2020 audit moving eighteen features across seven DevOps stages into open source. **GitLab pricing handbook** - the decision matrix in which the CEO decides. _Sourced from the company's own handbook._ One company's model; the promises are unusually strong and are not an industry norm.
- **Google open source release approval documentation** - the manager-owned strategy call, escalation to director or VP, parallel licensing/patent/privacy review, published rejection criteria, approve-by-default posture. _Sourced._
- **HashiCorp (2023-08-10), Elastic (Banon, 2024-08), Confluent (2018-12), Red Hat (McGrath, 2023-06-26)** - each company's own stated reason for its boundary. _Sourced from company or founder blogs._ These are positioning statements; treat the reasoning as sincere but self-serving.
- **Chef (Adam Jacob) and Mercedes-Benz (FOSS Manifesto)** - Sourced via trade press coverage of founder statements.
- **caniszczyk/rugpulls.dev** - a maintained dataset of relicensing events with dates and announcement URLs, including MongoDB's 2018 AGPL-to-SSPL move and Grafana's 2021 Apache-to-AGPL move. _Sourced dataset._ Use it instead of re-deriving a timeline.
## Reversal record
The six reversal cases this skill cites are each sourced to a company blog, LWN or trade press. What they collectively support: the reputational cost concentrates at the reversal, forks appear in days, and governance surprise costs even when no code is withdrawn.
What they do **not** support: that any particular initial scope prevents a reversal. The steelman for the opposite reading is that initial scope determines whether a community forms at all, and a project nobody adopts never generates a reversal event - so scoping is still causally prior. Both readings are defensible; say so rather than picking one silently.
## Operating guidance
- **TODO Group** - the open source program office definition and function set, the staffing picture, inbound and outbound policy structure, the upstream-first rule ("submit patches upstream first, and consume in your own products downstream"), engagement triage, and the foundation-membership band of **$5,000–$250,000+ per year**. _Sourced, but the membership band carries no publication date in the guide and membership pricing moves_ - treat it as an order of magnitude, and check the target foundation's current schedule before putting a number in a budget.
- **TODO Group, measuring open source program success** - the caution from a named Oath/Yahoo open source director that data gets collected because it is available, not because it answers the question. _Sourced._
- **Linux Foundation / TODO, "Business Value of the OSPO"** - Spotify spinning successful open source projects into separate business units with commercial products, the closest thing to a per-project success criterion from a named company. _Sourced._
- **CHAOSS** - adopted by Red Hat's open source office as its definition of community health. _Sourced._ Measures health, not strategic return.
references/strategic-motives.md›
# Strategic motives for opening company code
Contents: the eight motives · evidence each demands · signal each is measured on · how much to open · combining motives · motives that are not motives.
A motive is not a slogan. Each carries an evidence test the company passes out loud and a signal deciding whether it worked. A failed evidence test makes the motive decoration; the asset needs a different reason or stays closed.
Motives 1-7 are chosen internally. Motive 8 is imposed from outside and is the more common trigger - not a lesser case.
## 1. Commoditize your complement
**Claim.** Joel Spolsky, _Strategy Letter V_ (2002): "demand for a product increases when the prices of its complements decrease". Push a complement of what you sell toward commodity pricing and demand for your product rises, letting you hold price.
**His examples**: IBM's documented PC add-in cards, non-exclusive PC-DOS licensing, Netscape's giveaway browser, Transmeta hiring Torvalds, Sun and HP funding GNOME. His counter-example from the same essay is Sun's Java, which commoditized _hardware_ - the wrong complement for a company selling hardware.
**Evidence test.** Name the product whose demand rises, and name the complement being opened. If the two are the same thing, this is not the motive.
**Signal.** Growth in the paid product, not adoption of the opened complement. Adoption is the mechanism, not the outcome.
## 2. Cost sharing
**Claim.** Several organizations jointly fund a component none of them differentiates on, usually under a foundation, instead of each maintaining a private fork (Dirk Riehle, _The Innovations of Open Source_).
**Evidence test.** Name at least one other organization with a reason to co-fund, and say what happens if none shows up. A "shared" project with one contributing vendor is single-vendor open source with extra process.
**Signal.** External contributor organizations, and engineering hours displaced from the private fork.
## 3. Block a competitor from owning a standard
**Claim.** Open a component so a rival cannot make it a proprietary chokepoint. Riehle's framing of Linux against Windows and Eclipse against Visual Studio: commoditize before you are commoditized.
**Evidence test.** Name the competitor and the chokepoint. Defensive standard-setting also demands neutral governance sooner than the company usually wants - a standard nobody else can influence is not a standard.
**Signal.** Adoption by parties who are not your customers, and the competing proprietary component's loss of default status.
## 4. Market creation
**Claim.** Non-software companies fund and open components they operationally depend on, growing a supplier and talent ecosystem that did not previously exist.
**Evidence test.** Name who is supposed to build on it and what they get. This motive has the longest payback of the eight; commit to a multi-year horizon or pick another motive.
**Signal.** Third parties shipping products or services that depend on the component.
## 5. Talent
**Claim.** TODO Group: working publicly recruits people who already know the project, and contributors are a pre-qualified hiring pool.
**Evidence test.** The asset has to be work an engineer would want to be seen doing. A build script nobody would list on a CV recruits nobody.
**Signal.** Candidates who cite the project, contributor-to-hire conversions, and retention of the engineers who maintain it. Tolerates a small, well-run project - it does not need ecosystem scale.
## 6. Trust and auditability
**Claim.** Buyers, auditors and security teams can read the code instead of trusting a claim. Strongest for security, cryptography, privacy and agent/automation surfaces where "trust us" is expensive.
**Evidence test.** Point to a deal, an audit or a compliance review where the source was actually asked for. Otherwise this is a second-order benefit of opening, not a reason to open.
**Signal.** Security reviews passed faster, procurement objections removed, third-party audits published.
## 7. Lower maintenance through upstreaming
**Claim.** TODO Group's upstream-first argument: a private patch is re-paid at every upgrade; an upstreamed patch is maintained by the project. Applied to a company's own code, opening converts private maintenance into shared maintenance.
**Evidence test.** Shared maintenance only arrives if other maintainers do. Estimate the first two years as _added_ cost - review, releases, issue response, security reports - and check the motive still holds if no external maintainer ever appears.
**Signal.** External commits landing without company review time, and the fraction of the maintenance load carried outside the company.
## 8. External demand pull
**Claim.** The decision is triggered from outside - a customer, a platform owner, a regulator or a standards body requires it - rather than chosen in a vacuum. Henkel, Schöberl and Alexy (2014) found customer demand pull to be the _initial_ trigger for selective revealing, followed by a positive feedback loop in which openness becomes a dimension of competition.
**The clearest documented case** is the Sony DRM plug-in in step 2. In CAP-model terms it is a _bottleneck_ artifact: negative business impact if absent, no positive impact if present.
**Evidence test.** Name the party imposing the requirement and what happens if the company refuses. A customer _asking_ is not demand pull; a customer conditioning a renewal on it is. If refusal costs nothing, the real motive is somewhere in motives 1-7.
**Signal.** The requirement satisfied, the deal or certification obtained, and the share of the resulting maintenance carried by the other parties subject to the same requirement.
**The trap.** A forced decision still has to pass the value-capture and ownership gates. Companies open something under customer pressure, skip the ownership question because the deal was the point, and end up with an unmaintained repository that the customer then complains about.
## How much to open
Henkel's 2006 study of embedded-Linux firms found they reveal on average about **half** the code they develop, with wide variation. A base rate from one industry at one point in time, not a target. Its real use is to reframe the question: the unit of decision is a _fraction of a codebase_, not a binary per-project verdict, and a company opening 5% or 95% should say why its situation differs from the middle.
West and Gallagher (2006) add four distinct firm strategies - pooled R&D, spinouts, selling complements, attracting donated complements - of which commoditize-your-complement is one. Check which the company is running before assuming the complement logic applies.
## Combining motives
Rank them; do not average them. One primary motive decides the line and the measurement; secondary motives are welcome side effects. A brief that lists four co-equal motives has not made a decision, and its measurement plan will contradict itself - talent and commoditization, for instance, disagree about whether small-and-well-run beats large-and-adopted.
## Motives that are not motives
- **"Our competitors did it."** Their line served their value capture, which you probably cannot see.
- **"The team wants to."** Real as retention pressure, not as strategy. Route it into the talent motive or into a sanctioned contribution policy instead.
- **"It's not core anyway."** Not-core is an argument for _not keeping it closed_, not an argument for paying the cost of running it in public.
- **"To get free contributors."** The strongest form of the maintenance motive, and the one that fails most often - most published repositories never receive an external contribution.
SKILL.md›
---
name: open-source-company-strategy
description: Decides what a company open-sources and what stays proprietary, names the strategic motive for each side of the line, says who owns the decision, and states what the company commits never to close. Use whenever someone asks "should we open source this?", "what should we open source", "where do we draw the open-core line", "which features stay paid", "who signs off on open sourcing this", or wants a company-level open source strategy rather than a plan for one project - even if they frame it as a licensing question. Produces an asset-by-asset open/closed verdict, a value-capture and irreversibility check, a public non-reversal commitment and a re-evaluation trigger. Not license selection - use samber/developer-relations-skills@oss-license-strategy.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Open Source Company Strategy
You are an open source strategist advising a company, not a maintainer advising a project. Your output is a line: which assets the company publishes under an open source license, which stay closed, who owns that call, and the reason each side of the line holds.
Three facts shape every recommendation:
- Opening is **irreversible**: every released version stays licensed forever, so a decision that looks like an experiment is permanent.
- An opened asset is a **liability until someone owns it**: a repository with no maintainer, no release rhythm and no answered issues costs more trust than never publishing.
- What gets priced is the **reversal**, not the initial scope, priced by forkers, departing contributors and procurement allowlists.
Across six documented narrowings between 2017 and 2024, the cost landed when something was taken away, in forks that appeared within days.
This is a macro strategy skill: you decide _what_, _why_ and _who decides_. The tactical work - license, running the project, registries, the announcement - belongs to the siblings below.
## Scope check before starting
Say so and route immediately when the whole question belongs to a sibling:
- license text or CLA vs DCO → `samber/developer-relations-skills@oss-license-strategy`
- running a project already open → `samber/developer-relations-skills@oss-governance`
- being found once open → `samber/developer-relations-skills@oss-distribution-strategy`
- announcing the release → `samber/developer-relations-skills@oss-launch`
- the revenue model itself → `samber/developer-relations-skills@devtools-business-model`
- funding other people's projects with money rather than code → `samber/developer-relations-skills@oss-sponsors-brand-strategy`
Overlap is normal - this skill sets the line those skills execute against. Hand off only when the whole question is theirs.
## Interview
Ask one question at a time, offer choices where you can, and stop once you can name the product being sold, the candidate assets, the motive and the decider. Confirm the rest later.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What does the company sell today, and what does a customer actually pay for - software, hosting and operations, data, support, a marketplace cut?
2. What is being considered for opening: the product core, an SDK or client library, a protocol or format spec, internal tooling, an infrastructure component, a reference implementation, a dataset, a test or conformance suite?
3. What triggered the question - a competitor's move, a hiring problem, a customer or regulator demanding it, a partner asking for a spec, an acquisition, a cost argument, a developer on the team who wants to?
4. Which company type is this: venture-backed startup, public or late-stage software company, or a company whose product is not software? Each one's boundary primitive and decision authority differ.
5. Who can approve or veto this, by role - founder, product owner, a review board, the CEO? Has anyone stated it in writing?
6. Who is the buyer: other companies with procurement and legal review, or individual developers paying with a card? (Both is valid and splits the line differently.)
7. What is already open, and how is it doing - contributors from outside, issue response, last release?
8. Which competitor or platform could take an opened asset and run it as a service against you, and what would still stop them?
9. Who would maintain the opened asset, by name, for the next two years - and how many hours per week?
10. What constraints are fixed: investor or board expectations, existing customer contracts, employer IP terms, regulatory exposure, a license already shipped?
11. What does success look like in 18 months, stated as something observable?
12. Is there a date this has to be decided by - a board meeting, a release, a customer renewal, a funding round?
13. Is this one asset's release, or the policy every future asset inherits?
14. What is the effort ceiling: maintainer hours a week, annual budget, and how much irreversibility the company will accept?
Questions 12-14 set the step 4 ranking, so ask them before proposing any line and say which answer moved which candidate.
- A hard date promotes interface-open, the only line needing no tiering matrix or executive sign-off.
- A policy meant to be inherited promotes buyer-tiered open core, a repeated decision being worth the quarter it costs to draw once.
- A low irreversibility appetite deletes buyer-tiered rather than demoting it.
If the harness has persistent memory, store the motive, the assets on each side of the line, the success objective, the decider and the review trigger. Every later license, governance, launch and distribution decision reads from them, and re-deriving them produces a different line each time.
## Step 1 - Inventory the assets separately
Companies debate "should we open source" as one question. It never is. List every candidate asset on its own row, since they rarely share a verdict:
client libraries and SDKs · protocol, format and API specifications · internal developer tooling · infrastructure components · reference implementations · data schemas · test and conformance suites · benchmarks · datasets · the product core.
Then split each asset one level further, into the **differentiating layer** and its **enablers** - Sony contributing to Android's media frameworks while keeping camera effects such as smile recognition closed, in Linåker et al.'s study, is the sharpest recorded example. Most decisions happen at that inner split, not at the asset boundary, and a company debating whole assets never finds it.
SDKs and specs almost always pass the gates below; product cores almost never pass without a specific answer to what still captures value.
## Step 2 - Name the motive before evaluating anything
An open source decision with no named motive collapses into taste. Pick the primary motive out loud and reject the ones that do not survive their own test - [references/strategic-motives.md](./references/strategic-motives.md) has each motive's source, evidence requirement and downstream constraint.
Do not rank the motives against each other. This list is diagnostic, not a menu of investments: the motive is whichever one is true of this company, and an efficiency order would only invite picking the convenient motive over the real one. Ranking starts in step 4, once the motive is fixed.
The short list: commoditize your complement · cost sharing · block a competitor from owning a standard · market creation · talent · trust and auditability · lower maintenance through upstreaming · **external demand pull**.
Treat demand pull as a first-class motive, not an excuse. Henkel, Schöberl and Alexy (2014) found customer demand is the _initial trigger_ for selective revealing far more often than internal deliberation.
The Sony DRM case shows the shape: an operator required a DRM mechanism from every handset maker, so Sony opened its plug-in and shared the maintenance cost with direct competitors. No differentiating-versus-context framing predicts that move.
Name these two failure signals immediately:
- **"Commoditize your complement"** without a stated product whose demand rises is decoration; Spolsky's own counter-example is Sun's Java, which commoditized the hardware Sun sold.
- **"Cost sharing"** with no other organization willing to co-fund is just publishing code.
## Step 3 - Calibrate to the company type
The same gates produce different answers depending on who is asking. Read the full table in [references/company-type-and-authority.md](./references/company-type-and-authority.md); the headline is:
- **Venture-backed startup.** Distribution ahead of monetization; primitive is the _buyer persona_; the founder decides; reversal exposure low now, extreme once adoption is large.
- **Public or late-stage software company.** Defending a revenue line; primitive is _deployment mode_, self-hosting allowed and a competing managed service not; cross-functional with executive sign-off; the highest reversal exposure of the three.
- **Non-software company.** Cost sharing, talent, outside requirements; primitive is _enabler versus differentiator inside the product_; a governance board with legal decides, on a timescale that mismatches maintainers'.
## Step 4 - Brainstorm the line before drawing it
Enter brainstorming mode explicitly and say so; do not propose a verdict yet.
Widen first: per candidate asset, ask what would change for the company if it were fully open, fully closed, or open with a specific carve-out. Then present **2 or 3 candidate lines**, never one, ranked rather than listed. Delete any line the interview's fixed constraints rule out - a customer contract or regulatory exposure over the core removes buyer-tiered outright - and say which constraint removed it, instead of leaving it at the bottom where it returns as scope next quarter.
Default order, for a company with a product to sell and no line drawn yet - `>` means more of that axis:
- efficiency: `interface-open > infrastructure-only > buyer-tiered open core`
- value: `buyer-tiered > interface-open > infrastructure-only`
- effort: `buyer-tiered > infrastructure-only > interface-open`
- irreversibility: `buyer-tiered > infrastructure-only == interface-open`
- compliance cost: `buyer-tiered > interface-open > infrastructure-only`
| Candidate line | What it opens | Effort and irreversibility | What it buys |
| ----------------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| **1. Interface-open** | specs, SDKs, reference implementations; everything behind the interface stays closed | a standing job the size of one library, with nothing to take back later | integration and adoption, spending no value-capture surface |
| **2. Infrastructure-only** | non-differentiating infrastructure and internal tooling; the product stays closed | a week per repository, then a standing job per repository - routinely underestimated, and the direct route to dump-and-run | talent and cost sharing, nothing on the revenue line |
| **3. Buyer-tiered open core** | the core, with paid tiers defined by _who buys the feature_ rather than how good it is | a quarter to draw, then a standing job policing every new feature against the line; the only line whose reversal gets priced by forkers and procurement | core adoption plus a revenue line built on it |
Rows 1 and 2 tie on irreversibility, genuinely: neither publishes anything the company sells, so the worst case is an abandoned repository rather than a reversal a community prices. They separate on every other axis, so the tie decides nothing alone.
The order starves row 3, the highest-value line here: most effort, and the only real irreversibility, so it loses every round a ratio decides. Promote it anyway when:
- the buyers will not adopt a closed core at all (a developer tool sold to engineers)
- a competitor already ships an open equivalent
- distribution is the named motive and the core is what has to be adopted
Only buyer-tiered is a published model (GitLab's); the other two lines and the ordering above are this skill's own, defaults that move with the company and with who executes it. Re-rank against what you know:
- an existing platform team prices row 1 near zero
- a company whose one open repository is already abandoned should read row 2's effort as higher than written
- in-house open source counsel discounts row 3's compliance cost
Give each surviving line what it opens, what captures value, its cost per year, the risk it accepts and the motive it serves. Then make it survive the strongest argument against drawing a line at all: Adam Jacob's, from thirteen years building Chef's community (OSCON 2019), that the value sits in the totality of the product, not a proprietary sliver.
Ask what the closed part captures that the totality does not; a line that cannot answer is not ready to present. State your recommendation and the reason, and let the user choose before detailing anything.
## Step 5 - Put every asset through the five gates
Apply the gates in order, in writing, per asset. Method, scoring and worked rows: [references/boundary-tests.md](./references/boundary-tests.md).
1. **Irreversibility** - assume this can never be closed again. If the answer changes, the honest verdict is "not yet".
2. **Differentiating or context** - does the company win deals because of this asset, or merely need it to exist? Run it on the enabler and the differentiating layer separately.
3. **Value capture** - name what still stops a competent competitor from reselling it: hosting and operations, data, network effects, trademark, support, a paid tier. "The license" is not an answer; it stops no compliant competitor and substitutes for no trademark.
4. **Contribution viability** - would an outsider ever contribute? Test _accessibility_, not just transparency: West and O'Mahony found sponsored projects far more willing to make work visible than to let outsiders participate, which is the usual explanation for "we open sourced it and nobody came".
5. **Ownership** - a named maintainer, a release rhythm and an issue-response commitment, or the asset does not ship.
These are gates, not ranked options: they sit outside step 4's ordering and no ratio overrides them. An asset that fails gate 1, 3 or 5 stays closed however attractive the other gates look. Failing gate 2 or 4 usually means opening it later, or opening a smaller piece of it.
## Step 6 - Stress the line against the competitive case
Write the adversarial scenario out:
- name the specific competitor or platform
- describe what they would run as a managed service
- state what the company still holds
If nothing is held, the line is wrong: move the asset, not the license.
Source-available and delayed-open-source instruments (BUSL, FSL and similar) answer this risk and only this one, at the cost of procurement allowlists, distro packaging and contributors. Raise them only when the scenario is concrete, call them "source-available" and never "open source", and hand the instrument choice to `samber/developer-relations-skills@oss-license-strategy`.
## Step 7 - Name the decider and the promise
The cost of this strategy concentrates at whatever future moment the line moves. Constrain that moment now, from both sides: decision rights control _who_ can move the line, a public commitment raises the _price_ of moving it. Most strategies skip both; produce both.
**A decision-rights line.** Separate "should we open this?" - a business-context call - from "is this compliant to open?" - a specialist review.
Google assigns the first to the launch creator's manager, on the stated ground that its open source office lacks the business context, and runs licensing, patent, and privacy review as parallel approvers. GitLab routes large tiering decisions through a named matrix in which the CEO decides. Write down who plays each part here, even if two parts are one person.
**A non-reversal commitment.** State in public what the company promises never to close. GitLab publishes eleven such promises - including that an open-sourced feature will never move to a paid tier - and has run a proprietary tier for a decade with comparatively little sustained backlash.
Docker is the counter-case: renaming `docker/docker` to `moby/moby` in 2017, with no license change and no code withdrawn, still drew severe backlash - strong evidence that communities price governance surprise on its own. Mechanics and the full case table: [references/company-type-and-authority.md](./references/company-type-and-authority.md).
## Step 8 - Cost the operating prerequisites
A strategy that names assets but not the machinery produces abandoned repositories. Before signing off, state who owns each function, even if it is one person at 20%: release review for outbound code, an inbound license policy, an upstream-first rule, a contribution policy, the recurring budget. Function set, policies and cost lines: [references/operating-model.md](./references/operating-model.md).
Upstream-first matters more than its size suggests: a private patch is re-paid at every upgrade, an upstreamed patch is maintained by the project. Skip it and the maintenance motive that justified the strategy never materializes.
## Step 9 - Write the brief and validate it section by section
Produce a document an executive can act on:
```markdown
# Open source strategy - <company>
## What we sell - the value-capture surface, in one paragraph
## Motive - the primary motive, and the evidence it passes its own test
## Open - assets, each with its gate results and its owner
## Closed - assets, each with the gate it failed
## Not yet - assets deferred, with the condition that would change the verdict
## Competitive case - the adversarial scenario and what we still hold
## Decision rights - who decides, who reviews, who can veto
## Commitments - what we promise never to close, published
## Operating model - owners, policies, annual cost
## Measurement - the declared objective per asset, and the re-evaluation trigger
```
Present one section, get agreement, then write the next: a wrong motive propagates into every row below it, and is far cheaper to catch at the second heading than the tenth. A worked brief with weak and strong versions of the same rows is in [references/boundary-tests.md](./references/boundary-tests.md).
## Invocation examples
- "We're a Series A observability startup. Should we open source our agent SDK?" → Interview, inventory the SDK against the wire format and the query engine; expect interface-open, with buyer-tiered as the promoted alternative if the buyers are engineers who will not adopt a closed core.
- "Draw our open-core line - which features go in the paid tier?" → Step 3, then Steps 4-5; deliver the asset table plus the boundary shape, not a feature list.
- "A hyperscaler just launched a managed version of our project." → Step 6, then Step 7; often the line was drawn with no value-capture mechanism, and no license retrofits one.
- "Our biggest customer wants the connector open sourced before they renew." → demand-pull motive in Step 2, then the full gate pass; a customer requirement is a trigger, not a verdict.
- "Who should sign off on open sourcing our internal deploy tool?" → Step 7 alone.
Expect the brief above as output: assets with verdicts, a named motive, a named decider, a published commitment, an annual cost and a re-evaluation trigger. Not a license recommendation, and not a launch plan.
## B2B and B2C
The line moves with the buyer, so state which case applies rather than leaving it implicit.
- **B2B.** Nearly all monetized open source is here. Procurement, legal review and license allowlists turn an OSI-approved license into a sales asset and a source-available one into a blocker; auditability, a security contact and stable versioning are purchase criteria. Value capture is usually hosting, support and enterprise-tier features bought by a different persona than the user.
- **B2C.** Consumer companies open source too, but almost never the consumer product - the moat is data, network effects and brand, none of which the code carries. Realistic motives are talent, trust and cost sharing on infrastructure they already run; judge on hiring and reputation signals, never on adoption of the opened component.
## Measurement and the pass threshold
Start from an uncomfortable fact: **no widely adopted framework exists for judging whether one specific open-sourcing decision succeeded** - a review of the literature turned up none. What exists measures program health or community activity, and the TODO Group's own guide warns companies collect the data that is available rather than the data that answers the question.
The workaround, this skill's recommendation rather than documented practice: **declare the success objective per asset at decision time**, in the brief beside the verdict - retrofitting one always produces a number that flatters the decision. Measure against the motive (signals in [references/strategic-motives.md](./references/strategic-motives.md)) and re-run the evaluation every planning cycle, since an artifact differentiating today may be commodity within a couple of years.
The objective judges the decision in two years; the threshold below judges the brief today. Hold the brief to it and iterate until it passes:
- Every candidate asset appears exactly once, in Open, Closed or Not yet.
- One primary motive is named, with the evidence that it passes its own test.
- Every open asset has a named owner, a release rhythm and an issue-response commitment.
- The value-capture answer is a mechanism, not a license, and the adversarial scenario is written with a specific competitor named.
- A named role decides, a named role reviews compliance separately, and at least one commitment is stated that the company will publish and not walk back.
- The annual cost is stated, inside a budget someone has agreed to.
- A re-evaluation trigger exists: the next planning cycle, plus the events forcing an early re-read (a competitor's managed service, an acquisition, a funding round, a fork, the maintainer leaving).
**Sourced versus self-set.** [references/published-findings.md](./references/published-findings.md) cites every published claim behind this skill with what it does _not_ prove, and lists what is this skill's own baseline:
- the threshold above
- the gates' ordering and vetoes
- the Interview's horizon
- step 4's candidate lines and their ranking
Present the second group as defaults, and adjust them when a company's situation argues for it.
Report the check explicitly. A brief failing on ownership is not a brief needing discipline; it is a brief with one repository too many.
## Common failure modes
- **Open-washing.** A read-only mirror, or a source-available license, called open source. The audience it was meant to attract notices first.
- **Hiding the line, or moving it.** Refusing to publish where an open-core line sits is a credibility failure, and moving an already-open feature into a paid tier is the reputational event - adding new features above the line is not.
- **Governance surprise.** Announcing a unilateral change as a finished decision: Docker changed no license and withdrew no code, and still paid the full price.
- **Dump-and-run, and transparency mistaken for openness.** A tool published with no maintainer argues the opposite of the talent case it was meant to make; so does visible activity with no route to participate, the gap gate 4 tests.
- **Opening the wrong complement**, or expecting license terms to do the work of a product, a trademark or an operations advantage.
- **Deciding as one question**, with no re-evaluation trigger - one verdict over ten assets when the SDK, the spec and the core have three different answers, and nobody notices the motive stopped applying two years ago.
- **Ignoring supply-side reversal.** A former Chef employee removed components he maintained over a 2019 contract dispute, taking down part of the company's commercial business. No boundary framework covers this; name it as a residual risk rather than pretending it is handled.
## References
- [references/strategic-motives.md](./references/strategic-motives.md) - the eight motives, sources, evidence, signals.
- [references/boundary-tests.md](./references/boundary-tests.md) - gates in detail, CAP quadrants, scoring table, boundary shapes, a worked brief.
- [references/company-type-and-authority.md](./references/company-type-and-authority.md) - company types, GitLab's and Google's mechanics, the commitment, six reversal cases.
- [references/operating-model.md](./references/operating-model.md) - program functions, inbound and outbound policies, cost lines.
- [references/published-findings.md](./references/published-findings.md) - every sourced claim, its origin, what it does not prove.
Related skills in this collection are the six named in the scope check above, each picking up where this line hands off. See also `samber/developer-platform-skills` when the question turns out to be which API, SDK or integration surfaces to expose rather than which source to publish.