Home/Product/open-standards-strategy
O

open-standards-strategy

by @samberv
4.5(120)

Decides what posture a company should take toward one 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. It also fixes the venue (Git spec, foundation, consortium, IETF/W3C/OASIS, ISO), the patent-licensing mode, the conformance plan and the kill rule. Use it for protocol strategy, standards-body engagement, standards wars, donating a spec to a neutral foundation, or a competitor's rival spec.

open-standardsprotocol-strategystandards-bodypatent-licensingproduct-strategyGitHub
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill open-standards-strategy
compare_arrows

Before / After Comparison

2 组
Before

When a new protocol appears, engineering wants to implement it, product wants to wait, legal worries about patents, and several meetings later there is still no executable, reviewable conclusion.

After

This skill narrows the question through naming the spec, market position, effort ceiling and horizon, then outputs the posture, venue, licensing mode and kill rule as one archived decision record.

SKILL.md

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.

  1. 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?
  2. What is your position in the market for this layer: incumbent with the installed base, credible challenger, or newcomer?
  3. 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.

  1. Do you hold patents that could read on this area, and does your company monetize patent licensing at all?
  2. 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?
  3. 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.

  1. 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?
  2. Do you want a one-off win, unblocking the deal in front of you, or a compounding asset that pays across revisions for years?
  3. Is there already a spec that is roughly 80% right for the job, and what is wrong with the remaining 20%?
  4. 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.
  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 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.

PostureYou doYou getYou owe
Ignore (baseline)NothingFocusNothing, until procurement names it
ExtendImplement plus documented extensionsDifferentiation on top of interopPublic docs and graceful degradation
ConsumeImplement as a clientInterop, fastTracking their breaking changes
ConformPass the test suite, claim the markA checkable claim, sometimes a patent licenceFees, re-certification per version
ContributeJoin the working group, write textInfluence over the next revisionYears of attendance, the venue's IPR rules
Co-foundStart a spec with peersShared credibility, shared costGovernance work, co-funders who stay
DrivePublish your own, recruit implementersControl of the roadmapReference 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. Pro

...

User Reviews (0)

Write a Review

Effect
Usability
Docs
Compatibility

No reviews yet

Statistics

Installs9.1K
Rating4.5 / 5.0
Version
Updated2026年10月23日
Comparisons2

User Rating

4.5(120)
5
37%
4
43%
3
13%
2
5%
1
2%

Rate this Skill

0.0

Compatible Platforms

🤖claude-code

Timeline

Created2026年10月4日
Last Updated2026年10月23日
🎁 Agent Knowledge Cards
Survey