Repository: open-telemetry/opentelemetry.io
Pull request #6614: devex: add blog post for results of devex survey
Author: login: tsloughter
Labels: name: sig:collector
name: docs:blog
description: An issue requesting a blog post, or a PR for a new blog post
name: sig:java
name: docs:registry
name: sig:security
name: lang:zh
name: lang:ja
name: lang:pt
name: lang:es
Created: 2025-03-26T21:06:35Z | Merged: 2025-04-02T15:39:10Z

This post includes results from the Developer Experience SIG's user survey.


Diff:
diff --git a/content/en/blog/2025/devex-survey/image1.png b/content/en/blog/2025/devex-survey/image1.png
new file mode 100644
index 000000000000..ab12d6461b5c
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image1.png differ
diff --git a/content/en/blog/2025/devex-survey/image10.png b/content/en/blog/2025/devex-survey/image10.png
new file mode 100644
index 000000000000..3403d912fc36
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image10.png differ
diff --git a/content/en/blog/2025/devex-survey/image11.png b/content/en/blog/2025/devex-survey/image11.png
new file mode 100644
index 000000000000..ba3bec793c05
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image11.png differ
diff --git a/content/en/blog/2025/devex-survey/image2.png b/content/en/blog/2025/devex-survey/image2.png
new file mode 100644
index 000000000000..922ea3151c3b
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image2.png differ
diff --git a/content/en/blog/2025/devex-survey/image3.png b/content/en/blog/2025/devex-survey/image3.png
new file mode 100644
index 000000000000..56bd14aee9e7
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image3.png differ
diff --git a/content/en/blog/2025/devex-survey/image4.png b/content/en/blog/2025/devex-survey/image4.png
new file mode 100644
index 000000000000..9f6d5450a860
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image4.png differ
diff --git a/content/en/blog/2025/devex-survey/image5.png b/content/en/blog/2025/devex-survey/image5.png
new file mode 100644
index 000000000000..b916635335f9
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image5.png differ
diff --git a/content/en/blog/2025/devex-survey/image6.png b/content/en/blog/2025/devex-survey/image6.png
new file mode 100644
index 000000000000..c0fb06bb8e40
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image6.png differ
diff --git a/content/en/blog/2025/devex-survey/image7.png b/content/en/blog/2025/devex-survey/image7.png
new file mode 100644
index 000000000000..20127a92e802
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image7.png differ
diff --git a/content/en/blog/2025/devex-survey/image8.png b/content/en/blog/2025/devex-survey/image8.png
new file mode 100644
index 000000000000..a69a901c5eb3
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image8.png differ
diff --git a/content/en/blog/2025/devex-survey/image9.png b/content/en/blog/2025/devex-survey/image9.png
new file mode 100644
index 000000000000..8753d1717ebc
Binary files /dev/null and b/content/en/blog/2025/devex-survey/image9.png differ
diff --git a/content/en/blog/2025/devex-survey/index.md b/content/en/blog/2025/devex-survey/index.md
new file mode 100644
index 000000000000..c58eb338e90b
--- /dev/null
+++ b/content/en/blog/2025/devex-survey/index.md
@@ -0,0 +1,161 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-04-02
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+cSpell:ignore: OTTL Sloughter
+---
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability.
+
+The platforms used leaned towards Kubernetes (68.2%) and AWS (34.6%), with bare
+metal still making up a respectable percentage (12%).
+
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below.
+
+While those working on backends or operations were the majority of respondents,
+mobile and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?](image3.png)
+
+![Forms response chart. Question title: Which platforms are you running
+OpenTelemetry on?](image11.png)
+
+![Forms response chart. Question title: What programming languages are you using with OpenTelemetry?](image7.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on?](image9.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the Collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question, it seems clear there is a gap
+between getting started and operating with more complex pipelines or in larger
+deployments. More on this in the Future Plans section.
+
+Interestingly, _collector-contrib_ had a large percentage of the responses to
+the question, “Which collector do you use?”. Sadly, it is unclear if this is due
+to being unaware of OCB
+([https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder](https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder))
+for building custom images, disinterest in using it or a lack of adequate
+documentation around its use.
+
+![Forms response chart. Question title: How complex was it to get started
+operating the OpenTelemetry Collector?](image10.png)
+
+![Forms response chart. Question title: What environments are you using the
+OpenTelemetry collector?](image6.png)
+
+![Forms response chart. Question title: Which collector distribution do you
+use?](image4.png)
+
+### SDK and Instrumentation
+
+Manual instrumentation and getting started with the SDK leaned slightly toward
+being more difficult. On the other hand, auto-instrumentation was solidly
+towards being easier to get started with. Despite getting started with
+auto-instrumentation being relatively straightforward, the results showed that
+enriching that telemetry was more difficult.
+
+![Forms response chart. Question title: Do you use OpenTelemetry SDK directly or
+via vendor SDK of the languages you use?](image1.png)
+
+![Forms response chart. Question title: How complex was it to manually
+instrument your application with OpenTelemetry?](image8.png)
+
+![Forms response chart. Question title: How complex was it to get started with
+OpenTelemetry SDK?](image2.png)
+
+![Forms response chart. Question title: How complex was it to get started with auto-instrumentation?](image5.png)
+
+### Debugging
+
+A common theme in the responses to the final question on the survey, “What could
+be changed to improve the developer experience?”, is the desire for an easier to
+setup local environment – one you can see all the telemetry coming out of a
+running application locally – along with more information from SDKs, both during
+development and in production, when something is wrong, like data being dropped
+or an exporter being misconfigured.
+
+## Future Plans
+
+The results from those who responded are invaluable resources as we work to
+improve the OpenTelemetry developer experience. We will now direct some of this
+feedback to the respective SIGs, work on prototyping some solutions and follow
+up with the other teams.
+
+Thank you again to all those who participated in the survey! Even though the
+survey is now over, we do still welcome feedback. Feel free to reach out to us
+on
+[Slack, or during our weekly meetings](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs)
+if you want to provide additional informations, or want to join us.
diff --git a/static/refcache.json b/static/refcache.json
index 490754c6ba73..b915c4afc1d7 100644
--- a/static/refcache.json
+++ b/static/refcache.json
@@ -12299,6 +12299,10 @@
     "StatusCode": 206,
     "LastSeen": "2025-03-21T13:46:31.597120135-07:00"
   },
