 How do you, everybody? All right, we are going to get started. Unfortunately, Alelida Sharma got held up by the Metro, you know, traffic, but never depend on the network. You can never, ever depend on the network. It's always DNS, but sometimes it is the Metro. But as soon as she comes up, we're going to welcome her on stage. It's great to see all of you. We're really keen to answer your questions. Really informal sessions. So any questions that you have that you'd like to direct to the end user tab, we'd love to give you some answers on that front. Feel free to ask any of these folks questions, or Alelida, once she gets here. I'm happy to answer some questions, too, as it pertains to the CNCF. I've got a couple seed questions if anybody needs to kind of break the ice on that front. But yeah, we have a mic right here. We would love to hear from you. What questions might you have? Nobody be shy. Oh. I was going to say the exact same thing. Smart, yeah. Sorry, too many conference days. I guess that's all. My name is Sergio Betan. I'm representing Alianz. That's it. That's me. I'm Chad Boden. I'm from Boeing. I'm Mario Constanti. I'm from Mercedes-Benz. Take innovation. Joseph Seneville. I'm with Adobe. And I'm Ricardo. I'm with CERN working on the platform's infrastructure, too. Can each of you maybe talk a little bit about what your goals and vision are for what the table accomplished this year and beyond? Yeah, start at the other end. Yeah. All right. So I'm an end user. We've been using Kubernetes for quite a while in Cloud Native at CERN. I've been involved in the technical oversight committee for the last couple of years as well. And one of the things that was always problematic in the technical oversight committee was to go beyond what is individual projects. And we all know about the landscape, the CNCF landscape. And this is a complex thing to navigate. So there was always this idea of having what we called reference architectures in the TOC. And this was very controversial because the CNCF and the TOC is no key making. But end users need this kind of information because we don't all have time to try all the available storage systems because some of them will have some special cases for our special needs. But we cannot try them all. So if we could just start sharing better this information, have a place where end users can go, share their case studies, share their stacks, and start building on this information for the whole community. I think that's the main goal. Then I know this will be a little bit complex. So I think the biggest challenge for end users will be to make sure this information stays relevant, in the sense because it's outdated often or quickly. But also, there's an overlap between what end users say and what the TOC says about the projects and their maturity. So we have to be a bit careful to not confuse even more end users by producing more information that's kind of not compatible with each other. It's a long answer, sorry, but I don't think it will be very easy to these things, but I'm really looking forward to it. Yeah, I think it's similar to Ricardo. And so just to get some background, I've been around the Kubernetes community probably since like 2014. And even from early on, I've been with small companies to a large company. I'm very fortunate now that I have a real big platform team, but I also cover quite a bit of scope from like the underlying Kubernetes with also our traffic engineering and API gateways. And even throughout all these 10 years of having some of this experience, it's not easy, especially with the success of the CNCF. There's so many projects and just trying to sustain and keep up. And then I'm trying to also strategize and find ways internally of what these projects mean to our company, also just open source in general. And so I think if anything, to be able to be a conduit, my hope is that there can be a way that we can continually amplify the voices of end users, helping others from the experience, from a lot of people on this board are very experienced that will help the projects so that we can also make sure that the things that are being built align with our end users. I think just even before I started here, I was talking to Abby and we were talking about a project that's interesting because it's also like this emergence of we're starting to see solution driven type, taking projects and bringing them together and solving problems. And I think at the end of the day, that's the most important thing I think is end users are solving these problems. It's not just the technology, but it's like, what are we doing these technologies to make our company succeed or non-profit or whatever these areas are at? So that's my hope, similarly to what the artifacts that were mentioned here earlier. Perfect answer because, and then going one step further because a lot of companies or end users are dealing with more or less the same issues and using the same technologies. But what's also important is how they staff their teams, their engineering teams, how they build these teams and how they cut the responsibilities of these teams. And I think that's also something which might be from staffing a team might be much more also interested in beside the reference architecture. Yeah, same thing here. When I came into the CNCF ecosystem a number of years ago, it's like that chart of all of the tools available and where they all fit. It's just like it's maddening and it's very intimidating coming into it. I don't know where I start. Everyone suffers from imposter syndrome. I'll just pick something and act like I know what I'm doing and it'll be okay. So I'm looking forward to being able to advocate and help with some of the end users coming in. And like Joe was saying, now at Boeing I have a large platform team and the team can get things figured out very quickly. But when we started it was me and two or three other individuals and it took a long time. You had to choose your Kubernetes distribution very carefully because you were gonna be heading into that environment and it was gonna take you some time to figure those things out. And so helping teams move faster would probably be my biggest thing I'd like to see. Yes, and I will say, what can I say? Said it all, right? So it's hard for me to add anything else. But what's interesting, especially during these days is that the more you talk to people you see that everybody has a certain vision for us. So it's quite interesting to ask you what's your vision for us? And then I talked to Lin Sondation, for example, I asked them what's the vision for us? So we are collective visions. We're gonna have a bunch of them. We have already a lot of wisdom that we can already collect from this wonderful group. We're gonna identify those that most likely makes sense to address now and weight probably the value and the impact. Based on that, I'm sure we're gonna come up with a beautiful short-term vision that will give trust to the community and we're gonna build around that and we're gonna work on progress. Work in progress, work on progress, we enjoy this one. I love that, being cloud native and not cloud naive. I'm sure many of us can relate to that or it might not admit publicly, but when it comes to focusing in on some of the things that the end user tab is gonna be working on, so we've gotten all booted up. Sirgyu is our vice chair, Elida, who is still on her way, she's assuring us, is our chairperson for the tab. Are there any key things that you really want to focus in to when it comes to, are there any problem areas that are really of interest to you as specific end users that you're solving in your organizations, whether it be AI, are you looking at workloads? Is it still difficult to kind of work across silos or teams? Maybe I can start now, I have clarity, it's missing. It's so hard to navigate still, after so many years you think you're done and actually you're not, and you're still lacking the clarity, you don't know what's next, you don't know if you maximize what you did. It's so hard to just look at yourself in a mirror, so it makes so much sense to actually come in a community and try to really have multiple mirrors ideally and reference yourself to the whole industry ideally and then you have a different benchmark, and that's going to raise ideally your benchmark, so that clarity for me is extremely important. Whenever we build a vision, whenever we build a strategy, that's essential to have. Even if you're changing the next day, it's every morning it's nice to have a vision, so that's important for you. A vision and coffee, yeah. If you want to, if you want to. Maybe it's not really a vision but building on the clarity part. I think the one thing that I'm sure happens but I don't think it happens that could be improved in the community is the relationship between the projects and the end users. This is a gap that I think the vendors try to fill, but the community still doesn't have it solved easily. And you can see this also on the different bodies of the CNCF, the projects will come to the TOC and to the tags to present themselves, but the people listening are the technical people that they're not necessarily the end users. And then we have the end users groups that projects come from time to time to present their thing, but it's not a regular meeting point. So if we can somehow create this place where people hang out and they are interested not only in presenting their own things when it's interesting for them, but that it gets interesting to have this regular meetup like we have at CoopCons basically, everyone comes to the CoopCons because there are so many people. Emily is gonna ask a tough question now so I'm gonna set up and pass the mic. Okay, so I don't bite and I didn't shower today so I don't smell. But my question for you all is what is the biggest challenge that you have in projects? Is it a lack of a specific feature or is an end user trying to reach your scale? What is it that you're specifically looking for struggling with that doesn't exist in the ecosystem yet today? I'll try to take a stab at this one. I think one of the big things that have happened to me and over the last year is at times, maybe it's more around like when I talk to certain things meaning like a lot of us have been around this cloud computing for quite a long time and we've seen a lot of different things emerge. I think of one example that was interesting was like there was a lot of hype for a lot of years around like service mesh, all these things. And it's gone through quite a bit of evolution. You could have jumped on it early and I've watched some teams that were really early in on certain projects that were very large and I think the first iteration of this large mess probably wasn't as user friendly as it could have been. It was very specific to the vendor that had built this project. Watching it evolve, I don't know how many people fell by the wayside so if anything I hope some of these insights, I know we've talked about like driving into like the projects and their maturity and how to recognize it. And I think given where we're at especially what's happening in our open source community we're watching the challenges of some of these smaller companies and I don't fault them. I understand the landscape of where we're at but helping to provide clarity of like where are these things when you can adopt them. I mean we do know project statuses but then there's still like these hype cycles that we gotta go through. I'm tackling wasm right now. We're kind of there. We're at 80% Java house and I'm trying to temper the expectation on what we can and can't do. And I feel like there's not a lot of insights I can find so I'm really working hard going to the vendors that I know and hopefully I can model a pattern that maybe someone else may benefit and take some of those lessons learned when things work or don't work. Awesome, great question. Thank you so much Emily. I know many people that I've talked to here at KubeCon have really wanted to see that kind of unity between projects in the end user tab. I think so many projects folks have come to me and I'm trying to slowly direct them to you. Maybe they'll send you an email on Monday so it hits the top of the stack. But curious in wanting to send surveys out are people still using this feature? They're going to rename branches or have questions about stable releases tooling and things like that. So I've gotten to see both sides of that so I'm really excited to work with y'all on uniting projects with end users on that front too. There's lots of excitement on both sides. Any other questions from the community? Are there any things that you're finding difficult to adopt or problems that you really want to frame or solve? Would love to hear from you. I think- Or suggestions that you guys would like us to tackle to start off with. You know, we talked about white papers and reference architectures and things like that. But if there's things out there that you guys would really like to see us do, you know, definitely speak up. Are you planning on collecting guidance from the end users on how you are planning financially to contribute back to open source projects and contribute engineering resources, especially to graduated projects? I would say now, yes, we do. Thank you. Actually, I think over the longest period of time, end users, and I think this was also highlighted in Taylor's slides yesterday, have contributed into specific projects. Argo is a great example, Kubernetes, open telemetry. So I think that what we have lacked in general is really being able to take that engineering contributions coming back into the projects or financial contributions to support the foundation itself and kind of had a clear correlation, right? So I think as we do talk with the different end users and have more technical deep dives, I think that will be something that will emerge from that dialogue. I was thinking more of the, sorry, microphone, the continual, not financially to the foundation, but within your own companies, such as we are invested in these projects and we want to see them continue to succeed. And so we're going to make sure we have the engineering resources for not just key features we want now, but the overall stability and health of the entire ecosystem. Yeah, yeah, absolutely. Because I mean, that's something again, at least I'm familiar with the large organizations that are very conscious of that dependency on significant technical projects across the CNCF landscape. There are more than 180 projects at this point, but it's not only graduated projects, right? It's also the incubate projects in incubated state or even maybe coming in into the sandbox that often there is a dependency on. But again, I would say from the large organizations at least there is a very active effort to make sure that that dependency is first of all understood by engineering teams and also help and engagement from the engineering teams is asked for to get involved and contribute more. So I mean, again, we continue to do that, right? We rate that because that's the idea of working closely with the TOC, where as they also have a pretty good understanding of what the project status is for different technical features that are being rolled out or technical states that the projects are going in, communicating that back again to the end users also. Actually, I'm in contact with unconscious company about the value of this. We also have that side of the story. And normally how it goes is that you have to show the race probably when you, for example, I'm pitching Osmo inside Alliance and I tried many narratives. One that works, it's obviously the fear factor or it's as miracles. Another one is the exposure that you're not aware when you have a strategy to go to cloud but you're not aware that 95% of your stack, it's open source and you have nothing to say about that. You don't drive the technology. Technology drives you. That's insane when you put it like that. One way to accept the costs, which obviously you have to do on that level, it's probably through a certain step, which is inner source that normally helps because you build an inner source concept, you measure somehow the cost of an inner source and then suddenly you realize that if I put in that project in open source, actually I'm gonna spend half of the resources I'm currently spending, so it makes sense. I'm having the cost anyhow, so why not? That's one approach. I was gonna add just a little bit to that. I think this is very interesting but one thing I've been mostly involved on engineering roles until recently and one thing we started doing more methodically internally is this idea of built versus buy and which is everyone is doing it but embracing also what it means to take an open source project. You're not necessarily buying, you might be buying it from a vendor but you also might be just adopting the project and what does that mean? Like we were talking about health of projects, graduation, but what does that mean? If things change, what does it mean for me? Like when I'm adopting an open source project, I'm not necessarily paying for it but I'm still definitely buying into it and there has to be a commitment of investing into the community, investing into adding maintainers as an end user because it's around interest or if we are not doing it, what's the exit strategy? If the project goes bad, what does it take for me to recover from that? And it might be that I was buying it from a vendor and I changed my opinion and I instead dedicate some developers to maintain the project now. But to kind of document this clearly internally is something we started doing more in a more methodical way. I think this is also some experience we can share in the end user community to better understand how people are approaching these different ways of adopting open source software. Are you just taking the upstream vanilla? Are you going through vendors? What is the thinking behind this? Yeah, I think that's kind of exactly where that I'm at. It's similar like that bill versus buy strategy. Either way, I want these companies to succeed. These things are strategic to our business. And when I first took this position in this platform team, like the things I just wanted to cry is when I seen the Envoy fork and I'm like, what happened here? Why did we do this? And it was not even a conversation that anybody was having. It was just, it just happened. And then I got into it and it was like, well, we had a hard time engaging with this group. And they just didn't have that. And I think at the contributor summit, that will opening that discussion that we had with the steering committee was around that. Like a lot of end users are struggling to figure out how to get, how do I give the feedback in that area? And I know for us it's a work in progress. I think we've to our point now where the things that maybe we're not committing maintainers to, what we try to become customers of these products because they are important. And I think we just gotta continually mature that and help to drive that into the community. I think most of us are coming from large companies and I guess most of us are having an Ospo, but I can imagine that especially smaller companies do not have an Ospo. And I know a few colleagues also of mine are still struggling with, oh, am I allowed to open an issue and documents and kind of a problem and probably do not sell any sensitive information. And I think that's also something probably for us, but at least making the users more aware of at least having some kind of an open source strategy to really understand the cost of using open source software. Going back to the cost of open source, I mean, I have another perspective from an end user site. I mean, I work for SAP, so obviously we are having Ospo. And we are trying internally to push the narrative there that open source is free, like a kitten, not like free like a beer. So basically you get the kitten and then you start caring for it going forward because it's gonna bring you joy for the rest of the next years to come. And that's actually that I didn't even, that came from one of the meetups we had with the TDD group, the to-do group, which is trying to popularize this kind of notion and understanding in the value of Ospo and so on, so for the smaller companies that don't have an Ospo and don't have the fortune to bring that in-house, that would be my recommendation, so it would be a great source of information, inspiration, learnings, references and so on. And I forgot to say thanks for being there for all of us. I think it's great that you have a full panel here and several people that either were at home, got pulled into other talks too. So no matter what challenges you're facing as an end user, you can kind of choose your fighter and really align with people that have experienced this before or that can help you navigate some of that too. So really fantastic. I'm gonna kind of target Alelita and just ask this question. Is there something that you're seeing, when adopting projects as an end user, what's different than kind of like the more general pool of folks, whether it be health metrics of a project, whether it be kind of that adoption story or usability, could you talk to some of that? Yeah, sure. I think as an end user, there are three aspects which are very critical in kind of taking a decision as well as continuing on the open source path, right? And the three are fundamentally, first of all, really the technology, first of all, being core to the business. For example, if you are looking at cloud native technologies, then you are invested in Kubernetes, for example, and Kubernetes ecosystem, then at that point, you really are looking at, okay, so in the Kubernetes stack, how do I enable all our application engineering teams to be able to build a full service, for example, or a full system? And that's where project health matters a lot. That includes diversity of the maintenance of the project, because often one of the things that has happened, which has kind of taken us back also, is that projects have lost the maintainer diversity in terms of the number of companies who are actively involved as maintainers on the project. And even within the CNCF, there has not been a clear understanding of that first of all occurring on the project. And secondly, the project not being able to adjust to the change, right? Where it has literally gone into a feature status quo because of not having enough maintainership. And as a result of which, very significant projects have actually stalled in terms of feature growth. So that's another area which is super important to understand that in terms of feature rollouts and releases that are being done by the project, how much is changing? What is changing? Is it just refactoring or bug fixes or is it new features also? And as a result of which, often at least having some understanding of the roadmap for a project is important as an end user. Right, because when you're looking for a specific set of features in a specific stack and you're kind of saying, oh, okay, I'm seeing all these issues that folks have requested for similar features, but I'm not really seeing that in the release notes, right? And even if you're not actively involved in the project as a maintainer or as a contributor, you still are looking at the issues that are being filed on a regular basis. Engineers look at it, you know? And also, what are the changes that are going out in the releases? So that's the second part. And then the third part really is what is the trajectory of adoption of the technology from that project in terms of where the industry is going? And to evaluate that between where the industry is pivoting to versus where the current investment in those projects is. Cool. Any other members have any thoughts on that front? Cool. Any other questions? Please feel free to step up and we'd love to get those answered. Yes, we got one. First, thank you for being there and answering your questions. My organization recently joined and I feel just what you said earlier, it's a war, I like it, because there's some room trying to fit in. It's complicated. Even those great people welcoming us. My question is there's a way where we can find people that have the same problem as we do? I mean, there's a lot of groups where the developer experience one, they're interesting, but is there a way where we can describe the use cases of your facing in order to find people that have the same problem as we do? Or is it something that can be organized? That was actually one of the things that we were talking about at breakfast the other day. One of the places to start, where we were talking about reference architectures and that was one of the things that GB and the talk kind of threw to us to tackle was coming up with reference architectures. And as Ricardo talked about, that's a big ask and there's no reference architecture that fits everybody's needs and so like then it kind of gets watered down and so one of the things that we're looking at doing is taking a use case approach to some of these reference architectures. So like what is your use case? Here's a thumbs up on that. What is your use case? How many other people have that similar use case? Then coming up with the reference architecture for that, not necessarily saying this is the one best tool X that everyone should use, but like this might be the best for your use case. I'll just add one little bit, which is even partitioning users, it's really complicated. So maybe this use case approach or case study is better. I'll give an example. We have this research and user group and a lot of people get pulled off because they see research and they think, okay, this is for people doing academia, things like this. And it isn't like you have financial organizations that have exactly the same systems, the same use cases. You have AI, now everyone is doing AI, which is a very similar setup. And the same is true for other areas. We end up trying to categorize use cases and sometimes we can't do such a good job. So maybe a more generic approach is a better one. What is really hard is then to have a place where people can hang out and discuss. It's the same for the technical areas. We tend to do very specific areas for storage, network, runtime, but then there's all the cases where we don't know where things fit and we get some sort of block team and this creates a lot of inertia. So maybe we can break this silo somehow. I want to tag on that real quick because like you had asked specifically and I think there is a good opportunity to get people plugged in to user groups. There's a number of user groups that are out there and those user groups may have similar use cases to you. So just pointing people to some of those user groups can also be helpful. Yeah, you look at the origins of Kubernetes I remember like between 2014, 2015 to 2016, like the interesting thing that I was in San Francisco at that time and we were a small company but what you kind of describe is what we were doing. Like we were going to beatups, we were connecting. There's a lot of people I still see here today when they're at other companies and we're sharing these information. I think if there's like a real codifying of us or we figure out a way to start making these more artifact driven and even like now when like last year when the AI ML thing was really starting to explode and we're trying to like figure out how do we get efficient with Kubernetes? I went back to that tribal approach but I think what's important for us is to kind of get it out of there and start to try to find ways to like here's how you could do these things. I loved how the AI group, because I remember in December I was talking to them and all of a sudden they kind of churned something out and I think the other thing is just like taking a real minimal like let's do this one thing and get it out there so we can just keep building on that foundationally. So maybe it's something that's applicable to you but then we can extend it or some other use cases but I think that's really what I'd love to see out of this is just a lot of that things that I look for is like as a recording person, I love when I see other more pragmatic how other teams are doing these things because that helps me also then be able to do the same thing. I think it's also capturing some of this in conversations like having regular office hours and disconnecting folks, right? Because at the end of the day we all talk to each other, whether that's online or in person and it really is that if you are looking for like-minded or similar companies who are actually working on very similar stacks or similar use cases then if you're all aware of it whether we say, hey, this is like an issue we can file we can just keep it on our repo but at the same time also share that if you're interested in this particular stack for this particular use case then please reach out to other folks who are interested too but it's actively doing that on a regular basis and just continuing and that's why I'm so excited to see that tab take form because I think it gives us all a forum to be able to actually share that and learn from each other also, right? Awesome, well we are just at about time but we'd love to thank you all for being here in terms of getting in touch with the tab we do have a GitHub repository that can open up issues on we're gonna figure out tagging we're gonna have so much fun with that and the hashtag tab Slack channel as well so feel free to reach out, ask some questions we can help point you in the right direction. Yeah, wonderful to have you all I hope that you had a wonderful KubeCon thus far the finish line is in sight so much to be excited about and so many more people to work with Thank you so much Thank you Thank you