OpenTelemetry Governance Panel - Reese Lee, Juraci Paixao Krohling, Alolita Sharma & Daniel Dyla

Summary

The video script features a panel discussion with members of the OpenTelemetry governance committee, who introduce themselves and their roles. They delve into the committee's responsibilities, including managing product and feature backlogs, ensuring contributor and developer experience, and fostering community growth. The conversation also touches on the project's evolution, the addition of new signals, and the balance between supporting various programming languages and idiomatic APIs. The panelists emphasize the ongoing nature of OpenTelemetry's development and the importance of community involvement in shaping its future.

Takeaways

• 😀 The OpenTelemetry governance committee (GC) is composed of various contributors who manage the project's direction, including product backlog and feature requests.
• 👥 The GC members wear multiple hats, acting as representatives of the project to the greater community and handling external relations and media interactions.
• 🔧 The committee is focused on improving contributor and developer experience, supporting maintainers, and ensuring the health of the project.
• 🌐 OpenTelemetry is not a monolithic project; it is composable, with a focus on being a de facto standard for observability in cloud-native environments.
• 📈 There is a continuous effort to expand OpenTelemetry beyond traces, metrics, and logs to include new areas like profiling, client telemetry, and machine learning.
• 🛠 The GC is in the process of establishing a more structured project management approach, including the concept of 'projects' that need sponsors and clear active collaboration.
• 🔄 OpenTelemetry is designed to be vendor-neutral, allowing for changes in solutions while maintaining interoperability through the OpenTelemetry Protocol (OTLP) and semantic conventions.
• 🌟 The committee is keen on fostering a community that can absorb new requirements and technologies, such as those arising from AI applications and new hardware like GPUs.
• 📝 There is an emphasis on creating a clear path for subject matter experts to contribute and eventually become spec approvers or even members of the technical committee (TC).
• 🚀 The GC is working on making the project more accessible and convenient for new contributors, with a new developer experience Sig being initiated to streamline APIs and installation processes.
• 🔑 The key to the success of new Special Interest Groups (SIGs) within OpenTelemetry is having clear goals, committed leads, and sponsorship from the GC.

Q & A

What is the primary role of the Governance Committee (GC) in the Open Telemetry project?

The GC is responsible for overseeing the health of the Open Telemetry project. It manages the product and feature backlog, ensures contributor and developer experience concerns are addressed, supports maintainers, and acts as a strategic representative of the project to the greater Cloud native community.

What does the term 'Sig' refer to in the context of the Open Telemetry project?

In the script, 'Sig' refers to a Special Interest Group, which is a subgroup within the Open Telemetry community that focuses on specific areas or aspects of the project.

How often is the Governance Committee elected by the community?

The Governance Committee is elected by the community every two years.

What is the significance of having a project management structure in the Open Telemetry project as it grows?

As the project grows, having a project management structure helps in organizing work more efficiently, ensuring that new areas of work are properly sponsored and that there is clear active collaboration among subject matter experts and maintainers.

What is the purpose of the liaison program mentioned by the GC?

The liaison program aims to establish a line of communication between the Special Interest Groups (SIGs) and the GC, ensuring information flow and supporting maintainers more effectively.

How does the GC plan to engage with new contributors to the Open Telemetry project?

The GC plans to reach out to new contributors more directly, acknowledging their contributions, and providing support to help them contribute further to the project.

What is the relationship between the Open Telemetry project and the Cloud Native Computing Foundation (CNCF)?

The Open Telemetry project is part of the CNCF ecosystem and receives support in terms of resources, cloud credits, and promotional efforts from the CNCF and its member companies.

What is the current status of the Open Telemetry project in terms of its development focus on traces, metrics, and logs?

While traces, metrics, and logs have been the primary focus for several years, the project is now considering expanding into other areas such as profiling, client telemetry, and machine learning, while still addressing any backlog in the original focus areas.

What is the process for deciding whether to open up a new SIG or introduce a new signal in the Open Telemetry project?

The process involves creating a proposal in the form of a PR in the community repository, outlining the goals, leads, sponsors, and timeline. The GC reviews the proposal and assesses the availability of resources and the potential for the new SIG to succeed before making a decision.

How does the Open Telemetry project approach the balance between supporting different programming languages and adhering to language idioms?

The project aims to strike a balance where the API feels consistent across languages for those who switch between them, while also being idiomatic to each language so that it feels natural to developers who have been using a particular language for a long time.

What is the significance of semantic conventions in the Open Telemetry project?

Semantic conventions are important as they provide the necessary context and meaning to the telemetry data, enabling better storage, querying, and understanding by end users, which is crucial for effective observability.

Outlines

00:00

🗣️ Introductions and Governance Committee Roles

The paragraph introduces various members of the Open Telemetry governance committee and their roles in different companies and projects. Rey, a senior developer relations engineer at New Relic, initiates the introductions and mentions the governance committee's purpose. Dan from Dynatrace, Austin Parker from Honeycomb, Judan King from Graphon Labs, Ted from the Open Tracing side, and Alita Sharma from Apple all introduce themselves, highlighting their contributions to Open Telemetry and related projects. The paragraph emphasizes the committee's responsibility for the project's health, handling product management, feature backlogs, and addressing contributor concerns.

05:02

🛠️ Governance Committee's Structure and Community Engagement

