 I have the pleasure of introducing our next keynote by my fellow co-chair, Emily Fox. Emily is a security engineer at Apple. Today, Emily is going to talk about the importance of preserving what she calls knowledge glaciers for new generations of technologies to prevent important lessons from becoming lost to history and to keep our community in bloom. Please welcome Emily Fox. All right. Hello again, everyone. I'm Emily Fox. I'm a security engineer at Apple. And I'm also chair of the technical oversight committee for the CNCF. And you heard from my fellow TOC members previously. I've also been fortunate to co-chair this conference alongside some truly remarkable people and individuals. And I've stood on this stage and many others and shared with you all wonderful things about our community, about our projects, and also about how I approach challenges I experience in cloud native and an open source. Whether or not it's providing security guidance to a project or driving changes to improve your experience here at this event as an attendee, there's a principle that has stuck with me through all of my years from when I was a Girl Scout. And it's to leave it better than you found it. And today, I'm going to talk to you about how knowledge glaciers and gardens are passed to be able to do that. As projects enter our ecosystem, they embark on a journey of learning and knowledge and experience to cross the chasm. That journey, that learning experience is so essential to their success. And as with any new person or organization starting something new, we experience a lot of successes as well as failures that contribute to our growth, our development, and our overall maturity. And it can take months or even years, depending on our capacity to act and pivot on that information. But regardless, we always retain that information moving forward. This experience and innovation is what allows us to make better and more informed decisions to sustain some of these amazing projects and communities. That information is actually what I call knowledge glaciers. And for those of you that don't recall elementary science, glaciers are slowly moving masses of rivers and ice that are formed by the accumulation and compaction of snow on mountains or near poles. It appears very blue and very dense and free of bubbles that take years of compression to make the ice denser over time, forcing out air pockets between the crystals. That's what increases the bluish tint. Therefore, the purest parts of the glacier are in fact the bluest. And knowledge glaciers, they're not much different. Knowledge glaciers are the accumulation and compaction of deep knowledge that's built over time and provides foundational understanding as our community knowledge expands. But quite frankly, both of these are beginning to melt. Scientific research has actually shown the overall mass of glaciers on Earth is reducing at a very alarming rate. Due to environmental factors that are beyond the glaciers control, much like we see with some of our projects within the ecosystem. And in cloud native, we're seeing less and less individuals step into leadership roles. Because the time to onboard into these positions is nonexistent. That places us in a reactive mode, having that gap in knowledge with no one ready to transition into those roles. And this is where glacial melt actually begins to accelerate for our projects. As we innovate in cloud native, we leverage a lot of really awesome and amazing projects to make development, adoption and integration into our enterprises and organizations a lot easier. You see, we build on top of previous innovation and we begin consolidating our expertise, transitioning from developing distributed applications with a container runtime, which once was considered novel and unique. And now we're experimenting with projects like crosslet for scheduling applications in a wasm time based runtime or metal three for bare metal host provisioning for Kubernetes. But we're balancing a lot of these environmental and social factors like the early proliferation of AI and its impact on our projects and our groups, whether or not they can leverage it responsibly. What are the benefits and risks associated for that within their code or their documentation? We also see acquisitions and shifts in the companies and individuals behind several of these projects. And these changes, these factors along with many, many others can evaporate or impact the amount of and the completeness of our institutional knowledge within the ecosystem. That impacts this information from being transferred from one generation of cloud native contributors to the next, whether or not it's changes in these roles, changes in direction and vision. Sometimes it causes missing handoffs. Accumulating and transferring this dense mass of knowledge is extremely difficult and hard to perform in an organization, let alone one as international, asynchronous and distributed as the one that we have in cloud native and open source communities. You see, we've had eight years of knowledge compression on top of over 50 years of technical innovation that have contributed to the depth and breadth of cloud native technology, making this information denser over time as we force out the tiny, time-specific and potentially application-specific pockets of knowledge between bursts of innovation and building on top, abstracting new layers and forming a new foundation of pure knowledge from which further innovation is born and then commoditized within our ecosystem. Not only for adopters of CNCF projects, but also for projects themselves within the CNCF, like we see with Artifact Hub, who's publishing packages and configurations or kind, which we heard Priyanka demo about on Wednesday. But if you were to take a look at the TOC repo, or if you recall the previous presentation from Ricardo and Nikita, you'll see a lot of questions around project health, governance, maturity, and you've heard from me and others on this stage and in various meetings asked for you to come forward to contribute to our projects to our tags to take up some of these positions. Because our institutional knowledge is beginning to slip away as we experience turnover in cloud native. Those external factors I referenced before are impacting our community and bringing more innovation into our ecosystem, but that's not without additional strain and change on projects if we're not saving our knowledge glaciers or employing succession planning in our cloud native gardens. Because maintainers have been sustaining the growth of these projects probably a lot longer than they originally intended. In addition to feeling burnout and being inundated with requests and requirements and moving levels, engaging with adopters and other enterprise organizations to have their project widespread, they are also managing a community of tens, hundreds, and maybe even thousands. They're also likely to be feeling a sense of guilt. They want to try something new. They want something that's exciting, but there are no contributors in place within their project to step in behind them, and they simply cannot take on the extra work. It's very difficult. But contributors, they're also likely to be experiencing something similar, but in this case it's going to be a form of imposter syndrome, because the prospect of maintainership and leadership is a little scary and daunting. There's a lot of knowledge and learnings that go into leading a project or a group, and it's not something that we can learn overnight. However, it isn't much different when you start a new role within a new organization. When you onboard to a new organization, there are a lot of the basics that get you up and running, and you've often been brought in to fill a gap and not learn alongside someone. It will take you about a year or so before you get your feet underneath of you, or you understand the context of your work to be successful. That onboarding journey that you go through is usually successful because you're leveraging existing guides, existing documents, and other material that allow you to ease into the culture goals and objectives of your organization, and that does take time. It could take six months. It could take a year. It may even take two. You might have a buddy or a mentor available to guide you along that path. You might attend several meetings or even shadow some meetings to understand a little bit more about the context of your work, the scope of it, and how it fits into your organization's infrastructure, architecture, landscape, and in some cases their mission and vision. So how do you transfer all of this knowledge one generation to the other, and how do we bring alongside community members and collaborators to distribute that knowledge even broader? How do we enable and empower contributors to take up the mantle of leadership and serve our project community in a way that lets them build, empower, and support it? If you look at the ecosystem and you figure out how long some of our project maintainers and co-chairs have been in their positions, could you imagine the landscape if they didn't exist? Our community is a patchwork of gardens in the cloud-native ecosystem, and right now we only have one season of bloom. We have to successfully plant for the next one. So let's take a journey, let's scale that knowledge glacier and figure out how we can get those blooms moving from season to season for year-round. When you enter the cloud-native landscape, there's a lot to see. You saw that previous slide, the font size is really tiny. We can't quite read it all. It's a lot to take in. So when we're establishing our bearings, it's often best to seek elevation and what better way to start learning than to start looking for that knowledge glacier. I've talked in the past about how the documentation on Rebos is a good place to start as a contributor, but it often describes how things are supposed to work, how they should work. But what about the occasions where it didn't? Meeting community members and talking with them about their observations and their experiences within these projects and leading these groups is important. It can help set expectations for a role that you're interested in taking on, and reviewing pull requests and issue discussions, Slack channel messages and meeting notes are also great resources to figure out the size and the shape of that glacier, how big it could be to scale. They provide you with the context around how things should occur as well as how they did occur and why. So now that we've got our climbing gear and we know where that knowledge glacier is, let's start our climb. As we begin working within a project, we may start out on smaller, more narrowly scoped improvements. This helps us establish trust within the community, not only for others of us, but also establish the expectations of the relationship we're going to have with engaging with the maintainers and other collaborators within these groups. And you'll be experiencing firsthand how some of these things should be occurring. However, you may find a few gaps here and there in the documentation or in the processes that could have been clear. They weren't otherwise very well detailed and that led to confusion, misalignment, and in some cases, misunderstanding. So now you have two choices before you. You can take this information and keep it to yourself. Place it in your own personal knowledge glacier and move on. Or you can immediately contribute it back to the project. That means you're going to set anchor, you're going to climb back down from that knowledge glacier, harvest the seed of information, and plant it for the next person to follow along behind you. In guardian planning and design, we leverage succession planners so we have a harvest or crop continually, but also so that we have blossoms and blooms intermixed to enjoy the fruits of our labor. Visual interest, contrast, and diversity in our gardens is what bring beauty and innovation to the projects and groups within the landscape to accomplish a lot of fantastic things. A variety of plantings and blooms over multiple seasons also provides attractants such as beneficial insects or adopters, natural characteristics that repel disease, such as security faults, and bring harmony to soil ecology so that our gardens remain healthy and thriving. However, when a garden is a monoculture, meaning only one kind of plant exists, it becomes more susceptible to plague and disease. It's more likely to be attacked. It's more likely to wither and fail. Because the lack of diversity which provides the defense in depth is so important and we only get that in polyculture environments. On Wednesday, we heard from Dawn talk about the importance of a contributor's strategy in sustaining your projects. Because when we don't identify and invest in other community members or empower them to learn more about our projects, when we don't invite them into our design discussions, we're not only failing to plant successfully, we're also not giving them the space or light to reach their potential. And eventually the tallest flower or tree in the forest will retire and fade, and without another flower ready to step in and bloom, our garden is going to quickly begin to empty. As adopters and contributors to Cloud Native, designing our projects and communities for year-round blooms and successive plantings, we need to ensure that we're also designing communities into layers of leadership. We have canopies of maintainers that filter and distribute the light to the understory. But we also have sub-canopies of technical leads that provide a wide variety of conditions for activities to occur. We have shrubs that assist in triage management to provide erosion of our ecosystem and build healthy, active communities. We have an herbaceous layer of frequent contributors that continually enhance and support our projects. A ground cover of new contributions that help retain innovation and challenge assumptions of the previous project maintainers and climbers that move between all layers, connecting everyone together for a cohesive ecosystem. Identifying someone who is active and interested and setting the seat of support and growth within them, setting those anchors, provide chances for them to learn and to scale that knowledge glacier behind you. It may require you to climb back down, invite them into your discussions, and assist them with their climbing gear to mentor and coach them along the path that you took, and let them lead. It's important that you be the stake in the garden, providing support until they are ready to grow on their own, because the path of a contributor in cloud native is a journey to scale that knowledge glacier, to reach the summit and experience the beauty and joy in a thriving ecosystem of projects that have momentous international and global impact. But it is lonely at the top being the only steward of that knowledge and carrying the burden of maintainership alone. We've returned back to glacial melts. Maintainership and contributions in cloud native is leadership. We have a responsibility to leave our community and our projects better than we found them by setting those knowledge anchors for others to leverage into their scaling of the glacier. But also to plant seeds and teach others how to plant them to encourage and mentor growth and care in the garden so that when one bloom fades, we have three and four and five others ready to stand behind for years after to blossom. Thank you.