+  "https://github.com/open-telemetry/sig-developer-experience": {
+    "StatusCode": 206,
+    "LastSeen": "2025-04-02T15:06:58.750831554Z"
+  },
   "https://github.com/open-telemetry/sig-end-user": {
     "StatusCode": 206,
     "LastSeen": "2025-02-01T07:10:56.03728-05:00"
@@ -13103,6 +13107,10 @@
     "StatusCode": 206,
     "LastSeen": "2025-01-07T10:33:08.867508-05:00"
   },
+  "https://github.com/stevejgordon": {
+    "StatusCode": 206,
+    "LastSeen": "2025-04-02T15:06:54.87107868Z"
+  },
   "https://github.com/steverao": {
     "StatusCode": 206,
     "LastSeen": "2025-02-02T10:15:12.441147-05:00"


Reviews:
user: login: dmathieu
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T08:16:02Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T11:02:33Z
user: login: theletterf
body: First pass — thanks!
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-03-27T11:16:09Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T11:43:20Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T11:44:51Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T11:53:25Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T11:55:02Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T12:04:13Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T14:28:05Z
user: login: julianocosta89
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T14:36:11Z
user: login: julianocosta89
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-27T15:34:39Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-28T23:09:31Z
user: login: tsloughter
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-28T23:10:36Z
user: login: theletterf
body: Looking better! @open-telemetry/docs-approvers any more thoughts?
state: APPROVED
author_association: MEMBER
submitted_at: 2025-03-31T07:49:51Z
user: login: theletterf
body: 
@tsloughter There seem to be some Markdown issues with missing ALT labels. Also, I noticed that the ALT description for most charts are repeated or in the wrong order. Could you check them please?


state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-03-31T08:22:39Z
user: login: theletterf
body: Couple nits to appease the CI. Also, lots of files got into the PR -- could you rebase or run npm fix:all locally?
state: CHANGES_REQUESTED
author_association: MEMBER
submitted_at: 2025-04-02T11:59:37Z
user: login: theletterf
state: APPROVED
author_association: MEMBER
submitted_at: 2025-04-02T13:49:28Z

Review comments:
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarises our findings and
path: content/en/blog/2025/devex-survey/index.md
user: login: dmathieu
body: ```suggestion
prioritization of work within the SIG. This post summarizes our findings and
```
created_at: 2025-03-27T08:06:03Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarises our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question make it clear that getting started
+and operating with more complex pipelines or in larger deployments are not as
+easy as getting started, more on this in the Future Plans section.
path: content/en/blog/2025/devex-survey/index.md
user: login: dmathieu
body: This phrasing reads weird.

```suggestion
Getting started with the Collector was shown to lean towards the fairly easy,
though based on results for the question asking for problems with operating the
Collector and the overall experience question, it seems clear there is a gap between
getting started and operating with more complex pipelines or in larger deployments,
more on this in the Future Plans section.
```
created_at: 2025-03-27T08:11:42Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarises our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question make it clear that getting started
+and operating with more complex pipelines or in larger deployments are not as
+easy as getting started, more on this in the Future Plans section.
+
+Interestingly, _collector-contrib_ had a large percentage of the responses to
+the question, “Which collector do you use?”. Sadly, it is unclear if this is due
+to being unaware of OCB
+([https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder](https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder))
+for building custom images, disinterest in using it or a lack of adequate
+documentation around its use.
+
+![Forms response chart. Question title: How complex was it to get started operating the OpenTelemetry Collector?. Number of responses: 199 responses.](image4.png)
+
+![Forms response chart. Question title: What environments are you using the OpenTelemetry collector? (select all that apply). Number of responses: 217 responses.](image5.png)
+
+![](image6.png)
+
+### SDK and Instrumentation
+
+Manual instrumentation and getting started with the SDK leaned slightly toward
+being more difficult. On the other hand, auto-instrumentation was solidly
+towards being easier to get started with. Despite getting started with
+auto-instrumentation being relatively straightforward, the results showed that
+enriching that telemetry was more difficult.
+
+![Forms response chart. Question title: Do you use OpenTelemetry SDK directly or
+via vendor SDK of the languages you use?. Number of responses: 217
+responses.](image7.png)
+
+![Forms response chart. Question title: How complex was it to manually
+instrument your application with OpenTelemetry?. Number of responses: 217
+responses.](image8.png)
+
+![Forms response chart. Question title: How complex was it to get started with OpenTelemetry SDK? (skip if you don't use). Number of responses: 217 responses.](image9.png)
+
+![Forms response chart. Question title: How complex was it to get started with auto-instrumentation? (skip if you don't use). Number of responses: 161 responses.](image10.png)
+
+### Debugging
+
+A common theme in the responses to the final question on the survey, “What could
+be changed to improve the developer experience?”, is the desire for an easier to
+setup local environment – one you can see all the telemetry coming out of a
+running application locally – along with more information from SDKs, both during
+development and in production, when something is wrong, like data being dropped
+or an exporter being misconfigured.
+
+## Future Plans
+
+The results from those who responded are invaluable resources as we work to
+improve the OpenTelemetry developer experience. We will now direct some of this
+feedback to the respective SIGs, work on prototyping some solutions and follow
+up with the other teams.
path: content/en/blog/2025/devex-survey/index.md
user: login: dmathieu
body: I would finish this saying again that even though the survey is over, we still welcome feedback and anyone is welcome to join the SIG.

```suggestion
up with the other teams.

Even though the survey is now over, we do still welcome feedback. Feel free to reach out to us on Slack, or during our weekly meetings if you want to provide additional informations, or want to join us.
```
created_at: 2025-03-27T08:15:53Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarises our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question make it clear that getting started
+and operating with more complex pipelines or in larger deployments are not as
+easy as getting started, more on this in the Future Plans section.
+
+Interestingly, _collector-contrib_ had a large percentage of the responses to
+the question, “Which collector do you use?”. Sadly, it is unclear if this is due
+to being unaware of OCB
+([https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder](https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder))
+for building custom images, disinterest in using it or a lack of adequate
+documentation around its use.
+
+![Forms response chart. Question title: How complex was it to get started operating the OpenTelemetry Collector?. Number of responses: 199 responses.](image4.png)
+
+![Forms response chart. Question title: What environments are you using the OpenTelemetry collector? (select all that apply). Number of responses: 217 responses.](image5.png)
+
+![](image6.png)
+
+### SDK and Instrumentation
+
+Manual instrumentation and getting started with the SDK leaned slightly toward
+being more difficult. On the other hand, auto-instrumentation was solidly
+towards being easier to get started with. Despite getting started with
+auto-instrumentation being relatively straightforward, the results showed that
+enriching that telemetry was more difficult.
+
+![Forms response chart. Question title: Do you use OpenTelemetry SDK directly or
+via vendor SDK of the languages you use?. Number of responses: 217
+responses.](image7.png)
+
+![Forms response chart. Question title: How complex was it to manually
+instrument your application with OpenTelemetry?. Number of responses: 217
+responses.](image8.png)
+
+![Forms response chart. Question title: How complex was it to get started with OpenTelemetry SDK? (skip if you don't use). Number of responses: 217 responses.](image9.png)
+
+![Forms response chart. Question title: How complex was it to get started with auto-instrumentation? (skip if you don't use). Number of responses: 161 responses.](image10.png)
+
+### Debugging
+
+A common theme in the responses to the final question on the survey, “What could
+be changed to improve the developer experience?”, is the desire for an easier to
+setup local environment – one you can see all the telemetry coming out of a
+running application locally – along with more information from SDKs, both during
+development and in production, when something is wrong, like data being dropped
+or an exporter being misconfigured.
+
+## Future Plans
+
+The results from those who responded are invaluable resources as we work to
+improve the OpenTelemetry developer experience. We will now direct some of this
+feedback to the respective SIGs, work on prototyping some solutions and follow
+up with the other teams.
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Good point, I'm adding this locally and pushing it, I want to include links again to each of these.
created_at: 2025-03-27T11:02:33Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: You'll need to add a `cSpell:ignore:` field in the frontmatter with all the words not recognized by the SPELLING check.
created_at: 2025-03-27T11:11:33Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: ```suggestion
Thank you to all those who participated in the survey\! If you are interested in
```

The escaped ! is a bit strange.
created_at: 2025-03-27T11:12:17Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: Perhaps these findings could be better presented as a list or as a sequence of short pagraphs.
created_at: 2025-03-27T11:13:32Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: We capitalize Collector: https://opentelemetry.io/docs/contributing/style-guide/
created_at: 2025-03-27T11:14:22Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question, it seems clear there is a gap between
+getting started and operating with more complex pipelines or in larger deployments,
+more on this in the Future Plans section.
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: ```suggestion
getting started and operating with more complex pipelines or in larger deployments.
More on this in the Future Plans section.
```
created_at: 2025-03-27T11:14:59Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question, it seems clear there is a gap between
+getting started and operating with more complex pipelines or in larger deployments,
+more on this in the Future Plans section.
+
+Interestingly, _collector-contrib_ had a large percentage of the responses to
+the question, “Which collector do you use?”. Sadly, it is unclear if this is due
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: Why "Sadly"? We might to have explain a bit more about why the OCB should be the happy path.
created_at: 2025-03-27T11:15:39Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarises our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question make it clear that getting started
+and operating with more complex pipelines or in larger deployments are not as
+easy as getting started, more on this in the Future Plans section.
+
+Interestingly, _collector-contrib_ had a large percentage of the responses to
+the question, “Which collector do you use?”. Sadly, it is unclear if this is due
+to being unaware of OCB
+([https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder](https://github.com/open-telemetry/opentelemetry-collector/tree/main/cmd/builder))
+for building custom images, disinterest in using it or a lack of adequate
+documentation around its use.
+
+![Forms response chart. Question title: How complex was it to get started operating the OpenTelemetry Collector?. Number of responses: 199 responses.](image4.png)
+
+![Forms response chart. Question title: What environments are you using the OpenTelemetry collector? (select all that apply). Number of responses: 217 responses.](image5.png)
+
+![](image6.png)
+
+### SDK and Instrumentation
+
+Manual instrumentation and getting started with the SDK leaned slightly toward
+being more difficult. On the other hand, auto-instrumentation was solidly
+towards being easier to get started with. Despite getting started with
+auto-instrumentation being relatively straightforward, the results showed that
+enriching that telemetry was more difficult.
+
+![Forms response chart. Question title: Do you use OpenTelemetry SDK directly or
+via vendor SDK of the languages you use?. Number of responses: 217
+responses.](image7.png)
+
+![Forms response chart. Question title: How complex was it to manually
+instrument your application with OpenTelemetry?. Number of responses: 217
+responses.](image8.png)
+
+![Forms response chart. Question title: How complex was it to get started with OpenTelemetry SDK? (skip if you don't use). Number of responses: 217 responses.](image9.png)
+
+![Forms response chart. Question title: How complex was it to get started with auto-instrumentation? (skip if you don't use). Number of responses: 161 responses.](image10.png)
+
+### Debugging
+
+A common theme in the responses to the final question on the survey, “What could
+be changed to improve the developer experience?”, is the desire for an easier to
+setup local environment – one you can see all the telemetry coming out of a
+running application locally – along with more information from SDKs, both during
+development and in production, when something is wrong, like data being dropped
+or an exporter being misconfigured.
+
+## Future Plans
+
+The results from those who responded are invaluable resources as we work to
+improve the OpenTelemetry developer experience. We will now direct some of this
+feedback to the respective SIGs, work on prototyping some solutions and follow
+up with the other teams.
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Done.
created_at: 2025-03-27T11:43:20Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Oh ok, I see the test failure now. I thought `npm run check:text` would have told me if there were any.
created_at: 2025-03-27T11:44:50Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Yea, google docs exporting to markdon added those and I just left it since it worked, but works without too so I've now removed them.
created_at: 2025-03-27T11:53:25Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Thanks, done.
created_at: 2025-03-27T11:55:01Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question, it seems clear there is a gap between
+getting started and operating with more complex pipelines or in larger deployments,
+more on this in the Future Plans section.
+
+Interestingly, _collector-contrib_ had a large percentage of the responses to
+the question, “Which collector do you use?”. Sadly, it is unclear if this is due
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Here the sadly was referring to simply that the survey wasn't able to surface that kind of detail. But it is true we are also implying it is better to use ocb than contrib so should have an explanation. I originally was going to include that but it gets long and complicated, plus  veers off topic.

Let me see if I can find a good short explanation from the OCB docs. I also didn't want to imply too much about implications of using contrib since we haven't gone to the Collector SIG with this yet to discuss.
created_at: 2025-03-27T12:04:13Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Hm, maybe @julianocosta89 would be up to create another custom chart :)
created_at: 2025-03-27T14:28:05Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
path: content/en/blog/2025/devex-survey/index.md
user: login: julianocosta89
body: We have the following charts on the survey already:

- Do you work for an Observability or APM (monitoring) vendor?
- Are you running OpenTelemetry in Production?
- Where in your Observability journey is your organization?
- Which platforms are you running OpenTelemety on?

I'll create a new one for this last questions (platforms), as the one generated by Google Forms is horrible, but the others seem good to go.

Regarding the programming languages, we already have a chart later on the article.
created_at: 2025-03-27T14:36:11Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
path: content/en/blog/2025/devex-survey/index.md
user: login: julianocosta89
body: WDYT?

![image](https://github.com/user-attachments/assets/f03ab009-3c4a-4630-9c29-ce9484cee045)

created_at: 2025-03-27T15:34:39Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Looks ok to me. I can run with that if we want.
created_at: 2025-03-28T23:09:31Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,148 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-26
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey\! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability. The platforms used leaned towards Kubernetes (68.2%) and AWS
+(34.6%), with bare metal still making up a respectable percentage (12%).
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below. While
+those working on backends or operations were the majority of respondents, mobile
+and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?. Number of responses: 217 responses.](image1.png)
+
+![](image2.png)
+
+![Forms response chart. Question title: What kind of service do you regularly
+work on? (select all that apply). Number of responses: 217
+responses.](image3.png)
+
+### Documentation
+
+Results showed that, by far, people were getting their day one information when
+getting started with OpenTelemetry from the website and GitHub repositories for
+languages, 75.1% and 43.8%, while 25.1% were starting from their vendor’s
+documentation. However, unclear documentation took the top spot in the three
+questions related to getting started with manual instrumentation, auto
+instrumentation and setting up the SDK. In the collector's case, it took second
+place to “configuring the processors”.
+
+More details on the user experience with documentation can be found in the
+survey results of the [survey](/blog/2024/otel-docs-survey/) conducted by the
+End User SIG.
+
+### Collector Usage
+
+Getting started with the Collector was shown to lean towards the fairly easy,
+though based on results for the question asking for problems with operating the
+Collector and the overall experience question, it seems clear there is a gap between
+getting started and operating with more complex pipelines or in larger deployments,
+more on this in the Future Plans section.
+
+Interestingly, _collector-contrib_ had a large percentage of the responses to
+the question, “Which collector do you use?”. Sadly, it is unclear if this is due
path: content/en/blog/2025/devex-survey/index.md
user: login: tsloughter
body: Sorry, didn't report back that I checked the OCB docs and they give the impression OCB is for if you have a custom component, so I could not find a short explanation from there.
created_at: 2025-03-28T23:10:35Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,160 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-27
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+cSpell:ignore: OTTL Sloughter
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
+
+The OpenTelemetry Developer Experience SIG recently surveyed the community to
+better understand where the SIG could have the most impact on improving the
+developer experience. We received 218 responses, which we will use to guide our
+prioritization of work within the SIG. This post summarizes our findings and
+where we will focus in the near term.
+
+Thank you to all those who participated in the survey! If you are interested in
+joining us in these efforts or providing additional insights on where you think
+the developer experience of OpenTelemetry can be improved, please don’t hesitate
+to reach out. Contact information for the SIG can be found in the Community
+repo’s list of
+[Cross-Cutting SIGs](https://github.com/open-telemetry/community/?tab=readme-ov-file#cross-cutting-sigs),
+and we have a
+[repository](https://github.com/open-telemetry/sig-developer-experience) of our
+own on GitHub.
+
+## Key Takeaways
+
+The survey responses highlight the need for improved documentation, more
+in-depth examples and more substantial guidance on debugging, configuring and
+deploying OpenTelemetry in Production. Below are the main areas of concern:
+
+- Documentation:
+  - Documentation is difficult to navigate, requiring users to switch between
+    the OpenTelemetry website and GitHub repositories. Many users report having
+    to piece together information from various sources.
+  - Lack of examples of production usage for both the SDKs and Collector.
+- Local debugging:
+  - It's difficult to know why exporting isn't working, and if the SDK is
+    dropping data. Better tooling for local debugging would help with
+    troubleshooting.
+- SDK configuration:
+  - Overall complexity (both configuration and concepts)
+  - SDK configuration is complex, and many users have pointed out that
+    troubleshooting the exporter is the most painful part.
+- Collector operations:
+  - Debugging guidance on the Collector configuration and its components is
+    needed. OTTL was mentioned a couple of times for being difficult to
+    troubleshoot.
+
+## Detailed Insights
+
+### General Information about Respondents
+
+The survey responses came from users, of whom the majority use OpenTelemetry in
+production (83%) and do not work for a vendor (77.4%). 82% consider their
+organization to be at an intermediate or advanced phase of their journey with
+observability.
+
+The platforms used leaned towards Kubernetes (68.2%) and AWS (34.6%), with bare
+metal still making up a respectable percentage (12%).
+
+Programming language usage was split between the usual suspects of Go, Java,
+JavaScript, Python and .NET, but had a wide spread and even languages without
+official API/SDK implementations, as shown in the second graph below.
+
+While those working on backends or operations were the majority of respondents,
+mobile and browser were represented as well, see the third graph:
+
+![Forms response chart. Question title: Where in your Observability journey is
+your organization?](image3.png)
+
+![Forms response chart. Question title: What programming languages are you using with OpenTelemtery?](image7.png)
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: ```suggestion
![Forms response chart. Question title: What programming languages are you using with OpenTelemetry?](image7.png)
```
created_at: 2025-04-02T11:57:59Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,160 @@
+---
+title: Insights from the OpenTelemetry Developer Experience Survey
+linkTitle: Insights from the Developer Experience Survey
+date: 2025-03-27
+author: >
+  [Tristan Sloughter](https://github.com/tsloughter) (MyDecisiveAI), [Juliano
+  Costa](https://github.com/julianocosta89) (Datadog), [Steve
+  Gordon](https://github.com/stevejgordon) (Elastic), [Damien
+  Mathieu](https://github.com/dmathieu) (Elastic)
+sig: Developer Experience
+cSpell:ignore: OTTL Sloughter
+---
+
+# Insights from the OpenTelemetry Developer Experience Survey
path: content/en/blog/2025/devex-survey/index.md
user: login: theletterf
body: ```suggestion
```

No need for a separate H1, it's already in the frontmatter.
created_at: 2025-04-02T11:59:05Z
author_association: MEMBER

PR comments:
user: login: theletterf
created_at: 2025-03-31T07:50:11Z
body: /fix:all
author_association: MEMBER
user: login: opentelemetrybot
created_at: 2025-03-31T07:50:26Z
body: You triggered fix:all action run at https://github.com/open-telemetry/opentelemetry.io/actions/runs/14166675710
author_association: CONTRIBUTOR
user: login: opentelemetrybot
created_at: 2025-03-31T07:57:02Z
body: `fix:all` was [successful](https://github.com/open-telemetry/opentelemetry.io/actions/runs/14166675710).
### IMPORTANT: (RE-)RUN `/fix:all` to ensure that there are no remaining check issues.
author_association: CONTRIBUTOR
user: login: tsloughter
created_at: 2025-04-02T11:49:29Z
body: @theletterf wow, thanks for that catch. I thought google docs downloaded the images in a numbered order of how they were used but it was all mixed up. I've corrected the image order and alt text.
author_association: MEMBER
user: login: tsloughter
created_at: 2025-04-02T13:05:41Z
body: Ugh, it may be because I rebased locally, then saw you had merged here, so I rebased again on top of that... 
author_association: MEMBER
user: login: tsloughter
created_at: 2025-04-02T13:28:30Z
body: Alright, now its back to just the files that need to change. 
author_association: MEMBER
user: login: tsloughter
created_at: 2025-04-02T13:32:55Z
body: Oh, I need to include the new image from @julianocosta89 one sec
author_association: MEMBER
user: login: tsloughter
created_at: 2025-04-02T13:43:59Z
body: Ok, added the image, so should be good to go now and I won't touch the commits anymore :)
author_association: MEMBER
user: login: tsloughter
created_at: 2025-04-02T13:44:53Z
body: Actually, should I update the date on the page? It is currently still March 27...
author_association: MEMBER
user: login: theletterf
created_at: 2025-04-02T13:46:03Z
body: @tsloughter Yeah, I think we can go live today. :) Thanks! Will approve once the tests pass.
author_association: MEMBER
user: login: tsloughter
created_at: 2025-04-02T13:47:48Z
body: Great! I've updated the date.
author_association: MEMBER
user: login: tiffany76
created_at: 2025-04-02T15:03:34Z
body: /fix:refcache
author_association: MEMBER
user: login: opentelemetrybot
created_at: 2025-04-02T15:04:11Z
body: You triggered fix:refcache action run at https://github.com/open-telemetry/opentelemetry.io/actions/runs/14222959776
author_association: CONTRIBUTOR
user: login: opentelemetrybot
created_at: 2025-04-02T15:09:34Z
body: `fix:refcache` was [successful](https://github.com/open-telemetry/opentelemetry.io/actions/runs/14222959776).
### IMPORTANT: (RE-)RUN `/fix:all` to ensure that there are no remaining check issues.
author_association: CONTRIBUTOR
user: login: tiffany76
created_at: 2025-04-02T15:55:16Z
body: The [post](https://opentelemetry.io/blog/2025/devex-survey/) has been published and shared on social media. 🎉 
author_association: MEMBER