This section delves into the governance committee's evolving structure due to project growth, introducing the concept of 'projects' within Open Telemetry. It discusses the need for project sponsors, the importance of collaboration with subject matter experts, and the governance committee's role in facilitating community engagement. The paragraph also mentions the beta testing of community projects, the liaison program for better communication between the governance committee and maintainers, and the initiative to reach out to new contributors, reinforcing the committee's commitment to the project's health and community involvement.

10:03

🌐 External Representation and Strategic Initiatives

The paragraph highlights the governance committee's role in representing Open Telemetry to the broader cloud-native community. It covers the committee's involvement in securing resources such as cloud credits and handling interactions with the media to promote the project. The members discuss their strategic role in engaging with large organizations to develop Open Telemetry strategies, emphasizing the importance of advocacy for the project and open-source observability within the cloud-native ecosystem.

15:08

🔍 Future Directions and Continuous Improvement

The discussion in this paragraph revolves around the future of Open Telemetry, addressing the question of when the project might be considered 'done.' Panelists share insights on the continuous nature of open-source projects, the need for evolving standards, and the integration of new signals like profiling and machine learning. They emphasize the importance of community involvement in expanding the project's scope and improving the developer and end-user experience, acknowledging that the project will never be truly 'done' due to ever-evolving technology and requirements.

20:09

📈 New Observability Requirements and AI Integration

This section focuses on the emerging observability requirements brought by AI applications and the foundational work needed to support these new hardware and software developments. The panelists discuss the importance of Open Telemetry Protocol (OTP) and standardized metrics, tracing, and profiling in the context of GPUs and other advanced computational resources. They invite more contributors to join and support the new generation of applications, emphasizing the potential for Open Telemetry to adapt and grow with technological advancements.

25:11

🔧 Developer Experience and Signal Prioritization

The paragraph discusses efforts to improve developer experience and end-user adoption, as well as the process for deciding when to open a new Special Interest Group (SIG) or introduce a new signal. The panelists describe the project process and template for proposing new SIGs, emphasizing the importance of having clear goals, leads, sponsors, and timelines. They also touch on the challenge of balancing the desire to experiment with the need for structured development and the committee's cautious approach to avoid spreading themselves too thin.

30:13

🌟 Semantic Conventions and Signal Evolution

This section explores the concept of semantic telemetry and the importance of aligning new data types with existing signals in observability. The panelists discuss the evolution of semantic conventions, the challenge of instrumenting across different layers of technology, and the need for collaboration to maintain a baseline on protocol standardization. They also address the question of when to add new signals, emphasizing the importance of widespread adoption and the need for strict data structure guarantees for analysis.

35:16

🏗️ Balancing Language Implementations with Open Telemetry

The paragraph examines the challenge of creating a specification that is broad enough to accommodate various language environments while maintaining consistency across implementations. The panelists discuss the spec's generality and the interpretation allowed for language maintainers, the importance of balancing language-specific idioms with a consistent experience across languages, and the role of the Developer Experience SIG in addressing these concerns. They also highlight the importance of the Open Telemetry community's feedback in refining the API and spec.

40:16

🤝 Integrating Expertise and TC Development

This section discusses the integration of subject matter experts into the Open Telemetry project and the development of the Technical Committee (TC). The panelists emphasize the importance of collaboration between experts and Open Telemetry architects, the need for a clear path to the TC, and the desire for the TC to include experts in every signal area. They also address the importance of feedback and the project's commitment to ensuring that all voices are heard and integrated effectively, regardless of whether individuals hold a formal TC position.

45:17

🚀 Conclusion and Call for Continued Engagement

The final paragraph wraps up the discussion by emphasizing the ongoing nature of the project and the desire for continued community engagement. The panelists invite participants to connect with the governance committee and TC members during breaks or lunch, highlighting an upcoming panel with TC members. They stress the importance of feedback and the project's commitment to fostering an environment where anyone can have an impact, regardless of their position within the project.

Keywords

💡Open Telemetry

Open Telemetry is an open-source observability framework for cloud-native software, aiming to standardize the capture, transport, and ingestion of telemetry data (metrics, logs, and traces). In the video, it is the central project that the Governance Committee (GC) and Technical Committee (TC) members are discussing and contributing to, with various initiatives and subprojects under its umbrella.

💡Governance Committee (GC)

The Governance Committee in the context of the video refers to a group of individuals elected by the community to oversee the management and direction of the Open Telemetry project. Their responsibilities include managing the product and feature backlog, ensuring a positive contributor and developer experience, and representing the project to the wider community. The script mentions the GC's role in project management, maintaining communication, and fostering a healthy project ecosystem.

💡Technical Committee (TC)

The Technical Committee is responsible for the technical oversight of the Open Telemetry project. Members of the TC are expected to evaluate designs, gather requirements, and make decisions that align with the project's goals. The script discusses the importance of the TC in maintaining the project's specifications and how subject matter experts can contribute to the project even if they are not TC members.

💡Semantic Conventions

Semantic Conventions in the script refer to the standardized naming and structuring of telemetry data within Open Telemetry. This ensures consistency and interoperability between different systems and tools using the Open Telemetry data. The script mentions the need for stable semantic conventions and the role of a specific SIG (Special Interest Group) dedicated to this aspect of the project.

💡SIG (Special Interest Group)

A Special Interest Group is a subgroup within the Open Telemetry community that focuses on a specific area or aspect of the project. SIGs are formed to work on dedicated topics such as profiling, events, or AI observability. The script discusses the process for creating a new SIG and the importance of having clear goals, leads, and sponsors for these groups.

💡Observability

