 Six out of nine with quorum. Yeah, let's get started. So moving on, keep going. So in terms of agenda today, we'll cover a little bit about where we are with SIGs, have a couple of presentations from the community that's open telemetry, which is the merger of open tracing and open census, and then the cloud events annual review. If we have time and a little bit of discussion around archiving projects and PBEs. So I'm happy to kick it over to Liz to steer, if you so wish as chair. OK, I can give that a go. Hi, everyone. Oh, Alex is a Wall-American, as I've heard. OK. Well, I think everyone knows that about project presentations. Yeah, good. OK, so CNCF SIGs, I think one of the goals that we would like to get done this year is get the SIGs kind of up and running and running like clockwork. So we've got progress here with the security SIG and the storage SIG. So the security SIG, it says here that it's created and operational. Have we actually voted to approve its creation, Chris? Outside of the we have not done like a formal vote for the charter of the SIG. We've voted out of beating to actually have it graded, but we have not approved the formal charter. OK, so we probably need to do. I'm not quite sure what the process says, but we probably need to have that step. But at least the SIG is kind of it's doing things. They are actually kind of assessing projects and doing things. So I think that's a very good kind of bit of progress there. Yeah, so can we get a to-do item, Chris, or an issue about actually getting the, if there isn't one already about getting the charter approved? No worries. Liz and I synced a little bit offline. And it wasn't really clear what the process was from the document. That is it's very like we had a charter in the repo and then there's a proposal like it is the charter supposed to be part of the CNCF repo. Is it part of the SIG repo? This like details, right? And so we have a charter doc that's part of our repo. We have some co-chairs that are willing to keep going. Should we just do an async vote or request for comment? We don't have that many meetings left before. So we want to check in on logistics. Async makes sense, I think. I think so too. And I agree with Chris saying I think every SIG should own its own charter and it should be part of their own repo. Makes sense to me. Thank you. And the storage SIG I saw and made a couple of comments on. In fact, the PR for getting the storage SIG up and running. But I think again, that's a transition of an existing group of people who are doing things. But I think we're in good shape to have these two SIGs. We're going to announce at KubeCon. Is that the plan, Chris? If they're both approved, yeah, that would be great. Awesome. Do you want to also say something about Amy? Yeah, no. We've had discussions in the past of having more project and program help for CNCF. And we hired Amy to help with that. And she'll be focused on, more importantly, getting all these CNCF SIGs up and operational and helping those work well, along with supporting our projects on other initiatives. So she officially starts May 20th and will be at KubeCon. So you could say hi. Awesome. All right, what's up next? OK, on carving projects. So there is a pull request. We've been talking about this for a while. I think we are pretty close to the point where we should just start doing it. There is a pull request. Does anybody want to make any final comments about this before we call a vote? I think people are pretty supportive of the general idea that we should be able to archive projects. So, yeah, let's go ahead and call a vote on that. Cool, I'll do that. Yay. This was a last minute addition from Matt. So maybe Matt could speak to it. Sure, hopefully a pretty quick one. So we've had some requests to expand the Envoy XDS data plane API beyond Envoy. So the first consumer will be GRPC. They are adopting the Envoy XDS APIs for their Locoside Low Balancing. And as part of this process, we'd like to evolve the APIs beyond just for use in Envoy, to use in other load balancers and other control planes that are against those other load balancers. So we would like to form an official API working group. Initially, this will include folks from Google working on Envoy and GRPC. Myself, we have commitments from people in Azure as well as Amazon AWS. And we'd also like to invite folks working on other load balancers and other control planes around the industry. I think initially, this will probably eventually live under the networking SIG once we get that started. I think we view this as a pretty lightweight thing. We'll have some meetings, hopefully make sure that we're evolving the API in a direction that's not just useful for Envoy. And this might, in the far future, lead to these APIs becoming standardized in some more official way. But I think right now, we would just like this to be a lightweight process to evolve the APIs beyond Envoy. So I think what we're asking for here is just general TOC approval to start this lightweight working group. And then I think once we get the networking SIG started, the working group would just roll up into that SIG. So I'm supportive. I think there is a larger question of how much of a standards body is the CNCF because this is essentially patterns and documentation without code, largely. That's not the alien. I mean, Open Tracing and Spiffy are both sort of in a similar vein. But I think we've had this on again, off again, discussion around this over time. Well, Cloud Events is not an official project also, which is a weird sort of like, if it or isn't it a thing. So I'm a little bit like we have working groups that do work, and then we have projects. And there's a question of, well, should this be a project or a working group? And at what point does a working group turn into a project? And I think Cloud Events is a great example of that. It's essentially a bunch of people getting together and saying, hey, this seems like a good idea, but it's not an official project. So I think we have to decide that now. I'm just like, we seem to be muddling our way through this. Well, Cloud Events is a project. Yeah, just a project. OK, my bad. I'm sorry. It started as a working group in serverless and then of all two of them. OK, well, maybe that's a good pattern then. Well, yeah. And this is not just a working group. Like, we're taking existing produce. So there is an actual project. So I mean, these proto's live effectively in a repo called Data Plane API. And as part of this working group, we're going to be splitting them from the Envoy portions into the Universal portions. So there is actual code here. Well, OK, so then I guess that begs the question, why not just make this a sandbox project? I think we were just trying to start this as a lightweight thing. And Chris and Chris suggested doing a working group. I don't think we really want to go through the entire project lifecycle. So I think it sounds great to have this be a vendor neutral location where we can start having meetings and get a Zoom link and stuff like that. But I think we're not looking for a more heavyweight process right now. Yeah, in the future, it looks similar to what happened with Prometheus and Open Metrics, in my opinion. Sorry, was that you, Alexis? Yeah, I was just going to say what you just said about Open Metrics. But also, we're not a standards body. We're not ISO or IETF. We don't have a formal approval process for something then declaring something to be a standard. Someone could come up with other mesh library APIs if they wanted to and do projects there. That would be fine. I think it should be run as an open source project, even if the deliverables are documents as well as code. Sorry, so are you suggesting that we make a sandbox proposal? I think that'd be great. Yeah, if you're going to do some code. OK, let me take that back offline. And we can think about how we would want to do that. Again, I think right now, we're just looking for a vendor-neutral home. I mean, to be honest, we can start a Google Groups mailing list and we can have meetings that way. So I think we're just trying to strike the balance between vendor-neutral home and in not too much process. Yeah, I really don't want to throw a lot of bureaucracy at Matt here. So can we just let him do a working group and then to live all that it needs to be? Yeah. I'm not blocking on it. I just think that we're a little ad hoc on these things. That's all I'm saying. What else am I going to say? If a TOC board member can't easily distinguish if it's a work group or a project, then there's probably a problem in the wider community also distinguishing that. So do we need to have more prescriptive ways of saying which is which and why? I don't know. If it's not clear to you, Matt, then it probably isn't clear to other people either. No, it's certainly not super clear to me. And I guess the reason that I'm hesitant to go straight to a sandbox project is that it's not even clear right now what we would put in that sandbox project because a bunch of this code lives effectively within the Envoy repo today. And part of this working group is going to be to figure out how to actually split it out. So I wouldn't like there's no code that we could put in a repo currently. Like we have to start discussions. Well, and you don't have contributors contributing to that specific. I think of a project as a community associated with this and contributors and it might support other projects, but it doesn't even sound like it's to that level. Yeah, like again, I think really what we're looking for is just a place where we can host a mailing list and start having some meetings. And I'm perfectly happy to organize that outside of the CNCF, but I think Chris suggested that we do it within. So I really don't have a strong opinion here. I'm slightly supportive of the idea of the CNCF being a good home for this kind of discussion. I do kind of find myself questioning, wait a minute, we just turned working groups into six and how does this overlapped. I'm inclined to agree that there's been a few projects coming up just saying, yeah, make it a working group and keep it simple, which does make a lot of sense to me. But maybe we need to have a little bit of a think about what's the working group and what's the sake? Yeah, well, so I think my thinking there and there's an email from Lee in my inbox currently, which I haven't responded to, which is, I think we want to bootstrap the network sake that's definitely gonna happen. And I think it would be a natural place where this working group would live under that sake until we decide what to do with it. And I think there's probably a time box here of the next six or 12 months where we see how this goes. And then it evolves into a project with the repo, which has proto's and documentation, or we disband. Yeah. It's very analogous to the service working group and in that regard, sort of defining what we consider to be that term, a white paper eventually landscape, out into a sub working group of open events, which then can turn into an actual project, spec and sample implementation into sandbox, cloud events, that seemed like a, that was a relatively natural progression. And yeah, I think, Matt, that's reflecting on it. That's probably my suggestion as well that the traffic saving for the network sake, end up using something of an umbrella for, there are, I think, very near term in the coming weeks, probably around QCon, other related projects to come forth, that will be, I could see other working group proposals under that same umbrella coming forward pretty quick. From a process perspective of no one's opposed on the TOC from this being created since we have Quorum, we're happy to give Matt a mailing list and maybe a Zoom, whatever other resources he needs. Yeah, and again, I think that all we're looking for right now is an email list and a Zoom link for meetings. I'm happy to offline, we can discuss, I think there was a suggestion on the chat about having a time box in here, so we're happy to report back once per quarter, or if we bootstrap the network traffic sake, we can report back through that sake, but I think right now we just wanna kick this off and get people talking because we don't even know what we want to do yet effectively. So let's have that be the proposal that we'll create the working group and have it long-term live under the networking traffic sake with a time box that no one's opposed on the TOC, then let's just consider it approved and we'll move on. I just wanna add, can we also add an action item and I'm happy to review the DOCS and references around, or definitions around working group and our repo so that we're just clear on everything, so just as an action item on Erin's point. I can help you work on that, Michelle. Okay, thanks. Okay, what's up next? Nuts. I think Derek, Ellen. Hey, this is Derek. So, guys for taking a listen for us. Nuts is a messaging system that was designed to actually be the control plane for Cloud Foundry way back in the day. I still think it has pieces inside of Cloud Foundry and Bosch, but it's a messaging system that's multi-patterned meaning it can do request reply, it can do QBase, PubSub, and we also have Streaming. It's been around for almost 10 years now. It's been in production for over eight and a half years in different companies. It's built as a kind of cloud native microservices, very lightweight, very resilient type of a system and at the beginning of 2018 around March, we decided to ask for inclusion inside of the CNCF. Next slide, please. Since the acceptance, there's lots of different metrics that we can look at. Most people have access to all of them as we do, but what we're looking at is both the Docker pools and then the NAT streaming Docker pools have increased quite a bit since 2017. We're about to pass 40 million for the NAT's core server. We have about 5,500 NAT GitHub stars. And what's interesting is we have a lot of production use cases that we are simply totally unaware of. Like we'll learn of them after a year and a half of they're doing their own work and getting into production. And we might see questions on the Slack channel. Our Slack channel has about 1,200 or so active participants. But for example, we just had a large dating company say, yeah, we just rewrote our hold back end using NATs and it's been in development for a year. We had no clue. So I think these, at least for our project, we have some of these statistics, but we also realize there's a lot of stuff that we don't know about because they don't really necessarily need anything from us. It just kind of works, at least for what they're trying to do. Next, please. So it's an ecosystem of servers and streaming servers. Think of a streaming server as being akin to Kafka. And then of course, the various clients. The majority of our diversity, admittedly so, is in the client ecosystem. It's very straightforward and easy to write a client because it's a, although a very high performance, it's a text-based protocol. So it's very approachable for lots of different developer types. But if you look at the maintained client, there's one in Rust, which is not a weekend project type of a client given the language and given the fact that things are happening asynchronously and there's definitely memory passing. The core server and the streaming server, a majority of those contributions admittedly are from the NATs team, both from VMware, transitioning through a company called Obserion out to Senadia. However, we are starting to see people inside of the core server looking around and we do have lots of contributions there. We do have a maintainer for the core server that is at Google who did work on some stuff inside of the core server. But we realize and are being honest and transparent with the TOC that that's something that we are looking for and we are promoting. Again, we've actually went to certain large users and customers that we have and the ones either say, we're good for now, it does what we need it to do. Or the ones that say, oh, we'd love it if you just did this one thing, opt more towards NRE versus training up one of their own engineers today. Again, that being said, there's probably a couple big companies that will all of a sudden show up in the core server and the streaming server. But that is a weakness in terms of strict graduation criteria. I don't think it's a bad reflection of the project or its ability to solve needs and run in production environments for lots of customers. We have a lot of community-maintained clients where they write the code, they do everything about it and it's getting bigger. We're probably missing a couple there. Next slide. Since we joined the CNCF, Nats was kind of a standalone outside of integration with Engine X for rapid updates of its routing layer, which we used at AppSera and I believe they used that for Cloud Foundry as well for their layer seven. We're now obviously looking at being a good CNCF citizen and so we have been putting a lot of effort and are actually using ourselves, the Kubernetes operator, which can control both Nats core server clusters and streaming clusters. Nats can grow to very, very large cluster sizes if need be. Also a Prometheus Explorer with Grafana integration and we also have a Kafka bridge and MQ series bridge which is the majority of the interest from the Fortune 500 user slash customers today. They wanted explicit integration with those. So we negotiated even under NRE that those would both be Apache 2 and part of the larger Nats project inside the CNCF. So we feel good about that. And then we have a ton of community and maintain connectors and utilities from all different types of things that you can see. Next slide. The community is great. We feel that we do a great part in ourselves of being on the Slack channel and being responsive but they're always saying very nice things about us in terms of just works, it's been in production. One guy said his t-shirt's gonna wear out before he has to recycle the server. So we really try to encourage that. And at the same time, if someone says it's not working for them, we're actually even more attentive and want more information from those as they pop up. But they're very rare to date. And Matt and I had a really, I think good discussion on how does that in terms of the way a project is viewed from a user ecosystem, how does that affect how it fits inside of the CNCF and its criteria and things like that. Next. So these are just certain partners. We're starting to see a lot of SIs come on board, specifically they are being pushed towards us because of the license change in situation with Kafka and Confluent. So we are not outbound marking yet. We are about to go into outbound marketing mode, probably at the end of this month, beginning of June. But we do have quite a bit of inbound interest and it's going up very quickly. And it fluctuates between control plane or event streaming, but there's a lot of SIs coming in or people saying the license change on the Kafka side has to have them considering other options. I'm sure you guys are aware of that, but it's interesting. It's a very specific pattern. So next. Derek, before you move on, can I just ask a quick question? Sure. So it talks about Nats partnering with companies. Is that kind of shorthand for the company scenario, right? Is it really scenario doing the partnering or how is that working? Most of these are actually just, they are partnering with us, but it's around Nats. So it's very clearly promoted and marked as Nats. Not Senadia. So you'll see almost no Senadia stuff at all. But the legal agreement, if there does exist one, yes, it's with Senadia. Okay, thanks. So this is just a small group of the end users. And again, I think for us, we very rarely see any of these companies come out until one of two things happen. They are really happy with the result and they want to share, which is a good thing. Or they run into some issue, which for the most part, people get resolved on the support channel. But we do have a pretty global representative community. And we also have, most of these are very strictly production. They're already in production. They run their production user-facing systems using Nats as a control plane, servicing, addressing discovery type of a system. Next. And then here's the, I saw some comments this morning on the graduation PR. Obviously the website, GitHub, DrStacks. Slack again, we have about 1,200 members or so. That's slowly been growing over the last year and a half. We have a Google group that gets a little bit of traffic, but most of the traffic's on Slack, Twitter or Reddit. And so wanted to make it short and sweet, but happy to answer any and all questions that you have and appreciate the time. So one of the things that I'm always wondering is, especially with projects that are so closely associated with one company, what's, you know, the, and I want to see personally, I want to see some clear lines between sort of the company and the open source projects. I don't want these things to actually be conjoined. And so if you don't mind answering, and I don't want to, you know, ask things that you're uncomfortable with, what is the sort of commercial offering that complements Nats that actually justifies your investment here? And is that being presented in a way that creates sort of clean separability between the company and the open source project? No, I think that's a great question, Joe. And it's very, it's kind of like talking about religion, right? So we all have our opinions, but I'll definitely give you kind of where I- I won't pass judgment on like, whether I think it's a good idea or not. No, no, no, that's totally fair. You know, we've, a lot of us I think have been in this environment for quite a long time, myself included, coming up on 30 some years. My stake in the ground that I put to be frank is, is that I really felt that there were only three open source commercial models going forward, long-term. Most people will disagree, but I'm trying to give justification for Joe's question. Bundle it with hardware, run it as a service, or augment it with a service. Running with a service is not applicable for Nats because it's dropped that simple. GE Nuclear runs their servers for two years with no monitoring at all in their nuclear reactors, and they only shut it down when they're doing fuel rot stuff. All right, that's horrifying. Right, so running it as a single server in a silo technology, you know, that's not gonna help. Now augmenting with a service, people could say, oh, that's kind of a play on open core, maybe it is, but it's a very clear delineation that we're never gonna have a single code base that has certain parts of their synadia and certain parts that are Nats and Apache too. But what we've done is, is we've created technology inside of Nats that is open source, that allows us to run a global secure multi-tenant digital Dalton, which does not appear as a silo, that we can inject value added services and streams that don't have to be open source and we can charge for. So for example, you can possibly see a case where we might have services, which are you send a message and you get a response of some nature, let's say it's a secure store or a KB store or something like that, that we could actually offer for people who are running Nats clusters, large ones on premise and bridging to the cloud, they would pay us for that. They also pay us for training, education, consulting, NRE work, but our long-term value prop is to be treated like a utility with that digital Dalton, which connects everyone securely. Okay, so then your goal then is with Nats if you put in capabilities into Nats that enables your services, then those capabilities are then available to anybody else to sort of compete sort of an equal footing there. Exactly, and I feel really strongly, again, in my opinion, so I know we own all agreed, but I really feel that the premium enterprise model is usually understood as probably that's not where people want to be, but I think right now people are centered around open core. I just qualified as augment with a service, meaning there is a running thing and it's all open source, but it might be talking with a cloud service that augments it in some way, right? A machine learning, anomaly detection. And again, for us, it's these probably storage services. So it makes a complete solution where you just need Nats, which has a very good security story with 2.0 that we spend about a year and a half on. And if everything is a message, not only to communicate, but also to do lightweight, but 80-20 type storage of KB stuff in a total secure multi-cloud way, that might be something that could help us commercially. And we could keep that closed source and not have to pollute or affect any of the Nats ecosystem. Hopefully that makes sense. Great. Yeah, so I mean, my concern here, which I talked to Derek about last week, is like I feel that from a technology perspective, Nats probably deserves to graduate. It's widely used, it's stable. The part that I'm less clear on is this question that we're talking about now, which is if the project is primarily driven by a single entity and that entity potentially can go out of business, what is the implication there for project stability? And I wanna be clear here that I don't have the answer, but I think this is something that the TOC needs to discuss because I think that the guidelines are not super clear in terms of what are the requirements for either maintainers from different orgs or how much dependency can we have on a particular corporate entity. So, and this is going to come up in the context of not just Nats, but other projects that I think also want to graduate. So I'd love to hear from other TOC folks in terms of what people are thinking on this topic currently. I share your concerns, but I also read the updated portion of the proposal or the graduation proposal. And that made me feel better a little bit, but I agree we should have a longer conversation on that. What I would be, or what I'm also looking for or what I look for in the repo was some outline of how security concerns are resolved. So Matt, I'm not trying to veer off your topic, but I do wanna get some context around how do security concerns get raised and resolved, Derek? And are there any SLAs around that? Because I get the part about, there are only so many people who really understand the whole system and that paragraph, but I do wanna make sure that there is some SLAs around the security process. So if you could go over that, that'd be great. Yeah, so that's a really big deal to us because again, that's kind of a big push for us trying to innovate in that area. We did with the CNCS Health and Chris especially to have Pure 53 do an audit of us. We also have a company out of New York that I'm looking at to do a kind of a black hat type of approach, look at the 20 release, which is coming at the end of this month, it's been in development for about a year and a half. It's been in production though actually since last November, December. We have had, nobody raised any issues to us. Pure 53 had a couple of very minor ones, so we immediately fixed them and then we posted the results with the fixes there, but we take it very seriously. We don't know if the CNCF has finalized a formal procedure where it's like, hey, reach out in quiet, give them however long to resolve type of thing, but most people in our ecosystem seem really nice and friendly, so I imagine if they do, they would privately tell us, hey, we might see something, but at least for the system that Matt was talking about with a server that's been running now for years, it just uses TLS as presented by Golang. The only thing that we had prior to the newest technology pushed on security was that we decrypted passwords and you could change the computation factor, which was a trade-off. In the newer system that, again, a lot of people are actually already running. We use ED25519 keys, so we never have private keys at all, and we do a challenge, so the two areas that we've been asking people to look at and provide comment for was on the ED25519 and various client implementations and such, and then generation of the knots, which is the biggest deal if you look at it from a security perspective, there could be compromises in how you generate the knots, which is what's signed by the clients with their private key. So far, we have not had anything radical come back to us, but we have had, I've reached out to people I know and respect to look at it. So we're trying to be very proactive because it's a big deal for us, especially with production, but we don't necessarily have anything formal, but we'd be happy to take part in something if we want to formalize. I would imagine we want to formalize it for all CNCF projects as a just general template of communication. To Matt's point, after our talk, which I think was a great talk, and again, I hear you, I went and I talked to some of our users and customers, and I said, hey, you wanted something done, but you opted for NRE instead of having one of your engineers spin up. And I said, why? And they said, oh, it's just easier, we trust you guys, it'll get done way, way faster. I said, well, what happens if we all get hit by a bus? And they go, that's why we only use stuff as open source. I said, would you take it out of production? They go, no, no, we would then spin someone up. Again, that being said, we've drawn in the one guy, Oleg, who's now at Google, there's some interest at IBM, and so I think we're gonna try to pull some resources if they have that ability to get spun up on the core. So it's definitely something that we're working towards. I don't feel that, I feel that it's very nuanced when you're looking at the effect on users and customers of a single company kind of driving a lot of, at least the core server, maybe not the clients, that's fairly diverse, and the streaming server is a little bit more diverse. But when asking them, it doesn't feel like there's any trepidation when I ask them about that. It's not like, yeah, we're really nervous about this. It's like, no, no, we'd rather pay you guys or ask you guys to do it. And so I think that's at least a data point, not that we would perturb the diversity efforts whatsoever, but it was interesting because I did go out and kind of pulse with people and say, where's your comfort level with this? I mean, you're running it in production. It's a big deal. And they consistently came back and said, yeah. Yeah, and it's not just that though, right? I mean, and that obviously does make me feel better. And again, to be clear, I haven't personally decided, I think, my own opinion on this and I think it just needs more discussion, but it's not just bus factor. It's if a project is being driven primarily by one company and for example, not to get back into the business model discussion, which as you say, can be very contentious, but if later you decide that you need to move to an open core model to make your business succeed and then you start blocking features or changing the license or something like that and you control that product, is that what a graduated project should be, right? Like I just don't know. And to me, I think I'm really on the fence here because it's clearly a very mature technology, but there are definitely some risk factors from a project health perspective. I think those are fair. I think some of the offset is the fact that we're almost 10 years old though. So if they were gonna happen, it might have already happened in that perspective. I think I share some of these concerns, not necessarily in the context of NAS, but more as a precedent around what's, if we relax or we decide that our criteria need relaxing, is that gonna come back to bite us in the future? If we substitute instead of Senadia, if we substitute one of the giant sponsors, does that cause a problem for other projects? Or I have concerns, I don't have answers around that yet. Yeah, I think it's hard to rationalize about and the way I've been trying to approach it is, what is the end effect on the community? And I think the end effect on the community, to Matt's point of all sudden, we decided, or like Confluent just bought a company and immediately dropped dead, stopped their open source project and Apple has done it in the past. I think for the CNCF, that's possible with something like NAS, where it's a smaller company that's driving a lot of the innovation. For the bigger companies, where I think there might be a comfort level, it could be a counter argument to say, but what happens if they lose interest? So what happens if Google loses interest in one of the big projects or whatever? I think there are similar ramifications for the end user community. I don't have any answers either. I know that from our perspective, for the health of our community and being part of the CNCF, we definitely hear what you guys are saying and we're pushing very hard. But when we realize that all the users who are production users are saying, no, we're good. Even if you guys all get hit by a bus and go away or start doing whatever, we're still very comfortable with where we are with using the product. That's additional data points that we can use in a discussion of, okay, how does this make sense? And I agree, it's very nuanced. It's very difficult, in my opinion, to make it black and white. So I mean, generally in the past, how we've made this work is a TOC member pushes for a vote on graduation and we would call a formal vote. I don't know if there's anyone here that would like to do that or we could essentially hold. It's up to you. Yeah, I think maybe we need to have a little bit of a step back and think about the general principle before we vote on NATS specifically. Yeah, like I'm not... Right shape, Derek, this isn't in any way supposed to be a reflection on your project. I think it's more about making sure we're clear about the criteria. Right, and I think NATS is a great technology and again, same statement. In some sense, I feel bad that you're getting caught up in the lack of clarity around this topic, but my preference is that I think we have a private TOC meeting in two weeks or whenever that is, my preference is that we discuss this privately among the TOC and then we decide on next steps. Yeah, I definitely look forward to that conversation. And I think we're gonna be looking at this across a whole set of projects that folks wanna bring into the TOC either at the sandboxing or incubation level. And I think that as we look at sort of the set of projects coming in, there are a lot of questions around what does vendor neutral mean and what are the criteria around that? Any last questions for Derek before we move on? I have technical questions about the project since last I looked at it, but that's probably not appropriate here. I guess my question is like, my assumption was that it was a goal for Nats to have committers who are from a range of companies, not just Google and your company. Is that true? We have lots of committers across lots of different companies. I think the specific issue that was being raised is maintainers of server, core server. Okay, so I meant the core team, the people who are accepting full requests and controlling the road now. Yeah, I mean, maybe this is just a matter of governance and governance structure that brings in end users might be one of the things to look at here. But I think it's worth for the TOC to get together and chat about this. Sounds good to me. All right, let's... Thank you guys for your time. Yeah, thanks Derek. We'll work with you all follow up. I think it's open tracing, open census time now, or open telemetry. Open telemetry, yeah. All right, Morgan and Ben. We have about 15 minutes, so I apologize, but hopefully... We can do that, don't worry. So I'm Morgan McClain, I'm a product manager at Google. I've been on open census since the beginning. Ben, do you wanna quickly introduce yourself? Sure, I'm Ben Sittleman. I've been working on open tracing since the beginning and at LightStep, take it away Morgan. Perfect, can we go to the next slide please? So there's a lot of different types of telemetry that developers expect to pull out of their applications. Tracing, metrics and logs are probably the ones most talked about, though there are certainly others. There are different layers to this. So for tracing and metrics, you often need language specific APIs and language specific implementations to pull them out. For logs and other types of telemetry, you can often get away with an agent. And then there's other parts of your infrastructure, including collectors, sidecars, interrupt formats and so on. There are obviously a number of projects within the CNCF that involve these. However, when we look specifically at the combination of tracing and metrics, open census and open tracing have been sort of the most prominent ones out in the community. And open tracing already being a CNCF project while open census isn't one yet. Can we go to the next slide? So when we look specifically at open tracing and open census, there's a lot of similarities. They both offer APIs. Both have different implementations available. There are some differences as well. Open tracing primarily focuses on the API while it left implementations mostly up to the community. So there can be multiple implementations per language, some vendors have their own. Open census offers a single implementation for each language. But beyond that, both projects have broad adoption, both have pretty good language support and both offer a lot of the same functionality. Probably the biggest difference in terms of functionality is that open census also focuses on metrics. We go to the next slide. And there are of course, some sort of issues that each project has discovered. And I think as Ben has put it before, like after we've gone and built a thing for a few years, we look back and think of a few things we wish we could have done better. With open tracing, I think Ben was saying one of the challenges that they found was that they only deal with one vertical and that's tracing. It turns out a lot of users want a single dependency for all of their different telemetry types. With open census, one of the challenges is being tighter in some sense, overly tight coupling. There's a great standard implementation, but there are vendors in the space for tracing and metrics who would like to use a standard API and include their own implementation. Historically, open census doesn't allow that. Can we go to the next slide? So this is me. Both projects are very well-adopted. You can't not can read this slide, especially given the time crunch and everything. But we can just go to the next slide, I guess, which seems great. So we have two really popular projects. And if you hit next slide again, it's sort of great. And that's the problem. So if we go to the next slide, the fact that there's a choice in open tracing and open census is really problematic. Both projects, for better or worse, have escape velocity. I don't think that anyone on either project could really expect them to just die heat death at this point if we let them to be, which means that they were successful in a sense. But the fact that there are two of them is hugely problematic. You can see this in the ecosystem all over the place if you talk, I mean, I talk with companies all the time as part of my job at LightStep. And this question of what's the difference? Which one should we use? It's not just choice anxiety, but it actually creates paralysis. This thread I linked to is just one of many, many examples of this, but it happens to be a very visible one was to do where they were initially going to adopt open tracing. And then someone said, and that seemed like a great choice. And then they said, well, we should have an open census and they investigated that. And then they ultimately did neither. And so they just have like stopped. And this kind of thing happens a lot. So it's not helped by the fact that although the leadership open census and open tracing, I think are socially very friendly, there is a sense of a kind of holy war going on on Twitter, which I can't really fully explain, but that also didn't help. And I think about six months ago, we started talking about the fact that this is pretty bad for the ecosystem. Both projects, the goal is really to expand the reach of telemetry projects into cloud native technology. And the fact that there are two of these things was a significant problem. So let me go to the next slide. Oh yeah, great. So one more. Yeah, so this is just from the CNCA proposal that we wrote. I'm not going to read this slide. You all can look at it in your email or whatever, but we'll talk about it in a minute. I did want to address one important issue in the next slide, which is sort of the elephant in the room here. If you advance again, there's the classic SCAT CD comic about standards. And that's sort of the obvious concern here. We have two, I know CNCA doesn't like the word standard. So we'll just call them two, you know, common APIs that are not the same. And we're saying we're going to create a third and that's going to solve the problem. So that's definitely the risk factor. We advance to the next slide. We'll talk about our goals, long-term goals in a second. The short-term goal is just all about backwards compatibility. So I think Morgan alluded to the fact that we have a bunch of technical regrets on both sides. And it was really tempting to take this opportunity to just start with a clean slate. And we have resisted that holy temptation and instead have basically decided that the initial scope for the project is 100% focused on being backwards compatible with both open tracing and open census via bridges. And this, because the leadership of both projects are completely on board for this new thing, we believe that that plus this relatively aggressive timeline that is described in the slide should allow us to successfully converge onto a single project. We wanted to separate brands as well, just to make it very clear when people are kind of moving over to the new thing and it will make it easier to kind of wipe the old things off the map and just move forward with this unified project. We'll offer a two-year compatibility guarantee for those bridges so people on open tracing and open census today will be well supported for a while. And in the meantime between now and November, it should be safe to continue to develop an instrumentation and the translation process should be relatively easy. I think it's even more again. Yep, so what we're actually doing is merging the two projects into one. You've probably surmised this, so we're taking open tracing and open census. As Ben mentioned, we're sunsetting those and open telemetry will replace them. Open telemetry will maintain a broad surface area. Obviously, we'll have tracing and metrics that list of different types of telemetry may grow over time. But more importantly, it'll provide both APIs and a single set of reference implementations. So taking the sort of the best parts of open tracing and open census together. It also will include sidecars, data formats and all the other specifications that customers need. As I mentioned before, there's a loose coupling, so we'll have APIs that people can build integrations against and the sort of primary set of implementations. We suspect that a lot of people will just go use those or most people will just go and use the standard implementations. But if there are vendors in the space who want to provide their own implementations of those APIs, that works great. And we have open governance. The governance model is already being defined with we've got a seed committee and we've had a lot of really great people help us. Go to the next and the next. I'm not gonna read this, but we believe that the project is a natural fit for the CNCF. Next. Telemetry is obviously really important. The CNCF already has open tracing. There are other projects like Prometheus that are in the space. I think some other CNCF projects wouldn't be part of the CNCF. So no surprise that a telemetry focused project want to be home there. CNCF is a great home for implementations, for APIs and for data formats. And so this project wraps all of those up together. So we have the whole sort of package that people can use. And we have a lot of organizations that are already using open sets and open tracing in production. So we expect that to continue open telemetry. All right. Yeah, I mean, I guess our actual ask here is we'd like to be made a sandbox project. There's probably some, if you squint, maybe you could make an argument possibly that this should be incubated. We don't want to make that argument. We'd rather see the project proliferate, come back in whatever six months a year and make the argument with evidence that data. Given that the open tracing and open census projects are both quite aligned about this, we feel like that should be straightforward, but we don't want to get forward credit for things that haven't happened yet. So basically our ask is to be admitted to CNCF as a sandbox project and kind of go from there. And that's it. So then the idea is that open tracing would maintain being an incubating project while you slip the clutch on the new thing. And something like that. I mean, we're open to guidance from the CNCF on how you want that to work. I think it was understood that we did not want to sort of do a rename on open tracing if that makes sense. I don't think that does make sense, but I would suggest that we would keep open tracing in CNCF just because it seems easier. And then once open telemetry, well, basically once open tracing becomes read only, which is the goal for that by the end of the year, that seems like a natural time to consider what it's sort of ultimate fate is in CNCF. But open tracing supports a lot of languages and will take us some time to get through all of them. So until we actually have a forward path for everyone, I don't think we can really just remove it, if that makes sense. No, I mean, that makes a lot of sense. And it seems like hopefully folks and users won't reject this path and everything will be super smooth and you'll be able to get everything moving forward and have a bigger community at the end. We've had a lot of conversations with customers and they've effectively all been, they were banging the drum on this before we started. Yeah, this was really, this happened because there was such tremendous user desire and user desire for this to happen, which is great. So hopefully, if we can execute, everyone will be very happy. Really excited to see this go forth. And the only thing that would be kind of tricky with making it a sandbox project as I see it is that Santa F is not supposed to like help with marketing of sandbox projects, but here we are, we'd like want this to work. So I guess when you get to the point where you want marketing help and effort, I think that's the point that way. Yeah, I mean, it's really an open tracing interest. I don't know if this is considered too much of a sleight of hand, but I mean, open tracings marketing initiative would be to make sure that this is successful too. I mean, so you could think of it that way too. I don't know if that helps, but I mean, if you want to make it an incubated thing, that's fine, I guess it. I just wanted to express that we're very comfortable not getting that, I guess, but I don't understand the CNCF bylaws very well, and it's really up to you all to decide what to do with that, I guess. I think moving forward as a sandbox is a good place to start, and we can reevaluate sooner rather than later as this plan moves forward. I agree. I also agree. And just to point out, there's no time limit before you can move up to incubation, so we can look at that. Given our project processes, but yeah, there's no reason why we can move you to incubation when you're ready, if we agree you're ready. Yeah, I mean, they have three TSC sponsors already for the sandbox, so they're good to go, so we could formally get them on board. Awesome. Oh, with a minute left, I think that's probably time four. Cloud Events will move to next week for their annual review, and then Doug, I saw your note about the, what is the end-user thing, we'll address that in a future call, okay? Cool, thank you. And Doug, I'm sorry about getting the Cloud Events level wrong earlier. It pained me, Joe, it really did. My heart fell to apologies. Okay. Three plus projects, it's hard, so. All right, take care everyone, it's 10 o'clock, right, bye-bye. Thanks everyone. Thank you, see ya.