OpenTelemetry Marketing Guidelines for Contributing Organizations

OpenTelemetry (aka OTel) is a collaboration among end-users, adjacent OSS projects, and vendors who ultimately sell products and services built upon OTel data or components. Like many standards-oriented projects, the vendors that partner on OTel also compete in the marketplace, and for this reason it’s important to establish some ground rules and expectations for how contributing organizations communicate and message about OTel.

In fact, OTel’s success depends on both the reality and the perception of sincere collaboration between the many parties (and vendors) involved. There’s a lot of superb technical work happening within OTel, and we want to make sure it’s not overshadowed by an opportunistic marketing department here or there!

This document is divided into two sections:

• Goals and Guidelines: What are we trying to achieve? What is our guidance?
• Concerns and consequences: How do we determine that a guideline has been violated? And what do we do about it?

Goals and Guidelines

There are three high-level focus areas for these goals and guidelines.

I: OpenTelemetry is a joint effort

• Do’s:
  • Use project collateral such as logo and name in line with the Linux Foundation’s branding and trademark usage guidelines
  • Emphasize that OTel would not be possible without collaboration from many contributors who happen to work for competing vendors and providers
  • Cite names of the other contributors and vendors involved with OTel efforts
  • Emphasize our common goals as a community to improve end user/developer experiences and empower them
• Don’ts:
  • Imply that a single provider is responsible for OTel itself, and/or one of its various component parts
  • Diminish the contributions of another organization or of another individual

II: It’s not a competition

• Do’s:
  • Emphasize that all contributions are valuable, and that they come in many shapes and sizes, including:
  • Contributions to the core project code or to language- or framework-specific SDKs
  • Creating and sharing educational resources (videos, workshops, articles), or shared resources that can be used for educational purposes (e.g. a sample app using specific language/framework)
  • Community-building activities such as organizing an event or meetup group
  • Publicly recognize and thank other organizations for their contributions to OTel
• Don’ts:
  • Directly compare the volume or value of different contributors to OTel (E.g., via CNCF devstats)
  • Imply that infrequent or minor contributors to OTel are necessarily second-class citizens, and/or that their own OTel compatibility should be questioned as a result (in fact, there’s no reason that any provider needs to contribute to OTel in order to support it)

III: Promote awareness of OTel interoperability and modularization

• Do’s:
  • “Shout from the rooftops” about OTel compatibility – the more that end-users understand what they can do with OTel data, the better
  • Emphasize the vendor-neutrality and portability of any OTel integration
• Don’ts:
  • Imply that an end-user isn’t “Using OTel” unless they’re using some specific set of components within OTel (OTel is a “wide” project with many decoupled components)
  • Publicly denigrate the OTel support of another provider, particularly without objective evidence

Concerns and Consequences

Inevitably there will be instances where vendors (or at least their Marketing departments) run afoul of these guidelines. To date, this hasn’t happened frequently, so we don’t want to create an over-complicated process to handle concerns.

Here is how we handle such circumstances:

1. Whomever notices the relevant public (marketing) content should write an email to cncf-opentelemetry-governance@lists.cncf.io and include an explanation of why the content is problematic, ideally referencing the relevant guidelines above.
2. The OTel Governance Committee (GC) will discuss the case during its next (weekly) meeting, or asynchronously via email if possible. The OTel GC guarantees a response via email within two weeks of the initial report.
3. If the GC agrees that there’s a problem, a corrective action will be recommended to the author of the content in question, and the GC will request that the organization that published the content train relevant employees on the content in this document as a further preventative measure.

If a pattern develops with a particular vendor, the GC will meet to discuss more significant consequences – for instance, removing that vendor’s name from OTel-maintained lists of compatible providers, or simply publicly documenting the pattern of poor community behavior.