Observability in the context of the video pertains to the ability to understand the internal state of a system through the collection and analysis of telemetry data. The goal is to gain insights into system behavior and performance. The script highlights the importance of observability in various domains, including AI applications and the evolution of new observability requirements with emerging technologies.

💡Metrics

Metrics in the script refer to a type of telemetry data that represents measurements or counts of activity within a system. Metrics are used for monitoring and alerting and are a fundamental aspect of the Open Telemetry project. The discussion includes the evolution of metrics and the potential for new types of metrics to emerge with new technologies.

💡Traces

Traces are a sequence of events that are captured and correlated to provide insights into the flow of requests or transactions within a distributed system. In the script, traces are mentioned as a foundational telemetry signal within Open Telemetry, with discussions on their importance and the potential for new use cases to emerge.

💡Profiling

Profiling in the video script refers to a type of telemetry data that captures performance-related information, such as the runtime behavior of applications. Profiling is discussed as an area of interest within Open Telemetry, with the potential for new profiling signals and the need for subject matter experts to contribute to the project.

💡Context Propagation

Context Propagation is the process of passing contextual information, such as trace IDs and other metadata, across different components of a system to maintain the correlation of telemetry data. The script mentions the importance of context propagation for ensuring the interoperability of telemetry data across different systems and languages.

💡Vendor Neutrality

Vendor Neutrality in the script highlights the Open Telemetry project's commitment to being platform-agnostic and allowing for flexibility in the choice of tools and technologies. It emphasizes the ability to change solutions without being locked into a specific vendor's implementation, as long as the data remains compatible with the Open Telemetry standards.

Highlights

Introduction of the governance committee members and their roles within the OpenTelemetry project.

Discussion on the responsibilities of the governance committee, including managing product and feature backlogs.

The importance of addressing contributor and developer experience concerns within the OpenTelemetry community.

The concept of project management and the need for structure as the OpenTelemetry project grows.

The role of the governance committee in sponsoring new projects and facilitating collaboration between subject matter experts.

Initiation of a GC liaison program to improve communication between Special Interest Groups (SIGs) and the governance committee.

Plans to reach out to new contributors more directly to acknowledge their contributions and support their integration into the project.

The governance committee's ultimate responsibility for the health of the OpenTelemetry project and fostering a supportive community.

The strategic representation of OpenTelemetry to the greater Cloud Native community and handling of external resources.

The interface role of the governance committee with the media to promote OpenTelemetry and open source observability.

The continuous evolution of OpenTelemetry and the challenges of determining when the project is 'done'.

The potential for new signals in OpenTelemetry, such as profiling and machine learning observability, and the criteria for their inclusion.

The balance between supporting different programming languages and maintaining idiomatic APIs in OpenTelemetry.

The developer experience SIG's focus on improving the convenience and accessibility of OpenTelemetry APIs.

The process for proposing and establishing new SIGs within the OpenTelemetry project, emphasizing the importance of clear goals and sponsorship.

The need for subject matter experts to work closely with the OpenTelemetry architecture team for successful project proposals.

The importance of the Technical Committee (TC) in evaluating designs and the criteria for becoming a TC member.

The project's aim to ensure that impact can be made without necessarily being a member of the TC, emphasizing the project's health and autonomy.

Transcripts

so my name is reys um my day job is at

New Relic where I'm a senior developer

uh relations

engineer and I also work on the end user

Sig um that Austin just mentioned so if

there's any events or any end user

resources you're interested in starting

up definitely come see me or uh Ren is

here as well I think that's just the two

of us but anyways I'm going to pass a

mic down the line here so everyone has a

chance to introduce themselves but we're

here to get to know the Govern committee

find out what they do and you all will

also have a chance to ask

questions I'll stand so I can be seen uh

I'm Dan daa uh my day job is at Din trce

I've been contributing to open Telemetry

since uh late

2019 uh it's been a while I've been the

maintainer of the JS Sig since then and

I've been on the governance committee

since uh late 2020

I totally forgot to introduce myself

earlier sorry I'm Austin Parker um I am

director of Open Source at honeycom doio

I've been on the governance committee um

since last year and I've been involved

in open Telemetry since um yeah late

2019 and then I was maintainer on open

tracing before

that I'm judan King I'm a software

engineer at graphon Labs um I work with

the open Telemetry or own the open

Telemetry project as my day job um and

and I've been with open climet since it

was open tracing right so um it's been a

while um I work out I work on the

collector as well so I feel like I know

the collector folks in this room here I

know the other uh I don't know 50% of

this room here from open Telemetry but

I'm here this week to get to know the

other half of the

room hey everybody I'm Ted uh I'm one of

the co-founders of the project from the

open tracing side of the family and uh

yeah I serve on the GC

and mostly run around putting up fires

and uh trying to make people

happy hi everyone very nice to be here

I'm Alita Sharma and uh I've been on the

project working uh contributing to

metrics uh metric ga uh Prometheus inop

uh for since 2000 so you know super

thrilled to see the project grow and

really take off and be this de facto

standard uh I lead AIML observability at

Apple so uh again lot of exciting things

going on in the in the world of IML

nowadays uh and super thrilled to you

know see the intersection of our

wonderful Community here at otel

Community day today so ree over to

you sorry I didn't mean to just

awkwardly pass in

front so I guess we'll get started so

what does the governance Comm comme

do well um I think uh it's a very good

question and we've asked ourselves that

too you know several times because I

think it's a good way to actually check

in on what you know the governance

committee is up to given we are you know

elected by the community uh every two

