samber/developer-relations-skillsチェック済み
SKILL DETAIL
open-standards-strategy
samber/developer-relations-skills/open-standards-strategy
Decides how a company engages a named open standard or protocol - ignore it, consume it, certify conformance, extend it, contribute upstream, co-found a spec with peers, or drive its own as a de facto standard - plus the venue (Git-based spec, foundation, consortium, IETF/W3C/OASIS, ISO transposition), the patent-licensing mode, the conformance plan and the kill rule. Use whenever someone raises open standards participation, protocol strategy, standards body engagement, standards wars, joining versus competing with an emerging protocol, donating a specification to a neutral foundation, whether to standardize an interface at all, or a competitor's rival spec - even if they never say "standard". Not project governance - use samber/developer-relations-skills@oss-governance.
インストール · 414出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill open-standards-strategy
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "open-standards-strategy",
"evals": [
{
"id": 1,
"prompt": "I'm VP Platform at Corvado, a B2B logistics SaaS, about 180 people. Our CTO put \"open standards strategy\" on my H1 OKRs and wants a strategy document for the exec team by next Friday. Can you write it? I want something that covers our overall approach to open standards and commits us to being good ecosystem citizens across the board.",
"expected_output": "A refusal to write the company-wide strategy document, plus a single scoping question naming the missing unit of decision: which specification, over what horizon, owned by whom.",
"files": [],
"expectations": [
"Declines to produce the general, company-wide open standards strategy document the user asked for",
"States that the unit of decision is one named specification, not a company-wide posture",
"Asks which specification or protocol the decision concerns before proposing anything",
"Names a single time horizon and a single owner as part of that decision unit, alongside the named spec",
"Treats \"we support open standards\" as a value rather than a strategy, explicitly",
"Recommends no posture (ignore, consume, conform, extend, contribute, co-found or drive) while no spec is named",
"Produces no decision record, KPI table or venue recommendation in this response",
"Asks what triggered the question, offering options such as a customer or procurement request, a competitor announcement, a recurring integration cost, a regulator, or an internal proposal",
"Poses a single question and waits, rather than delivering the whole interview as one block",
"Offers to run the full analysis once the user names one specification"
]
},
{
"id": 2,
"prompt": "Helvar Systems here, we sell fleet-orchestration software for warehouse robots. A EUR 1.4M renewal with our largest customer closes in 11 weeks and their procurement team added a hard requirement that we support FleetLink 2.1, an interop message format maintained by a robotics industry consortium (membership is EUR 48k a year). Our VP Engineering wants to join that consortium's technical committee so we get a say in FleetLink 3.0, which is due in roughly two years. We have two engineers free starting next week. How should we play this?",
"expected_output": "A short-horizon answer that removes the consensus-venue postures from the menu entirely, presents two or three fast postures, and recommends conforming or consuming to clear the renewal, with the committee seat handled as a separate decision.",
"files": [],
"expectations": [
"Removes Contribute, Co-found and Drive from the options presented, rather than listing them as lower-ranked alternatives",
"States that consensus venues work in years and cannot produce a result inside the 11-week window",
"Presents at least two and at most three candidate postures before recommending one",
"Draws every surviving candidate from Consume, Conform and Extend",
"Recommends Consume or Conform as the action that clears the renewal requirement",
"Names the test or interview answer that eliminated each rejected posture",
"Treats the technical-committee seat as a separate decision on a separate horizon, not as the answer to the renewal",
"Checks whether FleetLink 2.1 has a conformance suite and a certification mark before treating \"support\" as a checkable claim",
"States that procurement naming the requirement promotes Conform above the other rungs, because its value becomes market access rather than preference",
"Counts the named renewal as demand evidence instead of asserting general market demand",
"Recommends neither publishing nor driving a competing fleet message format",
"Carries both the 11-week deadline and the two-year FleetLink 3.0 horizon through the reasoning that deletes the consortium seat"
]
},
{
"id": 3,
"prompt": "Tessral. We sell an anomaly-scoring engine for industrial telemetry; the entire product is the scoring model and the score API around it. A group of six historian and SCADA vendors has invited us to help standardize an \"anomaly score exchange\" interface covering the request shape, score normalization, and the explanation payload. Our CEO wants us to chair the effort so we're seen as the category leader. I can commit one senior engineer for 18 months. Should we take the chair?",
"expected_output": "A refusal of the chair on commoditization grounds: the interface being standardized is the company's own differentiator, so the posture ceiling is Extend.",
"files": [],
"expectations": [
"Applies the commoditization test by name and identifies the layer the proposed standard would commoditize",
"Identifies the anomaly score exchange interface as Tessral's own differentiator rather than a neighbouring or commodity layer",
"Caps the posture at Extend and refuses Contribute, Co-found and Drive on that basis",
"Declines the chair position",
"Names the product whose demand would rise if this layer got cheaper, and finds it is not Tessral's",
"States that a standard commoditizes the layer it covers by design",
"Justifies nothing on visibility, category leadership or ecosystem-citizenship grounds",
"Warns that standardizing score normalization hands the six vendors interchangeability with Tessral",
"Presents two or three candidate bundles rather than a bare yes or no",
"Names what each candidate bundle forecloses within two years",
"If engaging at all, specifies implementation plus documented extensions, with public documentation and graceful degradation as the obligation owed",
"Decides on the commoditization test rather than on whether the 18-month engineer commitment is affordable"
]
},
{
"id": 4,
"prompt": "There are nine of us at Brindle. We built a config-sync protocol for edge devices and we want to publish it as an open standard and get the whole ecosystem onto it. The incumbent is Aurelen's proprietary EdgeSync: roughly 80% of deployed gateways speak it, Aurelen also owns the two fleet-management products everyone buys alongside, and they've been shipping for 11 years. We have one very large pilot customer, a utility with 40,000 gateways, who loves our approach and can't stand Aurelen. Seed money covers maybe 14 months. How do we win this?",
"expected_output": "A control-test scoring against the seven key assets showing Brindle holds almost none, a recommendation of Contribute over Drive, and recruitment of the 40,000-gateway utility as a co-combatant.",
"files": [],
"expectations": [
"Names Shapiro and Varian's seven key assets as the control test's scoring frame",
"Scores Brindle against all seven assets rather than a subset: installed base, intellectual property rights, ability to innovate, first-mover advantage, manufacturing or operating-cost capability, strength in complements, and brand and reputation",
"Finds explicitly that Brindle holds few or none of the seven",
"States that no single asset is decisive",
"Counts the 40,000-gateway utility as a controllable asset, because a large customer controls part of the installed base",
"Recommends recruiting that customer as a co-combatant rather than only as a reference or logo",
"Does not recommend Drive as the posture",
"Names Contribute as the ladder's answer for a team holding none of the seven assets, because it buys influence over the same spec without requiring them to win it",
"Classifies the fight by which side is backward-compatible with what is already installed, before choosing tactics",
"Prices the 14-month runway against the venue's real pace instead of assuming the spec can be won inside it",
"Notes that penetration pricing or giving the technology away is hard to fund when building a coalition around an open standard, because no single supplier carries the losses without a sponsor's control to recoup them",
"Does not recommend a feature-superiority push as the route to displacing an 80% installed base"
]
},
{
"id": 5,
"prompt": "Okay, so: Nordhall. We publish the OpenLedgerFeed spec for accounting-system event streams, 6 independent implementations. Our competitor Marrowcast published LedgerWire eight months ago, 5 implementations. Both do exactly the same job. Since April every enterprise deal has stalled on \"we're waiting to see which one wins.\" Our board wants us to out-ship them: three new features next quarter plus a big marketing push on our adoption numbers. Worth knowing: Marrowcast's format reads the legacy CSV drop convention that every existing ERP integration already emits, and ours requires a rewrite. Give me the plan to win.",
"expected_output": "A classification of the battle as Revolution versus Evolution with Nordhall on the incompatible side, followed by a merge proposal on named terms rather than a feature race.",
"files": [],
"expectations": [
"Classifies the situation as the fragmentation case rather than a feature race",
"Classifies the battle type by backward compatibility with the technology already installed",
"Names the classification as Revolution versus Evolution, with Marrowcast compatible and Nordhall incompatible",
"States that absent compelling performance the compatible side wins slowly by default",
"Recommends proposing a merge or truce rather than a faster Drive or the three-feature push",
"Cites Shapiro and Varian, \"The Art of Standards Wars\", by name as the source of the truce argument",
"Notes that an early truce can benefit consumers as well as vendors, and can therefore pass antitrust muster",
"Recommends building the position before opening truce talks, because strength in battle is the currency at the table",
"Specifies bridges preserving backward compatibility with both predecessor specs as a merge term",
"Specifies a dated end to parallel development as a merge term",
"Positions the merged spec as the next major version of both, not as a third option",
"Seats a governance body with both sides from day one",
"States what the merge costs Nordhall, including roadmap control and the \"we won\" narrative, against the unblocked adoption it buys"
]
},
{
"id": 6,
"prompt": "We're past the should-we stage. Caldmere, data-pipeline vendor, 60 people. We're co-founding a spec for dataset lineage handoff with two peer vendors, each of whom has committed a named engineer for two years. We hold no patents and we have never licensed IP to anyone. No browser has to implement this, it's a server-to-server manifest format. Nobody here sells to government. One of the two peers, Tarn Systems, told us in writing that they will not implement a spec that lives in Caldmere's GitHub org. Our lawyer wants to know by Thursday which body we're using and what the patent terms are. Internally the options on the table are: our own repo, a foundation, joining OASIS, IETF, W3C, or going for an ISO number.",
"expected_output": "A venue recommendation that starts from a Git-based spec, moves exactly one step right because of the named refusal, lands on a foundation host, defaults to royalty-free, and states the two charter-time irreversible decisions.",
"files": [],
"expectations": [
"States a Git-based community specification as the default venue",
"Moves exactly one venue to the right because Tarn Systems stated in writing it will not implement a spec in Caldmere's repository",
"Recommends a foundation-hosted venue as the resulting choice",
"Identifies that named refusal, not a general preference for formal process, as what neutrality is being bought to answer",
"Deletes ISO from the list because no tender, regulator or public buyer requires a standard number here",
"Deletes or deprioritizes W3C because no browser has to implement the surface",
"Removes the RAND branch because Caldmere holds no monetizable patents",
"Makes royalty-free the default patent-licensing mode",
"States that IETF outranks a paid-membership consortium on both efficiency and neutrality, because participation is individual and free and no membership tier gates who is in the room",
"States that an industry consortium leads compliance cost because its IPR mode cannot change without closing the technical committee and re-chartering",
"Names the two decisions fixed at charter time and not quietly revisable later: the patent-licensing regime and who owns the trademark",
"States that a royalty-bearing regime would put the spec out of reach of most open-source implementers",
"Refers the patent-portfolio and contributor-agreement specifics to counsel instead of giving legal advice",
"Presents the venue orderings explicitly across more than one axis rather than implying a single blended rank"
]
},
{
"id": 7,
"prompt": "Vantefor ships v1 of our device-provisioning spec in six weeks. Plan so far: we hand anyone who asks a \"Vantefor Compatible\" logo, we write the test suite in Q3 once we see who actually implements, and we're thinking $5,000 per certification with our solutions architects observing each run over screen share so we can vouch for the quality. The goal is 20 implementations in year one, mostly small hardware shops plus two funded OEMs. Sanity-check this for me.",
"expected_output": "A conformance plan reordered by efficiency: version the mark and stand up the registry first, ship the suite with v1, drop witnessed testing, and make passing free against the 20-implementation goal.",
"files": [],
"expectations": [
"Works the four conformance decisions in efficiency order, starting with the versioned mark",
"Requires the mark to state which spec version it certifies and when it expires, decided before any implementation carries it",
"States that the versioned mark and the public registry are the two decisions that cannot be retrofitted",
"Rejects deferring the test suite to Q3 and requires it shipped with v1",
"Names the paper-standard failure mode: with no test suite every vendor claims support and buyers find the gaps in production",
"Specifies one maintained public registry page of certified implementations, and notes that buyers consult the registry rather than the claim",
"Rejects witnessed testing for this market and deletes it rather than leaving it on the menu as an option",
"States that self-service testing scales while witnessed testing is a standing job",
"Recommends free certification over the $5,000 fee, given the 20-implementation goal",
"States that the fee decision is made against the adoption goal, not against cost recovery",
"Notes that self-service and free tie on compliance cost, because neither obliges Vantefor to anything beyond publishing the result",
"Warns that gating the patent licence on conformance cannot be unwound once implementers hold licences under it",
"Cites the Khronos Adopters Program as the programme pairing a passed test with both name and logo rights and a licence to members' essential patents"
]
},
{
"id": 8,
"prompt": "Draft the KPI section and the stop condition for our standards decision record. Here's what I have so far: \"Industry standard is two independent interoperating implementations, and the accepted benchmark is that you need them within 12 months of v1 with at least one implementer who isn't a customer.\" Add conformance pass rate too. Context: the spec is HarborLink, we drive it, v1 published last month, review in a year, I own it. Six vendors have told us they're interested.",
"expected_output": "A KPI table tagging each threshold sourced or baseline, correcting the 12-month figure's provenance, plus a kill rule carrying an obligation to existing implementers.",
"files": [],
"expectations": [
"Tags the two-independent-interoperating-implementations threshold as sourced",
"Attributes that threshold to RFC 6410 section 2.2, the IETF's maturity bar for promoting a Proposed Standard to Internet Standard",
"Corrects the user's claim that the 12-month window is an industry standard or an accepted benchmark",
"Tags the 12-month clock and the non-customer-implementer condition as a baseline the user is expected to replace",
"States that RFC 6410 sets no deadline",
"Suggests replacing the baseline horizon with one drawn from the market's own cycle, such as the segment's buying cycle or the release cadence of the frameworks that must adopt it",
"Produces a KPI table with a column marking each threshold sourced or baseline",
"Uses independent implementations the company does not control as the headline KPI for a Drive posture",
"Includes conformance pass rate across implementations and the share of the target integration surface the standard covers",
"Treats \"six vendors have told us they're interested\" as uncounted demand and asks for named implementers instead",
"Writes a kill rule stating what happens when the threshold is missed, with a concrete action such as de-escalating to a lower posture, donating the spec, or withdrawing",
"States the obligation owed to existing implementers inside the kill rule: a notice period, a bridge or documented successor, and a migration path",
"States why the kill rule must be written at the decision: standards programmes are rarely cancelled, because withdrawal reads as defeat"
]
},
{
"id": 9,
"prompt": "Short one. We're Pellmoor, a mid-market HR analytics tool. Three deals this quarter came with a procurement questionnaire asking \"is your product certified against the SecureExchange 4 profile?\" and we've been answering \"we're compatible.\" Our CTO says certification is bureaucratic theatre and wants to keep saying compatible. What do I tell him?",
"expected_output": "A scoped conform-or-not answer covering the fee, the version certified and the registry entry, promoting Conform because procurement named the mark.",
"files": [],
"expectations": [
"Scopes the answer to the landscape work and the conformance decision only, without running the full seven-rung posture ladder",
"Produces a conform-or-not recommendation rather than a general standards strategy",
"Names the certification fee, the spec version certified, and the registry entry as the three things the answer needs",
"Establishes whether SecureExchange 4 has a conformance suite and a certification mark before advising",
"Promotes Conform above the other rungs because a procurement questionnaire naming the mark turns it into market access rather than a preference",
"States that Conform buys a checkable claim, and that \"we're compatible\" is not one",
"Names re-certification per spec version as the standing obligation Conform creates",
"Counts the three named deals as demand evidence",
"Checks whether passing conformance also conveys a patent licence",
"Recommends neither joining a working group, nor contributing spec text, nor publishing a rival profile",
"Notes that which spec version the mark certifies matters, because an unversioned or expired mark ends up attached to implementations of a spec nobody uses any more"
]
},
{
"id": 10,
"prompt": "Halcyon Grid owns the Streamvane spec, published three years ago, about 40 implementations out there. Over time we added roughly a dozen fields to our own implementation that were never in the spec, because customers asked and we shipped fast and nobody wrote them down. Now we want to cut over to Streamvane 2, which drops half of them. The plan is a blog post giving everyone 60 days, then we turn off v1 support in our cloud and archive the v1 repo. Separately, a much bigger vendor, Calderwood, has started shipping their own extra fields and their version is quietly becoming what integrators mean when they say \"Streamvane\". I need two things written: the sunset announcement and a response to Calderwood.",
"expected_output": "A refusal of the 60-day sunset plan with a proper migration obligation, plus a conformance-and-trademark counter to Calderwood and a cleanup of Halcyon Grid's own undocumented extensions.",
"files": [],
"expectations": [
"Names embrace, extend, extinguish as the pattern Calderwood is executing against Streamvane",
"Recommends a conformance suite and a trademark as the counter to Calderwood's dialect",
"Recommends spec text defining the required behaviour for unknown extensions",
"Identifies Halcyon Grid's own dozen undocumented fields as the same move committed by the spec owner, stranding their customers on a dialect only Halcyon Grid implements",
"Requires those fields to be namespaced and documented, with the useful ones proposed upstream",
"Rejects the 60-day blog-post sunset as the plan",
"States that whoever owns a spec owns the migration off it",
"Requires the replacement to be shipped and proven before v1 is withdrawn, not alongside it",
"States that implementers depend on the spec's undocumented behaviour as much as on its text",
"Requires a notice period, a bridge, and a documented successor before withdrawal",
"Rejects archiving the v1 repository as part of the 60-day cutover",
"Requires a versioning and migration path published with the new version, before there is an installed base to defend"
]
}
],
"trigger_queries": [
{
"query": "Should we join the working group standardizing agent tool-calling, or ship our own format?",
"should_trigger": true
},
{
"query": "A competitor just published a rival spec to ours and buyers are stalling.",
"should_trigger": true
},
{
"query": "Should we donate our protocol to a neutral foundation?",
"should_trigger": true
},
{
"query": "Procurement keeps asking whether we're certified against their interop profile.",
"should_trigger": true
},
{
"query": "What posture should we take toward this new protocol?",
"should_trigger": true
},
{
"query": "Is it worth sending an engineer to IETF meetings for the next two years?",
"should_trigger": true
},
{
"query": "We want to make our wire format the standard for this category.",
"should_trigger": true
},
{
"query": "Every customer wants a different integration format and we're drowning in adapters.",
"should_trigger": true
},
{
"query": "Should we build a conformance test suite for the protocol we publish?",
"should_trigger": true
},
{
"query": "RAND or royalty-free for the spec we're about to charter?",
"should_trigger": true
},
{
"query": "Our biggest competitor sits on the technical committee and we don't. Does that matter?",
"should_trigger": true
},
{
"query": "A partner says they won't implement our spec while it lives in our GitHub org.",
"should_trigger": true
},
{
"query": "Do we need an ISO number to win public tenders?",
"should_trigger": true
},
{
"query": "Is there any point standardizing our plugin interface?",
"should_trigger": true
},
{
"query": "Write us an open standards strategy.",
"should_trigger": true
},
{
"query": "Should we certify against their profile or just keep claiming support?",
"should_trigger": true
},
{
"query": "We keep paying for one-off integrations. Is a shared format worth building?",
"should_trigger": true
},
{
"query": "Our spec has no test suite and three vendors claim they support it. Now what?",
"should_trigger": true
},
{
"query": "Should we add our own fields to the protocol or propose them upstream?",
"should_trigger": true
},
{
"query": "The consortium wants $60k a year for membership. Is that worth it?",
"should_trigger": true
},
{
"query": "How do we stop a bigger vendor from forking our format into their own dialect?",
"should_trigger": true
},
{
"query": "Who ends up owning the trademark if we hand the spec to a neutral host?",
"should_trigger": true
},
{
"query": "Two specs exist for the same job and neither is winning. What should we do?",
"should_trigger": true
},
{
"query": "Can we change the patent licensing terms after the charter is signed?",
"should_trigger": true
},
{
"query": "We want to own the roadmap of this protocol. What does that actually cost us?",
"should_trigger": true
},
{
"query": "Is it better to co-found a spec with two peers or publish ours alone?",
"should_trigger": true
},
{
"query": "Should we implement the draft now or wait until it's finalized?",
"should_trigger": true
},
{
"query": "When do we kill a standards effort that isn't landing?",
"should_trigger": true
},
{
"query": "How many independent implementations does a spec need before it's real?",
"should_trigger": true
},
{
"query": "Our CEO wants us to lead on open standards next year. Where do I even start?",
"should_trigger": true
},
{
"query": "A regulator now references a spec we don't implement.",
"should_trigger": true
},
{
"query": "we shipped a bunch of extensions nobody documented and now customers are stuck on our flavour",
"should_trigger": true
},
{
"query": "should we open up our file format so other tools can read it",
"should_trigger": true
},
{
"query": "The framework everyone uses already has a format that's about 80% of what we need.",
"should_trigger": true
},
{
"query": "W3C or IETF for a brand new protocol?",
"should_trigger": true
},
{
"query": "What do we owe implementers if we retire v1 of our spec?",
"should_trigger": true
},
{
"query": "How do we decide between joining an existing effort and starting our own?",
"should_trigger": true
},
{
"query": "Our integration surface is nine frameworks times three per customer. Is there a smarter way?",
"should_trigger": true
},
{
"query": "They announced a spec before shipping anything. Should we respond?",
"should_trigger": true
},
{
"query": "Do we charge for conformance certification or make it free?",
"should_trigger": true
},
{
"query": "Who should own the certification mark?",
"should_trigger": true
},
{
"query": "What's the risk of standardizing the exact layer our product sits on?",
"should_trigger": true
},
{
"query": "we want to be seen as the neutral option in this space",
"should_trigger": true
},
{
"query": "The spec we depend on is controlled by a single vendor. How exposed are we?",
"should_trigger": true
},
{
"query": "Should engineering spend a quarter writing drafts for that protocol?",
"should_trigger": true
},
{
"query": "Is a Git-based spec good enough or do we need a real standards body?",
"should_trigger": true
},
{
"query": "How do I write this up so legal and product both sign off on it?",
"should_trigger": true
},
{
"query": "I need a one-pager on where we land on this protocol.",
"should_trigger": true
},
{
"query": "Someone has to decide whether we adopt their format or fight it.",
"should_trigger": true
},
{
"query": "our roadmap keeps getting hijacked by interop requests",
"should_trigger": true
},
{
"query": "Can we keep charging for the connector layer if it gets standardized?",
"should_trigger": true
},
{
"query": "What happens to us if we do nothing about this protocol for twelve months?",
"should_trigger": true
},
{
"query": "Should we pass their certification or build our own?",
"should_trigger": true
},
{
"query": "Their format is backward compatible with the old one and ours isn't. How bad is that?",
"should_trigger": true
},
{
"query": "Who decides what gets merged in our project?",
"should_trigger": false
},
{
"query": "Write a GOVERNANCE.md for our repo.",
"should_trigger": false
},
{
"query": "We need a maintainer promotion path and a succession plan.",
"should_trigger": false
},
{
"query": "Our project has a bus factor of one. How do we fix that?",
"should_trigger": false
},
{
"query": "How should we run a maintainer vote on a contested decision?",
"should_trigger": false
},
{
"query": "MIT or Apache-2.0 for our new library?",
"should_trigger": false
},
{
"query": "Should we require a CLA or a DCO sign-off from contributors?",
"should_trigger": false
},
{
"query": "Does AGPL actually protect us from cloud providers?",
"should_trigger": false
},
{
"query": "How do we relicense to BUSL without triggering a fork?",
"should_trigger": false
},
{
"query": "Which SPDX identifier goes in our file headers?",
"should_trigger": false
},
{
"query": "Should we let third parties build integrations on top of our API?",
"should_trigger": false
},
{
"query": "Why does nobody build on our platform?",
"should_trigger": false
},
{
"query": "How much of the value should complementors get to keep?",
"should_trigger": false
},
{
"query": "Open core or managed cloud for our developer tool?",
"should_trigger": false
},
{
"query": "Where should the free-versus-paid line sit in our devtool?",
"should_trigger": false
},
{
"query": "Adoption is high but revenue is flat. What's wrong?",
"should_trigger": false
},
{
"query": "What should we open source and what stays closed?",
"should_trigger": false
},
{
"query": "Who signs off internally on open sourcing a component?",
"should_trigger": false
},
{
"query": "Which registries and awesome lists should we target for our project?",
"should_trigger": false
},
{
"query": "Adoption flattened after launch. How do people keep finding the project?",
"should_trigger": false
},
{
"query": "Write the migration guide for our v3 breaking changes.",
"should_trigger": false
},
{
"query": "How do we tell users about the v2 API cutover?",
"should_trigger": false
},
{
"query": "What should our deprecation timeline look like for the old endpoints?",
"should_trigger": false
},
{
"query": "Turn these 80 commits into release notes.",
"should_trigger": false
},
{
"query": "What goes in the GitHub release body for this tag?",
"should_trigger": false
},
{
"query": "How does our docs quality compare to our main competitor's?",
"should_trigger": false
},
{
"query": "What is our competitor doing in developer relations right now?",
"should_trigger": false
},
{
"query": "We're launching the repo next month. What's the launch plan?",
"should_trigger": false
},
{
"query": "Our quickstart takes 40 minutes. Fix it.",
"should_trigger": false
},
{
"query": "Restructure our documentation site's information architecture.",
"should_trigger": false
},
{
"query": "Should our API version live in the URL or in a header?",
"should_trigger": false
},
{
"query": "Design idempotency keys for our payments endpoint.",
"should_trigger": false
},
{
"query": "Set coding standards for our TypeScript monorepo.",
"should_trigger": false
},
{
"query": "What SOC 2 controls do we need before the audit?",
"should_trigger": false
},
{
"query": "Write our security policy so we can get ISO 27001 certified.",
"should_trigger": false
},
{
"query": "Draft a data retention standard for our warehouse tables.",
"should_trigger": false
},
{
"query": "Standardize our error codes across all microservices.",
"should_trigger": false
},
{
"query": "Review this patent application for our compression algorithm.",
"should_trigger": false
},
{
"query": "Negotiate the patent cross-licence with our competitor's counsel.",
"should_trigger": false
},
{
"query": "Write a press release about us joining the foundation.",
"should_trigger": false
},
{
"query": "Draft a conference CFP submission about our protocol.",
"should_trigger": false
},
{
"query": "Plan the sponsorship tiers for the standards summit we're backing.",
"should_trigger": false
},
{
"query": "How should we staff our devrel team next year?",
"should_trigger": false
},
{
"query": "What metrics prove devrel ROI to the CFO?",
"should_trigger": false
},
{
"query": "Write a blog post explaining how our new protocol works.",
"should_trigger": false
},
{
"query": "Build the partner certification steps for apps listed in our marketplace.",
"should_trigger": false
},
{
"query": "Set up automated conformance tests in CI for our REST API.",
"should_trigger": false
},
{
"query": "Which HTTP status code should a rate-limited request return?",
"should_trigger": false
},
{
"query": "Write the customer email announcing our v1 API deprecation.",
"should_trigger": false
},
{
"query": "Standardize the interview loop for hiring backend engineers.",
"should_trigger": false
},
{
"query": "Benchmark our protocol's throughput against gRPC.",
"should_trigger": false
},
{
"query": "Migrate our internal RPC layer from Thrift to gRPC.",
"should_trigger": false
},
{
"query": "Choose a serialization format for our internal microservices.",
"should_trigger": false
},
{
"query": "Write a CONTRIBUTING.md for our repository.",
"should_trigger": false
}
]
}
references/decision-record-template.md›
# Decision record template and worked examples
Contents: [Template](#template) · [Worked example 1: driving a spec](#worked-example-1-driving-a-spec-that-collapses-an-nm-problem) · [Worked example 2: rival spec](#worked-example-2-answering-a-rival-spec) · [Negative example](#negative-example-what-a-bad-record-looks-like) · [Public precedents](#public-precedents-worth-citing)
## Template
```markdown
# Standards decision: <specification name>
Date: <YYYY-MM-DD> · Owner: <person> · Review: <date>
## Landscape
- Specs covering this job, their venue, stage, IPR mode.
- Implementations, split into vendor-controlled and independent.
- Our counted demand: deals, tickets, RFPs naming this standard.
- Conformance suite and certification mark: exists / does not exist.
## Decision
Posture: <ignore | consume | conform | extend | contribute | co-found | drive>
Because: <2-4 sentences, including the layer being commoditized and the product whose demand rises>
## Alternatives rejected
- <posture>: rejected because <test it failed: demand, commoditization, control, cost>
- <posture>: rejected because <...>
## Venue and IPR (only if contribute or above)
Venue: <...> · IPR mode: <RF / non-assert / RAND> · Trademark holder: <...>
Charter-time commitments we cannot revise later: <...>
## Conformance plan
Test suite owner · who may run it · fee · certified spec version and expiry · public registry location.
## Staffing
Named person, hours per month, committed horizon.
## KPIs and thresholds
| Metric | Threshold | Sourced or baseline | By when |
| ------ | --------- | ------------------- | ------- |
## Kill rule
If <metric> is below <threshold> on <date>, we <de-escalate to posture X / donate / withdraw>,
and our obligation to existing implementers is <notice period, bridge or successor, migration path>.
```
Tag every threshold in the third column. "Sourced" needs a name a reader can check (RFC 6410, a venue's own process document, a published study); anything else is "baseline" and is expected to be argued with.
## Worked example 1: driving a spec that collapses an N×M problem
**Situation.** A vendor of observability tooling integrates with 9 agent frameworks; each customer wants their own 3. Each framework pairing costs weeks and breaks on every upgrade.
**Landscape.** No spec covers the job. Two competitors ship proprietary adapters. Counted demand: 14 deals in 12 months named at least one missing integration.
**Tests.**
- Demand: passed, named accounts.
- Commoditization: the standardized layer is the wire format between framework and collector - a layer the company does not sell; it sells the analysis on top.
- Control: 40% share of the collector market and the only cross-framework tooling.
- Cost: two engineers for four quarters is fundable.
**Decision.** Drive, with a Git-based community specification, royalty-free, reference implementation under a permissive licence, conformance suite shipped with v1.
**Why this shape.** The pattern that made the Language Server Protocol work applies: integration effort "must be repeated for each development tool, as each provides different APIs", and a common protocol turns M×N into M+N. Language-neutral primitives, not framework-specific constructs, are what make the spec adoptable by parties who dislike each other.
**KPIs.**
- Two independent interoperating implementations - _sourced_, from RFC 6410 §2.2's bar for Internet Standard status.
- Within 12 months of v1, at least one from a party that is not a customer, and 6 of the 9 frameworks covered - _baseline_, chosen from this market's annual framework release cadence, not from any published norm.
- Conformance suite passed by every implementation claiming support - _baseline_.
**Kill rule.** Fewer than two independent implementations at month 12 → stop investing in the spec, keep the adapters as product features, and publish a note saying so rather than letting the spec rot in public. Anyone who already implemented v1 gets 6 months' notice and a maintained adapter, because withdrawal is our decision and theirs is the sunk cost.
**Exit.** If adoption crosses the threshold, donate the spec to a neutral host to remove the "one vendor controls this" objection, before a competitor stands up a rival neutral spec.
## Worked example 2: answering a rival spec
**Situation.** Your spec has 6 implementations; a competitor's has 5. Both cover the same job. Adoption of both is stalling, and buyers say they are waiting for the market to settle.
**Analysis.** This is the fragmentation case, not a feature race. The OpenTelemetry precedent is direct: the merged project's own framing was that "the biggest problem with either project has been the fact that there were two of them", and "the main benefit to the ecosystem is the consolidation itself – not some specific and shiny new feature". Shapiro and Varian reach the same conclusion from the economics: "declaring an early truce in a standards war can benefit consumers as well as vendors, and thus pass antitrust muster", and pressure to negotiate rises with the cost of the fight to both sides.
**Decision.** Propose a merge rather than a feature push, on the terms that made that precedent work:
- bridges preserving backward compatibility with both predecessors
- a dated end to parallel development
- positioning of the merged spec as the next major version of both rather than a third option
- a governance body seated with both sides from day one
**What this costs.** Roadmap control and the sunk narrative of "we won". What it buys is the only thing that matters at this point: unblocked adoption for the merged spec.
## Negative example: what a bad record looks like
```markdown
# Standards decision: OpenFoo
Posture: contribute. We believe in open standards and want to be good ecosystem citizens.
We will join the working group and send an engineer to meetings.
Success: increased visibility in the community.
```
Four defects, each fatal on its own:
1. **No named change.** Attendance without a target revision buys travel expense, not influence - text and sustained presence are what move consensus venues.
2. **No commoditization test.** Nobody checked whether the spec covers the layer the company sells. Standardising your own differentiator hands competitors interchangeability with you.
3. **Unmeasurable success.** "Visibility" cannot fail, so the programme can never be stopped.
4. **No IPR or staffing reality.** Charter-time patent commitments and multi-year attendance were never priced.
## Public precedents worth citing
- **RFC 6410 §2.2** - the IETF's maturity bar: "There are at least two independent interoperating implementations with widespread deployment and successful operational experience." The one implementation-count threshold in this skill that is genuinely sourced.
- **Shapiro & Varian, "The Art of Standards Wars"** (_California Management Review_ 41:2, Winter 1999) - the four battle types, the seven key assets and the truce argument.
- **Language Server Protocol** - the M×N framing: one server reusable across tools, tools supporting languages "with minimal effort"; language-neutral primitives (document URIs, text positions) kept the protocol simple enough to adopt.
- **OpenTelemetry** - consolidation of OpenTracing and OpenCensus; bridges for backward compatibility, predecessors moved to read-only mode within the year, merged project framed as the next major version of both.
- **PDF** - de facto first via free readers, formalised afterwards as ISO 19005-1:2005 and ISO 32000-1:2008; the standard number followed adoption, it did not create it.
- **Khronos Adopters Program** - conformance separated from membership ("A company does not have to be a member of Khronos in order to become an Adopter"), tiered fees (OpenGL 3.2–4.5 at $25,000 for members, $30,000 for non-members; WebGL free), and passing grants both logo rights and a licence to members' essential patents.
- **Embrace, extend, extinguish** - the _United States v. Microsoft_ record, including the 1998 Gates memo that "allowing Office documents to be rendered very well by other people's browsers is one of the most destructive things we could do to the company"; cite it when arguing for a conformance mark rather than as a tactic to copy.
references/standards-war-framework.md›
# Standards-war framework (Shapiro & Varian)
Contents: [Source](#source) · [When it applies](#when-it-applies) · [Four battle types](#four-battle-types) · [Seven key assets](#seven-key-assets) · [Two tactics](#two-tactics) · [How wars end](#how-wars-end-and-why-to-price-a-truce-first) · [After winning](#after-winning) · [How to use it in a posture decision](#how-to-use-it-in-a-posture-decision) · [Worked classification](#worked-classification)
## Source
Carl Shapiro and Hal R. Varian, "The Art of Standards Wars", _California Management Review_, Vol. 41, No. 2, Winter 1999, pp. 8-32; adapted by the authors from _Information Rules: A Strategic Guide to the Network Economy_ (Harvard Business School Press, 1998). Every quotation below is from that article. Cite it by name - it is the canonical framework for this decision, and naming it saves you arguing the logic from first principles.
## When it applies
The framework governs "battles for market dominance between incompatible technologies" in markets with "strong _network effects_ that cause consumers to play high value on compatibility". Two consequences:
- No network effects, no standards war. A format nobody else has to agree with is a product decision, not a standards decision.
- Not every new technology triggers one. Sony and Philips "pooled together and openly licensed their CD patents"; they "were not in a battle with another new technology" because no rival incompatible technology was contesting the same adopters.
## Four battle types
Classify by which side offers backward compatibility with the technology already installed. "The critical distinguishing feature of the battle is the magnitude of the switching costs, or more generally the adoption costs, for each rival technology."
| | Rival compatible | Rival incompatible |
| -------------------- | --------------------------- | --------------------------- |
| **You compatible** | Rival Evolutions | Evolution versus Revolution |
| **You incompatible** | Revolution versus Evolution | Rival Revolutions |
- **Evolution** strategy = "superior performance with minimal consumer switching or adoption costs".
- **Revolution** strategy = "such compelling performance that consumers are willing to incur significant switching or adoption costs".
- **Rival Evolutions**: DVD vs. Divx, the 56k modem battle, competing Unix flavours. Both sides read the old world; the fight is over features and allies.
- **Evolution versus Revolution**: includes "the important case of an upstart fighting against an established technology that is offering compatible upgrades".
- **Rival Revolutions**: Nintendo 64 vs. Sony PlayStation, AC vs. DC.
Read the table, not the prose: the article's text says "three distinct flavors" and then enumerates four cells.
## Seven key assets
"Your ability to successfully wage a standards war depends on your ownership of seven key assets":
1. control over an installed base of users
2. intellectual property rights
3. ability to innovate
4. first-mover advantages
5. manufacturing capabilities
6. strength in complements
7. brand name and reputation
Two qualifiers that do most of the work in practice:
- "No one asset is decisive." Atari's large installed base lost to Nintendo's superior technology; Sony and Philips controlled CDs but "could not move unilaterally into DVDs".
- "Don't forget that _customers_ as well as technology suppliers can control key assets, too. A big customer is automatically in 'control' of at least part of the installed base." A large adopter can therefore be recruited as a co-combatant, not just as a reference.
For a software or infrastructure vendor, assets 5 and 7 usually translate to operating cost per unit of scale and to whether developers already trust your specs.
## Two tactics
- **Preemption** - "build an early lead, so positive feedback works for you and against your rival." Its instruments are penetration pricing and, for zero-marginal-cost software, free or negative pricing. Three checks before giving it away:
- do free users generate network externalities for paying ones
- what is the installed base actually worth and when does the offsetting revenue arrive
- are you falling for the "Winner's Curse"
Note the constraint that bites open specs: "Penetration pricing may be difficult to implement if you are building a coalition around an 'open' standard", because no single supplier will fund the losses without a sponsor's control to recoup them.
- **Expectations management** - "The second key tactic in standards wars is the management of expectations." The legitimate form is "assembling allies and by making grand claims about your product's current or future popularity". The abusive form is vaporware, cited against Microsoft in the 1994 consent-decree ruling.
## How wars end, and why to price a truce first
"Standards wars can end in: a _truce_, as happened in 56k modems and color television where a common standard was ultimately adopted; a _duopoly_, as we see in video games today with Nintendo and Sony battling toe-to-toe: or a _fight to the death_, as with railroad gauges, AC versus DC electric power, and videotape players."
The truce argument, which is the sourced backing for proposing a merge instead of a feature race:
- "Before entering into a standards battle, would-be combatants are well-advised to consider a peaceful solution."
- "Unlike many other aspects of competition, where coordination among rivals would be branded as illegal collusion, declaring an early truce in a standards war can benefit consumers as well as vendors, and thus pass antitrust muster."
- "the more costly a battle is to both sides, the greater are the pressures to negotiate a truce; and one's strength in battle is an overriding consideration when meeting to conduct truce talks."
That last clause sets the sequencing: build the position first, then talk, because your assets are the currency at the table.
## After winning
- **Migration path**: "If you cannot improve your technology with time, while offering substantial compatibility with older versions, you will be overtaken sooner or later. Rigidity is death." The Minitel case is the article's illustration of harvesting an installed base by default rather than by decision.
- **Commoditize complements**: "Your goal should be to retain your franchise as the market leader, but have a vibrant and competitive market for complements to your product" - the same logic as the commoditization test in the main skill.
- **Preemption's hangover**: "Going early usually means making technical compromises, which gives that much more room for others to execute an incompatible Revolution strategy against you."
## How to use it in a posture decision
The framework describes the fight; the posture ladder decides whether to fight at all. Use it in two places only:
1. **The control test.** Score the seven assets honestly. A team holding none of them that still proposes Drive is choosing a war it cannot fund; the honest posture is Contribute.
2. **When a rival spec already exists.** Classify the battle first, because the type sets the tactic.
- Rival Evolutions rewards allies and expectations management.
- Rival Revolutions rewards preemption and raw performance.
- Anything Evolution-versus-Revolution turns on whether your compatibility advantage outlasts their performance advantage.
Do not stretch it further. It is a 1999 framework about product markets with network effects; it says nothing about venue choice, IPR mode or conformance programmes, which the main skill covers through its own venue reference.
## Worked classification
A constructed scenario, not a documented case - it shows the classification mechanics, so do not cite it as precedent. A vendor publishes a new wire format for agent-to-tool calls. An incumbent framework ships its own format that also parses the older convention every existing integration uses; the vendor's does not.
- Rival is compatible with the installed technology, you are not → **Revolution versus Evolution**.
- Implication from the framework: you are asking adopters to pay switching costs the incumbent is not, so you need "such compelling performance" that they accept it. Absent that, the article's own reading is that the compatible side wins slowly by default.
- Asset check: you hold ability to innovate and brand among a niche; the incumbent holds installed base and complements. Four of seven against you.
- The conclusion the framework pushes toward is not "fight harder" - it is the truce: propose bridging both formats before either has enough adopters for a fight to the death to be worth funding.
references/venue-and-ipr-options.md›
# Venue and IPR options
Contents: [Choosing quickly](#choosing-quickly) · [Git-based community specification](#git-based-community-specification) · [Foundation-hosted consortium](#foundation-hosted-consortium) · [OASIS-style consortium](#oasis-style-consortium) · [IETF](#ietf) · [W3C](#w3c) · [ISO transposition](#iso-transposition) · [Patent regimes](#patent-regimes-in-one-page) · [Questions to ask a venue](#questions-to-ask-a-venue-before-joining)
## Choosing quickly
| Need | Venue |
| -------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Ship a spec in weeks, keep control, add legal hygiene | Git-based community specification |
| Prove neutrality fast, several companies co-founding | Foundation-hosted consortium (e.g. Joint Development Foundation-style) |
| Enterprise data formats, members expect formal process | OASIS-style consortium |
| Wire protocols, open participation, engineering culture | IETF |
| Web-platform surface, browsers must implement | W3C |
| A tender, regulator or public buyer requires a standard number | ISO transposition of an existing de facto standard |
Speed and control decrease down the table; credible neutrality increases. This is a lookup by need, not a ranking - the efficiency, neutrality, effort and compliance-cost orderings live in the skill's Step 4, where the venue is actually chosen.
## Git-based community specification
Runs specification development in a repository with the legal layer attached:
- contributor licence
- specification licence
- scope
- governance
- contributing guide
- code of conduct
- spec template
The Community Specification 1.0 is the widely used instance of this pattern, developed through the Joint Development Foundation and drawing on the Open Web Foundation agreements and the Alliance for Open Media Patent License 1.0.
Specification licences are deliberately not open-source licences: a spec is "a blueprint developers implement in different ways in many different codebases", so the licence covers implementations of the whole specification rather than one codebase.
- **Cost**: near zero, plus your own maintainer time.
- **Buys**: velocity, a normal pull-request workflow, contributors who already know Git.
- **Does not buy**: neutrality - the repository owner still looks like the owner.
## Foundation-hosted consortium
A neutral host supplies incorporation, policies and IP options so a group of companies can start without negotiating a consortium from scratch. The Joint Development Foundation describes itself as offering "rapid-start, out-of-the box materials to create custom-branded non-profit technology consortia".
- **Offers**: an existing 501(c)(6) structure, no cost to start a project, optional services (accounting, certification, events, legal), and a route to advance the work into a larger standards organization later.
- **Buys**: neutrality with far less process weight than a formal standards body, and a defined escalation path.
- **Costs**: shared governance from day one; you can no longer change the spec unilaterally.
## OASIS-style consortium
Membership-based technical committees, with the patent regime fixed by the charter. OASIS offers four IPR modes:
- RAND
- RF on RAND Terms
- RF on Limited Terms
- Non-Assertion (a covenant not to assert)
The mode is effectively permanent - "a TC may not change its IPR Mode without closing and submitting a new charter". Patent obligations attach after presence thresholds (60 calendar days of participation, plus remaining active through approval ballots).
Practical consequence: pick the IPR mode as a strategic decision at charter time, not as a legal formality at the end.
## IETF
- **Participation**: open and individual. "IETF participation is voluntary and there is no top-down plan that requires any particular topic to be worked on or idea to be adopted." No membership fee; people participate, not companies.
- **Path**: Internet-Draft → working-group adoption call (about two weeks) → Working Group Last Call → IETF Last Call → IESG approval → RFC publication.
- **Decisions**: rough consensus, not votes. RFC 7282 records Dave Clark's formulation - "We reject: kings, presidents and voting. We believe in: rough consensus and running code" - and the working question "Can anyone not live with choice A?". A chair may declare rough consensus over a standing objection once that objection has been genuinely considered and answered.
- **IPR**: BCP 78 (RFC 5378) for contribution rights, BCP 79 (RFC 8179) for patent disclosure. Disclosure is mandatory; licensing terms are declared rather than dictated.
- **Implication**: influence comes from writing drafts and showing running code, not from company size or membership tier.
## W3C
- **Recommendation Track**: Working Draft → Candidate Recommendation ("ready for implementation experience") → Proposed Recommendation (Advisory Committee review) → Recommendation. Advancement requires evidence the specification "can be implemented interoperably".
- **Chartering**: charter refinement with wide review (minimum 28 days, up to six months), then Advisory Committee review (minimum 28 days, extendable to 60). Budget months before technical work starts.
- **Patent Policy**: royalty-free by design - specifications "can be implemented on a Royalty-Free (RF) basis", with licences "available to all, worldwide", not "conditioned on payment of royalties, fees or other consideration".
- **Essential Claims**: those that "would necessarily be infringed by implementation" where "there is no non-infringing alternative"; design patents, enabling technologies and non-normative implementation details are excluded.
- **Exclusion windows**: 150 days after the First Public Working Draft, 60 days after a Patent Review Draft for newly essential claims, 60 days after resigning from the Working Group. Miss the window and the royalty-free commitment binds.
## ISO transposition
ISO/IEC JTC 1 maintains a procedure for taking de facto standards "through the formal standardization system to be transformed into international standards". PDF is the reference run: an Adobe format, spread by free readers, then published as ISO 19005-1:2005 (PDF/A) and ISO 32000-1:2008.
Use it when a buyer, regulator or public tender needs an international standard number. It does not create adoption, and the process is the slowest of any venue here.
## Patent regimes in one page
- **Royalty-free (RF)**: participants licence Essential Claims at no cost. Required by W3C, available as several OASIS modes. Maximizes the implementer pool, including open-source projects.
- **Non-assertion covenant**: no licence granted, but a public promise not to sue implementers. Lighter to administer, weaker for implementers who need an explicit grant.
- **RAND / FRAND**: licensing on reasonable and non-discriminatory terms, potentially with royalties. Common in telecom and hardware. Most open-source projects cannot implement a royalty-bearing standard, so this caps grassroots adoption - a legitimate choice when your implementers are funded vendors, a strategic error when your plan assumed community uptake.
- **Conformance-gated licences**: some programmes grant the patent licence only to implementations that pass conformance testing, which turns the test suite into the IP gate as well as the quality gate.
Never join an RF venue expecting to keep monetizable claims out through exclusion windows: exclusions are narrow, dated and public.
## Questions to ask a venue before joining
1. What is the IPR mode, and can it change without re-chartering?
2. What did this group actually publish in the last two years, and how long did each document take?
3. Which companies do the active participants work for, and does one affiliation dominate?
4. Who owns the trademark and the conformance mark?
5. What does membership cost, in fees and in hours per month?
6. Who arbitrates when consensus fails, and what has that produced before?
SKILL.md›
---
name: open-standards-strategy
description: Decides how a company engages a named open standard or protocol - ignore it, consume it, certify conformance, extend it, contribute upstream, co-found a spec with peers, or drive its own as a de facto standard - plus the venue (Git-based spec, foundation, consortium, IETF/W3C/OASIS, ISO transposition), the patent-licensing mode, the conformance plan and the kill rule. Use whenever someone raises open standards participation, protocol strategy, standards body engagement, standards wars, joining versus competing with an emerging protocol, donating a specification to a neutral foundation, whether to standardize an interface at all, or a competitor's rival spec - even if they never say "standard". Not project governance - use samber/developer-relations-skills@oss-governance.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Open Standards Strategy
You are a technology-standards strategist. You help a company decide what posture to take toward one named specification or protocol, and you make that decision defensible in front of engineering, product and legal.
Four rules govern everything below.
- **Decide per standard, never in general.** "We support open standards" is a value, not a strategy. The unit of decision is one named spec, one time horizon, one owner.
- **A standard commoditizes the layer it covers.** That is its purpose. Useful when the layer being commoditized belongs to someone else, self-harming when it is what you sell.
- **Separate sourced numbers from your own baselines.** Tag every threshold sourced - traceable to a named standards body or published study - or baseline, a starting number the user is expected to replace. A baseline dressed up as an industry standard makes the record unarguable for the wrong reason: nobody can challenge a number whose origin is hidden.
- **You are not a lawyer.** Patent-licensing modes, exclusion windows and contributor agreements are described here as mechanics with consequences. Anything touching a real patent portfolio, an acquisition or a live dispute goes to counsel.
## Interview
Ask one question at a time, multiple-choice where you can. Stop as soon as you can name the standard, the posture question and the horizon - confirm the rest as you go.
**Name the standard and the trigger.**
**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. Which specification or protocol is this about, and who publishes it today - a vendor, a consortium, a formal standards body, or nobody yet?
2. What triggered the question: a customer or procurement asking for it, a competitor's announcement, an integration cost you keep paying, a regulator, or an internal proposal to publish your own?
**Locate their position.**
3. What do you sell, and which layer of your stack would the standard cover - a differentiator, a commodity layer, or the seam between you and other vendors?
4. What is your position in the market for this layer: incumbent with the installed base, credible challenger, or newcomer?
5. Who else would have to implement it for it to matter to you, and have any of them said anything in public?
**Price the engagement.** Patents and the effort ceiling rule out the expensive postures fastest - pull these forward whenever the user is already talking about Contribute, Co-found, or Drive.
6. Do you hold patents that could read on this area, and does your company monetize patent licensing at all?
7. What is your effort ceiling - an engineer part-time for a quarter, a named person for two-plus years, or a small team - and how much of it survives a change of sponsor?
8. What could you not walk back from once committed: a charter-time patent regime, a trademark you no longer control, or a spec whose migration you would owe implementers?
**Set the horizon.**
9. By what date must this have produced a result - a deal closing this quarter, a product line next year, or a category position over five years?
10. Do you want a one-off win, unblocking the deal in front of you, or a compounding asset that pays across revisions for years?
11. Is there already a spec that is roughly 80% right for the job, and what is wrong with the remaining 20%?
12. What happens if you do nothing for twelve months - who fills the space?
Questions 7 to 10 re-rank Step 3's ladder before you present it, so ask them before you show anything:
- A date inside two quarters promotes Consume, Conform and Extend, and deletes Contribute, Co-found and Drive - consensus venues work in years.
- A compounding mandate promotes Contribute and Co-found, and moves Step 4's venue choice right, toward a foundation or IETF.
- A low effort ceiling, or an irreversibility the sponsor refuses, deletes Drive and Co-found outright rather than ranking them last.
- No monetizable patents removes the RAND branch from Step 4 and makes royalty-free the default.
If your harness has persistent memory, store the standard's name, the chosen posture, the venue, the IPR mode, the KPIs and the kill rule. Every later revision, conformance decision and sibling skill reuses them.
## Step 1 - Establish the facts before opinions
1. **Inventory the existing specs** covering this job, including drafts and vendor-published ones. Prefer contributing to something 80% right over drafting something new - self-caused fragmentation suppresses adoption of both specs.
2. **Read each spec's venue and IPR mode**: who charters it, what stage it has reached, whether implementation requires a royalty-free or a paid patent licence. See [references/venue-and-ipr-options.md](./references/venue-and-ipr-options.md).
3. **Count real implementations**, separating those controlled by the spec's author from independent ones. One vendor's spec with no outside implementation is a product API with a nicer name.
4. **Count your own demand**: deals, tickets, RFPs and integrations that named this standard. Name the customers. A belief that "everyone uses it" is not demand evidence.
5. **Check for a conformance suite and a certification mark.** A spec with neither cannot stop divergent implementations from claiming support.
Report this as a one-page landscape before proposing anything, and refuse to argue posture while the venue, the IPR mode or the implementation count is still unknown.
## Step 2 - Run the four tests
Each test can eliminate postures outright, which is faster than comparing all seven.
- **Demand test.** Is there counted, named demand for interoperability? No demand eliminates everything above Consume.
- **Commoditization test.** Name the layer the standard commoditizes and the product whose demand rises when that layer gets cheaper. If the answer is "our own product", the ceiling is Extend, never Contribute or Drive.
- **Control test.** Score Shapiro and Varian's seven key assets - installed base, intellectual property rights, ability to innovate, first-mover advantage, manufacturing (or operating-cost) capability, strength in complements, brand and reputation. No single asset decides it, and a large customer controls part of the installed base too, so a committed adopter counts as an asset you can recruit. Holding none of the seven while proposing Drive is choosing a war you cannot fund - the ladder's answer is Contribute, which buys influence over the same spec without requiring you to win it.
- **Cost test.** Match the posture to what you can staff for the venue's real pace: consensus bodies work in years, Git-based specs in weeks. An unstaffed seat in a working group buys nothing.
When a rival spec already exists, classify the fight before choosing tactics: which side is backward-compatible with what is already installed decides whether you are in Rival Evolutions, Rival Revolutions, or one of the two mixed cases. See [references/standards-war-framework.md](./references/standards-war-framework.md) for the classification, the seven assets in full and the sourced argument for proposing a truce before a battle.
## Step 3 - Brainstorm postures, do not jump to an answer
1. Announce that you are in brainstorming mode and that no recommendation comes yet.
2. Walk the ladder below against the surviving postures from Step 2's tests.
3. Present **two or three candidate postures**, never one, in the efficiency order below. Each candidate is a bundle: the posture, the venue it implies, and what it forecloses within two years.
4. Price each bundle honestly - who stops trusting you, which door closes permanently, what the standard makes free that you currently charge for.
5. Recommend one bundle and say why, naming the test that eliminated each alternative.
6. Validate the deliverable section by section: landscape, then posture, then venue and IPR, then conformance, then KPIs. Get agreement on each before writing the next - a posture agreed after the venue is really a venue chosen by convenience.
The ladder, ordered by efficiency - value returned per unit of effort, not by what each rung costs. Obligations still accumulate along the escalation Ignore → Consume → Conform → Extend → Contribute → Co-found → Drive, whichever order you evaluate the rungs in.
| Posture | You do | You get | You owe |
| ------------------- | -------------------------------------- | --------------------------------------------- | ---------------------------------------------------- |
| _Ignore (baseline)_ | Nothing | Focus | Nothing, until procurement names it |
| Extend | Implement plus documented extensions | Differentiation on top of interop | Public docs and graceful degradation |
| Consume | Implement as a client | Interop, fast | Tracking their breaking changes |
| Conform | Pass the test suite, claim the mark | A checkable claim, sometimes a patent licence | Fees, re-certification per version |
| Contribute | Join the working group, write text | Influence over the next revision | Years of attendance, the venue's IPR rules |
| Co-found | Start a spec with peers | Shared credibility, shared cost | Governance work, co-funders who stay |
| Drive | Publish your own, recruit implementers | Control of the roadmap | Reference implementation, conformance suite, support |
The four axes disagree, which is the whole reason to state them separately rather than let the row order imply one blended rank:
- efficiency (best ratio first): `Extend > Consume > Conform > Contribute > Co-found > Drive`
- value (most first): `Drive > Co-found > Contribute > Extend > Conform > Consume`
- effort (most first): `Drive > Co-found > Contribute > Conform > Extend > Consume`
- compliance cost (most first): `Co-found > Drive > Contribute > Conform > Extend > Consume == Ignore`
Read effort as years of working-group attendance, engineering to build a reference implementation and a conformance suite, governance hours, and how little of it you can undo. Read compliance cost as the review each rung triggers and the reversibility it spends: patent-licensing regime, exclusion windows, certification obligations, trademark ownership.
- **Ignore is off the first three lines, not last on them.** Nothing over nothing is not a ratio, and ranking a do-nothing rung on value or effort is false precision. It is the baseline every other rung has to beat - an argued opt-out from ranking, not a rung that lost; it appears only on compliance cost, where zero exposure is a real reading.
- **Extend leads** because the marginal hour past Consume buys differentiation instead of parity - the same interop, plus something only you ship.
- **Conform sits below both** because re-certification per spec version is a standing job that buys a checkable claim and nothing else. A buyer, a regulator or a procurement questionnaire naming the mark promotes it above everything, because its value stops being a preference and becomes market access.
- **`Consume == Ignore` on compliance cost is a real tie**, not a dodge: neither creates a charter-time commitment, an exclusion window or a certification obligation. Nothing distinguishes their exposure, so nothing should separate them.
- **Co-found leads compliance cost over Drive** because a co-founded charter's patent regime and trademark need every co-founder's consent to revise, while a spec you publish alone you can still widen unilaterally - never narrow.
**What this order starves.** Drive and Co-found lose every efficiency round, and they are the only two rungs that buy control of the roadmap. Promote them anyway when one of these holds:
- The commoditization test names a layer you do not sell, no existing spec is 80% right, and the control test scores real assets → Drive.
- Neutrality is the blocker rather than the spec, and named peers will co-fund and stay → Co-found.
- A competitor is already driving a rival spec and buyers are stalling → Co-found or a merge, never a faster Drive (see Step 2's classification).
**Delete, do not demote.** A posture the interview or Step 2 rules out - no fundable staffing, a commoditization ceiling at Extend, an IPR mode the company cannot accept - comes off the ladder you present. A ruled-out rung parked at the bottom reappears a quarter later as scope.
**Re-rank against this user before presenting.** These orderings are defaults, not laws - here, in Step 4 and in Step 5 alike. They shift with the company's position and with who executes them.
- A seat already held in the working group makes Contribute's effort sunk and promotes it.
- A reference implementation and conformance suite already built collapses most of Drive's effort.
- A competitor already driving a rival specification demotes Drive whatever the assets say.
## Step 4 - Pick the venue and the IPR mode
Only for postures at Contribute or above. Six venues, one menu: a Git-based community specification, a foundation-hosted project, an industry consortium, IETF, W3C, ISO transposition. Each venue's mechanics are sourced in the reference; the orderings below are this skill's inference from them, not a published ranking.
- efficiency (best ratio first): `Git-based > foundation-hosted > IETF > industry consortium > W3C > ISO`
- neutrality bought (most first): `ISO > W3C > IETF > industry consortium > foundation-hosted > Git-based`
- effort (most first): `ISO > W3C > industry consortium > IETF > foundation-hosted > Git-based`
- compliance cost (most first): `industry consortium > ISO > W3C > IETF > foundation-hosted > Git-based`
- **Default to a Git-based community specification.** Move one venue right the moment a named party states it will not implement a spec whose repository you own - that refusal, not a preference for process, is what neutrality is bought to answer.
- **IETF outranks a paid-membership consortium on both efficiency and neutrality**: participation is individual and free, so influence costs drafts rather than fees, and no membership tier gates who is in the room.
- **The consortium leads compliance cost** because its IPR mode cannot change without closing the technical committee and re-chartering - the least reversible commitment on the list.
- **What this order starves: ISO and W3C.** Promote ISO the moment a tender, a regulator or a public buyer requires a standard number; its value goes from near-zero to gating, and nothing else substitutes. Promote W3C when browsers have to implement the surface.
- **Delete a venue the IPR answer rules out** rather than ranking it last: no royalty-free commitment available means W3C leaves the list entirely.
Make the two irreversible decisions explicitly, because both are set at charter time and cannot be quietly revised later: the patent-licensing regime (royalty-free versus paid RAND terms, which decides whether open-source projects can implement at all) and who owns the trademark. See [references/venue-and-ipr-options.md](./references/venue-and-ipr-options.md) for each venue's stage gates, participation model, patent rules and exclusion windows.
## Step 5 - Plan conformance before publication
A specification has no teeth; a test suite bound to a trademark does. Four decisions, each a choice rather than a form to fill in:
- efficiency (best ratio first): `versioned mark > public registry > who runs the tests > what passing costs`
- effort (most first): `who runs the tests > what passing costs > public registry > versioned mark`
- compliance cost (most first): `conformance-gated patent licence > witnessed testing > fee > self-service == free`
Decide them in efficiency order, because the two lowest-effort ones are also the two you cannot retrofit:
1. **Which spec version the mark certifies, and when it expires** - a sentence at design time, unfixable once implementations carry the mark. An unversioned mark ends up attached to implementations of a spec nobody uses any more.
2. **Where the public registry of certified implementations lives** - one maintained page. Buyers consult the registry, not the claim.
3. **Who runs the tests** - `self-service > witnessed` on efficiency: upload scales, witnessed testing is a standing job. Promote witnessed testing when the market is regulated or a buyer requires an observer, and delete it otherwise rather than leaving it as an option.
4. **What passing costs** - `free > fee` on efficiency: free maximizes the implementer count, which is the number that decides whether the spec is real. Promote a fee only when your implementers are funded vendors and the suite's maintenance must fund itself. Pick against the adoption goal, not against cost recovery.
`self-service == free` ties on compliance cost because neither obliges you to anything beyond publishing the result. Gating the patent licence on conformance leads that axis instead: it couples the IP grant to the test suite, and cannot be unwound once implementers hold licences under it. The Khronos Adopters Program pairs them exactly this way - passing buys both the right to use the API name and logo and a licence to members' essential patents.
## Step 6 - Write the decision record
Produce a short document, not a deck. Sections:
- the standard and the landscape
- the chosen posture with the rejected alternatives and why
- the venue and IPR mode
- the conformance plan
- the named owner
- the KPIs with thresholds
- the kill rule
Use the template and the worked examples in [references/decision-record-template.md](./references/decision-record-template.md) - two positive runs plus a negative one showing what a bad record looks like.
Expected output shape: one Markdown document of roughly 1-2 pages, every threshold tagged sourced or baseline, every rejected posture named with the test it failed. A record that recommends a posture without naming what was rejected is a conclusion, not a decision.
## Invocation examples
- "Write us an open standards strategy." → refuse the general form and ask which named specification, because a posture only exists per spec.
- "Should we join the working group standardizing agent tool-calling, or ship our own format?" → run the interview, then Steps 1-3; expect a landscape page and two or three posture bundles before any recommendation.
- "A competitor just published a rival spec to ours and buyers are stalling." → Step 2's classification, then the truce analysis in the framework reference; expect a merge-or-fight recommendation with the cost of each.
- "Procurement keeps asking whether we are certified against X." → Steps 1 and 5 only; expect a conform-or-not answer with the fee, the version certified and the registry entry.
- "Should we donate our protocol to a foundation?" → Steps 1, 4 and 6; expect a venue comparison and a dated donation trigger, not a yes/no.
## Measure it, and set the threshold before starting
Pick the KPIs the posture actually earns, set a numeric threshold and a review date at the decision, and write down what happens when the threshold is missed. Standards programmes are rarely cancelled because withdrawal reads as defeat, so the kill rule has to exist before there is anything to defend.
- **Consume/Conform**: integrations shipped per quarter, engineering days saved versus bespoke integration, deals unblocked where the standard was a stated requirement.
- **Contribute**: your accepted text or resolved issues per revision, and whether the change you joined for landed in the target release.
- **Co-found/Drive**: independent implementations you do not control - the single number that decides whether the spec is real.
- **All postures above Consume**: conformance pass rate across implementations, and the share of your target integration surface the standard covers.
**Sourced: two independent interoperating implementations.** The IETF's maturity rule for promoting a Proposed Standard to Internet Standard requires "at least two independent interoperating implementations with widespread deployment and successful operational experience" (RFC 6410, §2.2). W3C's Recommendation Track applies the same idea: its Process document requires "implementation experience... to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized" before advancing past Candidate Recommendation, and the Team weighs it against questions including whether implementations are independent, publicly deployed, and built by people other than the specification's own authors (W3C Process document, §6.3.2 Implementation Experience). Use two independent implementations as the bar for calling a spec real, and say where the number comes from when someone pushes back.
**Your baseline, not a standard: the clock and the customer test.** RFC 6410 sets no deadline, so "within twelve months of v1, with at least one implementer who is not a customer" is a starting baseline this skill proposes, not an industry norm. Replace it with a horizon drawn from the market's own cycle - the buying cycle of the segment, or the release cadence of the frameworks that must adopt it. Say in the decision record which number is sourced and which one you chose, so the review conversation argues about the right thing.
## Failure modes
- **Embrace, extend, extinguish, inflicted on you.** A larger implementer adds incompatible extensions until its dialect is the real standard. Counter with a conformance suite and a trademark, plus spec text defining behaviour for unknown extensions.
- **The same move, committed by you.** Undocumented extensions buy lock-in and strand your own customers on a dialect only you implement. Namespace them, document them, propose the useful ones upstream.
- **Fragmentation you caused.** Two credible specs for one job suppress adoption of both - the OpenTelemetry merge's own framing was that the consolidation itself, not any feature, was the benefit. Merging on the other side's terms often beats winning slowly.
- **Commoditizing your own differentiator.** Standards erase switching costs by design - make sure the ones being erased are someone else's.
- **Paper standard.** No test suite means every vendor claims support and buyers find the gaps in production; the name then carries no information and blocks a second attempt in the same space.
- **Venue capture or pace mismatch.** Before joining, count active participants' affiliations and read two years of the venue's output for real delivery pace.
- **Participation with no named outcome.** Influence goes to whoever writes text and stays for years. Enter with a specific change, a target revision and a person committed to that horizon.
- **An exit that strands implementers.** Whoever owns a spec owns the migration off it: announcing a sunset without a notice period, a bridge or a documented successor pushes the cost onto everyone who trusted you. Assume implementers depend on the spec's undocumented behaviour as much as its text, so a replacement has to be shipped and proven before the old version is withdrawn, not alongside it.
- **Winning, then standing still.** A spec that stops improving while staying compatible gets displaced by one that offers enough performance to justify the switch. Publish a versioning and migration path with v1, before there is an installed base to defend.
## B2B versus B2C
Standards engagement is a B2B and infrastructure motion: the audiences that reward it are procurement teams, platform teams and other vendors. For a consumer product, run the same analysis and expect it to end at Consume or Conform - then check the two exceptions where conformance is a market-access condition rather than a preference: regulated domains and app-store or platform rules.
The usual regulated domains - payments, identity, media codecs, accessibility - are this skill's shortlist, not a sourced inventory; confirm the actual regulation or store rule in play before leaning on the exception.
## References
- [references/venue-and-ipr-options.md](./references/venue-and-ipr-options.md) - venue-by-venue process, participation model, patent regime, and how to choose.
- [references/standards-war-framework.md](./references/standards-war-framework.md) - Shapiro and Varian's four battle types, seven key assets, two tactics and truce argument, with a worked classification.
- [references/decision-record-template.md](./references/decision-record-template.md) - the output template plus worked positive and negative examples.
- `samber/developer-relations-skills@developer-ecosystem-strategy` - the product-to-platform decision that often precedes this one.
- `samber/developer-relations-skills@devtools-business-model` - when the standard would change which layer you charge for.
- `samber/developer-relations-skills@open-source-company-strategy` - what to open-source and why, once the standards posture is set.
- `samber/developer-relations-skills@oss-governance` - governing a referenced spec implementation (mentioned in description as the skill for project governance, not standards strategy).
- `samber/developer-platform-skills@partner-app-onboarding` - the certification steps a partner implementation passes through (Step 5 conformance).
- `samber/developer-platform-skills@mcp-server-offering` - the tactical build once the posture toward the MCP standard itself is decided.