add roadmap blog post (open-telemetry#4419)

content/en/blog/2024/collector-roadmap/index.md

@@ -0,0 +1,97 @@
+---
+title: The roadmap to v1 for the OpenTelemetry Collector
+linkTitle: Collector Roadmap
+date: 2024-05-06
+# prettier-ignore
+cSpell:ignore: Antipatterns Boten Broadbridge Helmuth Hrabovcak Ishan Jaglowski OTTL Pantuza pushback Shishi Vijay
+author: '[Alex Boten](https://github.com/codeboten) (Honeycomb)'
+---
+
+The [OpenTelemetry Collector](/docs/collector/) is a very popular component in
+OpenTelemetry that has been under heavy development for quite some time. It is a
+binary that allows many formats of telemetry to be sent to it, transformed, and
+emitted to a destination. Much has been said about the Collector over the past
+few years in various blog posts and talks. Here's a small list of talks about
+the Collector if you haven't had the chance to learn about it:
+
+- [Connected Observability Pipelines in the OpenTelemetry Collector - Dan Jaglowski](https://www.youtube.com/watch?v=uPpZ23iu6kI)
+- [OpenTelemetry Collector Antipatterns - Adriana Villela](/blog/2024/otel-collector-anti-patterns/)
+- [Telemetry Showdown: Fluent Bit Vs. OpenTelemetry Collector - Henrik Rexed](https://www.youtube.com/watch?v=ykq1F_3PmJw)
+- [OpenTelemetry Collector Deployment Patterns - Juraci Kröhling](https://www.youtube.com/watch?v=WhRrwSHDBFs)
+- [OTTL Me Why Transforming Telemetry in the OpenTelemetry Collector Just Got Better - Tyler Helmuth & Evan Bradley](https://www.youtube.com/watch?v=uVs0oUV72CE)
+- [Manage OpenTelemetry Collectors at scale with Ansible - Ishan Jain](/blog/2024/scaling-collectors/)
+
+The Collector has been a core component for organizations looking to adopt
+OpenTelemetry as part of their strategy to improve the telemetry emitted by
+their systems. Organizations around the world have already adopted it and
+successfully process large amounts of data through pipelines as documented by
+these various talks:
+
+- [Adopting OpenTelemetry Collector @ eBay - Swapping Engines Mid Flight - Vijay Samuel](https://www.youtube.com/watch?v=tZJd6W-CIcU)
+- [Ingesting 6.5 Tb of Telemetry Data Daily Through OpenTelemetry Protocol and Collectors - Gustavo Pantuza](https://www.youtube.com/watch?v=aDysORX1zIs)
+- [Today, Not Tomorrow: Scalable Strategies for Migrating to OpenTelemetry - Jason Anderson & Kevin Broadbridge](https://www.youtube.com/watch?v=iPGd9_aYu-A)
+- [How and Why You Should Adopt and Expose OSS Interfaces Like OTel & Prometheus - Daniel Hrabovcak & Shishi Chen](https://www.youtube.com/watch?v=D71fK2MFreI)
+- [Why, How to, and Issues: Tail-Based Sampling in the OpenTelemetry Collector - Reese Lee](https://www.youtube.com/watch?v=l4PeclHKl7I)
+
+A few months ago, there was an
+[ask from the community](https://github.com/open-telemetry/community/issues/1971)
+to declare the OpenTelemetry Collector stable.
+
+![Can haz Collector v1?](can-haz-collector.png)
+
+Now you might be asking yourself "Why would anyone want the Collector to be
+declared stable? You just told me it's already used in production!" It's true,
+the Collector and its configuration have been fairly stable for core components
+for some time. However, being "unofficially stable" is not good enough for a
+wide variety of organizations who wish to adopt the Collector:
+
+- An official v1 will signal that the OpenTelemetry community is ready to
+  provide long term support and not introduce backwards incompatible changes
+  without bumping the major version.
+- Organizations with policies not to use pre-release software will be able to
+  start adopting the Collector.
+- Stability in the Collector helps the community move OpenTelemetry to become a
+  CNCF Graduated project.
+
+The request to stabilize was met with pushback from maintainers since calling
+anything 1.0 has a way of setting expectations indefinitely. This led to a
+series of discussions and meetings that brought together the maintainers of the
+Collector to decide on what a 1.0 really means for the Collector.
+
+And after a lot of back and forth, we decided on a limited scope of what we
+wanted to focus on:
+
+1. A distribution of the Collector that only includes an OTLP receiver and an
+   OTLP exporter.
+2. Individual Go modules that the Collector components rely upon must also be
+   marked as stable as per the project's
+   [versioning guidelines](https://github.com/open-telemetry/opentelemetry-collector/blob/main/VERSIONING.md#public-api-expectations).
+
+Aside from this, there were a few areas the contributors wanted to improve based
+on user feedback:
+
+- The telemetry generated by the Collector about itself:
+  - Traces, metrics, and logs must be available via OTLP.
+  - The configuration for the telemetry must follow the configuration schema.
+- The scalability of the Collector:
+  - Handling for queueing, back pressure, and errors must be improved.
+  - Clear benchmarks and performance expectations for end users.
+- Overall documentation befitting of a stable piece of critical infrastructure.
+
+The
+[roadmap](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/ga-roadmap.md)
+was published in the Collector's repository and milestones were created to track
+the work underway. To ensure the effort can be successful, the scope of the
+deliverable was limited to provide:
+
+- a clear and achievable goal
+- the focus needed to not get distracted
+- a signal to new contributors of where the project is focusing
+
+There is much to do as you can see on the
+[project board](https://github.com/orgs/open-telemetry/projects/83), but there
+is a lot of excitement around this effort. If you're keen on helping, reach out
+either by commenting on any of the open issues in GitHub, or attending the
+Collector SIG call that happens weekly on Wednesdays. For a quick overview of
+the 1.0 progress you can checkout the tracking
+[issue](https://github.com/open-telemetry/opentelemetry-collector/issues/9375).

static/refcache.json

@@ -2951,6 +2951,10 @@
     "StatusCode": 200,
     "LastSeen": "2024-03-19T10:16:37.692028682Z"
   },
+  "https://github.com/open-telemetry/community/issues/1971": {
+    "StatusCode": 200,
+    "LastSeen": "2024-05-03T07:21:04.501478-07:00"
+  },
   "https://github.com/open-telemetry/community/issues/828": {
     "StatusCode": 200,
     "LastSeen": "2024-01-18T19:37:16.771654-05:00"
@@ -3123,6 +3127,10 @@
     "StatusCode": 200,
     "LastSeen": "2024-04-04T11:07:15.276911438-07:00"
   },
+  "https://github.com/open-telemetry/opentelemetry-collector/issues/9375": {
+    "StatusCode": 200,
+    "LastSeen": "2024-05-03T08:34:29.3339-07:00"
+  },
   "https://github.com/open-telemetry/opentelemetry-collector/pull/6140": {
     "StatusCode": 200,
     "LastSeen": "2024-01-30T05:18:24.402543-05:00"
@@ -4175,6 +4183,10 @@
     "StatusCode": 200,
     "LastSeen": "2024-01-30T05:18:13.065627-05:00"
   },
+  "https://github.com/orgs/open-telemetry/projects/83": {
+    "StatusCode": 200,
+    "LastSeen": "2024-05-03T07:21:05.157831-07:00"
+  },
   "https://github.com/orgs/open-telemetry/teams/technical-committee": {
     "StatusCode": 200,
     "LastSeen": "2024-01-30T16:15:03.796394-05:00"
@@ -5807,6 +5819,14 @@
     "StatusCode": 206,
     "LastSeen": "2024-03-19T10:16:59.755536357Z"
   },
+  "https://opentelemetry.io/blog/2024/otel-collector-anti-patterns/": {
+    "StatusCode": 206,
+    "LastSeen": "2024-05-06T07:53:28.679391-07:00"
+  },
+  "https://opentelemetry.io/blog/2024/scaling-collectors/": {
+    "StatusCode": 206,
+    "LastSeen": "2024-05-06T07:53:28.903161-07:00"
+  },
   "https://opentelemetry.io/docs/collector": {
     "StatusCode": 206,
     "LastSeen": "2024-02-23T22:55:03.656226-05:00"