years the GC has a two-year term and you

know it rolls over across the GC so um I

would say a couple of areas that we

definitely you know have taken on and

have been working through is first of

all wearing a product hat you know

managing the product backlog uh and the

feature backlog if you will for the

project and looking at you know some of

the new uh issues that are coming up in

the spec and you know Ted and everybody

else on the GC actually has been

phenomenal in uh contributing to making

sure that you know we all actually look

at the backlog on a regular basis so we

do look at it on a weekly basis and the

second uh area of course is that making

sure that uh you know any kind of uh

contributor and developer experience uh

concerns that the project Community

might be seeing or any governance you

know concerns that they might be seeing

are brought up and uh supporting our

maintainers of course

Ted yeah um there besides dealing with

nonsense behind the scenes um that

better goes left un said uh there's uh

been this need as the project has grown

to have more and more

structure um we're always adding

structure every time we add a piece of

structure I always ask how did we get

this far without having this much

structure um and this year is no

different though I think we've really

turned it up quite a bit by specifically

adding uh a concept much more concrete

concept of of project management so we

haven't fully rolled this out to the

community because we're kind of beta

testing it and we want to get get

comfortable uh with it but basically we

have this concept of projects uh that

are themselves something that's evolved

uh projects need to have sponsors this

is something that we've learned is that

uh as a Project's grown we have a lot

more people coming in from the outside

when we're working on a new area it's

almost always a collaboration between

subject matter experts who understand

that area because we're just you know a

bunch of Trace jockeys so we don't

necessarily know anything about

profiling or client Telemetry or

anything like that so subject matter

experts come in but they don't know much

about open Telemetry and if we want to

make sure those groups can quickly is uh

come together on a design proposal that

is going to be accepted by the Community

uh we have to like sponsor those groups

and there needs to be like some clear

active collaboration and people in those

groups need to understand who they can

go talk to uh in open Telemetry about

like getting their stuff moving um and

the next step of that is like the GC

besides putting those groups together

needs to actually like keep tabs on them

uh and also like all of the rest of the

maintainers in the project um trying to

make sure everyone's a little more

connected we just started a new GC

liaison program just making sure there's

a line of communication between the the

sigs and the GC so that there's just

some information flow going back and

forth um we do have a maintainers

meeting but um just like rather than

waiting for maintainers to like bubble

things up just like outreaching to the

maintainers and just checking in with

them and uh also uh the next step of

that we'd like to start reaching out to

new contributors a little more directly

we feel like that's a role that GC

should play uh when we see new people

joining and making uh significant

contributions just letting them know

that they've been seen and you know uh

seeing what we can do to help them

contribute

more I guess there's nothing else to say

about that I mean um I guess I would

summarize all of that with the idea that

the GC is the ultimate responsible for

the health of the project and if it

means means going monthly to the

maintainers and asking them how they're

doing or if it means building handbooks

for new contributors then that's what we

we have to be um perhaps not doing

ourselves but um fostering a a smaller

community on executing on on those ideas

on those needs um and I think that's

what the GC does so the GC um is also

part of most of or every one of us uh we

wear different heads uh in the project

so we we are at the GC only for one hour

of the week I think uh but then acting

as um members of the project in in on

the remaining of the

week h two hours because there's triage

too yeah

yeah um I'll actually add something to

to your point about wearing multiple

hats one other thing that the

GC acts as is in a lot of ways like a

strategic representative of the project

to the greater Cloud native community so

there's a lot of like little things that

are very boring about that but for

example

um the open Telemetry now has access to

some like very large amount of like

Oracle Cloud credits um that sigs can

use there's also Amazon credits that we

have access to and there's a lot of like

resources that we can get from the cncf

from Member companies who make donations

of resources into the cncf

and so part of our job is like going out

and and handling that the the like

talking to people and making stuff

available and d d d d right we also wind

up getting ried into I say roped in um

we also wind up kind of being an

interface to the media so when we go to

cubon and you know we want to talk about

like here's all the cool things

happening in otel um we collaborate with

the cncf PR department to you know build

news releases and do interviews with

analysts and journalists about what's

going on um to help promote the project

obviously but also to help promote like

open source observability and and Cloud

native more generally right um and that

also leads to kind of we'll talk to

people at a strategic level in sort of

like large member organizations right

like larger Banks or you know people

that are trying to like develop an open

Telemetry strategy um we we become

advocates for the project and advocates

for like what we're doing so a lot of

that stuff is like really not visible to

um anyone you see the outputs you see

things like this or you see like the the

open Telemetry Observatory At cubec Con

but you know it's another one of those

function you know kind of those

invisible functions of the GC you have

anything else to add or is there more to

add I don't think so I think that

basically covered it do these things we

do the the maintainer track talks yeah

we do these panels and maintainer track

talks

um

yeah so for a long time the past few

years the focus has been traces metrics

logs are you all

done yeah it's it's it shipped projects

over

all

right yeah this is actually you know

back to the like project management this

is one of the reasons why I think we've

had to like step it up more recently was

like we didn't really need much of a

road map for the first several years

it's like what are we working on this

year pinky it's like the same thing

we're working on last year tra's metrics

and logs um but as we've like gotten

near the end of that there's been a

whole bunch of interest in expanding the

project in a bunch of different ways and

at the same time there are parts of

traces metrics and logs that we kind of

put aside uh we kind of have an 8020

rule we found in open Telemetry when it

comes to design there's often like 80%

that like everyone can totally agree on

and then there's like some bit where

