 Welcome, welcome everyone. This is kind of our, you know, CubeCon open kind of, you know, session with the TOC. They'll do introductions of who they are and then we'll kind of go through the kind of the basics of how the organization works from a TOC perspective. And then we'll kind of just open it up to the audience for questions. People always have questions regarding how do things work? How do you, how do I submit a project and so on. So we'll start first with introductions. So my name is Chris Anizak. I have the fun job of being a CTO of the organization and work closely with the TOC. Maybe we'll start from left to right with Katie and go from, oh, no. Can people hear me? Yes. Hello everyone. My name is Katie Gomanje and currently I'm working as a senior field engineer for Apple. I have many roles in the community, including the TOCs, looking forward to your questions. I'm Dave Zalotewski. I'm an engineer on the platform team at Spotify and I'm on the TOC in the end user seat and I do a bunch of work with backstage. Richie, working at Gorthon Labs, Prometheus team, governing board, TOC, a few other things. Emily Vox, I'm a security engineer at Apple, TOC, security tag, co-chair emeritus, KubeCon co-chair with Ricardo and Jasmine and a lot of other stuff in the open source community. Right. So I'm Ricardo. I'm computer engineer at CERN and I'm also in the TOC since just over a year as an end user representative as well. I also co-lead the CNCF research user group, so I invite everyone to go check that out as well and I'm co-chairing KubeCon Europe with Emily. Hi. My nickname is Dimps. You can usually see me in Kubernetes channels. I'm here part of the TOC and first of all equals I'm the chair here. So thank you. And obviously we have some folks that are not able to fully attend. And we have election process going on for one more. We will get to that eventually. So quick little intro for a lot of folks. CNCF mission is all about making cloud-native computing ubiquitous and the TOC is essentially our technical board that helps set the overall kind of vision and helps ensure that projects are cared for, advised for, and so on. The way the CNCF is structured, if you're not familiar with open source foundations, there's generally a board of directors. Sometimes there's technical project leads and so on. The way it's done in CNCF at least is there's three main pillars. There is the governing board, which is kind of your boring business budget kind of decision makers. These are generally the companies that will pay to sustain the organization. So like your IBM's, Google's, Oracle's, Apple's of the world and they get basically a vote on how kind of budget is kind of spent across the organization. You have the TOC, which is here represented here today. They focus on accepting projects, advising projects, potentially dealing with issues when it comes to conflicting projects and so on. They are basically the technical leadership advisors of the organization. And then you have the end user community, which is a group of end user companies, not vendors that kind of share practices and work together. And they also get to nominate people to sit on the technical board. And these things are overlapping but distinctly firewalled offering each other. So just because you have a board seat on the governing board because you pay maybe for a seat, you necessarily don't have the ability to influence technical decisions. And that's kind of our best practice of separating the business side of the house from the technical side of the house. And we have 11 members that exist in this TOC. So other things for folks that are new to the organization, the TOC a while ago came up with a set of principles that kind of guide how they work as an organization. You know, highly recommend folks to kind of go over this if they've never seen this before. But the simple idea is being project centrics, you know, projects are essentially self governing. The TOC doesn't necessarily metal in the matters of projects. They work out on their own. We're not a standards body. You know, there's no kind of slow traditional standard body processes within CNCF. There is not a one size fits all. We aren't king makers also. And what that essentially means is we allow for competing and overlapping projects. If you kind of see in the 120 plus projects we have now, there are projects that, you know, overlap a little bit in the service mesh space. There's probably at least five, six, maybe seven, I don't know. There's a lot of service meshes we have these days. There's a lot of security related projects that kind of overlapping could be a little bit. That dynamic is meant to happen. It's healthy. Competition breeds innovation and better solutions potentially for end users. A lot of people always ask, like, why don't you just have one project of anything? That's not how we work or how we were structured to go about. We want to allow that competition to flourish. And overall the TOC is really there to kind of truly help projects and not interfere with their day to day. Moving on, the way kind of things are structured. You have the 11 person body up here and the way the kind of TOC divvies out work to the community is structured usually through these things called technical advisory groups. Or they used to be known as SIGs previously when we had to rename them due to the confusion caused between the Kubernetes SIGs and our TADs here. And they're generally broken up by specific categories. So whether it's, you know, security, storage, you know, observability and so on. So if you're very new to the community and you would love an opportunity potentially to be on the TOC, generally getting involved in one of these tags is kind of a great first step. Not everyone is a domain expert in security or observability and networking. So if you have something to contribute, it's a great place to kind of get in those tags. And the TOC leverages those tags for advice, especially if they may not have particular expertise. And also just scale their workload at the end of the day. How do projects work in CNCF? There's three levels. I'm sure people have seen the crazy landscape and so on. But generally the way projects are broken up in CNCF is by what we call maturity levels. You have sandbox, which is meant to be very early stage. Generally a very low barrier to entry to get as a sandbox project. You just have to meet minimum bars around IP due diligence and code of conduct, road map and all this kind of basic things. Incubation is kind of the next level where you're a little bit more mature. You may have a little bit more diversity in terms of companies and organizations contributing to the project. And then graduation, which is kind of the stamp of approval from the TOC, that this is something that's going to be around for a while. It's not necessarily going to go away. You could definitely bet your business on it. And then it's kind of this process that we've kind of come up with historically an organization to kind of give guidance to end users. To apply and submit a project, generally the pathways are we mostly recommend people to start a sandbox. That's generally meant for the kind of early stage and first kind of stage projects. It's a very simple Google form that you fill out with basic details. And then the TOC reviews them once or twice. One every two months basically is kind of the rough cadence. You could also apply through incubation pathways. We've had projects like K-Native and Istio go that, but that's a little bit longer pathway to get to. But those are more mature projects at the end of the day. So we'll go through a little bit more and then I'm going to open up and ask some questions for the TOC. And then we'll just kind of open it up to everyone to have an opportunity to ask why their project wasn't accepted and so on. So why was my sandbox project not accepted? Richie didn't like it. So these are some ideas, but the question I'll kind of start off with before allowing the audience to kind of open up is we have 128 or seven projects in the CNC that covers all sorts of aspects of K-Native computing. And we've kind of expanded that over the years. If you look at the landscape that we have in CNCF, huge, multiple categories. We're almost seven years in the evolution of this organization. What is missing? What's next essentially? What needs to be filled in potentially that currently is not there? Or what potentially needs to be consolidated? So basically, my question to you is, what do you think are the future missing gaps that still need to be filled in the organization over the next six to 12 months? Anyone could start. My personal answer would be more integration, also more open standards. Of course, we have this huge breadth of projects and one of the things which are here again and again and again, I think most of you will, is that people are confused about how to do things and where to get started and where to go to the next step. And we have all those really, really great tools, but the integration between them is not super great. One of the ways to solve this is similar to IDF or ISO, open standards, and then have everyone implement against those standards because then you have interoperability and then you can build integrations on top of these and make more glue code. Anyone else take a chance to answer the question? No worries. I think interoperability has been a very important factor for cloud native. It has been happening from the beginning. If you look at Kubernetes, there are a lot of interfaces that allowed us to integrate different networking and runtime components. So that was always a factor. And I think continue kind of building on top of that is going to be quite important for our community. In terms of the missing technologies, I think this is like a long-term strategy for, well, Emily can maybe talk more about this one, but security is a very important factor. We're not talking about adoption at the bleeding edge anymore. We're talking about enterprises looking into adopting cloud native and they need to be secure. They need to be insured over and over again. This is safe to run in production and you can actually get your business on top of it. And I think that's definitely something which gained a lot of momentum. And another thing that I kind of would like to emphasize is we have a lot of tools. We have a lot of tools to do our basic infrastructure. We have observability. We have continuous deployment. However, we still need to improve how we optimize these tools. It's not just about integrating something. It's about how can we optimize this on top. So I think interoperability is still going to be a very important factor with that. But if you look at, for example, the CNCF landscape, if you look at the observability side, you will see that there is like a new range of companies focusing on continuous optimization. And this is something that has like billions of dollars in investment at the moment. So this is quite new, but definitely something to keep an eye on. So that's my take. I can take next, but I'll actually quote Dave, because since I joined the TLC, there's something that sometimes keeps coming back, which is from an end user perspective, how do you build your stack? How do you make choices? There's a topic that came back a couple of times, and we never really got to a good answer yet. I think it's something to come, which is this idea of having something like reference stacks and how would people choose one product and why this stack instead of another one? What fills your needs? I think it's something that the TLC can also work on contributing together with the stacks. I want David to finish the talk on the end user project. Sure, yeah, I don't know if there's too much more to add. I mean, I think from this point of view, Richie kind of stole the thing I was going to say, and then Ricardo built on it, where as an end user, you say, let's go cloud native, and then you look at this 128 project landscape, and like Chris said, a bunch of the seven or eight projects, and you don't want to evaluate eight projects to figure out which one works best for you, and then evaluate eight more in a different piece of the stack, and then find out that those two don't really work well together, so then you figure out which one of the categories you want to use, the second best one in, because they do work well together. So this kind of combination of knowing what stacks work, having open standards in our ability, and having some understanding of which projects do what and which ones work well together really goes a very long way for end users, and the next thing I was going to say, of course, was security. So I don't need the microphone. Okay, so let's talk about security. It wouldn't be this kind of conference without it. So there's a lot of stuff that's going on in the security space throughout this conference. There's a ton of talks covering supply chain security, open source security. One of the things that I've seen within the security tag community and several other open source security communities is secure defaults and how difficult that conversation actually is, especially if you're an open source project where you're intended to be adopted by end users, potentially even vendors, and a lot of that is really industry vertical based. So I see a lot of need for projects partnering with the different industry verticals such as healthcare, fintech, government, all of those, to understand what their assurance requirements are and to start developing secure by default configurations based off of your assurance requirements, whether or not you're low and you're not going to be dealing with healthcare or personally identifiable information, or if you are a high insurance where people's lives actually depend on high uptime, resiliency, the confidentiality of the data. So this is one of those large spaces. And then taking a further step back, what are the secure development pipelines of all of our CNCF and open source projects? How should they be looking? There's a lot of different requirements, and Salsa has been kind of leading the way in what secure software development looks like, but we need to get that across the ecosystem and get a lot of our projects on board. So there is a, hide it. So there's a couple of things that I would like to see as well, which hasn't been covered yet. One of those is like, you know, a cluster, Kubernetes cluster is a unit. How do we make multiple Kubernetes clusters work together? How do you manage them? How do you set policies? We tried a few things like QFET 1, QFET 2, but then now we are on to doing newer things, and there are multiple projects in this space that we would like to go look at and see how they span clusters and not just span clusters across cloud providers and even to the edge, right? Networking becomes a challenge. Storage becomes a challenge. Just pulling the images becomes a challenge. So I would like to look at those areas to see what is a new innovation and try to figure out if we can do some of those here. That is what I would like to look at. Also, there's always cutting edge stuff that we've been wanting to do. Like, you know, we, at one point we said, okay, serverless is the cutting edge, so let's do serverless, right? So, and then K-native is coming to, came into us. And so there are other things like wasm-related stuff is happening, rust-related stuff is happening in the community. Like, how do we welcome them into the cloud-related world and how will they fit into the things that we are doing, right? And it can't be just that Kubernetes is the only solution here, so we need to go figure out like what, is there anything else that we can do based on the knowledge, information and things that we have, you know, got from how we are building Kubernetes, running Kubernetes and to see what are the other projects that we could be doing and especially what are the other things that we could be doing that will explode with ecosystem-building projects similar to the success we've had with Kubernetes as well. So those are some of the things that I would like to think about. Awesome. I'll kick it back to me. So one more question before opening it up to folks in the audience. So developer experience, huge kind of problem depending on which projects you use. You know, I'm a pretty terrible engineer, but things like Prometheus are actually very easy for even me to kind of get started and work with Kubernetes, a little bit more difficult depending on which way you go, K3S or everything. What are your thoughts of what we could do as a community from a TOSer's perspective to ensure that projects have like a baseline improved developer experience for especially new folks in the community get started because even though like Kubernetes has made so much strides to make things significantly easier to get started, it's still difficult for a lot of folks. And then we have other projects that, you know, something like Falco, it's like good, it's hard. So it's like, I would love to kind of hear people's thoughts of how we could improve this. So if you take one of these things you will see a class like for example, if you talk about security policy, then you have OPA and you have Q and O and things. And if you have CNI, then there is a set of things that are kind of standard, they work kind of similar fashion. So, but there are de facto standards that end up, that we end up building or we collaborate with multiple communities and get them to go together lock steps. So it becomes easier for the end user to adopt like open telemetry that we were talking about. So I like to give this to Richie, so he can complete the thought on observability since you asked about Prometheus. I don't think this is mainly about Prometheus. Maybe the one thing about Prometheus and Kubernetes for those who don't know those were like the first two projects and it's kind of a little bit cheating because Borg and Borgman share history, Prometheus and Kubernetes share history, but they are super well integrated with each other. So they uplift each other. And that's one of those things where you can see integration keeps paying forward forever. As to the actual question, hire 10 tech writers, hire two people who just do the ICD and stuff for the project. Of course, speaking as the second largest project, like the second project within CNCF and pretty much everything is second after Kubernetes, Kubernetes has its own resources. That is not the case within CNCF across the project. So the thing which I see again and again and again and for those who don't know, I'm the developer seat on the governing board. That's part of my platform. What I want to actually try and do, get all the toil and all the janitorial work out of the project's way so they can actually focus on the code because they are the subject experts at code. They're not the subject experts writing good documentation or having good grammar or finding out that there is this one gap. They can work with those people or if we move to a new thing where CNCF gets cheaper cloud credits, like it's on the projects to migrate. The CNCF is like, okay, here's this new thing. We'll migrate it for you. We'll be done in a week or in two months. It doesn't matter. Everyone's got to generate S-bombs now, so another thing to put on. Basically, keep the facts free. I just want to echo exactly what you said. We can't expect the software engineers to write excellent documentation for other software engineers to read. So just making sure that you're taking the time to document and keep track of why you're making some of these design decisions or what? Testing, testing? We lost you? I think we lost. Oh, okay, now it's back. So part of it is making sure that the things that you're doing you're making clear to your audience because not everybody is a senior staff level software engineer. There are going to be folks that are more junior level and you have to take the time to bring them along the path with you because if you leave that community and you're trying to get more contributors or more software engineers to assist if you didn't bring them along and explain those design decisions to them they're going to be lost and they're not going to be able to carry the project forward. Anyone else? Cool. Alright, we have about 10, 15 minutes and feel free to open up questions to I think we have a microphone in the middle, I guess, over there. So if anyone wants to ask questions don't be shy. It's not it's very rare to get the TOC in one place. Also if you want to, you can just grab it and give it to the next person so we have a runner. Yeah, we're in a tough situation where we have limited mics. Or you just go there both ways. Okay, you could form a line and kind of go. So I have a question. So the original mission and I love that you all started with what is the mission of the CNCF and the TOC. It all hinges on the definition of cloud native and I know that there is an official definition of cloud native but that's still open for participation. So I think so much of what the TOC does really hinges on that sort of I know it when I see it with respect to cloud native. So like, I guess, you know have there been, you know do you each, you know do you have your own sort of spin in terms of what you think of when you see cloud native what does it mean for you and how does that influence the decisions that you make on the TOC. Joe, thanks for this question. So we struggle this every time we try to vote in a new sandbox project literally, right, like you know, sometimes for example we were looking at projects that is plugins for VS Code or IntelliJ and like what is the cloud native stuff out there, right and do we need to get them and is it going to be beneficial to the community and is it going to improve the developer experience so those are some of the kinds that we think about. There's a debugging tool in the community. Is it cloud native? Does it help debug cloud native applications then you know how much relevant is of is it a side business of the project to debug cloud applications or is it the whole business, right so we start looking at those kinds of things so yes the Google form is simple but we do have to spend each of us have to spend time on looking through all the things that the project brings into our ecosystem and the other Angular also think always is, hey, is there any common things where existing projects can go help out those new projects that are coming in if there is good back and forth things happening there's a good feedback loop happening which will improve everybody together so those are other kinds of things that I look for in addition to the definition of the cloud native itself. Anybody else wants to add to it? Do you think you'll ever update the definition again because I remember a blessed Brian Grant's heart I think he spent a long time trying to push that through and it took probably six plus months of I don't say bike shedding but like collaboration to get something written down. I honestly think we should at some point and it's not here yet and we are still trying to make sense of where we are and trying to build a complete picture for the people who are using so the other thing so the mission statement also is the main thing that we have in mind to get things across is a CNCF end user can they rely on the set of projects that we have and rely on the health of the projects that we have to build and sustain their own businesses so that is the game that we are in and that's what we need to look at. Thanks Joe. Good answer. Okay so there's a lot of technical overlap these days between the CNCF the Continuous Delivery Foundation and OpenSSF. What can we do to have greater like active collaboration and cooperation with those two other organizations? Emily's turn. So I'll start so I obviously am on the talk former security tag co-chair but I am also becoming more and more active within the open source security foundation and a lot of the initiatives there because I've recognized we have a lot of overlap and activities and in some cases some of the work that our foundation has done has really kind of set the stage for how we can continue to move forward in that space so having individuals that are really passionate about these specific domain areas take on leadership positions in both foundations it's a lot of work but it ensures that we're applying consistent messaging to all of the communities where our members will show up. So the other thing is in the end it's the people right like who show up in multiple space like you ask any one of us everybody's wearing multiple hats means they're doing different things in different spaces at different levels so in the end it's the people that bring the rest of the people together right like we can do something on SA we need a regular meeting between OpenSSF TOC and our TOC or something like that too right we can do that but it doesn't work as well as people trying to do things in both spaces that overlap and that complement each other so a quick example here is like for the longest time the Kubernetes steering has had regular contacts with the OpenSSF foundation for example right so and that is because people showed up from one to the other and they were able to talk to each other and they were saying hey we are seeing similar kind of problems and you are ahead of us we are behind us and there are some things that makes it easier for you and harder for the other person so it's the people that ends up bringing everybody together so yes we can mandate things on the regular meetings on the calendar if nobody shows up it really doesn't matter right so that's my take on it and you know from a Linux foundation perspective people who come to us to start things and all this stuff you start your own organization with your toys and your little sandbox and scope naturally expands and creeps up and there is overlap and our goal is always to facilitate the conversations and if people want to merge or dissolve or us that we could accommodate that but even in nature to like want to start your own specific thing it just happens the way the world works unfortunately but we do our best to kind of enable that collaboration I think you'll see more open SSF, CDF, CNCF kind of events overlapping in the future we have about seven minutes left so anyone or we'll just go through the row of folks now cool I'll try and be as quick as possible first off super appreciate all the work you're doing so thanks I guess on that note is I can obviously see by the screen how to get involved but one of the things that I am limited on is time what do your like schedules look like being involved in the TOC and the tags because like I'm already swamped but I really want to do this stuff how much time do you spend on this is it like just like occasional meetings or are you guys spending half of your life living in this stuff the right question to ask is how much time of sleep did you get right now like four hours so anybody wants to take that question so I've always tried to maintain 20% of my work is in the open source community and there's been a few occasions where things slow down within the TOC or within the security tag and that allows me to focus more on my regular day job because I have one of those and in other situations like right before this conference I'm spending significantly more time doing open source work so it's a balance and it's really up to you to figure out what's going to work best for you but you need to make the time and I think that's the biggest challenge maybe I'll just add something to that but I would just say that it's time that we'll pay back as well because you get a lot of exposure to a lot of projects but also end users like doing due diligence for projects for incubation it's super interesting you will get in contact with a lot of people interact with different types of projects so I think it's something that definitely should be part of your day job as much as possible it shouldn't be like a side thing I think as much as possible should be recognized great, thank you yeah I think in the ideal situation if you could have your employer support a percentage of your time that makes a world of a difference for sure, some people are as lucky to be in that situation next question there's two competing missions where you've got this mission to have a big tent be very inclusive all comers are welcome under the tent then you've also got the open standards mission how do you balance those conflicting things so let's say you've got two projects that are in the same space but they've got competing and sometimes conflicting APIs or protocols how in both the due diligence process and incubation all that what are the types of conversations that you have to weigh those conflicting needs I guess go ahead I think the answer to that is healthy competition we have many projects within our ecosystem that are focusing on the same problem but at the same time they deliver it in a very different manner so if you think about the observability we have Cortex and Thanos if you think about GitOps we have Argosidium flux and this list can go on and on the idea here is not to be exclusive the idea here is we have different initiatives and they try to solve a problem in their own way with their own resources however over time we see that we don't have a monopoly of like functionalities we have this healthy competition and when you have healthy competition you have innovation by default so I think we're trying to facilitate that as the TOC system have that in mind so just try to be as inclusive as possible as long as it follows the cloud native mission and as long as it follows that vendor neutrality and healthy community and contributors and maintainers and so forth they're going to be welcome within our landscape Do you want to do the end user thing? Go ahead, it seems like you've had something to say Yes, I'm going to do the end user thing So I agree that it is good to have healthy competition and everything but at the same time having too much competition leads to a situation where you have too much overlap and it's super hard for end users to actually navigate this theme and then you have those small islands or group of islands which are not fully compatible my personal belief but that's not TOC speaking my personal belief is that open standards should be a lot more driven throughout CNCF I come from networking so in ITF working code speaks and that is what the defined interfaces and everyone else speaks this until they build something better which actually works That's the end user So since Richie did the end user thing I'll do the maintainer thing I think if I created a project in a space where a project already existed and CNCF said this guy was here first and you don't adhere to their API you are not welcome that would be a really negative message So I don't necessarily view them as conflicting things it's more a thing of as you move through the stages it would be nice like we've all talked about to get closer to open standards but I don't think it's I'll hesitantly use the word fair for lack of a better one to force that open standard as like a criteria for being welcome We do encourage people to talk to each other and make sure that we provide a space for them to actually work through an issue or a problem dependencies can be shared test suites can be shared there's a bunch of things that can be done to improve collaboration it's only when and then let people decide together whether they want to do things separately or apart and which ones they want to do together Right? If you look at common examples you had the container D rocket thing that was standardized on container D and kind of Creo as the dominant solutions Envoy Gateway announced this week is basically taking two projects and kind of merging it into Envoy so these are like things that are driven long term based on end user and kind of vendor competition it's not forced by the TOC We'll have one more question and then I think we'll close it out and then I'm sure you could try to catch everyone here so one more question and then we'll wrap it up Hi, so is there any cycle for any software in the world that are CI-CDs or production environment observability and so on and I think CNTF did a very awesome job like starting from CI-CD until the very end but when it comes to the early stages of development for software engineers like local development and all of that I think that part specifically is I guess suffering a little bit because of the like huge landscapes that we have right now so is there any direction inside the CNTF to make this a little bit smoother especially for the early stages of the software development cycle before even the CI-CD during the local development in that early stage Anyone else take it? Are you referring to like the IDE or like the local development feedback, are you? Yeah, go ahead Think of it as like someone who is still working on the early version of the code locally on their own laptop like they are not even touching the CI-CD yet Okay, Katie I think there are already plenty of tools focusing on that so you have like lightweight version of Kubernetes and you have multiple products for that you have kind, you have K3S even QBADM you can use it locally if you really try so I think there are plenty of those at the moment it really depends where you'd like to focus on towards, is it just like application deployment or if you like to integrate different networking components or different storage that becomes a bit more complicated and this is mainly because you have different providers and like they require integration with the third party so you cannot really do everything on your local machine this is just like if it's just like hello world definitely very easy, if it's a bit more complicated I think that's definitely something we need to improve really, so for example let's talk about load balancer, if you want to kind of use a load balancer service, like there is a there is a tool kind of in my mind now it's not metal free metal LB, that's the one so you can use that one but even that one requires a bit of like tweaking making sure it works smoothly so definitely an area for improvement when it comes to the next level of bootstrapping your application and not just, you know, have a container running locally okay, all right we're a little two minutes over time, I want to thank the TOC here for their time I want to just stress everyone is generally very accessible even though everyone is a little bit busy feel free to reach out, send an email, Slack everyone generally will respond eventually it's very kind of a great group of folks we have up here and you know they're here to kind of serve the community and advise, so thank you for your time yeah, Dim's is pro hallway track, so all right so thank you, everyone sorry, just one more last thing Shilu mentioned the election, does that make up? yes, elections, elections, elections yeah, final thing so we, Cornelia has stepped down, you know, from the TOC, so this means we have an extra slot opening and it's part of the governing board tranche of slots, so it means the governing board helps to kind of vote on this, so if you're interested in potentially having an opportunity to run in this, please reach out to me or any TOC members and we kind of walk you through the process but it's fairly rare for this type of thing to occur, these happen in tranches, usually it's a couple year style term, so it's an opportunity, so feel free to ping me or reach out to any folks and we'll help you with the process, so thanks for the reminder there, cool, thank you everyone thank you