 So right now we're starting the maintainer forum. I'm really, really excited to be here and learning from everything's covering up everything else. To learn from these awesome contributors who've made some significant contributions to OpenClimitry. So let's go around and have each of our panelists introduce themselves starting with Tyler. Cool, yeah, not normally the first. So yeah, hi, I'm Tyler. I work at New Relic as a software engineer and I'm a maintainer of the GO special interest group of the SIG as we call it in the OpenClimitry project. And I've been working in OpenClimitry for just about a full year at this point, pretty much every day and working with these other wonderful folk in the community. I've also collaborated a lot with all these other people in the metric specification and the other sides of the specification as well. So I'm usually in a lot of different parts of the specification, well, infrequently, but yes. So yeah, that's kind of me and we'll probably dig into some more details as we go on. Thank you, Tyler. Tristan, can you go ahead and introduce yourself? Yeah, hi, I'm Tristan. I work at Postmates and I maintain the Erling and Elixir implementation SIG and I started with OpenClimitry, I guess over a year ago now, I was maintaining the Erling and Elixir OpenCensus implementation before that. And so I've segwayed into OpenClimitry when the projects were merged. Thank you so much. Tigran, can you go ahead and introduce yourself? Hi everyone, my name is Tigran. I'm an OpenClimitry maintainer and a technical committee member. I've been with OpenClimitry since the very beginning, actually before that, I've gotten consensus a little bit. Most of the work I do is on OpenClimitry collector and on the specification and primarily it's the tracing and blogging parts, a bit less so the metrics. Thanks, and Bogdan? Hi, my name is Bogdan. I'm one of the person that is guilty for all this mess that we created. When I was back in Google, I started the OpenCensus project as an open source initiative coming from Google. We did make a lot of contributions in that project and Tristan was part of that. Tigran was part of that effort. And then at one point we decided that, you know what? I think we are doing something wrong for the community. We are competing standards between OpenTracing and OpenCensus, as everyone know. And here we are, we are OpenClimitry and I'm very happy for this conference. It was great. Thank you so much, everyone. Thank you, and I'm Shelby Spees. I am a developer advocate at Honeycomb and I'm just here to help moderate and ask some questions, ask questions from the chat. I also want to mention that anyone who is a maintainer on OpenClimitry is encouraged to participate. So go ahead and raise your hand in Zoom and we can have you contribute and answer questions. So with that, I will share the first question. What has been your experience as an OpenClimitry maintainer and what are the challenges? Yeah, we can probably just start in the same order, I think is probably the best way. And then Bogdan can laugh at me, I guess. So, yeah, I think it's actually kind of ideal to kind of talk from my perspective, because unlike some of the other maintainers on this board, I didn't come from the world of already contributing and already building a census or OpenClimitry. In fact, I came from a world where I was using OpenCensus or using OpenClimitry or better to say evaluating as Bogdan kind of put out, there's a little bit of a, you know, which one, which you want to use. And it was extremely passionate about like this idea that having an open standard is really needed and the community I think can really benefit from it. And as I transitioned into contributing more into the project and to becoming eventually a maintainer for the GOSIG, it's just been really, I think, one that is a positive experience based on the community. I think Rachel Klein gave a great talk earlier, a little lightning talk about the community in general. And I think it kind of understates this fact, like the community itself is actually a really positive element about contributing in the open source world. And I've really appreciated that dynamic of it. It also moves at its own speed, which coming from a very close source world is not the speed that essentially I'm used to. So it's kind of fun to try to get up to that new kind of model of operating I think has also been really exciting. And then just to benefit from the immense knowledge that comes from these other maintainers and other collaborators and other contributors participating in a very awesome and hopefully impactful project going forward has been kind of the run I've had so far. Continuing on as I'm really excited about as well, but we'll get into that. Yeah. Go ahead. Sorry. Yeah, and I think I have a unique perspective on maintainership in this because open, there wasn't ever an open tracing, Erlang elixir official API or anything. So there are dozens of them spread throughout. And when open telemetry started, since it was merging in open tracing, I spent a lot of time going through searching get hubs and package repos and Slack channels and finding all the people who maintain these open tracing elixir or Erlang implementations and asking them to join forces and try to drop theirs and push their users on to open telemetry. And we've been slowly moving forward with that and it's been pretty successful and people have been pretty happy to work together and we recently started the Erlang foundation and that's been a part of this. So yeah, a big challenge has been that consolidation but I think it's working out and it makes people feel more comfortable with the language with Erlang or Elixir use in their company because they see this CNCF project and with us involved and that they're able to integrate with the other, most companies aren't purely one or, you know, an Erlang or Elixir shop so they have to integrate with all these other languages and being able to work in this community with people implementing in other languages has been really useful towards that. Yeah, I was really excited to see that the Erlang or Elixir integration was one of the more mature ones because that's not always something you see in open source children, so awesome job there. So we have one question from the audience and I went ahead and edited my slide so everyone can see it. Let me try and be cool on the fly. That is not this one. How is the race towards a release candidate going in your SIG and what are the things that the community can do to help? So Tegan, it looks like you want to say something. Yeah, that's a good question. I think we're doing pretty well in the specification SIG. We have just frozen the portion of the specification which defines how pricing is supposed to work. So we're very near the finish line for the specification and we know that the language maintainers, language SDK maintainers are also ready to give us the implementations according to the specification. I would say we are now very close to the finish line through 1.0 release. So I feel very good about what we have done so far with the pricing part and the metrics. Josh was talking about that earlier. It's coming pretty soon after that. So we're doing well in all of the regards here. That's my perspective. Yeah, I don't know if I can show you. I'm just going to jump in with that same question. Yeah, I think we're going along in the ghosting. I can speak specifically. Obviously, the metrics set of things in the specification is still a work in progress, but we are making progress on that. And so it's more, I think, from the ghosting's perspective, an interesting thing because now we are really coming to the end of the tracing specification saying, this is going to be the release candidate. So really go make it, implement the specification. Sounds cool. Like, well, now you're done essentially, but the truth of the matter is that it's the implementations of that specification and the language communities that we're going to be offering them to. The adoption needs to be something that they want to use, I think. And that, as a SIG author, is really critical to me at this point in time because there are always multiple ways to implement a solution. And sometimes they're better for that language than others. And I think that having feedback from the community that we're hoping to eventually give this out to is paramount at this point. Like, it's absolutely critical. And we're trying through many different ways of requesting feedback from forums or through other like direct access to other users to get some feedback into those language implementations and trying to iterate them on those fast going forward. But yeah, it's still a work in progress. And I think that we're going to be asking and trying to do a lot more of that going forward. I see one of my co-maintainers in the go SIG, Anthony jumped on as well, not to put him under the spotlight too much. But I think that he has a really great perspective as well because he came from a world as an end user. I think this was pointing that out in the chat. And so, like, really, I mean, we can have him talk a little bit. I'll throw him under the spotlight as well about that. Yeah, I'll add him to the... Oh, I can add him to the spotlight. There he is. So we can put him on the spot to answer his questions if that's okay, Anthony. Yeah, sure. Awesome. So yeah, as an end user, I came to the project, I think fairly early on, because we were just starting a new application development project where we expected developments going to last two to three years. And we were looking at how do we instrument this and we saw, well, open tracing and open census are they're coming together, they're merging. So two to three years from now, when we're ready to go into production with this, they're not going to be there. I guess that means we ought to get in early on this open telemetry thing. And so we did. I dove in to start figuring out how the Go SDK worked. Might have been a bit early because I think the first time I tried to do the Hello World example, the documentation had changed between the time that I pulled the code and the time that I went to look at the documentation to see what I tried to do from the example wasn't working. But things have gotten a bit better from there. And the community was incredibly welcoming. So as soon as I jumped into the getter and started asking questions and saw that there were gaps in the capabilities that the instrumentation had that I could offer, offer up, you know, help with the HTTP instrumentation and things like that. Everybody was incredibly receptive to the help. And that just kind of one thing led to another of, you know, starting to review other people's pull requests becoming a reviewer and approver. And now here I am trying to help get it across the finish line to become an RC and then a GA. I would like to say first of all, thank you to all maintainers, all approvers and all contributors to this project without this would not be here. Secondly, I think at this moment, it's very critical for us when we talk about RC, when we talk about GA, that now more and more end users will help by trying our project. I think even though you don't do PRs contributions, helping us by using our work and trying our APIs, our implementation and provide feedback is probably more valuable at this point than anything else. So please help. If you, if you want to help with this, it will be greatly appreciated. Yeah. And the early electric thing we're nearing, you know, completion with the tracing API and SDK. And so when people have been coming and asking about how they can help, I usually say, can you write examples and put them up on GitHub so that we can point people to running examples. That's a really good place to help out. Thank you so much. And definitely like, I was really excited to see the talks this morning on just how to how to get involved and how welcoming the community is. And from from what I've been learning, you know, just the past like six, eight months of being even aware of the open telemetry community. I'm really excited to dive in and start contributing in my own way. So thanks everyone for just, you know, making the community so great. Let me pull up my next question. Share. So how can users provide feedback to maintainers and to the community in general? Like what, what is the best way to go about that? I will take this first just because Tyler was give him a moment to laugh at me. Sharing this experience. So first of all, I think I saw during the life of this project different ways to give feedback. I saw certain people coming writing some small Google Docs or whatever some documents with the, which incorporate the feedback and share that with us. That's a very, very nice way. And I think we, we treated all of them very seriously. And I think we, from there we filed issues and so on. So we, we took that in consideration. And I think Go has a good experience with that. Tyler can, can explain more about that. The other, the other way that I saw people doing this is via issues. So simply create issues with, with your, with your problem, with your feedback, try to, to, to explain the problem that you are trying to solve and try to, to give actionable item out of that issue. So somehow, how we can help. I think overall any channel, any way that trans, that, that makes a transfer or translation from, from your head to our head is good. It doesn't matter how it is. As long as we transferred this information, somehow it's, it's very good. And I'm, I'm happy with any way, but some, some other maintenance may have other preference, but. Yeah, thank you. And from what my understanding is there's, there's the Gitter, Gitter channels for each language and, and the different SIGs and as well as the CNCF channels, is that like sort of year round that you can participate in the CNCS Slack and ask questions there. The GitHub repositories, opening issues there. But yeah, I've certainly had my moments where I'm just like, man, I can make a list and just some Google doc and share that with somebody is here. Here are all the things that I want help with. Or I'd like to help improve. So that's good to know that we don't have to. Yeah. Just to clarify one thing. Yeah, we're using the CNCF Slack for the duration of the KubeCon conference, but we typically don't hang out too much on it. Gitter's after KubeCon. Gitter's better. After GA, we may migrate to Slack. There's a bunch of discussions about that, but we don't want to pull the trigger on that quite yet. Sure. Good to know. Thank you for clarifying. One, one small comment on Gitter usage. Please use the public rooms. The direct messages, they are, they are not visible to anyone else. Obviously you'd want to use that. It's something you want to keep confidential. Otherwise, please use the public room. So there's the visibility for everyone else. Others can participate as well. And, and you can, you're also very welcome to come to the Seed Meetings. They are open for participation. They are great for live discussion. If you have something that you would like to both give feedback and also discuss that. So that's a great setting to come and talk to people who are working on the particular Seed. That's, that's all. Language Seeds, the Collector Seed, the Specifications Seeds. Apologies. I had the wrong window clicked. Technical difficulties. Here's my next question though. I know, I know lots of people have been talking about this today, but my question started out as how do you see open telemetry evolving over the next year? But I think I really want to know is what, what's the most excited, most exciting evolution, besides GA or besides your release candidate that you're excited about in this upcoming year? Should I call on somebody? So I think one of the things I'm most excited about is seeing what the end user community does once they've got a GA release that they feel comfortable taking and running with. We've got a lot of great instrumentation that's been added to the Go contrib repo, but I think it covers just a tiny slice of what's out there. And so I'm really interested to see how people instrument other libraries, what libraries they instrument, and where it goes once we hit that real taking off point of having a GA release. I'd like to expand a bit on what Anthony said. I think it's very important for us, one point always released to focus on our attention on actually making open telemetry popular. We want open telemetry to be widely used, right? I want to, I personally want to see every software library, every piece of popular software, database management system, web frameworks to have to be instrumented by open telemetry, right? And so that that instrumentation is also maintained as a first class capability by the authors of the library and the framework. Obviously, this is a very big goal, right? It will take years to be there, but I think it's very important for us, maintainers, contributors to open telemetry to think about this and make this out of our vision. We want to make sure that open telemetry is attractive to developers. It's easy to use. So we need to spend time on popularizing open telemetry to sell it to developers. It is very important. To follow up on that, do you know of any framework developers, framework maintainers who are involved in open telemetry or who are using open telemetry on their frameworks? As far as I know, .NET has plans to open telemetry. .NET shipped with open telemetry or a subset of open telemetry to keep adding new functionality. The other, by the way, another work that we did was with the Spring community, with the Spring Slute community, thanks to Margin, one of the maintainers of the Spring Slute tracing artifact there. He made a huge contribution. So most likely, I don't know if it's already released or it's going to be released this week or something like that. The new Spring Slute will include the open telemetry as well as one of the options there. Additionally, go ahead. Sorry, I didn't mean to catch up. I think we also have contributions in the Go Redis library itself directly, which is a really awesome thing to see. It's pretty cool just to see a very organic adoption at that level. That's in addition to all the contrib repos that are essentially plug-in models, which have also seen contributions from outside developers to help progress those. So you're getting a lot of community involvement there as well. Yeah, for me, I'm excited to see more vendor adoption as in early in the lecture, it's always been, you write just enough to support a vendor that you want to ship to and that's all you get because vendors never write integrations for us. And now it'll be a different world when vendors are adopting open telemetry and we're able to use hopefully most all of their features through it, which will be a very different world and I think it'll get a lot of adoption coming in from our big frameworks and Elixir, the Phoenix framework to start using these vendors and tools. Yeah, talking about vendors, this is a good point. I'm starting to see more and more vendors trying to make the canonical way or recommended way to be open telemetry, which means more and more contributions will come to the project because once vendors start selling this, they have to contribute more, they have to make it more robust, they have to increase quality and everything. So I think this is definitely a good point. I also want to see next year, maybe a world where different frameworks or independent projects like the one you pointed, Tyler, the goal already is different other projects starting to instrument themselves and take the dependency on these and see how that world will become and if that will become a better world or not. I hope it will be. Yeah, I just kind of wanted to go back to the original question of also how we see it evolving. I think we've done a really good job talking about how we see the code evolving. But I'd love to kind of just follow on what Bogdan was kind of leading into it. I'd love to see that community become bigger and continue on in its path to inclusivity that we try to engender in our community. I think that's a really awesome thing. I think we're really excited to just help in whatever way I possibly can and to facilitate that. Thank you so much. Go for it. Thanks for it. One last thing is also there's some work going on in logging and that won't be part of the release candidate or GA process that we have planned for Traces and Metrics. But next year we are going to see logs arrive for open telemetry later in the year and that's also quite exciting. And then we have a question for the audience. I'd love to get some answers in the chat. What do people want to see from the project in the next year that you haven't heard about today? What is something that you're just itching for for the maintainers to start prioritizing? Well, I know my answer is more sort of like three materials or like helping people especially whether you're developers or infrastructure engineers or whatever you probably haven't had to think about instrumentation this way before or a lot of people don't have experience with this sort of thing and what I found in the observability community is we're very good at talking about instrumentation, we're very good about talking about telemetry and most of our end users don't think about that every day, right? And so we tend to be very focused on that part and less able to reach out to the people who've this isn't their day-to-day work and now I'm seeing lots of answers in the chat so I will read those a lot. So Liz Funjones, my colleague feels that we need to do more telemetry workshops now that the API is stable and that's something that we've been working on Austin and Liz do the open telemetry workshop, they've given that I know several other people in the community have done that Josh McDonald who spoke earlier wants more logging when we reach GA This is an inside joke This is an inside game Sorry Short explanation he always pushes us to focus on GA and ignore other things and then later we can talk about other things which is good don't get me wrong Jonathan wants more stories on onboarding your organization and I would love that especially Anthony I know you shared your experience already but anyone else who can share your experience getting your organization to adopt open telemetry that would be awesome feel free to unmute and chime in and then also more open source projects and planting hotel more framework authors using GA would be fantastic I can say from the end user perspective and getting an organization onboard the two things that I found critical were one, making it as easy as possible for the developers to get started and I think some of the vendors are starting to go down this path with the distributions concept of here's an easy way to get everything configured I ended up internally writing a set of libraries that made it easy for you to hand us an HTTP handler and you get back a server that is instrumented and all of the trace providers and metric providers are configured for you so it becomes very easy for a developer to take an existing service and get it onboarded and the second thing is showing them the value, showing them why they want to go in and add their own custom spans and attributes to those spans and for me I think the most benefit I got was during the sprint demos we were working on some backend services and things were fairly opaque to the end users but I was able to say okay you had a question about how this was working and why this happened I can now show you here's a Yeager waterfall view where I can show you all of the things that this request did while it was processing and here's how it ended up getting to that result and not only the end users but also the developers and we're like oh yeah that makes it a lot easier for us to talk about what this thing is doing so then they were much more willing to engage with adding their own spans and attributes in the appropriate places thank you Anthony and we have I think this is a question documentation on concurrency in open telemetry and exporters for database backends can someone speak to that Tyler, yeah I can take a stab I think this is in the ghost space just based on some terminology and some of the known issues that we have there in the github org so one of our things is obviously in go it's a very concurrent language and in a lot of other languages like concurrency patterns are really important for performance let alone just overall programmability and support across other applications I think that we've definitely tried to bake that sort of things in API but maybe we could also try to make that a little clear for end users perspective and then when it comes to database backends in go there's a very long sending issue we're trying to provide a very good support for databases this is going to be a really important part of the long standing application interactions so we want to make sure that open telemetry has a really good story there so yeah Raj that's a great request hopefully a year's time from now we're going to have a great story for you on both of those things and I have a question I didn't write it down but what advice would you give to work for open source platforms or vendor platforms for implementing native OTLP ingest if you want to start supporting open telemetry for users more easily like how can on the product side like how can you prioritize OTLP is a good idea we want to support that natively and then what advice would you give for actually sitting down and implementing it what should people expect I'll take that on the tracing side I would say it's relatively straightforward because the mental model of the traces or spans in OTLP is quite similar to what other protocols are using Yeager or consensus there is no mismatch or surprising new semantics or concepts or very little of anything that is completely new in OTLP traces portion of it if you're especially if you're familiar with a particular protocol you can have a look at the translations code in the OTLP technology collector which will show you precisely how for example Yeager concepts map to OTLP OTLP concepts for traces for metrics it's a bit more complicated if you were in the presentation that Josh gave earlier there is going to be more complications particularly coming from the fact that there is more new types of metrics available in open telemetry and then corresponding to the in OTLP which have different semantics so that may require your back hand to be expanded to support those types those types of metrics I think we will have more clarity on that when the specification on the metrics is finalized and the metrics it will have also probably the recommendations and definitely there will be clear semantic definitions in the specification what the particular metric types are intended to reflect and that will drive your implementation in the metric portion of OTLP my two cents here by the way if somebody would start a completely new open source back end for all these three pilers that we produce metrics, traces, logs I would encourage them to start thinking from the what we call resource perspective so model from resource and then from there they can use their imagination to build the UX experience but that would be just a free advice for somebody who wants to build the new open source I think it's a pretty cool concept that you have a notion of a resource and you can see metrics, traces and logs that belong to the same entity in one place that's a really good answer thanks both of you for giving such a detailed answer and I think both on the vendor side and on the open source side we're going to see more people jumping at the opportunity to support open telemetry natively because it's been so rewarding just learning more about this community and seeing how all these people who should be competitors working together toward this common goal of just making our data more accessible and easier to manage so I'm going to wrap it up there and I think I can hand it off to Liz and Todd for closing remarks thanks to all our panelists and maintainers who hopped on and I'll hand it off to Liz hey thank you for moderating both panels this afternoon Shelby you did a really great job