it's like this is weird and we're not

totally sure exactly how to do this and

we can't find consensus on it quite yet

and we tend to be like well let's put

that aside so we can get the 80% through

but at this point there's now kind of a

backlog of of some of those things so I

don't think we're actually done with

traces metrics and logs uh but we do

need to find a balance between that and

also doing like profiling and client and

machine learning and you know all these

other things so figuring out like how

much bandwidth we actually have is

something we're thinking

about I I mean is anything ever done an

open

source yes okay well we seem to have a

split decision I I think the the key

thing really is that I don't think open

Telemetry is going to be done

until the until everyone agrees with

this um but really when you think about

it right like otel is one of the otel is

it's interesting because when you look

at it how you perceive it depends on

where you're kind of looking at it um if

you look at it from the perspective of

like well I've been using X thing for

like metrics and log aggregation uh you

know the collector is just another

filebeat or whatever right um it's

another way to scrape Prometheus end

points and it's a way to perpetuate you

know it's an open source way to do it

it's a nonproprietary way to do it cool

but it's another way to kind of

perpetuate the sort of observability

signals that you've already had and then

if you look at it from the other

perspective it's like oh there's

actually a lot you can do here because

of these fundamental changes that are

baked into the data model and baked into

the tooling and ecosystem and I I don't

think we're going to be done until most

people are looking at it from that

second perspective um quite

frankly yeah I see a few ways we can

evolve in the future one of them is um

the standards like semantic conventions

we have so many semantic conventions to

make stable and to convince people that

uh specific names are um I don't know

worse pursuing more than other formats I

don't know uh then the collector itself

we we are trying to get A1 uh towards

the end of the year or I don't know

sometime this year but uh at the same

time we have profiling coming so where

do we fit profiling The Collector and

what are the next steps for The

Collector so we have so many things

around like building collectors with a

builder and building interfaces to build

collectors and so it's we're never done

I think to to your point uh and then we

have new signals as well so we have we

can grow in so many directions and uh

and for those of you who are not

contributors to the project we need you

we need you to expand into those areas

that we know that we need but we don't

have the the capacity right

now I would also say that obviously we

do have new signals coming but even if

we didn't say we we froze the project

today and said we're not expanding scope

we still have many many years of

improving the experience more

instrumentation native instrumentation

like it's it's a project that will never

be done kind of by definition it can

always be

better one point

because um and I think we were all

having some conversations earlier today

and I would like to reiterate to

Daniel's point we won't be done because

you know we have a lot of work to do in

improving developer experience and end

user uh experience for adoption uh but

it's also that we are also seeing a new

generation of observability requirements

that are coming in with AI

applications and there is foundational

work to be done at every layer uh in

order to make that intersect with the

not only with OTP which is our protocol

data protocol but also with uh inherent

support and standardized metrics uh

tracing profiling coming in uh for um a

new class of uh Hardware which is uh

gpus and you know additional compute

that is coming in so it's very very

important that you know again if you say

kubernetes uh metrics you know

observability is it done not really uh

is it uh is tracing done not really

because you know you have also this

lower layer that is completely changing

the way that we are going to have you

know the uh the networks and the and the

uh applications that are supported

across that so with a new generation

come new requirements and I think that's

the cool thing about working in open

source that a project like open

Telemetry can actually absorb and you

know start an a a whole generation of

new sigs which actually can work on

these areas as you know developers in

that space need to be able to support

that so I really welcome you know and

would love to have more contributors

joining in to supp support that new

generation you know work towards the

spec work towards the um uh protocol

work towards you know the

implementations in the different

languages and the standardization of

metrics and traces and profiles which

are coming in to support that new

generation of applications yeah just a

quick shout out to the new convenience

Sig that's starting up um what's the

developer experience developer

experience that we're calling it now

okay well uh anyways the idea is there's

at least one of the ideas there is

there's a lot of places where we could

add sugar like our apis installers

configurators and everything are

designed for completeness and meeting

requirements so that they can work

everywhere and handle everything that of

course means for doing like the basic

normal things they can be like a bit

overly complicated so where in the see

so many heads nodding right now uh where

in the project can we add sugar on top

of these things things uh to make those

parts uh just faster and more convenient

I think this is a great place for end

users to get involved because you're all

the people who really know uh where the

pain points are uh oh um this is not a

bit otel will not be done until someone

other than open Telemetry has

implemented the

spec God yeah when we have our first

like hard hard implementation Fork

that's when we're done we're all going

to go home but seriously no I I do think

like alternative there's there's so much

there right like it's very easy to see

otel as this big monolith but it's it's

very composable and um I'm the future

holds a lot for it do we want to do

audience

[Music]

Q&A I I'm sure you all have many

interesting

questions feel free to raise your hand

and I

will come find you

ah brave

soul so how do you decide like uh

whether it's appropriate to open up a

new Sig or a new signal um when people

suggested the project because like

there's a lot everyone like has a lot of

ideas and whatnot but resources are

limited and every new like Sig that we

had on it's a more over I'm just

curious a good a great great

question I guess I'll use this uh so

this is a thing we've had to work on

because we want sigs to succeed and so

what we've developed is uh a project

process and um a project template so

when someone wants to propose a new Sig

uh there's a whole bunch of pieces uh

that need to be laid out so you create

an issue in the community repo um

actually a PR in the community repo um

with all of this information and we try

to work with that group to fill it out

so it's like what is the goal um who's

actually going to work on this project

who's going to be the lead who's going

to sponsor it who is committing to

