 I hope you've been enjoying GitLab Commit so far. We have just a few more talks and then we'll be calling wraps on another great GitLab Commit event. Over the past two days on all of our stages, we've heard amazing stories that bring the DevOps vision to life and our next speakers are no exception. In 2011, GitLab started as an open source project and what better way to celebrate 10 years of innovating together than to hear from some folks who live and breathe open source at the Linux Foundation. Brian Dawson is VP of Developer Relations and Ecosystem Development and Steve Ira is VP of Information Technology. Together, they'll share how there is a symbiotic and reciprocal relationship between open source and DevOps with each driving the other forward. Hello, thank you for joining us here at GitLab Commit Virtual 2021 and thank you GitLab for having us. Today, we're here to talk about reciprocity, how open source and DevOps drive each other. To introduce myself and my co-speaker, I'm Brian Dawson. Recently, I'm functioning as the Vice President of Developer Relations and Ecosystem at the Linux Foundation. Prior to this, I've spent the last decade of my career helping Fortune 1000 organizations and DevOps practitioners optimize and modernize their software development and delivery. I'm joined by Steve Ira. Hello, Steve. Steve's the Vice President of Information Technology at the Linux Foundation. Over his years at the Linux Foundation, he's supported infrastructure, systems and process for some of the world's largest open source projects. And he's going to join me today to give you that real world perspective on what it means to support DevOps processes in open source. So I'm going to kick it off before we go over to Steve and I'm going to start by talking about the role of open source and DevOps. Then Steve's going to come in and he's going to talk about the role of DevOps in helping deliver open source. My goal for today's talk is to highlight for you the role that open source has had in driving the pillars of the DevOps Trinity, people and culture, process and practices, tools and technology. And what I hope is you can use some of this conversation around open source and open source principles to help inform your DevOps journey and cause you to consider how open source affects your strategy. And if all works out when we're done with this, you'll not only have new inspiration on how to implement CI CD and DevOps, but you'll also be inspired to embrace open source. At the end of the day, open source and DevOps work together in the spirit of driving innovation together. So to understand the relevance of the organization we're from the Linux Foundation to open source and the relevance of open source to DevOps, it's important to understand the projects that exist under the Linux Foundation and how we help them. We provide legal hosting tools, infrastructure, marketing process and support to multiple projects across multiple verticals and multiple industries. As you look at the logos on this slide, you'll likely see numerous tools and technologies that you're familiar with. And if you look a little closer, you'll also see a number of tools that are key to software development and delivery within the DevOps ecosystem. And in fact, I expect that there's some of these tools that your devs, your DevOps engineers, your system admins are using. Let's move a little further and take a look at an open source project or actually foundations which are central to the DevOps ecosystem as we start to lead into this is what open source is about but what does it have to do with DevOps? Those two foundations are the Continuous Delivery Foundation, also known as CDF and the Cloud Native Computing Foundation, known as CNCF. We'll start with the Continuous Delivery Foundation or CDF. CDF is composed of over 30 member companies. As I said, open source alone does not exist on its own. It works in partnership with organizations including commercial for-profit organizations. These companies like GitLab have helped CDF identify and then ultimately define, socialize and train on continuous integration, continuous delivery and DevOps best practices. In addition, they work to steer and contribute to development of fundamental technologies and these are the technologies where whether directly or indirectly ultimately support your team and your products as well as the member's company's products. So what you'll find with CDF for example is whether you're seeing it directly or indirectly the Continuous Delivery Foundation and its members and its contributors and its governance board are all helping shape the world of DevOps that we interact with. Next, let's look at what is really the pinnacle of open source projects, the Cloud Native Computing Foundation, which you likely know through Kubernetes or if you don't know CNCF, Cloud Native Computing Foundation, it is likely that everybody in the audience is familiar with Kubernetes which has been unofficially declared as the Cloud OS. CNCF and its members and contributors have led identifying and developing a set of easy to understand best practices for delivering modern Cloud Native applications and these are built on and extend the DevOps principles which we'll talk a little bit more about. CNCF has a phenomenal impact. As you can see on this slide, I actually had to crop it. I couldn't even fit all the participants in. A phenomenal ecosystem with a large group of members that are driving significant impact. In fact, these teams of people in this open source project are developing the standards and related tools and technology that ultimately are bridging yesterday to today and to tomorrow where we are almost all developing in a cloud-centric manner and delivering software at speed while maintaining quality and security. So, let's take a moment and get into the history of open source and DevOps. I thought about doing the drunken history of open source and DevOps but I figured that might not be appropriate for a keynote. And when we look at the history of open source and DevOps, understand that while their timelines may differ in terms of specific dates and convergence points, there is a significant overlap between the maturation of open source and then the spawning and maturation of DevOps. The people and culture process practices and tools and technology used in and then built through open source set the stage for inspired and drove many of the DevOps principles and practices we use today. So we're gonna take a moment to look at the history of each and then kind of talk about how they converge. And we're gonna start by looking at a specific period that y'all were probably taught in history class, right? OS or maybe not. So this is the period for open source. And we'll say in the 10, 20, 30 years prior to open source what we found is that while there was a focus on innovation and in fact kind of prior to 10, 20, 30 years prior to the introduction of the term open source, at least through academia and even in government and research oriented software development, there was a lot of collaboration and communication that was driving innovation. But as it became a richer commercial opportunity and commercial economy, people felt that the rigid structure of commercial organizations, as well as the fear of IP was potentially limiting collaboration and then therefore slowing innovation and resulting in software that potentially had an unstable equilibrium that wasn't necessarily the most secure, wasn't necessarily the highest quality software. And so many of us are probably familiar with the Free Software Foundation or GNU. If you're a developer in this audience, you've probably built something with a GNU compiler. That's what until roughly 1996 to 98, people often associated with open source. Now around the time that the term open source or the term open source was introduced at around the time that Linux was launched or started to gain traction and maturity, around the time that Netscape open sourced their browser and also around the time that one Eric S. Raymond created an essay called The Cathedral and the Bazaar which informed a lot of how we think today. Now what also happened around that time is Eric Raymond and one of my colleagues Brian Bellendorf along with many others like Tim O'Reilly gathered in Palo Alto and in fear of the ambiguity of the Free Software term, agreed to socialize and promote this term open source. And really that's when open source started to hit the mainstream. Now The Cathedral and the Bazaar essay by Eric Raymond is really important because that's where principles of open software development that underpin the open software movement were first sort of quantified, documented and widely socialized. So let's look at those for a bit and I'll just, I'll blow the surprise and say that as you read these if you've been practicing our following DevOps you'll see the similarities, right? So people in culture, when we talk about a Bazaar approach to development as opposed to a Cathedral approach we think that users should be treated as co-developers. You involve the user early and often you get their feedback and in fact if you have a user base that is open to receiving early releases you actually involve your users in testing your releases not just quality tests but user acceptance tests. You should shy away from top-down decision-making structures to drive dynamic decision-making. And this is really one of the places or around the time that we started to see this common term fail fast be introduced. Next, if we look at tools and technology or process and practices, excuse me you see common things like release early, integrate frequently, leverage not only really stable safe versions but allow people to get their hands on early versions and use a high level of modularization. When we talk tools and tech you can start to see the way that open source tools developed and continually supported some of these open source practices better. You can look at source control where we went from central versioning system after source safe and clear case to SVN to Git and then ultimately to hosted in social coding SCMs similar to GitLab. We've gone from CI to CD. We've gone from concourse to go to Jenkins to GitLab. QA, Bugzilla to SonarCube to Selenium. These are all tools that were around and being used before the term open source was coined but they also unleashed the ability to implement DevOps. So let's talk a bit about DevOps. And with this period that you also probably were not taught in history class this is called DO or before DevOps. And you'll note, I just copy and pasted and use the exact same graphics because the problems, the villain in this story the problems that we're being experienced were very similar to open source. We needed to innovate. The traditional software development model was waterfall. It was a very risk averse and failure averse and very top down. And that again resulted in slowing of innovation and in fact, unstable deployments, laborious deployment processes. And what I didn't call out here when we talk about the inception of DevOps was this concept that these structures resulted in dev and ops not working well together. So in comes a group, Alex Campbell, Chris Bytar, Patrick DeBull, a number of others who both worked in the operations and the dev brain and said, hey, look, we have two separate groups of people trying to solve the same problem working against each other. And with that, they launched DevOps days and crazy enough that was about between 2006 and 2008 which the first DevOps days, I believe being in 2008. So it's only been three years. But in that time, DevOps has become a mainstream term. It's become a practice that is proven to drive outcomes and output. So we move from the separate sort of upstream processes which are broken and different on the planes of the DevOps trinity from downstream processes. And DevOps has driven this approach of aligning stakeholders around the shared objectives of delivering quality and secure software rapidly, reliably and repeatedly. And DevOps has adopted these very similar principles, people and culture. There's a focus on collaboration, experimentation and learning, process and practice. There's a quality first focus. We focus on continuously integrating and releasing frequently. Does this kind of hark back to the cathedral and Bazaar principles? We talk about small increments just like pursue modularization. And at the end of the day, we focus on automate, automate, automate. When it comes to tools and tech, we look for things like shared and or hosted tools, no longer is version control RCS on your desktop. And again, they need to be governed. We need continuous security and we need to automate, automate, automate. Now, if we talk about the current state where kind of DevOps and open source have converged, open source has empowered DevOps to pursue that principle of experimentation and learning. Because you can adopt a new and emerging technology that's been developed, if you will say by the people, for the people, you get the freedom to try. But what's also happened is as DevOps has matured and open source has had to mature to be able to support enterprise a jobs in and use for critical projects. Now that said, what we're also finding though is a tighter synergy between open source and commercial. So a lot of commercial vendors in the DevOps space are either open sourcing a component of their offering similar to GitLab so that you can contribute and bring innovation to the tools that you use. Or they're building solutions that embrace open source and enable you to connect and coordinate across multiple open source tools. We're also finding that CNCF, CDF and other open source projects not mentioned are leading the path to the cloud. They're driving standards and practices. And as you see on the screen here in open source with our LFX solutions, we provide our open source tools with metrics and measurements as kind of spawned by Higia coming out of Capital One, just as we see application monitoring in GitLab. So open source and DevOps are both moving more and more to continued rich visibility shared across the stakeholders. So what's next? I'll just call out quickly that the future of open source and DevOps includes a higher focus on security. As open source use is prevalent and DevOps tool chains are prevalent, it's important that they not only enable secure applications but they're secure themselves. We also need to go beyond DevOps because DevOps isn't just DevOps and have solutions and end to end pipelines like a value stream view which connect everybody. We need to better embrace cloud development and it's important that we focus on ensuring that we're upskilling the participants in the process and we're driving diversity. So Steve can cover some real world examples of how he's supported CI in open source in pursuit of DevOps. Over to you, Steve. Thanks a lot for that, Brian. Thanks for the intro and glad to be here. I will touch briefly on sort of the perspective that we have seen in the LFIT department at the Linux Foundation, sort of the trends that and strategies and approaches we are taking and touch on a few of the principles that especially around tooling that drive some of the changes in open source we have today. Briefly, the IT department traditionally and it's a long standing department at the Linux Foundation since its inception there's a lot of long tenure staff within that department that have been involved in open source in many different ways. And generally speaking, we can divide our service catalog into two primary areas, which is collaboration and general services and then the tooling on the CI that any given project would need. And then there's real basic services, every open source project needs like domain management, service desk, mailing lists, websites, those sorts of things. But more importantly on the CI front, that's definitely changed a lot over the years. And I think before even mentioning a particular tool, it's important to kind of related to Brian's presentation is open source projects and the tools that they use and platforms that they use are constantly evolving. They're projects that are coming together from a lot of different experiences, individual and collective experiences. Projects are large, they're small, they're old, they're new, different maturity scales. So I'll talk a little bit about what we do to approach those decisions when a new project's formed. But generally speaking, as Brian had mentioned, there are 900 plus projects for Linux Foundation. There's quite a few large umbrella organizations with multiple projects underneath that umbrella. There's individual projects, collections of projects. And each one has varying needs and degrees of requirements that they have to satisfy as they come together. The industries are very different. The companies are very different. And one of the things I'll come back to you often is when you are participating in Open Source Project, how is it so that you can play a role in influencing the tool selection or the service selection that supports the development of open source? And the short answer to that is to get involved and participate and specifically to get involved and participate at the working group level, which is more of a bottom's up approach to definitions of toolings. But that's where you want to be if you want to have a say and influence the decisions around any open source project. This evolution as we see it, kind of broken up into three main streams that are running concurrently. And the first one is replace and optimize in place. So there are some long-standing projects while there might be aspirations for new tooling. A lot of consideration has to be taken before any tool can be turned on or off overnight or even within a week or a month. So new projects that are coming to the foundation and the promise of the modern tools that we see in CI as a service are obvious. So by default, as new projects come in, we as a advisory service to those projects bring those solutions to the conversation. But in addition, we are looking at transformations for some of the large projects and we have to consider what it takes to do that, how overly disruptive it will be. If it's a large community, how would they be educated on the new tool platforms? But those are going on concurrently. And the way we're doing this at the Linux Foundation is at the outset of formation, we meet with these communities, even before the working groups are defined at the formation level, and we partner with some of the existing large CIA providers. I'll call out GitLab here because we've done quite a bit of work and they've helped us quite a bit on defining some of those integrations and those early access periods where projects are just coming together, they're trying to figure out what they want, what is the best tooling for their project. Many of these environments have free, freemium packages, but some of the larger projects that we host need to go beyond that and for builders, for example. So we do those calculations on behalf of the projects, often in the working groups with the DevOps teams. And GitLab CI is a perfect example of that where we have a relationship and are introducing as appropriate in our open source projects as they come into the foundation. In fact, we've got one large one that's doing a transformation exercise and working closely with GitLab team that have partnered with the Linux Foundation to help facilitate that. And then lastly on this topic, it's not just one solution on CI even. We have projects that are leveraging the value add of modern CI and CI as a service platforms like GitLab, but also are requiring a fully managed stack in Jenkins and Garrett for whatever technical or architectural reason that they require. So it really runs the gamut on where a project is in its maturity, the size and the industry, the projects coming from, and sort of the communities that come and help form the initial project information. And then lastly, I wanted just to, as the trend continues on our evolution, and self-service is a critical buzzword today. Even in our platform at the Linux Foundation, we have near-term plans for helping integrate with these as a service vendors, helping curate the experience as they come through our LFX platform at the Linux Foundation, self-provision, auto-provision the underlying clouds, manage secrets, account management, repo management, hierarchies, reusing templates, all of the things that we've done traditionally at the Linux Foundation, we are bringing that to the as a service offerings to help facilitate and bootstrap new open source projects that come on board. And then given that time is running out, I'm gonna close on just sort of recap on the principles that I'd like to leave the audience with and that is to recognize that open source is a very collaborative endeavor and people have a lot of different experiences and reflections in what they've used. And certainly on tooling, that's always a big challenge to make sure everyone's on the same page when it comes to tooling, because there's a lot of opinions on what the best tooling is, but there are so many different industries, so many different sizes, so many different maturity levels that our role is a neutral and governance role of advising based on the project's overall objectives. And then, as I mentioned, to really influence that direction in an open source project, the working group is where you would do that or where one does that effectively. And that's, like I said, is a bottoms up process there within the development community underneath, maybe more than one open source projects participating and gaining approval from the various committees like the technical services committee and all managed by the governing board. So if you want to influence that, do it at the working group. And then lastly, I think when it comes to open source projects and what the shape of your project will be as it's collaborative decision and your member companies are coming from all over the world, frankly, it's important to remain flexible and be focused on the project goals that are stated at the formation side. So those are sort of maybe obvious, but they're actually quite practical when it comes to open source for those that haven't been involved. Most important thing is participate. And I think that kind of resonates with what you've been saying, Brian, and hand it back over to you to close out. Let's recap what we covered in our session, right? Open source has proven to be instrumental in unlocking the DevOps movement. And they're both very collaboration and community focused as hopefully this discussion about the Linux Foundation and its project structure showed you that, yes, there's a grassroots component and it is very much about enabling the practitioners to work together, but that doesn't mean that you don't need planning, forethought, infrastructure and support. And the other thing is your teams use open source just flat out categorically, whether it's a library that's included in your dependency tree, whether it's a tool that's brought in or whether the commercial tool that you use is built on an open source component, you use open source. So it's important that you have an understanding of what it is and embrace it as you embark on this path of improvement. And I would ask, what's your open source strategy, right? Be sure to contribute to drive your needs, right? Let an engineer, let a team stakeholder, not even an engineer, maybe a doc writer, contribute to an open source project that affects your world. I'd ask, when's the last time if you're a GitLab customer attending GitLab that you committed to the GitLab open source project, right? And then also think about the fact that open source tools live in the DevOps tool chain ecosystem. So as you look to build or acquire a solution for your team, keep in mind you should do it with an eye towards unifying with a self-service platform similar to as Steve's team has done. At the end of the day, DevOps was founded on a principle of collaboration and community as was open source. So in that spirit, I called you to contribute, contribute to your internal projects and efforts, continue to external projects and effort, engage with your peers, your teammates, CDF, CNCF, et cetera. And then in the spirit of this conference, we can innovate together. Thank you.