Changing requirements for contributing new components

[mx-psi]

Component(s)

No response

Describe the issue you're reporting

Given the increased focus on open-telemetry/opentelemetry-collector/issues/14065, it is important the approvers and maintainers have the bandwidth to focus on project-wide priorities. One of the current duties of approvers and maintainers is sponsorship of new components, which can take a significant amount of time. As such, there have been some discussions among approvers and maintainers from the Collector SIG about balancing new components acceptance with the needs for increased focus.

We all acknowledge that it is harder than we would like to build, maintain, distribute and discover Collector components hosted outside of the official OpenTelemetry Github repositories, and there is ongoing work to improve some parts of this (see e.g. open-telemetry/community/pull/3000 or the work for API stabilization we have completed as part of open-telemetry/opentelemetry-collector/issues/9375, as well as external projects such as the distro builder or distrogen (talk)). I would argue that we are at a point where making acceptance requirements for this repository more strict can help push the OpenTelemetry community towards improving these aspects.

As such, I would like to brainstorm some ideas on this regard, some of which are mine and some of which have
been discussed by Collector approvers and maintainers (from most extreme to least extreme):

1. Rejecting all new components until OpenTelemetry graduates. Pretty self-explanatory, also pretty radical.
2. Shifting towards building and growing your component outside of official OpenTelemetry repositories before accepting a component. Our current Contributing guidelines to add new components focus on discussing everything about the component before writing code. I argue that a shift towards explaining how to build your component outside of the repository, adding it to the registry, and then 'donating' the code to OpenTelemetry can be beneficial in 'federating' the build experience and reducing the load that approvers/maintainers face. You have to 'prove' to us that your component works, is usable and has been built outside.
3. Increasing the minimum number of codeowners required for a component to be accepted to be at least two. This is a small change but also something that can ensure that a healthier, more active community is built around a component before acceptance, making sure that approvers/maintainers have less to worry about.

This issue is meant to be a place to discuss what is the appropriate balance when making changes to our current policy for accepting new components. Feel free to discuss the ideas on this list of propose other, new ideas.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[mx-psi]

Some notes from live discussion on the 2025-10-05 Collector SIG meeting (@ChrsMark @pjanotti if you want to expand feel free to mention it):

• One important aspect that we should clarify is how can end users evaluate the quality of components living outside of contrib
• We should ensure vendor fairness
• We should ensure that there is a fair process for component donation (e.g. what if there are competing implementations)
• We should measure codeowners activity in general
  • In addition to the changes here, we should be more aggressive on removing unmaintained components
  • Two codeowners rule: we could use other criteria could be used (community membership, role in other SIG)
• There could be a risk of a bifurcated ecosystem
• We could build some venue for people to discuss building components that is not necessarily contrib

[ChrsMark]

As a Collector Contrib approver and component code owner, I support prioritizing quality and sustainability over quantity. Elaborating inline since I was already preparing to post :):

One important aspect that we should clarify is how can end users evaluate the quality of components living outside of contrib

Clarify that components maintained outside Contrib are not considered inferior to those in Contrib when they meet documented criteria (quality, security, maintenance?).

We should ensure vendor fairness

Clarify how vendor fairness will be ensured. Vendor X should not have more components than vendor Y in contrib.

We should ensure that there is a fair process for component donation (e.g. what if there are competing implementations)

Ensure a transparent, fair donation process: for example, if Vendor X and Vendor Y both maintain a foo component externally and both want to donate, what is the process (consolidation/merge expectations, co-ownership, or selection criteria)?

[atoulme]

I'll throw one more option in there for discussion.
We can enforce that the population of components needs to be somewhat managed, as in:

• we have a max of components in alpha/beta/development stability levels
• we queue up new components based on their maturity - meaning, we offer a process driven view where we don't say no out right, but we maintain a priority queue based on maturity factors and sponsors.
• we review the backlog on a rotation

This gives some level of power to new entrants to help move existing components past a certain threshold so they can make room for their own, become members of OpenTelemetry, and adhere to this.

This can be in complement to the solutions 2 and 3 which I support.

[axw]

Shifting towards building and growing your component outside of official OpenTelemetry repositories before accepting a component

Seems reasonable to me.

Increasing the minimum number of codeowners required for a component to be accepted to be at least two.

Is this in addition to the sponsor? Because otherwise IIANM the sponsor-becomes-codeowner rule means that there will always initially be two codeowners, except if someone sponsors their own proposal (shouldn't be permitted?)

A semi-related option would be to remove that requirement, and put more onus on the proposed codeowners to handle all development and code reviews independently. Sponsors would just be giving +1 with no actual commitment to be code owners. That would alleviate some burden on approvers/maintainers, but I worry a bit it will end up reducing quality. As a mitigation, there could be a sort of mandatory check-in where some quorum of approvers/maintainers have to review things between stability phases. i.e. when going from development -> alpha, one or more approvers reviews the configuration and README to make sure things look in line with project standards.

In addition to the changes here, we should be more aggressive on removing unmaintained components

💯

[mx-psi]

Is this in addition to the sponsor?

Yes, in addition to the sponsor!