 Hello, my name is Katie and currently I am one of the senior field engineer at Apple. I have joined Apple two years ago and in this role I am aiming to bring the cloud native and Kubernetes expertise to different products and teams within Apple. As well, I am one of the TOC, a technical oversight committee member for CNCF. As part of this role, I am joining 10 of the champions in the industry and we try to provision a long-term vision for our CNCF landscape. And we have, well actually I have many roles in the community, however I would like to mention that currently I am the creator of the cloud native fundamentals course which is completely free and you can take on Udacity, a very good resource for anyone who's looking to start or getting started within the CNCF community. And lastly, quite recently I won the Women in AT Awards for the Next Generation Leader and with this, Bill. So I'm Bill Mulligan and I work at Isovalent. I'm a community pollinator and my goal is to help make the Cilium and EBPF communities blossom. I'm also a committer to the Cilium project which is CNCF terms is basically like a maintainer. Today our aim is to actually talk around cross-ethicism and how a project can reach graduation. Now for anyone new to cloud native, our mission is to create a vendor neutral space for projects to grow while we focus on interoperability, scalability, resilience and many other principles. In short, we aim to make cloud native ubiquitous. The TOC or the Technical Oversight Committee drives technical decisions to serve that mission. We work very closely with the projects, provide the long-term vision for the landscape but at the same time advise projects on how to reach a healthy maintainer and a doctor base. Now who are we? Currently we are 11 people coming from very different organizations but experts in their own domains and areas. Now we had the elections for the TOC closing in December and we have welcomed Duffy and Nikita to our TOC member for committee and as well Emily Fox is our TOC chair as well. It is worth to mention that Erin and Kathy, they actually renew their terms and they're going to be with us for their second term within the TOC. Now moving forward, I would like to identify three main principles of fundamentals that shaped our community and got us to where we are today. These principles are focused on open governance, interoperability and scalability and sustainability. Now open governance and transparency is the nucleus of our community. The Kubernetes community is operating from the beginning on the principle that inclusive is better than exclusive. This is what invites everyone to contribute but at the same time pushes innovation forward. Next we have interoperability and this is pretty much the catalyst of the extensive portfolio in the landscape or the ecosystem that we currently have. Interoperability pretty much focuses on the fact that we embrace multiple solutions for the same problem but at the same time we shift the power towards the end users because as an end user you can choose the right tool or the best tool for your infrastructure with minimal compromises. And when it comes to sustainability we can actually look at this from two different perspectives, technical and community. Now recently we had an initiative that focused on observing, measuring and optimizing the carbon footprint for open source projects. This particular initiative crowned with the creation of a new tag or technical advisory group which is called tag environmental sustainability. They aim to put environmental sustainability on everyone's agenda but more importantly they aim to innovate for green technology. Now if you look at sustainability from the community perspective the main thing here is that we need to scale as a community at the same pace with the technology growth. We always have to strive to create a nurturing space for the next generation of cloud native practitioners to operate in and we can do that through many initiatives such as upskilling, mentoring, certifications and many more. Now everyone or most of you might have been familiar with this picture here. This is pretty much the CNCF landscape. Now usually this showcase to highlight the size and complexity of our community. However as the TOC's we look at this from a very different perspective. It reinforces the fact that we are one of the fastest growing community of open source out there. And this means that we need to grow and scale our processes as well to ensure that we can further expand as a community again from a community standpoint and technical standpoint as well. Now one of the main missions for the TOC is to collaborate and guide projects for three different maturity levels from which we have sandbox incubation and graduation. Now most of you might be familiar with the crossing the chasm notion or diagram where we have this crossing the chasm gap where a project is mature enough, has enough momentum gathered around the community, the adoption and it's pretty much a project that we have confidence that's going to be there for a while. Now the very nice thing here is that the CNCF maturity levels correlate quite nicely or overlap quite nicely with the crossing the chasm phases. As such the innovators they overlap with sandbox projects. These are very green field projects, bleeding edge, they might solve a problem for a very niche domain but they already kind of start to get community and some usages. Next we have early adopters and this correlates with incubation projects. Now in this case we already have usages in production, we already see a growing roadmap and community around it. And finally we have the crossing the chasm gap, this is where we have the graduated projects and early majority in adoptions. If we cross the chasm if a project is graduated such as Kubernetes or Prometheus we have confidence that this project is going to be around. We already have proven evidence that this project changed or did very well in different organizations in different sectors. Now within the CNCF currently we have 155 projects which are fully open sourced from which we have 96 in sandbox and this is hashed out with the red part on the graph here. Now you can see that this exponentially grew in the last two years and this is because we lowered the bar to entry for sandbox projects. Next we have 36 projects in incubation and 20 projects are currently graduated. However I would like to highlight the gray line which is just at the top. This is highlighting the archive projects. It is very important I think for us to see archival as a natural state of a project that can reach because sometimes you don't have enough contributions or no contributions and no adoptions and I think it is important to realize that and archive the projects and actually spread the effort towards different different projects out there. However that's not all we have a lot of open submissions and processes currently undergoing with other different projects. So currently we have 36 submissions from which 18 are trying to go for a sandbox, 11 going for incubation and seven going for graduation. Now this highlights the fact that again we have quite a huge backlog for the TOCs but more importantly we are scaling. We are having more projects joining our community and we need to scale our processes overall and the thing is as a TOCs we can oversee the entire landscape. However we cannot have deep technical expertise in every single domain. Here is where we have to delegate and actually the creation of the tag was super successful in this regard. As such the tags or technical advisory groups are created of experts in the domain that can provide valuable input for the TOC to make a decision and these technical domains are focused on things like runtime storage observability and very recently created tag environmental sustainability which was announced in Detroit last year for KubeCon. Now one thing here I would like to mention is that if you'd like to get involved or get started in Cloud Native I do recommend reaching to a tag first. They have all of their resources available on GitHub, all of the meetings are public, mailing lists, Slack channels, everything is open so you'd be able to not only interact but get started with your contributions straight away. And with that I'll take over to kind of talk about like the actual implementation of these processes from the project perspective. So as Katie was saying the first stage is usually the sandbox. Now the sandbox is where the early stage projects go. These are kind of experimental projects, people that want to try out new combinations of technologies, bring new ideas into the Cloud Native ecosystem. For example right now there are a lot of sandbox projects around wasm because it's a new and exciting technology but we're not really sure like what direction it's going. The sandbox is a great place for people to come together in a vendor-neutral way and collaborate and cross-pollinate ideas with one another. It's kind of like the lowest level and we're not really sure what's going to happen to these projects. The goal is for every project to go through the levels to incubation and graduation but not every sandbox project is going to go through all of that. They are new and they are experimental so some of them may not work out and as Katie was saying they we have archived some of the projects that were in the Cloud Native sandbox. So a little bit about the process. Previously the sandbox applications were done through a spreadsheet like any good process starts but it's recently migrated to GitHub issues and there's a couple benefits from the TOC and the community on this. The first one is the transparency. Everybody can see and track the whole process in GitHub like we do for a lot of things in the Cloud Native community. The second one is tracking labeling, seeing things like new and other late being able to sort by other labels. The TOC also votes in GitHub so we can track like how the votes went and now the projects can have direct contact with the TOC and the TOC can directly contact the project maintainers for more information when they need it. So let's walk through like an actual application from the sandbox and this is a project that was recently accepted in Spectre Gadget into the CNCF and here you can see the GitHub issue that they opened and it's now closed because they are accepted into the sandbox. Like the basic info that you're going to need is kind of things like what's the project summary description like where the repo the website and things are located things like the roadmap adopters and accepting a lot of things about like the CNCF IP policy. That's the basic info but there's a couple of these I'd like to deep dive into a little bit more because I think they're the ones that you should really focus on. So the first one is every single project within the CNCF needs to have a code of conduct. The cloud native community is known as a welcome opening open and diverse space and a code of conduct for your projects is a very important part of this. If you're not familiar with code of conducts a lot of projects including Sillium which I work on adopt the CNCF community code of conduct and it's a good template to get your project started. The next one is the adopters file even though I said that like the sandbox projects are oftentimes early and experimental there are people probably out there in the world using them and it's great to be able to start tracking them as soon as you know about people using them even if it's just in a homelad all the way to large scale production because as the project grows it's great to have a record of who's using the project and what they're using it for. You can see examples here from Sillium where we track it in the GitHub repo who's using the project you can see a short description of their use case a link to maybe some resources and like talking about which features of the project they're actually using. We then use this actually on our project website so we can promote who's using the project and what they're using it for and show the community like why how other people are adopting the project too and this is great to keep track of from the very beginning because it's easy to forget lose track of where things are and then the next part I think probably like the most important part for the application is actually kind of like the justification and this is kind of your argument to the TOC why your project should be in the CNCF versus any other project foundation under the Linux foundation or as a separate independent open source project so things like why does the CNCF uh benefits to the landscape as we saw it's already so large what what is new that your project is bringing the cloud native fit like why should it be here versus a different foundation like for example the EBPF foundation or the FinOps foundation the cloud native fit in integration and how it overlaps with other projects. I think an important thing to note here is CNCF has the principle of no king makers and so no project is going to be crowned as the champion in any one space. A lot of projects have overlaps with other projects in the CNCF ecosystem and that's okay it's great to see innovation and cross collaboration between projects and we see that a lot of times so it's completely fine to have overlap between projects and let's kind of like go through what the actual outcomes are so after you submit to the sandbox repo the TOC is going to do a review of the application they'll have an actual review review session where it's one of the meetings of the TOC they'll go through all the different projects and there's actually kind of three different decisions that they can come to so the first one is you're accepted congrats you're now a CNCF project the second one is declined you maybe you're not right fit the right fit for the CNCF you'd be a better fit under a different foundation or you don't fit into the cloud native landscape but I think probably the third one and the most interesting one is postponed and we can see this a lot either like the CNCF needs more info or clarification they might assign you to a different tag that Katie was talking about to get review or feedback or clarification on something that the project's doing or you may need to grow the project a little bit more the contributors who's using it and the TOC would like to see it in the CNCF in the future but they'd see like to see a little bit more maturity of the project before they accept it into the CNCF the next stage after sandbox is the incubation and this is really where a lot of the due diligence in the process comes I think the gap between sandbox and incubation is saying this is a innovative project that may or may not work out to people are actually using this in production and some people that are trying to do cutting edge use cases are adopting it today and so this is where the CNCF really goes through and kind of sees what if the project meets those requirements and so how it happens is the project puts forward a proposal a TOC sponsor steps forwards a tag presentation has happened so you can gather recording and recommendations from the relevant group of people the due diligence doc is put together both on the technical side and the governance side and user interviews from both the project and the TOC side and then the whole TOC reviews that and puts it up for a vote whether to move on to incubation or not like the TOC wants all projects to be successful and actually at this point there hasn't been any projects that have failed the vote for incubation some have taken longer than others and that's perfectly okay like sometimes it takes a project longer to mature it's it's not a problem we'd like to see projects continue to grow develop and evolve now the key things in the application process for incubation are first being successfully used in production by at least three independent adopters so the TOC wants to see that people are actually putting this into production and relying on it in the real world the second one is a healthy number of committers so people that are contributing to the project and have the actual commit bit the third one is an ongoing flow of commits and merge contributions so is the project continuing to grow evolve and expand I think the important caveat here to note though is that the CNCF has a wide variety of projects from specifications all the way up to Kubernetes these metrics aren't going to look at look the same across all the different projects because there is so much variation what may be like a healthy number of contributions for a specification could be vastly different for a fast-growing open source project like Kubernetes a clear versioning scheme is important and for specifications at least one public reference implementation so that's kind of like the high level requirements and then the actual due diligence document dives into the details so the TOC wants to know the background of the project what its goals are and its current status the future plans and project scope the formal requirements I talked about before and they actually go will go and interview your end users to understand what their experience is not only just using the project but actually interacting with the project to is the project open does it have like a welcoming community are people like willing to engage and is there a good feedback loop between the actual end users and the project to there's also other considerations and contacts that may be very based on the project for example how does it fit into the rest of the landscape and overlap with other projects if you want to see an example of a due diligence stock you can check out the one that I put together for psyllium the links at the top there and you can see kind of go through and see like what we said about the psyllium project now as Bill mentioned we actually do the end user interviews and this is because we really want to capture the entire experience of developing a project and using the project in production as such we're going to focus on three main aspects experience benefits and challenges now we really want to understand what was the experience of the end users while adopting the project and integrating it with the existing components within their platform systems as well we focus on the interaction with the community as well because as an end user if you had an issue or for example you have a request for a new functionality or discovered a bug what was your experience in communicating that and actually getting a result for your issue so really try to understand what is the entire lifecycle of the project from creation to adoption next we're going to focus on the benefits what is the key selling point for this project we really want to understand why this project was chosen in comparison to other products on the market is it because is the only product out there and that was your only choice or is it because this particular project actually brings something very valuable to the community and to your project as well and finally we're going to focus on some of the challenges what were some of the drawbacks or difficult moments on integrating the project within your infrastructure now here actually we discover some of the points or the areas that the project can actually improve on so we can pretty much send all of this feedback back to the maintainers for them to improve and enhance on top of and once you've gone through kind of like this whole process the TOCL vote and hopefully you'll move to incubation and the final stage when we have to the maturity level is going to be graduation as part of the graduation we have a due diligence document as well which has a very similar format that bill mentioned and the screenshot that he shared for psyllium is actually the graduation due diligence document so you'll be able to see the same aspects that we're deep diving into now it is very important to mention here that once going for graduation you actually have to fulfill the criteria for sandbox and incubation so you cannot really skip all of that you have to fulfill all of the criteria and in addition we have some other guidelines on top of it the first one is a healthy contributor base you need to have contributions from at least two organizations however we're looking to have a very balanced contribution as well if all of the PRS and issues are opened for example 90 of those PRS and issues are opened by one organization that does not signal a healthy community we're really looking to balance it out as much as possible the more contributors you have the more organization we have contributing to a project the better next I think this is one of those checkpoints but we really want projects to achieve and maintain a best practices badge and there are a lot of resources on how to include that into your project and maintain that next security is actually something very important we focus on that quite heavily and we want the projects to complete an independent and third party security audit as part of that we want them to publish all of the results but more importantly we want them to fix all of the critical vulnerabilities in order to reach graduation now we've mentioned things like the governance and conduct and processes however when it comes to graduation we really want to have a very clear and explicit definition on how anyone can start to use the project or how they can actually contribute to the project this should be a very clear path so the first one we're going to have a governance.md file it can be any other name this is just a placeholder but the idea is should contain the process governance and committers here is like as a as a contributor how am I able to approach this project and contribute as well in the governance file would expect a reference towards an owner's file and this will contain all of the existing and emeritus committers now another important factor is the onboarding overboarding and emeritus criteria for the project and this is going to be usually kept in a maintenance file more importantly we want this to be not only defined but actually applied in the community in the project community so we would expect this to be updated or reviewed at least once a year and finally Bill mentioned that we really want to see real applications of the project in the real world and here we want to have a list of adopters and again the more the merrier excuse me now and everything is if this is accompanied by case studies or extreme information that's even better because it really helps us to make the best judgment on the project maturity so this seems like a lot of information and it may be hard to think about trying to implement this all at once so what the TOC has started to put together is some cloud native guideposts which are currently a work in progress to help projects understand how they can mature through these stages and there's three main categories that I'd put these into the first is adoption the second is security and the last one is contribution adoption we've been talking about a lot having the adopters file right from when you're in sandbox and it's really having companies publicly saying that they're using the project it helps other end users know that people are relying on this and that they can too also along with that is like good documentation around your project and how people can use it so that they can actually adopt it the second one is the security I know chris announced this morning that cncf has spent I think it was like two million so far on security audits for projects and that's an important part if you're putting something into production and users want to know that they can rely on this software to be secure there's also things like audit badging and having a published threat model that will help enhance the security of your project the last part is the contribution open source projects live and die based on the community and the contributions flowing into their project so having things like getting started documentation contributor guides public discussions open governance and a way to go through the project levels are very important for the health of your project if you want to learn more I'd check out the keynote from dawn that happened just this morning talking about how you can grow and have a healthy community around your project tag contributor strategy also has a great a bunch of great resources and templates that projects can use and go to contribute dot cncf dot io slash maintainers to find them I know for myself in cilium I've used a bunch of the templates from the project to grow some of the governance around our project too and the last thing if this seems like a lot of process a lot of overhead you may be wondering why would I ever want to donate my project to cncf what are the actual project benefits that I as a maintainer or contributor can get from cncf and there are actually quite a few of them the first one is the design if you've seen I guess the all the great signage around here the t-shirts um 50 characters all that's done by cncf and projects can take advantage of it projects can also when they're graduated get a fit be character for themselves too and I know I'm looking forward to the cilium project character the second one is around program management helping out with things like zoom meetings and cool rocks I guess a lot of the project overhead this may be not as fun to do legal services if you thought program management was bad try switching to legal luckily cncf has a bunch of very experienced people in open source legal matters that can help for things like license reviews and other things that you may need tools and technical documentation this is the infrastructure that makes all the other work possible cncf has a broad variety of tools that projects can leverage and they also have tech technical documentation writers who can help review and improve your project documentation things like ci cncf can pay for it's great to have so many members because we can then bring this money back into the project so we can fund their ci efforts certifications and trainings so for example the introduction to cilium course was launched yesterday by lf training and I'm excited to see more certifications come up up around that and it helps people upgrade their knowledge around their project and show others that they're certified to use it and the last part is the marketing you're here today so you're getting part of that marketing experience from cncf a thing to note though sandbox projects don't get marketing support because they're still experimental it's only for incubating and graduated projects and the last project benefit all of these can be accessed through jira which is most people's favorite piece of software I love to have a ticketing system and finally I would like to live with a perspective on the overall life cycle of a project whilst being in the cncf the first thing which is very important to remember is that entering and moving level criteria is in constant change and this is only natural we actually should update our processes for example a project that graduated two years ago had slightly different criteria from a project that's going to graduate in the next couple of years so this is only natural because we want to provide clear guidance and milestone for the projects to actually ensure and reach that maturity level next is that actually with every single project as a tuc we have a tailored approach and this is sometimes necessary for example we have projects who enter directly to incubation they skip sandbox and they apply for incubation straight away that is possible we cannot go directly for incubation at least we didn't have that but you can go for for incubation now the thing is that due diligence for that particular process it's more thorough because we need to answer some of the questions we had for sandbox is this project a right fit for the cncf does it overlap with our tools what is the actual key selling point for this project and why it should be part of our community so we need to do a more like more work and a more thorough insight deep dive into the project as well actually to mention here some of the examples of tools that moved incubation straight away we had cilium we have istio and kubflow which currently is work in progress or has open submission with us next another example that is quite tailored is the linkardy steering committee now looking at linkardy we actually have most of the contributors coming from one organization and we really want to ensure that vendor neutrality when it comes to the product development as such the tlc advised for the linkardy project to have a steering committee to ensure they collect all of the voices across different boards such as end users our vendors and to make sure that it's as vendor neutral as possible in his development now as well kind of kind of got the gist but it is very important for all of the projects to have a close collaboration with the tax because the tax can really help you to reach the maturity level if you'd like to improve your contributor base go to contributes tag and trip strategy they will help you to redefine your criteria work to clarify your criteria when it comes to not only getting the contributors but retain them as well if you'd like to improve your security and actually increase that confidence in the doctor base when it comes to adopting your project you can go and work with tax security and so forth there is a lot of collaboration the project should do not only with the tlcs but with the tax to reach the maturity level now archiving I mentioned in the beginning but I think it should be very highly shared and discussed about because I think it's more of a taboo subject it's okay to be in our archive projects because again it's natural to for some of the contributions to go down to zero and adoptions to go down to zero it is more about understanding that getting the lesson learned from the project and spreading your efforts across other projects within the foundation and and everything that we have actually currently on undergoing is the annual reviews and this is happening only for sandbox projects now the tlc currently are asking the projects every single year from sandbox to provide an annual review which is providing updates and the latest dynamics within within the project we are actually looking to perhaps expand this for incubation and graduated projects last thing a couple different resources to go if you want to engage with the tlc it's the first the tlc has a github repo where a lot of this is done there's also a channel in the cncf slack a mailing list and they have public meetings on the first tuesday of every single month last one i really want to give a shout out to tegg contributor strategy because they have a lot of resources and helping grow and maintain a healthy open source community so with that thank you and we have i think a couple minutes for questions maybe thank you for all of the really helpful information um i was wondering if there is like a uh cutoff time for the amount of time a project can spend in the sandbox before they get archived or what happens to them after that um currently we don't have a timeline for the project because we're actually facing a different problem well not necessarily a problem but a different situation at the moment because some projects are gathering that momentum to move to incubation and that's kind of a natural way to move forward but some projects they still have contributions and adoptions that they quite low and they're just going to be in sandbox for a while they they serve for a very particular segment and niche within the market and the thing is they don't have sufficient um current capacity to move to incubation perhaps if if they get more contributors and they get more adoptions but we're facing this new situation where we're thinking what to do these projects i think at the moment again no timeline to answer your question very directly but i think what we're trying to do from the TAC side is to provide more support and guidance on how can they thrive even if they stay in sandbox for example for forever supposedly we still want them to cut releases we still want them to be a dynamic project all the way through so um yeah i think when it comes to that particular segment of projects work in progress um but yeah definitely no timelines thank you very much enjoy the rest of the kubicon