actually write code and build the

Prototype tyes what is the rough

timeline that we think uh will will be

done and if we can get all of that

together and it seems like we aren't

spreading ourselves too thin then we'll

start the Sig but we're trying to be

very cautious about this sounds like a

fun idea let's just spin a group up um

and when people don't have all of those

things just like one note there's often

this temptation be like well we'll it'll

just be experimental we'll just start

this thing in the corner and we'll just

experiment we we have a hard no to that

because that results in people doing a

whole bunch of work and then coming back

with their experiment and we're like no

we're not accepting this experiment

because you know it was not enough

people involved so that's that's how you

actually do it and that's how we we make

the

decisions um I think I can maybe speak

for the

GC and say it's actually like there's I

think there's a perception that we have

we have accepted too much

work um and I think that's partially

true but I also think that it's a

there's a little bit of recency bias

because a lot of the stuff

that just to be like pretty blunt like

people will I've I've heard from people

that are like very heavy tracing like

primarily using otel for tracing and

they're like why are you doing profiling

why are you doing events this doesn't

make sense to me profiling and events

have are literally like 2-year-old plus

projects right we've been working on

those for quite a while and in a lot of

cases those came effectively pre-

staffed right like the people that are

working on profiling as a signal are

people that work on profiling it is a

kind of a distinct um sub specialty the

people that are working on events are

web performance Engineers that you know

are very deeply committed to it and I

think they've brought like this amazing

level of like depth and care and it's

required us you know and this is not an

easy process to kind of EX to comport

those together together right now the

end result is I think a good one where

we've kind of are going of achieved for

the most part uh we will have a

compromise that makes everyone equally

unhappy

but you don't get there by like without

taking that time and putting in that

effort I do think in general we're

probably going to be like the the bar

for like a net new thing to come in is

going to get higher

but I also feel like as the spec matures

and becomes more stable you know you

don't have

to be a Sig to build on otel right like

as the spec stabilizes and the API I the

API stabiliz and all this stuff becomes

more stable I actually expect to see

like the ecosystem around otel getting

larger and there's already some examples

of this there's a project um that I

think is a Sandbox project now called

open

lemetry which is a which is basically

like o which is built on otel apis and

sdks and it's for like hey this is how

you observe these various AI components

right so you know people should feel

free to do that if you have look at the

kubernetes ecosystem there's a boatload

of projects in the cncf that are like

kubernetes plus something or some

kubernetes component right they don't

all live under the kubernetes project

you know this is this is how these

things mature and improve so people

should feel free to if they have like a

really great Hotel idea to like go build

that really great idea um and if it is

sustainable then it can become you know

a separate project as part of the you

know the

foundation perhaps just a a small

clarification before um you asked what

when we Define when we decide for a new

Sig and we here would be like open time

as a project or the GC the GC doesn't

decide when a new Sig is for right so we

can uh sometimes yeah but I mean we

merge the pr we yeah but we um it

doesn't we wear different heads um it

doesn't have to come from us and we

don't do the the the the sourcing for

that project right so we we expect the

the the people U proposing the Sig to go

and find all of the information they

need and then we just say okay that's

that's okay or that's uh we're not going

to accept it um but it's mostly formal

right I mean if if the a proposal has

enough like people and interest then

we're not going to say no um likely but

yeah I think there was a question

question yeah

okay hi how's it going uh my name is

Mike so I caught something there that

was kind of fascinating to me um

you're talking about how while

fundamentally all of these signals are

probably like a time stamp and a number

or a time stamp and a string you are uh

as it evolves you're finding that there

are specific objects you want to be able

to capture because those are the objects

we work with so like an event for

example you mentioned or a metric I

think again fundamentally time stamp in

a string time stamp in a number but

you're recognizing those as specific

objects that should be

captured uh

separately uh you also mentioned

lemetry that's an interesting word um

and I believe one of you mentioned that

you are uh responsible for observability

in AI at Apple um so this is all kind of

leading me to be very curious what are

some of these newer signals that we're

discovering that should be captured as

their own first class object in our

Telemetry in the AI world

you want to go first sure okay so I I

think you know um uh it's a good

question and I think we are still in

that uh process of discovery if you will

but uh the foundational approach uh for

even new types of objects or new types

of uh data that are related to these

objects you know mod models is a good

example um models have existed in ml for

a long time um they are becoming more

and more sophisticated larger and also

you know a lot faster but uh I think

that foundationally what we the approach

we have taken in observability

especially is to align with the existing

signals and the existing data types as

much as possible because it's always

easy to go and spin off and say Hey you

know this is another type of data uh and

let's go and support this new data

stream right and and but um it's also

very hard to roll out instrumentation

across the industry and the different

layers um of support whether that's uh

you know Hardware instrumentation or Os

instrumentation can you know or your

orchestration layer or your application

layer where you have to have full

support for that whole stack right so we

are very considerate in looking at how

that you know what these new data types

are can be aligned with existing um data

signals in observability and if you know

uh there is a need to Define additional

areas uh we are doing some work in

semantic conventions as uh Austin was

mentioning earlier we do have an llm uh

semantic convention Sig in on the

project and again also the community he

was referring to from llm metri and

others have also been working in that

Sig so we do try to kind of invite

everybody to work together and

collaborate so that we still maintain a

baseline on the protocol

standardization uh that said things will

evolve we may have new data types you

know as um the uh generation of AI

implementations gets more complex and uh

you'll see that Evolution

occur uh the

sorry no you

