 All right, let's get started. So nice to see all these people here, long conference. And I'm so glad to see so many open source contributors and committers and community people who work really hard in making these open source projects a success. We learned a ton about how to enable and engage communities in open source in this conference. And yet I think we have not learned enough about ways to not engage communities in open source. There are people out there that are creating amazing new creative ways of messing with open source communities. Just from a couple of weeks ago, just remove TypeScript and all your downstream dependencies are having trouble depending on the open source project. A more common problem and one that was talked in the keynote yesterday is relicensing. Relicensing is increasingly common and we're not going to talk about the fact that companies are absolutely free to do whatever they want with their open source software. They can totally relicense it under a non-open source license. It's their prerogative. They created something and they can own it. But it can actually happen to you. And so when that happens, you are in a business that relies on open source software and the software is no longer open source. You have real money riding on this. Your business depends on it. Your customers depend on it and you are serving your customers. So what do you do? Do you shut down? Do you tell all your customers, sorry, we will not have any more updates for the software? Bye, please don't use our service. You can't. Do you fork it and continue maintaining the open source project that was there? We did it. We had a business inside of AWS that depended on a fairly large open source project. The project changed its license and then we forked it. So I'm gonna tell you about the story. My name is Daniel Dubrovkin. I go by DB. I work for AWS. I've been working on the open search fork for two and a half years and it's a huge endeavor. Driving a project of that size is a lot of work. It's a big investment. It's not something to take lightly. We had to figure out how to do it in a hurry. So let's talk about that. You don't have to fork an open source project into open source. You can actually fork it in closed source and there were plenty of reasons for AWS to take the open source project, the elastic search and fork it into closed source. I'll explain why we did not and why we continued, why we forked into open source. Once you forked, you have to get stable and healthy to be able to accept contributions from other people and I'll give you some details about how we did that. Finally, Log4j was an amazing security vulnerability that affected everyone, all hands on deck, across the board and it has been amazing for open search. And I'll tell you why you should have your own security vulnerability that will affect your product and your customers. And finally, we'll ask ourselves important questions around next steps and the steps we did not take early in the project, in the evolution of the fork, notably things around topics like governance. So let's go back two years. AWS runs a managed service called Managed Elastic Search and there is the open source software called Elastic Search that is an Apache V2 licensed product. There's a number of components, some of which are essential such as security, such as nearest neighbor search, anomaly detection, observability, these are plugins. And these plugins exist in two versions. There is the open source version and there is the not open source version. And if you go to Elastic Cloud, it runs the proprietary non open source versions of that software. So the engine is open source, but then there's a whole ecosystem a zoo of plugins on top of that. The open source package is called open distro for Elastic Search. It's actually maintained by some AWS people and then AWS built a managed service on top of it. So if you think of the software that's open source, we call it the data plane and the software that controls that, it's a control plane. So what does the control plane do? Well, it orchestrates massive clusters of open search, Elastic Search at the time. It makes sure that those stand up, that you can get an instance when you need to, it does upgrades for you. It has a variety of features. You can just go and click a few buttons and it works. So the control plane is actually quite complicated. The reason why many customers like AWS is because you get all that service. You don't have to hire people to manage your infrastructure. And so the tremendous amount of work was done on the control plane, but the core engine itself all the way down to close to the metal is an open source product. So for AWS, it actually made a lot of sense to fork into closed source. Here's why. We have customers who run very old versions of Elastic Search and now open search all the way back to versions like five. I think it's like 50 years old now, something like that. So as a customer, I run an old version of the software and if I'm super happy with it, the only thing I care about is that security gets patched and that performance doesn't degrade. I actually don't want to upgrade. It's very costly to upgrade. So AWS runs very old versions of the software and every time there's security vulnerability, it actually backports the security vulnerability to many, many old versions of the software and deploys them in production. You don't even notice. Now the upstream open source project does not take patches all the way back. Nobody's maintaining those versions of the software. So internally inside of the Git inside of Amazon, there's actually a tremendous amount of the security patches, sometimes even performance fixes that don't affect functionality that backported all the way to many old versions. So that's a lot of work and it would be amazing to get rid of this open source upstream and just do it in a private fork. It would save tremendous amount of time and tons of money would be so much easier. But we didn't fork into closed source. We didn't just go and continue a competitive product that was closed source. And here's why, we just asked customers of the service what would you like to do? And the more we talk to customers, the more we realize that customers like the freedom of open source software. Many of them want to be able to run it on their own laptops, want to be able to deploy it in their own infrastructure. On-prem, they would like to be able to customize the software. It's better for security because open source software is more transparent and things like vulnerabilities are more visible. And then there's customers out there that are actually developers. There's plenty of companies with developer hands and many times the companies want to at least customize the software to their liking. They want to assemble their own distributions with just the plugins they care about. Sometimes they want to modify the software in ways that works in their organizations. And sometimes they even want to contribute upstream and develop features and then bring them back to the upstream open source project. And all these are great things of open source. And so more and more we see customers, users, people like you, get the open source software, decide to use it and then only afterwards figure out how they're going to run it. And there are many options to run the software. You can hire people and manage it on-prem. You can run in a variety of clouds. You can get open search from a variety of cloud providers including AWS. You can use companies like Ivan or LogZ for very specialized workloads, login analytics or things like that where the real specialists of that particular configuration of the software. So you have a lot of options. So customers prefer to use open source software for all the good reasons for using open source software and then they choose where to run it. And of course, I work for a large organization that hopes we're the best place to run that software and we will continue doing our best to be the best place to run that software. But people want an open source elastic search. They want an open source open search. So, but open source and Amazon, the intersection between those two concepts usually is not that, at least in the people's minds, is not the thing that comes in your brain when they say open source and Amazon. Usually those things don't really go together, it seems. Many have criticized Amazon for not bringing the contributing upstream. And of course, we can do better. But the truth is that Amazon has been doing open source for a very long time. Do you know that OSPO at AWS existed since 2007? And this morning I counted in our system 28 contributors to Lucene, some of which contribute pretty major features. And Lucene is the foundation of open search. And my own experience of four and a half years at AWS has been quite great. There's really no barriers for contribution to open source. You go into an open source project and let's say you want to do a bug fix or add a small feature and you can go read a handbook of contributing to open source on some internal website. And it says, well, if the license is one of these permitted licenses like MIT, Apache V2 and so on and so forth, and it's a small feature or an improvement, just please go contribute. And here's how you should set up your GitHub and here's how you should connect to it. Here's maybe you need to register that you have a GitHub account, things like that. It's super easy. And then even for bigger contributions that are not super easy at all, it is quite easy. If I want to take some core IP that is competitive and super interesting, I have, I'm supported by a team, I can go file a ticket, I have an IP review with people who care about both open source and competitive advantage of the company and the business for which I work. And we can have an honest discussion about whether this is the right thing to open source, not open source, and so many developers at Amazon do this today all day long. So it's not just small things, it's also big things. It's really quite simple. So we decide to fork. And when you fork, you need to have people who are going to do this work. So we hire an open source champion, somebody who has actually been at Amazon for a very, a low number of years, I think he's been by that time 12 years at Amazon or even maybe more. And we give them, we give this open source leader, this guy, dozens of people. We allocate these people, and then we consult some design experts because what's a hard problem in software? No naming, of course. So we ask everyone and we come up the most creative name possible for this new search engine. We call it open search, drumroll. People were waiting on the name for like three months and this is what we came up with. It's great, it's pretty straightforward. Open source search. We actually have two products, there's open search and there's open search dashboards, which is the fork of Kibana. So once you have a name, what do you do next? We create an internal Wiki, of course. All right, I hope I don't get booed when I say that we create a GitHub organization. So we create open search dash project, a GitHub org, and then no booze, thanks, Dave, great. So we started figuring out, as soon as we created the GitHub org, we started figuring out the minimum list of problems we need to solve if we didn't add any features. Just bring the project to a state where an external contributor or any contributor for that matter could come and just bring code to open search and somebody would review the code, merge it and things like that. So we said what is the absolute minimum even if we didn't add any features. And there were two kinds of things that we had to do right after the fork, some of which were organizational and some of which were technical. Let's talk about the non-technical stuff first. First, when you fork a project of any size, you got to call a lawyer. And this is a very difficult thing to do for an engineer that the first person I call is a lawyer, but you will have so many legal decisions to make. One of these important decisions is trademark. So Amazon chose to own the trademark and as soon as you say you own the trademark, you have the legal obligation to police the trademark, you have to control it, you have to protect it in the legal sense. So we, from first principles, we wanted the most permissible trademark. Imagine you're building a competitive service to AWS powered by open search and then AWS comes up to you and says, no, you could not build a competitive service. Well, it defeats the whole purpose of open source. We don't want that. So we created the most permissible trademark that ensures the longevity of the project so that we can have absolutely many competitive businesses to us. And then we, at the same time, reserved the right to go after bad actors that might be disingenuous about it. So we really tried to make it super simple, most permissible possible and not be dumb about it. That's a pretty simple TLDR on trademark. It's up there. You can go read it. From the organizational point of view, we have to figure out how we're going to be organized and function. And we had a lot of people who came right after the fork and had very strong opinions about what open search should be. Should it be donated to a foundation? Should it be a self-organizing committee? What should be a contributor ladder? A lot of people started voicing the very strong opinions about what things needed to be. But we were not ready to have the discussion. We needed to get the project in a healthy state for contributors to come so we can ensure long-term development of this open source fork so that we can continue taking patches, security patches and things like that into our managed service. We were operating a business on top of it. We were building the open source infrastructure, but at the same time we did not want to ask, to be in a rush of answering things like governance. So we just said, is that the minimum? We said this is not the minimum and so we did not deal with those questions. Doesn't mean we didn't want to do them, but we said, we'll deal with those later. So for now, we're trying to do the fork, copy the code and get running fast. And while we're doing this, the amount of people that are added to the project as more especially senior people with business sense, they keep coming and they keep asking, why are you doing this? So you have to remind everyone again and again and again, what is the purpose of forking into open source? It is always considered in large companies as a risk, as a cost, as something you don't have to do. But we have to remind everyone that our goal is to create something sustainable, long-term for our customers, something where we can innovate in the very long run. It is absolutely true that once open source software has gained enough momentum, has taken market share, it is almost impossible to displace. It becomes the best software out there. It's very difficult to compete with a successful open source project. And so that's the kind of project we wanted in order for us to also continue building a business on top of it in the long-term. We want to innovate in the long-term and so we had to continue reminding people about that. Yes, it's going to cost a lot of money, but it's important for us in the long-term, take a long-term view of this. And then we needed to divide the land of all the things. So open search is two engines, dozens of plugins, lots and lots of things. So we said we need some infrastructure to support our operation, be able to do releases. We need teams for core engines at the very least. We have teams for plugins. And this actually existed before in the open distro for elastic search times. We had teams that were specializing in writing the K&N plugin or the anomaly detection plugin. And every one of these teams has an engineering manager with whom the puck stops. So why do we have that? That's a very Amazon thing, that's a very AWS thing. When we have a security problem or when we have something where we need to call the person in charge, there's a very clear escalation path. And this is why you can be safe in AWS's hands. We care about security and we have an escalation path to go upstream. And so we use that experience to say, let's have an owner for every one of these components. This is the person who will do the work with their two pizza team. It's a small team that you can feed with two pizzas. And then they have their destiny. They own their components from the beginning to the end. So we actually assigned an engineering manager to everything that we have out there and had an escalation path. OpenSearchCore was at the time 1.1 million lines of Java code according to CLock. So we're talking something like five million lines of code across all the repos, across 35 plus repos. So this is not a small thing by any means. And we POC'd every type of rename. We built some standards around conventions for the fork of how it's going to work. We made decisions about what is going to go in the distribution. We multiplied this across 35 teams and then we went and executed the fork. And finally, once we get the source code, we went and we did a thorough security review of the code. We did a thorough IP review of the code to make sure that nothing that was not open source because the code base had mixed code in it. We made sure that no non open source software and made it so we can have a clean slate from which to go forward. We set up obvious things that you do in an open source project like CICD. And then finally, we made the repos public. We had to figure out how to do common things. So the way of doing it here, I really appreciate the decisions that were made there. We have a .github repo in the organization that has all the common stuff. That's where you'll find a code of conduct that gets copied in all the repos. That's the repo that you inherit when a new public repo gets created. It has things like a friendly contributing document that says, here's how you would contribute in general to the project. And then every repo will modify it and tailor it to the needs. It has things like security so that you can trust that every part of the project has a security escalation path, and so on and so forth. Of course, it has the license, which is very important as an open source project. So there's a bunch of markdown documents in .github that are common for the entire project. For things that are common across some repos, for example, we have 2,000 plugins, and we have a bunch of clients. There's a client for every language. We have a repo called Open Search Clients, or Open Search Plugins. And in that repo, you'll find developer guides for all clients. And we're trying to level up the quality of all the clients across the Go client, the Python client, the JavaScript client, and so on and so forth. Hopefully, somebody will write an Elixir client, contribute it, and will be up to standard of all the clients. We work on projects like code generation across them so that all clients can have support for all APIs. So you'll find developer guides that are specific to themes in these theme repos. And you'll find some tools. We use a tool called Meta to affect multiple repos. Like let's say I need to update code of conduct everywhere. We never had to do that. But let's say I needed to. I could run a Meta tool, and then it would update all the repos at once. So it's super convenient. So we created all these common concerns and created repos for them. So everything went into markdown. And we worked completely in public for those. There are support systems with so many teams with only hundreds of developers just at Amazon. And you need common practices and common infrastructure. For example, how are you going to do branch protection? Should we protect main or should we not? Should we have a pull request that gets merged with a rebase? Or should we have it with squash? Should we have DCO, which is the minimum? I say that this is Apache V2 license. I'm authorized to contribute to this project. Or should we have something else? So all these common things needed to be set up. Open search documentation did not come with the fork. That was a trademark copyright that I'm sure what the exact terms are. But we had to start documentation from scratch for this 10-year-old product. And a lot of people are saying that documentation could be better, yes. And we've had to write it from scratch. We have to host releases and patches, create forums, websites, opensearch.org. All these things, every one of them requires someone to work on it, figure out how to do it, then publicize how it's done, and then iterate, iterate, iterate. Every single one of these things we found as we went and built. So we announced the fork in February. We went public with some repos in April. And we were able to release six months later, so five months later. So it took five months, hundreds of developers to do this operation, repo by repo, copy, rename, set up, all that stuff, do the distribution. So we learned one very important thing. Releasing small stuff is super easy. But releasing not small stuff is extremely hard. Not only had to figure out how to release this big distribution and wrote a tool that assembles a big distribution, but in the middle of it all, we got hit by Log4j. And Log4j was a massive event for a lot of people out there. And just think about, just AWS, forget about the open source project for a second. Inside of AWS, we are running millions of instances, EC2 instances, millions of instances of software that lives on top of it. And just about all of this is affected by Log4j in a big way. So it was all hands on deck. And every single service, every single component, everything had to fix Log4j, see if it's affected and so on and so forth and patch. Because we invested in automation early in open search, it was a breeze for the open search project. We updated Log4j libraries, and then we pressed some buttons and we released three full versions, three patched versions of the software after running all integration tests in something like a week. Every time there was a new vulnerability found on top of Log4j, we're able to release it. AWS also released a live patching tool where you could take an instance of a Java process and without shutting it down, patch a Log4j vulnerability in production in your running code, which is something that has been used across the world. We used it inside of AWS as well. So it's only one basic lesson. You just have to automate yourself out of the job right away when you fork something. You cannot be doing things by hand. It's insane. The first release took us something like two months to do by hand, and then we just understood that it's not going on scale. We automated everything. And so today, you too can go and check out OpenSearch code and build it from the top, all its components, and do a distribution. And in fact, the free BSD distribution is something that no Amazonian is involved in. It's done by a completely different group of people. I don't know even who they are and thank them. So a release of the product takes a village. We've automated. Every time a version is incremented in a main repo, we have automated pull requests that increment versions across all the dependent components. Then we also have GitHub issues that are being filed and that have a checklist, which is actually a template file sitting in the repo that humans need to go and check. Like, okay, are you ready? Are you feature complete for this release? And it has dates and has all that. That entire process on GitHub is done automatically, very proud of all the bits and pieces that went into there. And so one single release manager can observe that this is going well and can effectively do the work. And you can join the releases in public. There are public zooms of these. And you can see this process going on. It's mostly supported by GitHub. You don't have to join a meeting. You can follow it on GitHub as well. It takes a lot of components to come together at the same time. It's quite an impressive thing. For security, the topic keeps coming back, especially with Lock4J, which is a security vulnerability. We were very lucky to be able to leverage AWS in the beginning. And so AWS security and organization that is dedicated to the security of our customers has said from the beginning, okay, we don't know how to do this open source thing, but we know how to do security escalation. And so if there is anybody who suspects there is security problem, we'll help you. And so they were our response. You could email AWS security and they would have a process and respond to everything escalated within our organization as needed. So we piggybacked it and we didn't have to deal with it for a while. But this is something you will, if you fork you will have to deal with very, very early. You need to staff and document ways to respond to security. And I'm happy to say today this is actually a community process now. There is a separate escalation path of maintainers that don't work for all for Amazon. And when you report a security vulnerability to open search, it gets dealt with like any open source, any healthy open source projects. There's actually an independent report that was published two days ago that is an audit of open search processes and code. Very happy to see that it only found two minor vulnerabilities and generally commented that the source code and the state of automation and affairs is in a healthy state in open search. It's work that a lot of people have been doing for the last two years. Then you can go download and read this report. Security remains our number one priority and very proud of what we've accomplished. So now what? You've set up the project. You can report security vulnerabilities. You can, you have some community engagement. So you can just accept the contributions. Well, contributions might come, but most likely they will not. The truth is it takes a while for people to decide to go from I'm interested in the project to I actually have a business need to contribute to the project. So one of the big mistakes companies do is that they just don't staff up. We could have prepared the project, just did the dev rel part of it, the community, the engagement. Like here we are ready for contributions, but contributions would not have just come out of nowhere. So we seeded the community. We hired engineers to do the work and we worked backwards from our customers and we said our business needs a bunch of features and a bunch of fixes. So we're going to pay people to work on our business problems in this open source product. And we are hoping that others will come and engage with us. We also spent a lot of time, money and effort on using the same people to actually support those newcomers from the outside. So one of the things that happened that I was really pleasantly surprised is that many did not wait for governance decisions to come and contribute. Many folks did not stop at the limitations that were seeded at the fork. We weren't perfect by any means. They just started writing code. And so engineers from companies like Ivan came and started building. And you know what? They started building more. And they have a business that relies on the software and it's exactly the spirit of open source. If you have a business need, come and work on it. And we will help you be an owner of that project along with us and hopefully we can be the same. So people started noticing that the project is moving, releasing, things are happening, started contributing. They started opening pull requests. And so as soon as we saw real engagement from real engineers who are bringing value to the project, we immediately wanted to promote them to maintainers of the repos. So we had to figure out how maintainers would organize and so we let go of the maintainer process completely. And every decision we made in opening up more, we always consulted the community. We always did it on GitHub and it's true. We reserved the right for the final decision as existing maintainers of the project. And maybe we didn't have some of the elements of spelling out how we did it, but we consulted maintainers and we wrote it down in those markdown files. And so today, maintainers self-organize. And in order to become a maintainer in an open search project, it depends on existing maintainers. Some have contributor ladders. They say you must contribute three lines of code in order to be a maintainer. And others say it's just one person or two. So you could be a maintainer if you're just interested in maintaining. Or in open search core, you have to be a distributed system specialist. Have contributed a very complicated system to be part of that project. And maintainers are now groups of people and self-organized in public. You can read about it. It's a GitHub maintainer. So if you have a question about how open search project functions, just go and you'll find it there. So we started also taking some of the internal Amazon innovations and we started open sourcing them. We have a lot of experience running Elastic Search and Production for very, very large workloads. So we started funding the work of taking these innovations and open sourcing them around things like storage, segment replication. There's some really complicated stuff that has been written inside of AWS that never had a chance to make it upstream. And our goal is to have zero patches inside of AWS for the software. We want the data plane of the software to be 100% the same as the open source product. We just want to take it from upstream. And then large companies came and helped us with some of the complicated things. Intel contributed a compression codec that has a 15% throughput improvement. And I took them a year to bring it into the code base. But I think the result is quite impressive. So we're trying to form more partnerships. If your business has business needs and wants to contribute to the code base, we are there to help. We absolutely want you to have real skin in this project. Please come and we will help you contribute. So what's next? Once the infrastructure became stable and we could release, we saw contributors contribute. Great. Major features are being built. Now what? I think at some point soon, we're going to have to talk about governance. And we hope that there is some real partners that are willing to put some dollars and some people into this project and we can discuss what we do with governance. We do not intend to make this project an Amazon open source project by any means. We would like it to be a true community open search. We really care about that. So we are ready to start having these conversations. And so if you have opinions, start writing. Go to GitHub forums, slacks and so on and so forth. Should you invest in a fork? Let's see. You will make promises and you will make mistakes. It took us almost a year and a half to get a public slack. That is super embarrassing. I can't believe it took us so long to get something like that out there. Software is millions of lines of code and so forking will be hard. If you are in a large corporation like Amazon, 90% of your developers have never contributed to open source, they have no idea how to do it. You're going to have to educate them. You will absolutely need help from your Ospo, your lawyers to get any of this off the ground and contributors are just not going to come if you snap your fingers. You're gonna have to do hard work to do that. Stewardship of a project like this, 106 repos today, is a full-time engineering job. You need actual engineers engaging in source code all the time out there on GitHub in forums, continuously all day long. So let's see, how are we doing? I borrowed the title for this talk from a user who came and just opened the GitHub issue and titled it, fork it all if you fork it. And the issue was a little confusing after digging through what the user was trying to say. We helped them with their problem and I'm happy to report that a year after that issue, this person actually went and fixed a bunch of bugs in open search. That's amazing. Someone who was really frustrated from the very early days of open search became a contributor of the project. So fast forward and onward. We went from 73 repo, we've created 73 new repos in open search project. This ain't small. There are over 200 maintainers, tens of thousands of merged pull requests, issues closed, millions of lines of code that have been added to the project. So I'm not even counting the millions of lines of code that were deleted. We did over 100 releases of open search tools, clients, you know, all these things with many, many, many millions of downloads and lots of happy users. So I think it's a success. The measure of success that I use is the number of contributors. I've counted over 1000 contributors to open search and this is a live view of what open search is today. And about half of those contributors do not come from Amazon. These are non-Amazon contributors and this is a very proud moment and it's amazing to see that the community is actually engaging in the project and so many have written code or not code in this project. I also want to finish and acknowledge that the future is AI-driven and all those 1200 contributors are not going to be contributed for much longer and that AI is going to take over and we already see it. In open search, this work is also included the work of at least six bots. So please give a round of applause to the Panda Bot, to Jenkins CI, GCO Bot, Mend, GitHub Actions. These are important participants in our project as well. Thank you. I don't know if we have time for questions. I'm happy to answer some from the audience. There's any. Go ahead in the back. Your takeaways, are they the same if you do not have the financial power of Amazon? You know, the fact that you can hire engineers like, I won't say like that, but you have an attractiveness. People won't have, you know, if you are not Amazon, maybe if you are a small actor relying on elastic search, would not have been possible, no? So is your question always special? Is it just because Amazon is a large company? Yes, the fact that you succeed, is it linked to your financial power and attractiveness? Oh, great question. So the question is, is the fact that we are succeeding linked to our financial power and the ability to hire a lot of people? I'd say that, I'd say the answer, someone must pay people to do the work. I don't think we can get away from the idea. I never believe that open source is, that people do open source work exclusively for the greater good of humanity. Now I've contributed plenty of open source projects, which were not part of my job, but I've also contributed to many projects that are part of my job. So I don't think of open source as just a hobby. I want to work for a business that where open source is part of the code that I write. So for me, I think open source is cheaper. It is better, better quality, cheaper to develop. It makes complete business sense. It is just, for me, it's the difference between open source and open source. It's kind of like Java versus Go. These are choices we make. And if you want to have a sustainable business, building it on top of open source I think is a wonderful thing. So Amazon was able to fund development of this project, but it didn't have to be open source. It could have been closed source just as well. Someone will have to fund your fork. And I don't think just community engagement is enough. So if you depend on an open source project and it is much bigger than you, you must find friends, other companies that will be able to put real money into it. And so to finish the answer to your question, I ask other companies, would you contribute to open search? And I get two kinds of answers. I'm already contributing or I get, if I had a business need I would contribute. I rarely get other answers. I think in the end it's what makes sense for your business. Thank you. Can you talk a little bit about converting a large set of engineers who have never done open source over to doing an open, I mean like internal Jira and just talking to the guy next to you and all that. How did you change the culture? How do you change the culture of, especially in a large company, how do you change the culture so that developers who've never done open source contribute to open source? I think, first there are many motivations for a non open source engineer to contribute to open source. I worked for large and small companies and I worked for Microsoft and then I left Microsoft and I went to another company which had the exact same problem as I had inside of Microsoft and I had to reinvent the wheel again. And once you've done that a few times you never want to go and get the third job where you do the same thing again, you want to learn. So this learning, there's a lot of desire in the company to learn and do open source because this is the work you show. There's many good reasons to become an open source developer. In a company like Amazon, I think the key is educate and support and spell it out. So Ospo inside of AWS does a fantastic job being transparent available and being pragmatic about what's possible and what's not possible within a large company. And then you need, the leadership needs to understand why we're doing that. And it's never for the greater good of humanity. I think it's for the business. And the more you say it's for our business, it makes sense to our customers, I think the better it is. So you have to explain why you're doing this, create some kind of vision of why it's important and then educate and support people who are there. So I take engineers who've never contributed and I help them make their first contribution and then I tell them it's okay, it's going to be great and I'm going to be patient with you. I'll be the reviewer of your code if you need me to, if you have a problem, come talk to me, we can do it in private. I can help you if you don't understand something, there are no dumb questions. All the good stuff of any collaborative engineering team. I don't think open source is anything particularly different actually, except that you work in public and so you can be seen. It can be difficult for many people. There's another question right there, just pass the mic if you don't mind. Thank you. Even now that the open search project is a success, it's a successful project, did you still get the internal question of why are we doing this and why are we not building in private? Even though, so the question is, even though open search is successful, do we still get the question of why we're doing it? Well, first important thing to say about Amazon is that Amazon always asks questions. In fact, my job inside of AWS is to be a contrarian. When somebody says, I'd like to do X, my first question is what are the reasons to do X and then what are the reasons not to do X? I'd like to compare the two and then we pick the right option and that culture is very healthy because you can change your mind. You can have something that you've been doing and then if you think it's a mistake then you should absolutely be able to change your mind and just not do it afterwards. So yes, there's always people who ask why are you doing this but they don't ask it because they have a preconceived notion that it is bad, that we should not be doing it. They are asking because they are curious and smart people and they just want to understand something they don't understand. And so yes, you have to be prepared for answering the questions like, should we stop doing it? Now the project will continue existing it's an open source project but of course if we stop doing it it would have a negative impact and the first people it would have a negative impact on is our customers. So of course we're not going to stop doing it for as long as our customers are asking for it we'll continue doing it. It makes business sense for us. Absolutely. I encourage everyone to have a healthy critical way of working with others where different opinions including ones that seem completely bizarre to you can be voiced and where you can change your mind and make different decisions. Yeah, I love to talk to anyone who thinks that we should fork in private. I enjoy those conversations. I take the person who disagrees with me completely and then by the end of the hour I hope they walk away and they start thinking maybe I'm missing something. I heard good arguments. Like now I'm a, I turn your biggest enemy into the biggest fan. That's the opportunity. I probably don't need to convince people here that open source is a better way of doing things but definitely inside of out there. I have to convince my dad that doing open source is a good thing. He doesn't get it. He's like, we come from a communist country. Like why would we be doing open source and giving it away to the greater good of everyone? It has never worked for us. Anybody else? No, do we have time? I think that's it. Thank you so much. I'll be here. Please feel free to come and ask more questions in person. Thank you.