 Hi, everyone. Welcome to this session on how to execute open-source software products. My name is Saikur Banerjee and I'm an engineering leader here at AWS. In this session, we are going to talk about how to think about open-source products. The reason I've been invited to give this talk is because for the last one and a half years, I've spent considerable amount of time thinking about how to build open-source products, how to contribute more to open-source. I am part of EC2 Windows team in AWS and me and my team, we focus specifically on .NET open-source and how to make that space better, how AWS can come in and contribute to make the community more richer and with more engineering contributions and community engagement activities. So with that, let's start. So before we begin talking about the session, I want to introduce myself. So as I mentioned, my name is Saikur Banerjee. I live in Seattle, Washington. I studied computer science from West Bengal University of Technology in India. Then for nine years, I worked as a software engineer and as a consultant in different companies, starting with Cognizant, moving to PWC and then joining ESports as an SDE and then spending a brief time in NCR technologies, finally joining Tesco as an architect and then moving on to SDM role. And then after nine years of experience in India working on different types of roles, I came to the US to do my master's in engineering at MIT and I focus specifically on supply chain systems and analytics and sustainability areas that affect the supply chain technologies and supply chain companies today. Then after graduating from MIT in 2020, I joined Amazon and has been working in Amazon since. So let's get started with the session. So here's a brief agenda I've created to orient ourselves for the short session of 30 minutes. So we'll start with a brief history of open source, where we will talk about where we started, where the industry started with open source projects and where we are today with the GitHub revolution that we are seeing unfold. And what made us make this giant leap from where we started to where we are today? It's very important to understand the history to understand where we are headed and we will talk about some of that. Secondly, we'll talk about enterprise open source software. Why are enterprises interested in investing in open source? Why are enterprises interested in not only contribute code to open source but also to support several of the foundations that are there that support open source development? So we will talk about some of the benefits that enterprises get in shipping and maintaining open source software but also we will touch upon the impact areas that enterprises see today that if they do not contribute to open source, what are going to be the ramifications in terms of the business and ROI of the overall product proposition that the enterprises have? Thirdly, we'll talk about how to think about open source product strategies, how to think about customer problems and aligning them into a product or a suite of products and then thinking about an overall open source product strategies. This product strategy is not restricted to just engineering product strategy or just the engineering contributions that build open source product but this also has a community engagement element to it. How do we engage with the community to make the community better, make the community more involved in problems that affect the audience or the target market of that community? So we'll talk about how to shape a product strategy. Fourth, we will talk about how to execute open source products from an engineering standpoint. What are the processes required to develop at scale? Mind you, we are developing with individuals in open source whom we have not met. We have never met them. They're not part of the company. The open source product is released from. So there is an element of trust that needs to be programmed into the operating procedure in terms of set practices or the best practices of a standard operating procedure and how we manage each of these interactions as we go and how can we do so in a performant manner? So open source by definition is a very speedy way of developing something because of the multitude of people in the community involved in a project and that is one of the good things of open source. How do you manage that with good processes in place so that you do not mess with the speed of operation but at the same time maintain the trust in the development process? And finally, we will talk about some nuggets of advice that I have picked up in these last one and a half years. There are certain challenges and certain opportunities that come out of these challenges how to manage open source strategy. So I'll talk about some of those in terms of how to operate in an open environment and how to get people along with you in thinking about open source and contributing to open source ecosystem. So with that, let's get started with a brief history. So brief history of open source. Believe it or not, the first open source software that was shipped was in 1953. It was the A2 system and there's a whole Wikipedia page on this where I learned this from and at that time there was no internet. There was no GitHub. So what defined open source at that time? So open source was defined as software which shipped with access to the source code. So the A2 system was shipped with its source code along with the system that's the software itself. So by definition, the people who got their hands on the A2 system were not only able to see the source code but were able to expand on it, were able to extend that source code to their needs and tweak the source code to their needs. And I think this part of open source software has still not changed. A lot of open source software even today, like the heart of open source, open sourcing a software is accessing its source code and the reason developers can access the source code makes it very interesting because then the software itself can transform in the hands of different developers. And this nuance of open source software has kept us here even today. And today these numbers are from the GitHub surveys that happen every year and they get launched and then several other surveys that come out. So in 2020, 94 million developers built open source software on GitHub. 413 million open source contributions has happened in 2022 and 90% of the companies use open source today. So how are these numbers relevant? So why are these numbers relevant and why are these numbers important? So if you look at the industry today, most emerging technologies are coming first to open source. Take any large industry shifting technology that has happened in the past have come through open source. Be it the web technology, the whole JavaScript revolution that happened happened in open source be it Node.js or the UI frameworks around AngularJS or ReactJS happened in open source. Secondly, the machine learning area is just blowing up with lots and lots of Python packages and tools that are coming in the space all in open source. So Python has clearly seemed to have won the race with other scripting languages such as R and Octave. They were good statistical like languages that provided statistical functionalities, but Python packages have proliferated in the open source and are just aiding more and more in the AI and machine learning areas. Similarly, the area that I'm most familiar with and I run at the team here at AWS is around .NET open source. So even .NET is open sourced in Microsoft open source .NET in 2014. And since then, eight years, now almost nine years has passed. .NET is open source and the community has seen an explosion in the number of packages that are available today in the .NET ecosystem. So overall, we have come a long way and I would call it like a giant leap just like any other thing. Like Internet has obviously accelerated some of the open source development with GitHub and BitBucket and other open source repositories that are available out there. But overall, open source has accelerated the pace of software development and have accelerated the access to technology for the common people. Now, let's talk about why are enterprises turning to open source? In this slide, we'll talk about two areas of focus for enterprises. One is what are the benefits from open source that the enterprises are looking for when they are contributing new projects or contributing to existing open source projects? And we'll also talk about why are if enterprises do not contribute to open source, what would be the impact of that? So let's start with the first one. Multiplied effect is a very basic benefit of open sourcing a project. Say if you're working on a customer problem and you have a backlog of items that you want to develop into that product and you just have your own resources and an organic headcount, organic incremental headcount over the years that you can invest in that product, you will only be making so much progress. But if you open source that product and open source that project with the roadmap, say on GitHub and if that project resonates with a group of individuals or even one individual in the open source community, they can come in and contribute code to your project. That way, you are kind of short circuiting to the end state or the not star of that project of building the number of features that you want to build for the customers. Sure, along the way, the definition of the project can shift. It depends on where you want to take that project in open source and how you want that project to transform itself, given the needs in the community and in the customer base that the project is catering to. So multiplied effect is a very common use case that many enterprises open source their software for. Second is taking benefit from the latest innovation. Like we discussed in the previous slide, a lot of innovation is happening in the open source. The JavaScript revolution, the AI and ML revolution, the dot net space is all bubbling with innovation in the open source space. On the flip side, if you have a proprietary software, you are basically shipping every quarter or semi annually or yearly release. And many of the projects over the years have developed, but the pace of innovation is slower. A very common example of this is the features in an iPhone and the features in an Android phone. Usually, many of the features in an iPhone are approximately three to four years late than the features on an Android phone. One of the reasons being that Android has an open source developer base that contributes to some of these features which are coming eventually to the smartphone world. Third, enterprises are increasingly looking at open source as recruiting avenues. Say for example, you have a project that uses a niche technology, let's say Rust and not really a niche technology anymore, given its popularity, but say still in the enterprise world, Rust is still new. Now, in that Rust project, you're at a point where you need to hire a senior developer to think beyond that project and expand that project out. So you are looking for an experienced Rust developer who has had significant experience in developing projects using Rust. So traditionally, you would go to a recruiter or your recruitment team and give them a job description and hey, go find this individual for our team. Now, they will go and look for areas, different places and collate that information and bring you a list. But what if you or any developer in your team went and scoured the Rust repositories out there in GitHub and found the contributors who are writing good quality Rust code in their projects and have been doing that for a while because you see a history of contributions in the open source from that individual. So in that case, you just short-circuit the recruitment process and many of the enterprises are doing that today. Similarly, you share maintenance costs through the community involvement. So any project you have to maintain after the initial fanfare of releases, you need to patch the projects, make bug fixes, update the packages. So all these have engineering costs associated with it. If you build a rich enough community around the project and then create gatekeepers and create people who are responsible for the project, these costs are taken care of by themselves. Similarly, the overall uber cost of a project comes down because there is the community who's contributing to your project. Now, what are some of the problems of not investing in open source or not open sourcing something? So 82% of IT leaders are more likely to select a company as a vendor who contribute to open source. Similarly, IT leaders believe that open source is almost as secure as closed source products just because there are more number of eyeballs looking at the project in the open source. And finally, some of these top use cases that enterprises are investing in open source for are IT modernization, digital transformation, app development, and app modernization. And some of these I'm involved in myself in them at AWS. So these these data points and these perceptions are through a survey done by Red Hat called enterprise state of enterprise open source moving on to how to create an open source product strategy. So some of some of these areas I'll also color them with what we do at AWS in our team and how I have been getting involved in this space. So at AWS we always start with customers and you should do start with the customers and the customer problem. Then figure out, do you need a product or do you need a suite of products or do you need one year of investment? Do you need five years of investment? And then come back to our strategy, which you'd call an open source product strategy if you will. And that will stipulate what is the vision of your open source strategy in the overall suite of products that you're going to launch over the next few years. So the first thing to do is to start with the customers start with the problems you're trying to solve. Second is evaluate whether or not to open source the product. So this is a very hard thing to do because you need to like there are many aspects to consider not only in terms of the cost of open sourcing a product. There are several costs to open source the product, not just the benefits, the benefits we just saw, but there are some costs associated with open sourcing a product. By open sourcing a product, you are unofficially agreeing to maintain the standards of your development out in the open. You are responsible for all the contributions. If you're the owner of the product, you're responsible for all the contributions that are coming into your product, be it from a quality standpoint, a security standpoint, the code quality standpoint, and several other such aspects. So there is an overhead cost of maintaining an open source project. Secondly, there's a competitive aspect of innovation. One is that as you are innovating in the space, are you concerned that your innovation will be used by some other company and how you will manage that eventually? Sometimes we see that even though the competitive aspect is clear that that project might be used by competitors, but in the long run, it is beneficial to open source a project and we often prioritize the long term over the short term aspect of open sourcing a project. But having said all that, it's a deliberation that needs to happen intentionally while defining the product strategy. Third, you need to understand the community you'd be operating in. Every open source community is different, although they are tied with a set of values. For example, open source would be free. Open source would give you access to code. Some licenses would give you access to redistribute code, extend the code and stuff like that. But it is extremely important to understand the community you're operating in. Dotnet community is very different in its way of operation from the Linux community, for example, and things like that. And you need to consciously think about the engagement goals that you're taking up by being part of that community, by being a responsible member of that community. Fourth is create a standard operating procedure. So, your product strategy is incomplete if you do not have a standard operating procedure to react to things as they come in the open source and to set clear processes, clear boundaries in the things that gets pushed into open source from your company. It's extremely important to create a standard operating procedure at a product level, at a product strategy level, and will come down to what it entails for having a standard operating procedure at an engineering level. Fifth, establish the impact and define success metrics. This is one area that when you're starting out in open source projects, it's extremely hard because sometimes the project is new and you don't know how to measure success of your project. If you define adoption goals, then how does your adoption goals change over time? How does your feature goals change over time? And how does your metrics change over time? And what do you define as success? How does that change over time? So, all of that needs to be at least thought out and an intentional plan needs to be put on paper. And finally, execute. And this is where we will come to the engineering execution of an open source product strategy. So, talking about engineering execution of open source products, what are the key aspects of this engineering execution? So, identifying key technical collaborators is crucial while going open source with a project. Maybe there are several permutations here. First, maybe you are creating a project in-house and then open sourcing it into the community. While you're developing the project in-house, you need to maintain the architecture of the project in such a way that it is contribution friendly. For example, if you have a project that solves one problem, but you have six different projects that cater to that problem, it might be very jarring for a new contributor to come in and contribute to your project. So, that is just one use case. Another use case might be you are just starting the development out in the open. So, you're not only shipping an open source project into GitHub, but you are starting development in GitHub. And then you're trying to rally a community behind that project depending on the use case you're trying to address. So, overall, it's very important to identify the key technical contributors, both internal and external to the host company. So, one area that we kind of go through in defining .NET open source projects in AWS is that we work with a lot of partner teams across AWS. So, we are often solving a customer problem that needs open source contribution to another component that is owned by the other away team. And we call it away team in AWS, and we do a lot of away team work within our team. Second, this is again creating a standard engineering operating procedure. What does this operating procedure have? So, the product strategies, standard operating procedure, the primary element would be the pros and cons of open sourcing something. It's a one-way or two-way door decision. Usually, open sourcing software is a one-way door decision. And so, it's not that you don't make one-way door decisions, it's that you make those decisions after a lot of deliberation. So, for an engineering standard operating procedure, the things to look at are branching strategies, how you manage your branching, how you manage the branching of external contributions versus whether you maintain a sync of that code internally because you want to be sure of the security aspects of new code that is coming into the project, how you manage the scanning and the source code management, how you do testing, what kind of packages are you using for integration testing or unit testing of your project? And finally, coming to contributing to open source. It's not just having just the own project that you are open sourcing, but it's also important to identify new features and bugs in existing open source projects. I mean, being an active open source citizen doesn't always mean that you're shipping your own open source project into the community, but it's also how you make the community richer by going in and fixing some of the existing issues that are there in existing projects. For example, this year we fixed a bug in the .NET runtime. Actually, it was not a bug, it was a feature that we added in the .NET runtime around static linking for native IoT. And we did that to contribute back to the .NET community of developers. Similarly, we need to be sure and conscious about how we accept external contribution, what goes in and what does not go in. We need to be very intentional about it to maintain the standards of the software and documentation. Open source projects needs extensive and well-written documentation for new contributors to come in and develop in your ecosystem. So with that, we move to the final slide about some of the nuggets of advice that I can give you based on what I have learned over these last one and a half years of operating in the space. Managing expectations at your company is extremely important if you're starting something new, be it open source, be it any other project. Leaders understand the relevance and importance of open source, that is why you're able to even get to that point of making that claim of starting an open source project or starting an open source product strategy. But it's also at the same time, you need to be conscious that this investment is coming at the cost of some other investment. Basically, there's an opportunity cost associated with anything. Similarly, there's an opportunity cost associated with open source development at your company. And being conscious about that, you need to think backwards from customers and work backwards from customer requirements how you define your projects and what are you investing in when you're saying that you're investing in open source. Obviously, open source comes with its benefits, but we need to be conscious about making good and true investments in open source, both from a company's perspective and also from a community's perspective. You need to be conscious about your actually solving a valid customer problem. At the same time, you're fostering a community by supporting the community. So there's a lot of stakeholder management that is involved in open source development. And along with the stakeholder management, it is not just the product management group or the engineering group, but there's a lot of stakeholder management around legal, around marketing, around developer advocacy, around solution architects, where you work with different people to make this product strategy a success. So stakeholder management is key. Oftentimes in many companies, including in AWS, you have set guidelines in terms of how to react to open source tickets, what are the SLAs that you have. And there's a central team managing these expectations as well. So as a service team or as an open source team, you need to interact almost regularly with the open source team at your company who defines some of these best practices for your benefit. And finally, community support is crucial. When you are operating in a community, it's your responsibility, as it is mine, to act responsibly in that community. You're not operating in open source just for the sake of it. You're operating in open source. The core principle behind operating in open source is working with the community and fostering that community to build your project and to build your project in a way that best contributes back to the community you're trying to contribute to or you're trying to build that project in. So my last point is that just act responsibly. You are out in the open and it's very important to actually work very responsibly in the community because it's for a good reason that the open source community is very vigilant of bad actors. And rightfully so, if the open source community isn't vigilant, there are many ways to abuse open source projects. And I think it is extremely important that we act responsibly in the open source community. With that, I thank you for your time and thank you for listening in today's session. And feel free to connect with me on Twitter or LinkedIn. I'm usually very responsive of comments. Give me a feedback. Thank you. See you next time.