 Open source has the potential to drive transformation and innovation in an organization, but many companies still have questions on just how to intentionally and strategically maximize their open source investments to achieve those objectives. It isn't just about the technical side and the decision to use open source software to support and grow your business. It's about also embedding value into your business. Really the why about why you're doing this in the first place, as well as the cultural considerations for your teams and the value that you put back into the community. We're going to talk about how you can use these levers to help drive innovation in your organization through open source. But first I'm Tracy Robinson I'm with GitLab, and I'm a technology go to market strategist, meaning I bring people ideas and resources together to create develop and take to market innovative technology solutions. I'm always looking at how businesses can transform to meet the needs of tomorrow through technology people and processes. So let's take a look at the obvious question. Why adopt open source software in the first place. According to a recent industry analyst study, nearly 70% of enterprises report open source is very important, or is a mission critical enabler of digital transformation initiatives. There are myriad benefits for adopting open source. It's helping organizations with achieving faster time to market and it's providing more efficient, more secure innovation. It's also helping to deliver a better developer and contributor experience that translates into happier employees and retention, which in turn reduces cost. It also provides a better customer experience and offers a greater flexibility and interoperability and many organizations state that open source software is also a significant part of their cloud migration initiatives. As a recent McKinsey McKinsey report described the biggest differentiator for leading companies in an industry vertical was open source adoption, where they shipped it from being just users to be active contributors. The reports data shows that for companies in the top 25% of their developer velocity index, the DVI, who adopted open source, that adoption had three times the impact on innovation than for those companies in the bottom 75%. According to McKinsey, building an open source culture is about more than using open source software within the code. It extends to encouraging contribution and participation and the open source community, as well as adopting a similar approach to how code is shared internally. That is strong inner source adoption for organizations that already have a high DVI score. Open source adoption acts as a major accelerator. In short, open source clearly has proven potential to drive transformation and innovation in an organization and to be the market differentiator that you need. However, in order to maximize your investment of time and people and money and resources, you must strategically and intentionally create a program that makes open source a priority and not an afterthought. The extent of the program should be threefold. It should, one, prove and demonstrate the value of your investments internally, especially to leadership. Two, it should embed the ethos of open source culturally, not just technically throughout the organization. And three, it should champion the virtuous cycle of contributing and reaping in the community. It is critical to demonstrate to leadership and to other internal stakeholders how open source adds value to the business, that your efforts and investments make business sense. You should start with defining why you're building this program and where you want it to go. Set goals and metrics, lay out your ROI objectives. These goals and metrics will certainly help keep your projects on track, but for the purpose of delivering and communicating value to leadership, this action is absolutely critical to reporting regularly on your successes. It will also help with relationship building with potential partners, users and developers, and the transparency that you will provide with this will help establish much needed credibility. You will find that metrics are only one measure of success. You'll want to also include non qualitative measures that are equally important as the numbers and articulating that value story. Some dimensions you might want to report on include your participation and the level of influence in the community that you're having your ability to attract and retain developers, your organization's reputation in the open source the health of the company and their open source projects and those that you contribute to externally and how well your open source licensing compliance is being managed. Perhaps you'll want to set up an open source program office to help you achieve your strategy and your goals. And if you do go this route some successful examples you'll want to consider include capital one red hat drop box to name just a few. So please see the resources at the end of this talk for links to their published case studies with greater insights that you can apply from the programs. If your communication plans to leadership you should make sure to explain and to demonstrate your risk management approach to ensure their sponsorship and the resources that you need. A couple of examples of organizations who are proving the value internally include Salesforce and the US Department of Defense. Salesforce has this open source strategy that keeps everyone aligned. They have a dedicated open source program team that circulates internal documents to the company's engineering team that provides strategic guidance and encourages the creation and the use of open source. The documents provide the foundation for an open source culture culture and it lets the team know clearly that the company's leaders are fully on board and behind what they're doing. One goal of the company's open source program is to build its reputation among developers. The open source program also focuses on expanding the communities that align behind the company's own open source projects. So the community doesn't just use their software they also are contributing to it. Salesforce also measures its own success against the industry-wide success of open source. The more progress there is in open source in all of its many dimensions, the better off everyone is because open source software and what constitutes shared components that everybody can depend on and use. That is what makes their entire ecosystem and the whole industry better and everyone benefits. With the Department of Defense, historically, software development has taken anywhere from three to 10 years for big weapon systems. Now releases, which usually took as long as three to eight months, can now be achieved in one week. In order to break the cycle of slow moving development, Platform One, which is the US Department of Defense's DevSecOps Enterprise Services team, it adopted a new approach to software development services that enables the DOD to support continuous upgrades and new features with integrated cybersecurity testing on a much faster timeline and at a lower cost than the traditional waterfall models and cycles had allowed them to do. And the core of this new approach is leveraging open source software, which has now allowed Platform One to adopt new technologies rapidly. And it takes advantage of the cutting edge solutions and innovations that were previously out of reach. The next step that you can take to invest in embedding open source culture into your organization is weaving it into the DNA of the business. According to McKinsey, culture that fosters open source includes factors like psychological safety, collaboration and knowledge sharing, bias towards continuous improvement, servant leadership, customer obsession and talent management, which also includes employee value proposition and career growth pathing. This all looks like creating and communicating policies for open source software usage and contribution on the individual level as well as making sure that your teams have the right level of support that they need for their success. Autodesk has done a really good job of this. They've made a company-wide shift to open source and to inner source. Inner source simply means applying open source development practices and methodologies to the internal projects, even if the projects are proprietary. The culture change required to be successful can be very, very difficult. It's a hard shift from a traditional corporate hierarchy to an open approach. But Autodesk's role in open source has become critically significant in the media and entertainment industry because of all the things that they're doing. And they're now looked to as the leaders for open source innovation. At Autodesk, the goal is to let engineers get loose from their business silos and to create a fully open source cloud-centric company. They have an intense focus on innovation, as well as making all the products work seamlessly together. So what they're trying to do is enable those engineers the freedom to find a way to make things work out in ways that they wouldn't previously have even uncovered. And part of that cultural shift really is getting all those internal stakeholders to say, you know, instead of why are we doing all of this, why are we doing this for community when we only care about our stuff, turning them past that and getting them to be champions for understanding, yes, we're doing this work, but that's going to be used elsewhere. But in the end, we're going to get benefits from pulling in work from other people who've done things that they know are going to be used in the community itself. So it's really changing their approach to that. GitLab has also invested heavily in the open source ethos. GitLab knows a lot about how hard this is, but also what the culture and results can be like when you build your organization around open source. So let me just take a moment to give you a bit of background on GitLab, as far as contacts for the rest of this discussion. We were founded in 2014. We have over 1300 employees in 65 countries around the world. We have over 30 million paid and free users who use GitLab from startups to enterprise level companies all over the world. And we also have a very strong community. We are open source core and that means that we balance the need to improve the open source code of GitLab with the need to add source available features in order to generate income. We have an open core business model and that generates almost all of our revenue with subscriptions from our paid tiers. We recognize that we need to do that to generate the income and also to balance the needs of our open source project. And as part of that corporate dual flywheel strategy that we have, one of our flywheels is the open core flywheel. Essentially it means that the more features that we have, they drive more users, which in turn drives more revenue and more contributions, which leads to more users. So that keeps going. Every single release that we have includes approximately 50 new contributions from the wider community of more than 2400 active global contributors. We strongly and actively engage with our community in stimulating and thought provoking conversations about how to best and safely leverage open source software to solve industry challenges. Our approach to open source culture is this. From the very beginning, our founders have believed that actions be louder than words. They've instilled a set of values and behaviors that are inspired by DevOps practices that drive how we function every single day. These traits are the key to why we're so successful and how we help our customers to be successful as well. It's all centered around the fact that everyone can contribute. That's the core to all of GitLab. We believe that everyone has a valuable part to play in contributing. That can be employees across departments, external contributors, customers, competitors, even random strangers on the internet, everyone. GitLab believes in a world where everyone can contribute and when they do, consumers become contributors and then we all greatly increase the rate of progress. For example, just one of the ways that we're contributing back to the community is through supporting the Finno's legend project led by Goldman Sachs. Legend is the project that provides a logical modeling language as well as the platform and visual model tool for banks and regulators. We also provide open source organizations access to our top tier features plus 50,000 CI pipeline minutes for free. Collaboration is also key to who we are. It's all about eliminating the silos. Silos create islands of information and barriers to trust and create friction everywhere. The first key to accelerating delivery is to reduce the impact of the silos and the handoffs. That doesn't necessarily mean a hundred percent flat organization, but it does mean that you'll find ways to encourage and enable collaboration everywhere with all of your stakeholders. Collaboration enables a DevOps environment that makes it possible for multiple work streams of product and development, QA, security operations, everyone to perform their task at the same time instead of waiting for handoffs. Teams that work concurrently and review changes together before pushing code to production. When employees make quicker decisions, when they're sufficiently informed, employees can communicate and make impact in real time or near real time. This keeps the execution process moving along and helps firms to change direction quickly. We also have a results driven approach. We do what we've promised to each other to our customers or users and to our investors. We care about what team members achieve, the code that they shipped, the users that they made happy, and the team members that they've helped. Someone who took the day off shouldn't feel like they did something wrong. We don't have to defend how we spend our time or our days. But we do trust team members to do the right thing instead of having rigid rules. Our focus is to improve the results that customers achieve and that their customers experience. And that is way more important than a long list of other things that can get in the way of delivering results. We value efficiency. We care about working on the right things, not about doing more than needed, not about duplicating work. This enables us to achieve more progress and that makes our work more fulfilling. We write things down. We create simple, boring solutions to problems instead of complicated ones. And we optimize solutions globally for the broader GitLab community. We're respectful of others' times. We spend company money like it's our own. We're frugal and we accept mistakes. We also honor diversity, inclusion, and belonging. The values of diversity, of inclusion, of belonging, those are very fundamental to the success of GitLab. And it complements our other values, specifically collaboration, efficiency, and results. We strive to create a transparent environment where all team members around the globe feel that their voices are welcome and heard. We aim to be a place where people can show up as their full selves each and every day and they can contribute their best. There is empirical evidence that diversity and leadership supports innovation. It promotes better decision making and it improves financial results. If that believes that many perspectives coming together creates a more innovative environment to work in, to be satisfied in, and have satisfied teammates, which all lead to better product and increased profitability. Part of our inclusion is realizing that you can't make great software without UX designers, without technical writers, and all the other people that all bring it together. The people who are promoting that work and they're helping to make the community inclusive are a huge part of the overall success of GitLab. We also work in iterative chunks. I'm sure that you've heard of minimal viable product, which was made famous in the lean startup. But we think that a minimal viable product is too big. We even consider minimal viable features too big. Think about how much you invest in designing and developing and testing and shipping in MVP or in MVF. Lots, right? We push ourselves to ship minimal viable changes. So we ask ourselves, what's the smallest change that is an improvement? Not something that's incomplete, just minimum. Not untested, just minimum. Here's an example of how we create a new webpage. We start with the title and a few key points, and then we publish. It's live, it's public, and from there we make frequent improvements while watching the feedback from our stakeholders. The point is to learn as we iterate. Here's why. Four good reasons. One is we get feedback and we learn faster. Two, we limit our risk from any one change. It's much, much smaller. Three, we can back out a small change much, much easier. And number four is we learn and improve faster because smaller equals agile, nimble, more responsive. And at GitLab, we've embraced the concept of smaller changes and a low level of shame to unlock velocity. We're also transparent and we believe in direct communication being fundamental and foundational. We strive to be open about as many things as possible. By making information public, we can then reduce the threshold to contribution and make collaboration easier. Everything we do is public by default, including issue trackers, but also our marketing and infrastructure and the public repository of our website, but also contains the company handbook. Transparency creates awareness for GitLab. It allows us to recruit people that care about our values and it gets us more and faster feedback from people outside the company and makes it easier to collaborate with them. It's also about sharing great software documentation, examples, lessons and processes with the whole community and the world in the spirit of open source. We believe that creates more value than it actually captures. Most things are public unless there's a reason not to be. And we take above average measures to make sure that those things are protected and secure and that things are confidential as appropriate. The cultural values that I've outlined here enable us to rapidly respond to markets and to define, develop and deliver new capabilities for our customers. But the good news is that these aren't proprietary. They are the foundation that anyone can adopt to transform their culture and accelerate their open source innovation. Step three is to champion the virtuous open source cycle. This involves not just using open source software in your business, but also being active contributors upstream, meaning sending that thing code back to the source repository and the project where contributions happen and releases are made. This has been official for the original source code and the forks of that code. It also involves starting and maintaining projects and ensuring that the right infrastructure and technology are in place to support your program. SAP and Uber have really great examples of this. SAP started its open source journey with Linux in the late 90s and its involvement grew over time. They formally defined and internally documented their processes for open source consumption and the company committed to being to using inbound open source projects to build SAP products. Eventually though, their developers began actively contributing to several Eclipse Foundation projects. But it wasn't until 2008 that SAP started to actively promote open source contributions from their employees on a company-wide basis. That was also when they decided to roll out their outbound open source process. They also integrated open source tools further into the development processes. In 2014, SAP shared with their open source community a tool they had developed for managing open source contributor license agreements. Their central open source program office was then established and that was under the guidance of their CTO. Since then, they've become even more visible in the open source community and they see that as a sign of their continued commitment to excellence in open source. Their goal is to form more partnerships and to spur accelerated innovation. Uber also has been an open source software user since their very beginning. It was natural and organic for them to create an open source program office because it allowed them to build their platform and to scale it at unprecedented speed. They love open source at Uber and they view it as essential to their success. In fact, their long history of contributing to open source projects has many active maintainers in the community. Their successes have solidified their program as being mature and it's prioritized the investments that they made in it. So what they want to do is they want to encourage their ongoing regular involvement in open source. So they instituted internal standards for governing and incentivizing contributing upstream and back to the community, which is one of the best ways to help ensure that you have sustainable projects. Those greater opportunities and innovations tend to spread outward to create greater good. Now, in 2019, Uber helped launch a program to support community development, which helped to improve mobility, transportation, safety and infrastructure for their communities. They have projects that can help like urban planners, policymakers, local governments all gain critical insights and better understanding about the data of their cities that they they operate in. They say that the collective knowledge that their engineers actually grows by integrating with the open source community and they note that one of the hidden benefits is that it's not just the technology that's benefiting. The engineers are learning about collaboration and best practices, and they're helping to build their leadership skills for the process of interacting with the open source community. So, what is it that you can do to realize the value and innovation that is the promise of open source. How can you make open source work for your company. And this three pronged approach to drive the innovation that you want to achieve. Start with proving and demonstrating the value internally. You've got to define your strategy and your goals and your measures of success. You want to make sure you know what you're looking for and, and your ROI is laid out so that you know exactly what you can expect. You should look at can at implementing an open source program office and designating a person, at least one person to help to manage the open source for the company and what that direction should be. Also invest culturally, not just technically technology is very important with all of this, but you need to look at driving home and embedding the culture into your company culture that that open source ethos is really important. So that people understand it is about contributing and reaping, but both of those things are part of this cycle. And then you also want to make sure that you're communicating the right policies for usage, and what does contribution look like, and what does it mean for you to accept contributions. You should also look at what that internal support layer should be a training and education should be, and to make sure that you're you're providing the right level of support for for your employees and for the community that you're you're working with. And then you should also make sure to participate in the virtuous cycle of contributing and reaping. So make sure that you're contributing upstream. That's very valuable what you can get back to the community, but also start projects, hire from the community support growth of people in your organization as well. Look at simplifying your IT infrastructure so that you can optimize your collaboration. There's also a lot of great projects out there that you can participate in, and whether it's the organizations it's projects and special interest groups but there's a ton of them here at Finno's and at the Linux foundation that could use your contributions and your help, but also groups like the clips foundation the triple foundation and many others. So, obviously, there's still so much that I couldn't cover today. I want to invite you to dive into the resources here on this page to help you scale your open source within your organization. There's a lot of really great things here and I've just touched the surface of it but I think that you'll find some really, really strong stories that you can learn from. So please visit our website about dot get lab dot com and you can check out our handbook and learn more about how we do the things that that I've shared all about our culture and how that's been very helpful for not only our organization but because we've shared that many other organizations have used that to work on building their culture in their DevOps culture in their their companies. So, all of this is out in the open, and I do invite you to take a look at it. And speaking of transparency, please also see our product roadmap and learn where we're headed in the spirit of collaboration and open source we like to hear your feedback. And we'd like you to join us as partners in development so please feel free to send me a connection on LinkedIn. I'd love to hear what you're thinking and your feedback as well. And remember, everyone can contribute. Thank you.