Set additional criteria towards accepting components

[atoulme]

Component(s)

No response

Describe the issue you're reporting

This is a topic open for discussion to the community and I will bring it to the next SIG meeting.

We now have a high number of components inside this repository, and each component adds to maintenance work.

We would probably want going forward to have express rules that govern each type of component to avoid creating additional maintenance needs.

For receivers and exporters, we should aim to ensure that no existing receiver can perform the ingest. We will look to also reuse elements of receivers, such as encodings, to reduce the toil of managing those receivers going forward.

For processors, we have clearly preferred for a while now to invest in the transformprocessor. We should aim to continue to send folks towards supporting and extending this processor rather than create additional processors.

For connectors, I guess we can be judicious about how we want to work towards supporting various use cases. For now, we should give ourselves license to explore.

I would like encourage more folks to maintain their own components in separate Github repositories:

• We are discussing elsewhere how to document additional distros besides the core and contrib distributions. Those distributions can in turn include components maintained outside of contrib.
• We have decoupled our release list from the code in this repository. See how the contrib distribution is made here: https://github.com/open-telemetry/opentelemetry-collector-releases/tree/main/distributions/otelcol-contrib
  I believe we can continue to think about other ways for folks to build their own and manage their distributions going forward.

If you were to develop a component in your github repository, what would you miss from contrib? What does it offer that we could make available?

With that in mind, would it be possible to discuss making the process of accepting new components in contrib more selective going forward, and document it within our repository?

[atoulme]

From SIG meeting:

• Propose more guidelines in issue template and push for more research before asking for a new component
• Vendor sponsored components needs to have codeowners from the vendor
• Need to have more explicit rules stated for vendors, they exist, just need to make them more explicit
• Make sure to recommend folks look at OTTL first for example, or make sure they don't create a new receiver if an existing receiver can do the job.

[djaglowski]

we should aim to ensure that no existing receiver can perform the ingest

I generally support the sentiment of controlling our maintenance burden but I think this particular rule would go too far. We can discuss in more detail on the PR but I think we should allow for some types of overlap. Some examples:

• The existence of the filelog receiver should not necessarily preclude the addition of a receiver that can read logs from files using another technology. e.g. fluent, promtail
• Similarly, one could argue there is overlap between prometheus receivers and many scrapers, but there are good reasons to allow this, e.g. single process, single config
• We have several receivers that are catch-all solutions for a given protocol but often only accessible to advanced users. (e.g. sqlquery, winperfcounters, snmp, tcp/udp). Then we have more specific receivers that are much more accessible e.g. mysql, activedirectory, syslog. I think both "levels" are justifiable for their own reasons, even if there is overlap.

Again, I agree with the sentiment but I think we either need to have some explicit carve outs, or just leave room for judgement calls.

Another option we could consider is to require two sponsors for new components.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.