can uh so the the question was about

adding new signals and what I wanted to

say is if we've done a good job

designing the existing signals they

should

cover many use cases into the future the

idea is not that we're going to add a

new signal every time that technology

changes because that would be uh a

NeverEnding uh misery probably um but I

mean the the the way that I think about

the signals is that kind of at its at

its base layer everything is either an

event or some compression layer on top

of events so when you have metrics uh

you're aggregating events together

you're counting events you're you're

doing something along those lines traces

is fundamentally a start event and an

end event that are correlated together

um so the time to add a new signal is

when you see something that is so widely

adopted uh that it makes sense to to

promote it up to a higher level uh to

enable like more strict guarantees about

the structure of the data when it comes

into your backend for analysis uh or if

it's in the case of like metrics you

just can't send every event so you have

to aggregate it as almost for

compression reasons uh over the wire so

in terms of new signals that's the way

that I tend to think about it um and

then uh what you're talking about I

think is more new use cases on top of

the existing signals uh and a lot of

that will happen in uh the semantic

conventions for example so you have uh

like a definition for this event should

have these attributes and this name uh

and as new use cases come in that can

evolve much more quickly without having

to Define new top level

signals yeah

um I think like we talk a lot about

semantic inventions but it's also

probably worth considering that like

otel Telemetry itself is semantic

Telemetry right a trace is you know a

semantic conven a semantically durable

way to express like what is an what is

the series of events that happen between

a start time and an end time and d d a

metric is you know a like that's why the

otel you know otel metric spec is like

super in-depth right why is that because

you need all these semantics um for

storage reasons for query reasons and

also for like end user reasons right

like there's no reason if you know that

a you know particular instrument is of

Type X then why let people do the wrong

kind of math on it um now a lot of the

tooling hasn't caught up to where all

these semantics are and I think that is

you know to my earlier point about like

people that are in kind of Class A

versus Class B of how they look at o

like we're not going to get to that

class B part until there is this the

tooling kind of catches up to where

these underlying um standards are

going so perhaps um specifically to the

um AI or or um that kind of new signal I

would say that it's too early for us to

know whether that warrs a new signal uh

we we had proposals from allita actually

for rum signal uh in the past when we

discussed you know do we need a rum

signal or do we not need it um people

still don't know whether we need that um

so it might we might have we might have

a new signal in the future um the same

for profiling so profiling even though

we can see we can debate whether it is

an event or not um when we look at the

details for theab for the LLP profiling

um specification we can see that a lot

of it is um optimization to make

profiling usable as a signal you know so

it's so much data that is that is

generated for one specific sample that

we have to do a lot of

optimizations um and I guess my point is

because we don't know which

optimizations we need in the future for

this new um new whole new area we don't

know whether we need or not a new signal

in the future even though it might look

like what we that we have the basics

covered already

today yeah

sure uh well I just wanted to say like

the most most important signal we need

to integrate is the bat signal like if

every time a system goes down if like

that thing could go off

so hi um I'm interested in the sort of

language question um you know when you

think about the balance

between um supporting different

languages and trying to stand I versus

idiom in a language kind of where do you

think the lines should be drawn how do

you how do you conal a spec that's as

broad as this across so many different

uh language environments in

particular

ionna yeah so I I I think that's

dangerously close to a TC question but

as a language maintainer and a GC member

I guess I'll try um the spec is written

very generally and leaves a lot of a lot

to the interpretation of the language

maintainers um we we really do want

everything to feel the same if you're

switching between languages as a lot of

Engineers do uh you shouldn't have to

completely relearn how to use otel uh

but at the same time if you've been

using some language like Java your

entire life you shouldn't install otel

and then just be like what is this API

looks so weird so it's it's kind of a

balance between the two uh and from a

specification level uh it's generally

left quite open to interpretation by

maintainers in order for them to make

decisions about their own uh language

implementations um that said we do have

some very specific requirements in the

spec uh around certain things that

either come up in multiple languages and

and multiple maintainers have asked the

same question that'll be added to the

spec as a clarification a lot of those

are like should requirements not not

must

requirements um but yeah in in general

we we like to uh like to think that we

can trust our maintainers to to make

those decisions in a way that makes

sense uh and occasionally you know

people make mistakes it happens and

things bubble up uh but that's why we

have uh kind of a long uh

experimental uh type of uh cycle longer

than I think most people would hope

sometimes but uh it is you know for good

reason and it does help a lot in that

regard I the the developer experience

Sig is designed to kind of tackle this

question I think just speaking

spiritually I do feel like we've

probably ered on the side of not being

explicit enough that languages

should be air on the side of like idiom

um existing language idioms

maybe you know maybe we should have been

more explicit about that from the jump

that has always been the intention of

the project right because one of the big

things we learned from open tracing was

that uh spec

adherence to the API spec um made the

spec really made the apis really painful

in langu in

it made it suck equally for everyone

which wasn't a great outcome I don't

think um and we really wanted to avoid

that in open

Telemetry

one just just to add one quick thing as

a a language maintainer I receive

complaints opposite complaints for this

question all the time so I get issues

that are open that are like this feels

like Java why would you implement this

way like you're a JS developer I'm like

well I don't know like and then I get

the exact opposite uh complaint that's

like you made this way too JS specific

and I'm coming from Ruby and this feels

super weird I've been using open

Telemetry Ruby for years and and now I

can't figure out how to use your API

I'll I'll get exactly opposite

conflicting issues opened and like this

is something that I think will never be

