"Go-to-Market" Strategy for OmniBOR

[alilleybrinker]

The following is adapted from the meeting minutes for the April 15th meeting of the OmniBOR Working Group.

The topic at hand is the question of how best to approach marketing OmniBOR.

• (Ashley) Question of target audience for OmniBOR outreach:
  • We care about driving adoption by tool producers and software producers, so language-specific or tool-specific conferences can be useful target audiences to drive integration of OmniBOR into their tooling
• (Andrew) Can think of presentations across a “supply/demand” split
  • Supply: tool producers, language communities who could produce OmniBOR data
  • Demand: security / software teams who could consume OmniBOR data
• (Ashley) There’s likely high leverage / value for winning with high adoption on the supply side
• (David) Sees high value for consumers with the presence of this data, and thinks the demand-side approach, convincing software consumers / companies to demand the data can be a good path.
• (Ashley) The specific demand-side path in the open source software space is challenging
• (Andrew) Underlying current of displeasure and resentment around open source software supply chain concepts (SBOMs, SLSA) is real and should not be underestimated
• (Andrew) If we propose for OWASP Global AppSec, we could frame it as a case study around existing Rust / Java implementation work
• (Ashley) On the side of generating demand, we could encourage interested folks to approach us about developing integrations, rather than approaching language/tool communities independently to demand integration
• (Ashley) Sees an opportunity for “maintainer friendly supply chain security option”
• (Bharathi) Sees a real need from engagement with folks at Cisco (and likely the same is true elsewhere) to develop more demos / PoCs to show the value of OmniBOR and drive interest and adoption
• (Bharathi) The more integrated, specifically with tools people are really using already, and/or integrated with SBOM tools (adoption of which is now being driven in part by legal requirements), will really help show value

---

Pulling from the above, we have basically two approaches:

• Supply-side: Working with tool producers and programming language communities to modify or augment existing tools like compilers, interpreters, package bundlers, and more to produce and distribute OmniBOR data (identifiers and manifests).
• Demand-side: Working with software consumers and companies to demonstrate value of OmniBOR data to encourage demand for OmniBOR integration in existing tools.

Ideally, we as a Working Group would coalesce into a coherent strategy, likely one which incorporates elements of both of the above, though perhaps not in equal measure.

[alilleybrinker]

Update from April 22nd meeting:

• (Andrew) Gave recap
• (Ashley) This conversation has arisen in part from discussion of how the OmniBOR Working Group approaches presenting to conferences, including both what conferences we try to present at, and how we choose to focus the conversation when presenting at those conferences.
• (Ashley) Andrew had also previously raised concerns that a demand-side strategy could lead to backlash from open source maintainers around things like SBOM, SLSA
• (Ed) Ideally we sidestep that by working with tools; this is basically the demand side approach
• (David) Interested in creating focus around identifiers which can be created with information which is already present. We have some existing implementations from which we can put together a proof of readiness based on the tooling we’ve built already, perhaps with the inclusion of specific patches we maintain.
• (Ashley) Current strategy for the Rust compiler is not to pursue upstreaming into the Rust compiler. General open source experience is that “just accept a patch” isn’t “just accept a patch” because you have to maintain the patch forever, and in practice this isn’t that easy and funding becomes a limiting factor.
• (David) This is very valuable knowledge because these kinds of open discussions can help find patterns to avoid. Personal experience from web framework was that they didn’t accept patches from people other than core contributors, relatively high bar. Different communities have different bars. Recognize the workload assumed with the assumption of a patch.
• (Ed) Don’t be the barbarian at the gate, expecting people to do what you want them to do.
• (Andrew) Very difficult to stop other people from doing this. Can learn from the “Rust Evangelism Strikeforce” phenomenon
• (Ashley) Direct experience with dealing with this exact phenomenon and trying to discourage people from engaging with open source projects in this way