 All right. Good morning. Good afternoon. Thank you for joining me today. My name is Andrew Akin and I'm the global open source practice leader for Wipro. I'm really excited to share this topic with you today. I hope that you each and every one of you is able to take away a few tidbits that will allow you to do your open source planning, a little bit more efficiently and effectively. So there are obviously a whole bunch of ways to do this, but I wanted to share a model and approach that I and my team have developed over the years. But that is that really help will hopefully will help you be able to get at some of the core decisions pretty quickly. This is not a very detailed sophisticated approach. Obviously it's a complex topic. And there are many, many elements that go into building an enterprise wide plan. We're going to tackle just one aspect of it today and that's how to leverage open source to help drive some of your key initiatives from a planning perspective. Just a second here, but the slides doesn't seem to want to move. There we go. All right. So for those of you who may not be familiar with with Wipro, we are one of the large global systems integrators around 9 billion in revenue and over 180,000 employees. What's more, more relevant here is we have a we have a lot of rich deep experience in open source coming from hundreds and hundreds of different projects across the globe and across all domains virtually. So I've been an open source for about 22 years now. I did launch the first open source strategy consulting firm way back when ran that for 11 years and then sold it to black duck software. I also launched the open source think tank, which was an annual event held in not the California and Paris France. Each year where we brought in 120 of the top open source thought leaders to really just kind of brainstorm on how open source was evolving the opportunities the challenges and so on. I have had the opportunity to work on a couple of hundred different projects for most of the major OEMs and ISVs for 20 or 30 different open source and proprietary software startups and certainly for dozens of large enterprises. So have a pretty good background on the topic here today and hopefully that that comes through for you. Why are we talking about building an enterprise wide open source strategy, especially when enterprises have so many other strategies whether it's around your digital transformation journey, legacy modernization, moving to the cloud. Well, there is one key factor that underpins all of these, and it is, it is open source is the core building block for all these major initiatives that happen today. And so if you're not treating it strategically and planning for it, then that can certainly have a resulting negative impact on some of the other key initiatives in the organization. So another another way to kind of determine why this is important to to build an open source strategy is around what we hear from your peers. So my team's been very careful over the last couple of years we've been asking your peers why they're investing in open source why they stay with open source why they make more and more commitments to open source. And so this is what we hear from from our clients this is not what we say this is not what analysts say. So open source really does have the ability to drive innovation in the enterprise. It also allows you to fail fast, which means that you can try something if it works that's great. If it doesn't, you can move on quickly with little to no repercussions for doing that. It allows your developers to get productive much faster we have one client that calls this zero day productivity. So they've identified they've defined that how an open source developer becomes more productive on their open source based applications versus those that they hire to work on their complex package proprietary software applications. Open source also allows you to recruit and retain your best developers, and it can have a very positive impact on your brand and overall reputation. So the one talk about a couple of assumptions that we can make as it relates to building an open source strategy. One is at a very, very high industry level. We hear frequently everyone wants to be a tech company. And one of my favorite actual taglines from a client of ours, not in financial services but I thought this is pretty interesting is today, we're a wholesome food provider, but tomorrow we want to be a technology company offering innovative protein foods. My view on this is that some some companies can take this just a little too far. But for those who do who are trying to make that transformation to becoming more of a technology organization, many of them are calling out open source as one of the key strengths to help them to do this. So, some more direct or relevant assumptions that that we can make. Today, you are almost guaranteed to be using more open source than you think you are, regardless of whether or not you have a strong governance program. You're going to be using more in the future, then you think you will. Today, open source is becoming more of a strategic imperative within your organization as opposed to simply a set of tactical IT component components in your IT infrastructure. Growing a community is is hard, and that's not likely to change. This is the cost pressures on your organizations, and we're all members of what I like to call the Baskin Robbins enterprise so Baskin Robbins favorite tagline is they have 31 flavors one for each day of the month. Well, when we get involved with with large clients large enterprises financial services organizations. I like to call this because every line of business, every development group has their own 31 flavors of open source that they want to use, which makes all of our jobs a little bit more complex. So every organization is on an open source journey today. It's important to understand kind of where you are in the attributes of where you are on your journey on a maturity curve. This really helps with the planning exercise so we're going to talk about that, identifying that where you are a little bit. So, excuse me, a part of being on on this journey is always about the value you derive from open source versus the amount of effort that you pull in. The model that we've that we've built over the years it's it's a set of buckets of characteristics or attributes that we've observed from from obviously open sources kind of famous for being grounds up or ad hoc. When the organization begins to realize that open source is important, they begin to try and implement some policies and processes, then they begin to try and spread this across the organization to become a bit more directed and active. The next step is beginning to internally and externally collaborate to create business value. And then the last stage is kind of realizing realization of the full benefits of open source their leadership leadership is involved. And so on. So it's also important to understand that an enterprise can be on multiple points on this maturity curve or this or this journey. Frequently, it's the case that when we get involved with with companies, a one line of business may be farther towards the left another line of business may be farther towards the right. So that's just kind of the nature of having a global distributed enterprise today. And so you may need to go through an exercise of identifying where each line of businesses, and then helping create kind of a lowest common denominator across the organization. Each one of the stages of this maturity curve, it can be broken down a little bit further into a set of attributes that are associated with with it. So at the end and these attributes are broken down by the constituents, the developers, the operational the support folks legal procurement security HR and so on, a set of capabilities. The, how value is created in the organization and the overall organizational leadership and culture. So, for example, the ad hoc level developers are certainly beginning to use more and more open source. Typically, operations at this point are unregulated capabilities are very uneven or sporadic across the organization. I'm not really aware of how value is is actually being created or what that value is. It's typically individual developers that find a cool technology that solves a particular problem they have in that moment. You may not see some value but there's no organizational understanding of how that value is being captured and and behaviors tends to be a bit bureaucratic and and somewhat unreasonable at that point because there's typically lack of a lack of understanding that's going on. So as you move up the maturity curve you move a little bit farther to the right the attributes obviously begin to change a bit. Talk about the collaboration when you when you begin to reach that collaboration level developers are beginning to work together to co create value. The operations at that level or to there's probably some sort of automation that's involved there's detailed processes and policies in the training program and so on. Your developers are becoming more and more skilled their active contributors at this point and you can actually see both individually and collectively their skills are growing by being more engaged in open source value creation is more in integrated across the organization. Groups are beginning to work together more closely to either drive more innovation to reduce your technology debt to reduce costs, whatever the focus is. And now we're beginning to have a culture that's beginning to become more open transparent collaborative. And you see, again, a more and more executive leadership at this level also. So again, this is, this is a way to look at how to understand where you are on the maturity curve and the certain attributes that are associated which with each step. Let's get started let's let's spend a few minutes on on going through and kind of building a sample decision support model for around open source here. So, obviously, you have to start with what you're trying to achieve. And here are some common, common aspects of open source of what people believe that open source can help them impact, create new revenue models, reduce and improve innovation, improve the brand and reputation and developer productivity so it's really important to start by trying to understand what are we trying to achieve and in most organizations you're trying to achieve one two or all of these. We're just going to go through one today. And I'm going to pick brand enhancement one of those kind of squishy things but we do hear this in almost every engagement we get into today, our clients want to improve their brand or improve their reputation and they think open sources and wait to do so. So, okay, let's talk about why. First thing problem statement I've crafted one here so our customers don't perceive us as providing modern or innovative banking capabilities. Pretty simple and straightforward. We have heard these exact words used a few times maybe resonates with some of you, some of you in the audience today. Let's let's break that down a little bit. And I like to use very simple root cause analysis models, very, very simple but let's say we've gone through that process we understand well actually, we're not that innovative but we don't have a strong ideation model in in our in our technology teams. Even if we did, we don't actually have the capability to technical capability to bring those to market fast enough, or effectively. And we feel that either we need to add new people we don't have the right people or we need to up skill the current people's resources so these are the three underlying issues that I've identified for this particular exercise here. And obviously very important at this stage, you have to create a baseline. You have to know where you are today you have to understand you, and we, and this is actually fairly common. And then we would like is people understand the people come to say we have to improve our grant. Okay, great. Why we get to these points by how much in what areas across what domains with what customer segment, so on and so forth. They don't have the answers they just know they need to improve their brand. Okay, so it's really important that at this stage, create a baseline there are lots of models and methods to do that. And surveys SEO, a variety of different softwares that will help help do this, whatever it's important before you go further to understand where you are today. So, let's talk a little bit about how you're going to improve improve your brand. So how are you how are you going to achieve this well, there are four levers of open source. One is how you consume open source how you ingest it how you acquire and how you operationalize your use of open source across the organization that's one. Second is how you contribute, and this is specific to how you contribute back to existing projects. The third one is around publishing that's simply about open sourcing your own software. And the fourth is what we call embed or using open source development best practices inside the organization so it's not about the technology. It's about the methods and the approach and how open source the model of how open source software is actually built it's commonly referred to as inner source today. So let's go through a little bit of an exercise here because we want to start breaking this down a little bit a little bit further. So, let's, let's, let's see if we can apply the levers of open source to the core underlying issues that we have that we've identified around helping drive brand enhancement. So, when let's talk about for innovation does consuming software drive innovation inside the organization. Yes, it does a little bit. Because most or many times organizations are simply just consumers of a packaged or community open source and so mild effect. Does it help drive technology improvement or enhancement it certainly can. It doesn't mean adopting the latest relational data open source relational databases really going to make you innovative. But if you adopt enough open source new innovative modern open source technologies, your overall organization will become more technologically competent I'll say, right. And does consuming open source really help drive the growth of the people category here. Again, it can, but may not have as large an impact if you're just pure consumers. So if you contribute to existing projects. Does that help drive innovation. It can. It may be more tactical contributions then then really innovative. So, yes, no. Can it help improve the technology in the organization absolutely if you're contributing back to existing projects. It typically means that you have developers or contributors who pretty well versed in these technologies, and that this can really help. Again, uplift your your own technology category here and can it help drive some of the people goals you may have tied to brand enhancement absolutely. Then we come to publishing, you can see that's fairly strong across all the categories obviously if you open source some of your own software, you're hoping it's innovative may not always be but there should be there's probably some very good reason for open sourcing it. And that generally innovation is a component of that. The technology perspective absolutely publishing your own software as as an open source in our observation typically means that the organization is beginning to overall increase their technology capabilities. And certainly it can enhance some of these, the people, the people category here because your people have to be domain, they have to be technology experts they have to be domain experts they have to be open source experts. You're really beginning to to reach some of those brand enhancement goals that you want to. So, last category is embedding or inner source. Yes, it can have this. It really does help drive innovation as your organization becomes more collaborative internally. I've absolutely seen this result in increased innovation, not just actual innovation but pace of innovation. So certainly can help achieve those goals from a technology perspective, it's a little bit less about the technology that is is about organizational cultural innovation so a little bit less there. But again, it will have an impact on how your people can help drive some of these brand enhancement goals so this is one way to to look at the how the levers of open source can meet the can can address some of the underlying issues of your overall goal which in this case is brand or reputational enhancement. So one more, one more exercise to go through. Now we have this, we have a premise at this point we're going to kind of test or the premise a little bit so. Now we can say by contributing to existing open source software projects, publishing your own software as open source or embracing inner source, you can address some of your brand image and reputational goals. So this part begins to get much more specific to each and every individual organization. So what I mean by that is, let's look at what each of these, the pros and cons of each of these different open source levers. So, contributing. Well, if you want there are lots and lots of projects out there that you're that your people can contribute to. It's typically less expensive than some of the other methods to do so. And you likely have more internal resources who can actually contribute to exist existing open source projects. So the con is in this instance, it's really hard to stand out and just look at this just take the CNCF the foundation where Kubernetes resides and the whole kind of Kubernetes ecosystem. Excuse me. There are hundreds and hundreds of projects in there today. There are what over 45 million projects on on GitHub. So it's, it's not easy to really pick the right project and stand out in that in that project. So the impact is probably going to be lower. So let's look at it. Let's look at publishing. If you open sourcing your own soft software, obviously you're going to do that because you believe there's a higher impact and typically there is. The question people is, you know, no matter your who you are, your brand, your position in in the ecosystem today. You're most likely to get lots and lots of interest right after you open source something, but don't get fooled or conned by that, because you have to make sure that you have a really solid bulletproof plan. Keep capturing that visibility and growing your community for at least the next 18 to 24 months and 24 months is what we tell people today. You have to be the core driver of some of these initiatives for at least a couple of years. So the basis to the cons here can be very expensive to open source some of your own software, and it can take lots of internal resources, not just the developers, but legal security, marketing, HR procurement, and so on. So it does take a, it does take a big effort to be successful here. It's, there are some good examples out there, but it does take a big effort. So, inner source. So we know that it can help drive does drive innovation, and it does bring about internal cultural and organizational change does help an organization become a little bit more agile, a little bit more collaborative. But it is typically hard to accomplish. And it does take a long time. So we're talking about the enterprise here not a single, not just one developer group or one line of business but we're talking about an enterprise so to really promote this across enterprise it does take a bit of time. This is an approach or a model you want to just keep taking the overall goal that you've identified can be as opposed to brand, brand enhancement it could be reducing costs, or driving more innovation as the as the higher level goals but you can. The idea here is to apply this approach to break it each step down a little bit more into its constituent parts until you get here. And then again this, this is where you begin to apply very specifically your own organizations, characteristics or capabilities. Some organizations have, you know, more developers they can apply to these efforts they may have more budget some have have less. Some are already are down this, this organizational cultural transformation path so it's a little bit easier to say drive inner source more enterprise wide. And so this is where you really have to apply your own context to this particular approach in model. So want to wrap up with just a few tips that that I've, I've generated through the work I've done over the years. And these are really, really want ones that are important to the success of open source across the enterprise. Okay, so, please take these these with a degree of seriousness so engage the right stakeholders early on in the process at all levels. So, understand it's important to actually understand who am I going to need to not only get this plan done, get the resources to get signed off on this plan to get the resources to execute this plan to get the resources to actually support the outcome of this strategy. And think about, you know, the functional groups also HR procurement legal so on, and get them engaged early in the process. Really, really important. Engage everyone in the community itself this may seem a bit a bit counter intuitive for some of what we call the functional operational groups such again as HR legal procurement. But it's important to get them engaged in the ways to do that are obviously get them involved in the planning process, have them experience the community have them participate on it on events like this have them participate in users groups. There are even whether there are a whole bunch of users groups are out there that aren't just developer oriented there are some that there's a legal open source community. There is a community loosely tied to procurement and security, but try and get everyone engaged in the process. It really helps smooth the decision making process here. And very, very importantly, don't skimp on governance governance, you know, my definition of governance is simply the open source lifecycle component management, which includes again, how you ingest policies and processes and automation and tooling that help manage open source from how it's ingested in the choir, how it's governed so how are you validating security issues, how are you validating licensing and IP potential issues or conflicts. How are you managing a version proliferation, how are you managing production support and so on. To address this early in the process. It's, you know, no one wants to do governance you do governance because you want to get at the actual benefits of open source, right, cost reduction innovation, whatever the case is, but it's really important to have a sound foundation here can't stress this enough. Most enterprises are using 510,000 or more open source components and you can't manage that effectively without without automation and without policies and processes. So please, if anything, pay attention to that piece get that right. It's early in this process as possible. I would like to say, you know, tell yourself or recognize that this is hard, but it will be worth it and tell you yourself that as many times as you need to. So, thank you for for joining me today. I am happy to answer any questions. I am not able to see them so Emily if there are any questions, please let me know. I don't have any questions just yet, but we'll stay on a few more minutes and see what comes in. All right. Well, hopefully, the fact that there are no questions means that this was a very simple and straightforward process something that you'll be able to to apply as you go through your own planning exercises here. I'll be on the event slap channel in a little bit and happy to answer any questions there or, or please feel free to reach out to me directly. Thank you Andrew there's a number of thank yous and congrats interesting and really useful insight. Okay, good. Thank you everyone and I do appreciate your time today.