completely solved uh and like I said

it's just a balance that we have to

strike yeah um so

one point I've noticed people uh haven't

realized so I've been saying more

recently is the spec actually doesn't

matter the details don't matter we

actually don't care what we care is that

the Black Box whatever it is

participates in tracing and emits OTP

and semantic conventions that is what we

care about if abandoning the spec and

everything else uh gets you to that

point then uh that's fine like that's

that is my hot take like now I'm not

saying now I'm not saying if we I'm not

saying if we spun up a group within open

Telemetry for a new language we wouldn't

say follow the spec and do all of these

things like for sure that is how we do

it but I'm saying for somebody out there

for some project out there if a language

decides they're going to fully integrate

tracing and observability into the

language and they're uh

you know um contous language developers

so they want to do everything different

like as long as the thing that's the

same is semantic conventions and OTP and

participating in tracing like that is

actually as far as like the the true

spec it's it's the data the the data is

more important than how the data is

generated and this does come up when

people are like what if I use this other

API to to do it we're like well that's

fine if whatever works for you

I I want to be very specific

participating in open Telemetry

context not just participating in

tracing uh API the API interop has to

work and the context propagation and

assigning

yeah I guess the idea and going into the

same spirit is we are all about vendor

neutrality so the ability of changing

Solutions if you want to change if you

want to use another API that's fine um

as long as you're still able to move uh

to different Solutions as As You Wish as

you as you

need I think we're one more question and

an important way for that Sig to be

successful are for those subject matter

experts to have direct Liaisons with uh

people who've understand the open

Telemetry architecture so those two

groups working together for a while to

develop their proposals we found that is

way way way uh has a much higher success

rate um and then on the other side of

that our hope is that some of those

subject matter experts will stay

involved and as they expand their

understanding of open slamry in general

become spec approvers and then uh

eventually uh we would like to make sure

that the TC contains subject matter

experts for every signal um but but we

kind of need it to go in that that level

of graduation

basically I think we're at a at a time

you want to no I think yeah um perhaps

just one thing to add there is we know

that we have gaps there uh on the TC

like profiling uh right now we don't

have anyone with profiling um background

there or some um but uh the other one

that I can think of is like client

instrumentation right so we we could

make use of people with better client

instrumentation background on a

TC um so but we don't have a a process

defined right now to cover those gaps uh

we we are thinking about how to make the

path to the TC more clear uh and we have

that in our heads uh it just needs to be

documented I I also just want to point

out like this has been a topic

for at least a year and a half or so um

certainly ever since I started like yeah

the the question not question but like

just this entire like top level TC um

maintenance and the role of the TC you

know I think we've actually had a lot of

really good progress this year in terms

of trying

to you know help the TC grow organically

um I know we actually have one of the

newest TC members in the room you know

so there's always more work to be done

um and but we need to make sure that

we're doing it in kind of a responsible

way for both the health of the project

um and also the health of the TC so

feedback is always of course

welcome yeah as as far as adding TC

members for for like you said new

signals but it doesn't have to be a new

signal like a new area of the project uh

people coming in from the outside are

very unlikely to be immediately added to

the TC and so kind of you know the the

these things that run for long periods

of time like a new signal is not going

to be added overnight so subject matter

experts that are that are working in

those signals should

hopefully evolve into the project and

and continue to stay in the project uh

to me the question is not like how do we

get uh you know a TC member with uh

experience in this specific area that we

just started working on but it's how do

we uh get that person's opinion

effectively integrated into the project

whether they're a TC member or not if a

subject matter expert is is working in

the project they shouldn't feel like

they have to to be like Oh I'm not on

the TC so I don't get a say here or I'm

not a maintainer so I don't get a say if

you know what you're talking about on a

particular subject uh having your that

that opinion heard and and integrated

into the project in a way that makes

sense uh to me is more important than

what that person's actual title

is yeah just yeah I think there's a

really important point to me made there

the thing we are looking for in TC

members is not necessarily being a

subject matter expert it's about being

able to work with subject matter experts

and evaluate designs against broader

requirements so someone who is say a

super expert at profiling or something

but has like a very high-handed opinion

about how to do it and doesn't really

want to listen to anyone else they might

be right it's not that they they would

necessarily be wrong but that is not the

kind of person we're looking for on the

TC we're looking for someone who's able

to to maybe be a little more diplomatic

and a little more interested in in

gathering requirements and and hearing

from everyone uh rather than being like

my way or the highway so that that's a

really important

quality yeah and and just to close that

out I think the ultimate goal is to what

Daniel said right in a perfect

world the pro you know the the the

processes and the ways that we work are

are established enough that you don't

that there is both a the perception and

the reality a line up that you don't

have to be like on the TC to be able to

actually have impact you know and I I

actually think that if there is a

perception that you have to be on the TC

to have impact then that is like a

failing of the project that we should

address um and you you hear all sorts of

things at this level um but I think

we're always working to make sure that

there is more autonomy and that people

can kind of come in and you know do do

their best work and as long as it's

aligned with what we're trying to do at

the project level that they will be

successful so I think with that we are

over

time

um yeah so we don't want to cut too much

into everyone's else's um time but you

know we'll be here all day so if you

want to grab someone in the GC um

there's actually a few other GC members

raise your hand yeah GC or TC GC or TC

yeah TC members also raise your hand TC

M yeah anybody yeah so come find us

during a break or at lunch um if you

have four questions and there will be a

panel with our TC members this afternoon

so thank you all very

much and thank you Reese