Open Source in Closed Ecosystems

So welcome. Um I'm gonna talk a little bit about open source and closed ecosystems here u which I will define um in this talk. Um this is something that's been floating around my head for a few years now. Um I'm working in mainframes these days. Um and that is a very proprietary space. Um so I've been thinking about ways that we've really made inroads into that space and that's kind of where the talk was developed from. And then I was able to talk to a bunch of people in other industries over the past um few months to get perspectives from them and weigh in on the way other industries that are more closed are starting to open up to open source. So what you will see is the culmination of all that and this is the first time I'm giving this talk so it might have some rough edges. Um and I just um welcome anyone after the talk or you know if you have questions please let me know. um or if there's any ways you can we could improve it or you have questions from your industry or your organization um that you've seen popping up that I don't cover here, I'd love to have a conversation. So, welcome. Um so, I want to start off by saying I've been to scale a bunch of times. Um so, instead of giving you my resume, I present to you my resume in the form of scale talks. [laughter] Um so, over the years, I've worked for a bunch of different organizations and been part of different companies. Um so when I first um came to scale in 2011 um I was working at a company called Linux Force. We were doing just sort of deployments of like things like lampstacks on Debian and some um sort of more basic things for a tech services provider I was working for out of Philadelphia. Um but I was very involved with the Ubuntu community at that time. So I I was actually working with Nathan here [laughter] and other folks um who uh were in the Ubuntu community. And so I did a talk on just how you find support in the Ubuntu community. Um I'm also part of a nonprofit in San Francisco called Partemis. Um we've been rather quiet in recent years, but we used to do a lot of deployments to public charter schools in San Francisco. So I I gave a talk on that. Um, and then I went to work for HP, was talking more about Ubuntu, and then got into sort of code review for systems administration because systems administration is where I'm where I what my actual job had been. Um, so we had started to do git ops and stuff before it really had a name um at HP and in the OpenStack project. Um, so I was giving some talks about that. Um, I then got into containers with a startup. So I was talking about open source communities and the open source project that was part of that startup. Um and then in 2019 IBM's like hey you want to work on mainframes and I was like I don't know what a mainframe is [laughter] so they told me and I learned that they are really cool. Um and so I I joined IBM almost seven years ago um to work work on open source and mainframes. Um, and that's kind of what the my past couple of talks have been around. So, in this talk, I will talk about mainframes a lot, but I'm also going to branch out into obviously the topic of this talk, which is more generally closed ecosystems. So, as I said, [sighs] I work on mainframes. That is a Linux one mainframe. That one only runs Linux. Um, and as you can see, they fit into like a 19inch rack spot. They're like seven feet tall and um, very huggable. Um, but I became when I joined IBM, one of the things that was really important to me was that there was an open source presence. So I joined as technically a developer advocate to talk to other Linux people like myself about like how cool these things are. Um, but one of the things that was important was that we had an open source presence because that was very important to me too, not just as a Linux cis admin, but as an open source advocate. So uh I joined the open mainframe project which is part of the Linux foundation and within a couple years I became an ambassador for that project. Um and then inside my own organization when the pandemic hit um that hit developer advocacy very awkwardly because we couldn't go to conferences anymore. Um and so that's when I sort of in my organization I'm like listen we need like an open source office um that like sort of pulls together a lot of our open source efforts so that when someone in our organization who's doing open source which IBM does a lot of um there's sort of like a central place where they can come and have those discussions and I can redirect them to the right team whatnot. So I I line I proposed that to my VP in 2022 and she was like yeah let's do it. So, in 2023, I founded the open source program office for IBMZ. Um, and I love this one on the bottom. So, these, it's hard to tell. That's a Lego mainframe, like a little baby one. And then Red Hat came out with like this little tiny Lego set that's like a little like Red Hat engineer sitting at his little um um thing. So, I put those together and I'm like, "Ah, all the Lego." [laughter] Um, we also built a life-size um mainframe out of Lego. It's like 250,000 Lego, but they don't let it bring they don't let me bring it with me because it's really big. [snorts and laughter] Um, I also like Lego. Um, okay. So, to get this started, so what what do I mean when I talk about a closed ecosystem? So the first part of that definition I'd say is it's an ecosystem that like either is mostly using proprietary um software today or like it's it's funny in the mainframe space because mainframe like back in like the 1950s 1960s like everything was open source because software didn't have value. Um so I could sort of say like there was no propri not much proprietary software at the time. Um, so I always say like like mainframe is open source by default and then they're like Liz, it's not okay. [laughter] Um, because things have changed and open source definitions came around and we have a real definition for it. But as you look like through the history of mainframe like a lot of open source then software became valuable in the 80s and things became very proprietary and that is sort of the world that I entered into when I joined IBM is that most of the main shops out there were running proprietary code for the most part. Um, or it may be the case that, you know, the company does a lot of development in-house. So maybe they're using open source components, but they're doing all their development in-house. So it's still proprietary. Um, but they have a big tech team working on it and they're not contributing back to open source. Um, some of these companies that I've worked with, they have dabbled in open source. Um, but what I see this mostly look like is they'll they'll create a product or a project and then they'll just like throw it over the wall, so to speak, to the community and be like, "Here you go. We gave this to the community. You have to sign a complicated SLA or CLA. You have to that which like gives all rights to your code over to us because we want to stay protected and we'll put a really complicated license on it that may not even be free." Um, and then they wonder why they don't get community contributions. Um, so they're kind of doing open source, but they don't have real direction in it. And they're so scared of like liability and losing IP and losing control over the project that they don't let anyone else in. And I've seen this a lot. Um, so in this talk I kind of wanted to, you know, take organiz or like I guess industries that fall into these categories and just pull in some some best practices that I've learned and how to sort of convince industries that are not so friendly to open source to start opening up to it a bit. Um, so of course I'll talk about mainframe quite a lot because that's what I know about. Um, but I've also spoken with people from the motion picture industry in the past few weeks and also the automotive industry which has some really interesting um um things going on right now. So I broke this down into four key things that a lot of these or uh industries are concerned about. Uh the first is that they will lose competitive advantage. Uh the next one is around security. Security is probably the biggest one that I encounter in the mainframe space all the time because all the clients that we have are concerned about security. Um the next one is support. Like hey there's no support for open source. Uh I'm like well what decade did you come from? Um [laughter] um and then they worry about their expertise with good reason because they threw the code over the wall and put a crazy CLA in front of it. Um so they they they're concerned that they they don't have the expertise to work in an open source realm. So the first point here is the competitive advantage. Um what I say here is that may be true. Um you cannot give all of the code in your company and in your industry to open source for the most part. Most industries won't allow you to do that because you do have something that you've built on top of that that that gives you a competitive edge in the marketplace. So the first thing that an industry or an organization needs to determine is what in their organization makes sense to open source. Um I first encountered this when I was working on OpenStack several years ago where um everyone wanted a private cloud. All the organizations coming together and they're like listen we built things on top of this. We don't care what the underlying compute infrastructure is. And this is the same thing that happened with Kubernetes, right? like everyone came together to build the core infrastructure because that is not what is the competitive advantage for them. The competitive advantage is what they build on that compute. So when learning about the motion picture industry um in their case they focused on like standardization around formats and colors and tooling and like video formats so that things could be shared between um studios that are working together. Um, so it was kind of [snorts] focused on the tooling and libraries around sort of standardization. Um, and so there's this one that's the the visual effects reference platform. That's a really big part of um the uh motion pictures open source piece is because they just focus on a lot of a lot of open standards that they can share. So that's where they went with it. in the mainframe industry. Um, we pretty much decided that we collaboratively want to make the mainframe easier to use and we want to build up skills. So, if you look at the projects within the open mainframe project, most of them are about easing access, sharing scripts among people of like, hey, this is how you like, you know, add a bunch of users at once and like sharing that sort of tooling. Um, and then we have a big education component to bring in the new generation of folks working on the platform. And then in the automotive industry, I was I watched this video um by one of the leaders of the uh automotive grade Linux and he was saying that uh you know we you get a new car and then you buy this dashboard sticky thing. You stick your phone onto your dashboard and that is ridiculous. But the problem is like even in a new car the like the the tooling inside the car, the infotainment system is not very good. Um it's I mean I I connect mine with Android Auto and that's getting there. It's a little better but um but effectively like we're we're just replacing the tech in the car because the tech in the car is not good. So what the automotive industry decided was like listen like we cannot keep pace with innovation that you're getting on your phone even in these cars because we don't share a common platform. So what they decided to do was share that common platform. So they created things like automotive grade Linux um to sort of get like a baseline. So everyone's going to use automotive grade Linux and then they don't have to all write their own operating system. Um so the way that these organizations have done it is generally by going to a foundation. Um so first of all the industry sort of decides like you know we want to work on visual effects and we want to work on standardization or we want to work on a Linux operating system for our cars right you decide what you want to do and then you work to create a foundation. So in the motion picture industry um that was that is the uh Academy Software Foundation and they've gone through a few iterations over the years because they've been doing this for like 20 years now. Um so the motion picture industry is very much in in open source these days. Um the open mainframe and uh the the ASWF I think that's part of the Linux Foundation. Um and then the open mainframe project which again is like IBM and a bunch of mainframe companies coming together to create that under the Linux foundation and then automative automotive grade Linux that's part of the Linux foundation and then the softwaredefined vehicle which I think is like a working group is part of the Eclipse foundation um so all of these industries kind of went to a foundation and said like please help us out to make the open source happen and that is a very good strategy which I'll talk about more. Um, one of the things I learned while I was talking to uh, Nithia Ruff. Um, she was recently at Amazon. She's worked in OSPOS's throughout her career. Um, but I was really curious to talk to her about her experience at Comcast um, several years ago. And one of the things that she mentioned um, was that standards bodies are a thing that a lot of industries are already used to dealing with. So there is a parallel to be made sometimes when you're having these discussions about why you need to collaborate with other people like why you have to collaborate with your competitors and they understand standards bodies. So you can start positioning it like it's kind of like a standards bodies for software now that we are in the future and this is really important. Um and they already know the value of standard bodies. They know if they do not adhere to standard bodies today like they're going to fall behind. Um, and this is one way that has been effective way to approach industries that are a bit more shy about contributing to open source. We can say like it's kind of like a standards body. Like if you jump don't jump on board, everyone else is going to have the good stuff and you won't have it, right? Um and then this is one that I have had to develop over the years is once you convince everyone to like start this foundation or start collaborating at least on like a small level um you need to remind your leadership at your organization all the time while you're doing this why you're doing this um because they will get that bill every year that we're paying the Linux Foundation to do something and maybe it wasn't a good year and they're like we can just not do this. you'd be like, "No, no, no. We need to do that because of all these reasons, right?" So, first of all, for things like if you think of something like automotive grade Linux, right? Like they're building a you know, they're building upon the Linux kernel and they're doing lots of like lots of really important embedded work to make sure that these things work in cars. That is going to save a lot of development effort in house. So, if you're sort of the person in control of this for your organization or you're really into open source, you want to make sure that you're keeping tabs on what this is saving for your organization. um metrics and things. There's lots of open source tooling out there for figuring this out inside of your organization, but making sure you have that like, hey, we are saving money and so the amount that we're paying to the foundation isn't that much, right? Or the amount that we're investing by putting engineers on the open source projects is less money than we'd be spending on developing in-house and we're getting a better product. So, just making sure that you're able to demonstrate that to your leadership periodically. Um there's one that that came up in the motion picture industry example is that um they tend to have a lot of people that move between studios um because they have a very specific skill set based on the movie that's being created. Um and having these people relearn tooling based on every single studio is no good. [laughter] Um, by having consolidated tooling and understanding there's like standards that are open across the industry has been really beneficial to these studios because then they can attract that talent when they need it and they don't have to onboard them with the tools. Like they already are familiar like what tooling you're using here and like how the color palettes work and all the other movie stuff. Um, so it's one thing that less they have to learn. And again, like if they were not on board with this, like all the other studios would be using the same tools and then you're not, right? So then you can't get that talent over to your organization because they're like, "I'm not going to work for you. You don't use any of the good stuff." Um, or the stuff I'm familiar with. Um, so there's a lot of training time saved. And also just generally your employees, people you hire from the industry, like you know, they're like, "Oh, I use this tool at my old company. I can learn a new one but like or I could not learn a new one and join a studio that has it. Um and then another one that came up I think it was the automotive industry example is where um there's a really key part of open source like a a really important project and the maintainer has left for whatever reason and now the project abandoned. And what I've seen is that there's these organizations, they will scramble to figure out how to manage that because they're competitors and they don't have like a neutral place to collaborate. So the problem will be is they're like, "Okay, well, we want to save this project, but I don't want to work with so- and so because like and I don't want to move this to my GitHub repo or I don't want to work, you know, on Ferrari's GitHub repo because I'm Ford, right?" like [laughter] um and so like it ends up being like this really problem where like either the project gets forked a bunch of times and that's no good or it just gets abandoned like the companies end up rewriting something internally which is also not great. Um but by having something like a foundation or a working group or some sort of organization that is vendor neutral they can come together and collaborate there and there's already a known space where they can do this work. Um, and then I will say also just as you are collecting this information and keeping this all in mind, just keep it up to date like have a document and be like, "Okay, we're saving this much money and you know, we were able to hire so and so because like they're a really great engineer and we use the tooling they use." Like just keep a thing open so when your VP comes to you and says like by the end of the day I need you to validate this expense, which has happened to me before. Um, just make sure you're like ready to be like, "Okay, this is all the stuff we do and this is the value that it brings." All right, so the big one for me is security. Um, this one is really funny to me because I remember 20 years ago in 2006, I was working for a company Philadelphia and I love Philly, but they weren't like on the cutting edge of technology in that in that area. Um, so we were still trying to convince them about open source and I I feel like I I can dust off my old decks from 2006 now with these organizations that I'm encountering in the mainframe space because they're saying the same things. They're like, "Oh, if the source code's out there, can't anyone just write a vulnerability?" And I'm like, "Oh my gosh, guys, there have been books written about this." [laughter] Um, and so it's like for part of this is kind of just like, you know, dusting off those old arguments and being like, "Okay, that's not actually true. There's been research and studies and like all kinds of stuff done to show that like you know for the most part the the core open source projects are um um better security-wise than than some of their proprietary counterparts. Um but the good thing also is that in the past 20 years open source has gotten so much better with security as well. So I remember when I was coming here at scale maybe eight years ago. Um, one of the things I was talking about is adding testing to your open source project and that was kind of new. [laughter] So, um, I'm glad everyone took my advice and added testing to their open source projects because it's basically ubiquitous now. Like if your open source project doesn't have tests, you are kind of falling behind. Um, so open source projects have been implementing testing and increasingly like security is part of those tests. Um, in some of like the Linux Foundation projects, you can't even graduate as a project until you pass like have certain security badges and have certain security scans in your open source project. Um, so there's been like a lot of, you know, proactive work being done in this space to make sure that these projects are more secure than they were 10 years ago. Um, and that's just being incorporated in a lot of their automation, which is pretty cool. Um, another thing that's been really helpful is that more huge companies are involved in open source. Um, and one of the benefits here is like you know IBM like before we adopt a piece of open source software or before we um incorporate it into a product or give it to a client at all, we have a whole host of testing that we do on that software. Um, and then if we find problems, we contribute those to the open source project. So take you know IBM and multiply that by the dozens of companies who are big and have massive testing infrastructures right so now you have all these companies who are not only running the tests that are being run in the open source project they're running their own tests to make it like enterprise ready um and this has been a huge thing for open source because now we're getting experts from the actual from the industry um from major companies who are working on the software to give um back to those projects through those that testing Um we've also been um like devoting security engineers from our companies to the security boards on these projects. So oftentimes you'll have if there's [snorts] like a vulnerability that comes into a project, it can get embargoed if it's a security vulnerability and then it's looked at by security experts from various companies who have come in to contribute to open source and be on this security panel. And part of that is the self-interest, right? Like that means the company is in on the embargo. Like they get to know what's coming down the pipeline. security-wise, but then they also have their security experts who can actually work on remediation. Um, so there's a a a compelling reason on both sides to have those security experts in the projects. Um, and as I said, like these days there is an established mechanism for most projects, at least the larger ones, to report security vulnerabilities. Uh, because one of the concerns that I hear is like, oh, what if someone finds a bug or a security vulnerability in your software? they submit an issue and now everyone can see that and then we've got a zero day that everyone knows about. I'm like, okay, well, don't do that. When you submit the issue, you have to go to the security team, right? Like the there is a mechanism in place for most open source projects now to report security vulnerabilities um for the big ones. Um and then again the foundations like the um the ASF, the Apache um foundation, they have a security team that will actually guide their member projects through issues like if a C a CVE comes up for a project in the Apache Foundation. Um the ASF security team will jump on that and be like hey what do you need from us like we will help you through this so we can remediate this and move on. Um, the Linux Foundation, their projects are since they do things like the Linux kernel, which is a very different beast from a lot of open source projects, they they give guidance on how to sub submit the security um uh issues to the projects. Like if you're not sure how to submit it, the the Linux Foundation can help you out. Um and they so they they also and and they also have like direct support for those projects like they they provide um like scanners and other tooling to members of the Linux Foundation so they can do their own scanning and find those vulnerabilities before they even have to be reported. Um we've also had some very bad things happen in the open source world security-wise. Um and thankfully we we had the right response. um you know things like like heartbleleed when that hit that was that was a huge huge wakeup call. Um and so one of the things that happened out of that was the the core infrastructure initiative was founded in 2014 and part of that was making sure we had funding for some of these like core open source utilities that everyone is using at the heart of their organization. Um, so that got funding from a bunch of major companies in the industry um to say like yes, hey, like we want to make sure that OpenSSL is secure. So we're going to give money um to make sure that that happens and fund engineers um to do extra security to make sure that this is the most secure thing that could possibly be because everyone uses it. And then I say recent, but XZ is what two years old now. Um but that was, you know, the the the uh the back door that was put in through social engineering. you've got someone who is a trusted member of the project and they shouldn't have been trusted and that has opened the the eyes of the community a lot more to the trust that needs to happen in open source communities. So I was actually just saw a talk on Thursday about one of the trust mechanisms that's being put into place um to sort of trust users and and communities um to try to build up um against the sort of social engineering that happened in that situation. Um, and it's it's a shame that huge incidents like this is what has to wake us up to this. And I think as technologists, most of us knew these hap these things happened, but to convince our bosses something major had to happen, [laughter] the ones who have the money. Um, but but it's going in the right direction. I'm really happy to see open source um taking these things seriously and the companies investing it in. Um and then today, so if you Google the core infrastructure initiative, you're like, Liz, you said that was created and it was awesome, but now it's gone. Um it was actually just pulled into the the broader um open source security foundation. Um I've been to a few of their events and the thing I love about the open source security foundation is they develop not only like best practices for open source software, they have a badging program for pro projects, um but they also develop tooling. Um, and it's really like a home for tooling um that is very uh both like like scanning for for vulnerabilities but also just like it's a home for security software um for open source projects. Um and so they help in general and then have conferences around all this stuff and like best practices and are continually developing things for open source projects to follow. So we are in such a better place security-wise than we were even you know five or 10 years ago. Um, the other thing I hear a lot about in mainframe space is the support component. Um, a lot of these companies are concerned that they like they're using open source software. They just downloaded it from the internet. No one's going to support me. Um, first of all, I'll say that's a very outdated view of things. Um, there are a lot of companies out there who are doing open source software support these days. um which is it just makes this myth just increasingly untrue. Like it's just it's not the case anymore that there's no one out there to support the software. Um but if you do find yourself in a space where you're like hey my company wants to use this there doesn't seem to be a company behind it. Um or there's a company but they don't offer it for like you know working in mainframe like they don't offer it for my platform or I don't think they have the right tooling around what I need for this. Um but they don't ask um they just look at a company's website and they're like ah they don't support us and they move on. Um so my my plea is to say like just ask like you know email someone on their sales team um or you know go higher than that and say like hey you know I've got this potential big support contract coming your way like can you can you support us? Um, and additionally like a lot of these companies who are offering support, they tend to have a stack that they want to sell you and you can get like support for a specific product, but if you find that like you want support for a specific product and you're using something else that you really can't find support for, that company may have a solution for you. So really just like engage with the teams at those companies and say like, "Hey, I need support. I want to pay for it." Um, and just see what you can we can get out of that. And you get further than you might expect. I will say um and if that doesn't work um you could also approach larger companies who you may have had business dealings with. So I like working at IBM I know we have clients who come to us for everything even though we don't do everything. So what we have is we have an extensive program with our um like independent software vendors that we are partnered with and so say someone comes to us for you know support on some piece of open source software we may say like okay but you have to go to this other company for that and in some cases we actually have gone to that other company that supports it and be like hey like can you add S390X support we're going to be your partner in this we're going to help you do that and then you'll get this customer [laughter] um and like having having a customer ready for that development work is like the biggest thing for us. So again, like you know, come to your IBM or come to your whoever you're working with in the technology space and see if they have influence over getting support for that piece of software that you're looking for or that maybe they'll support it themselves, but it's just not as big as a problem as I think a lot of people make it out to be. The second part to this is really just taking a step back and asking yourself, do I need a support contract? Um, this came up at a panel I was doing um, back in October around open source software. And this one guy was mentioning that like the new engineers that they're hiring on their teams, they don't want the support contract. They know how to use Google. They know how to use Stack Exchange. Um, and these days like they know how to take a pile of documentation and shove it into AI and get answers out of it. So like it the support contracts are kind of a thing of a bygone era for some of these organizations and they just go to them by default. But I think a lot of companies need to you know step back and say like is this really important for me? Do I actually need a support contract or is my tech team capable of figuring this out on the figuring out themselves? Um, another thing I learned from from speaking with someone um was that like sometimes they'll get a support contract for a year and then they'll be like actually we now have our expertise in house so we don't need that anymore or like the support contract made us feel better but it turns out we don't actually need it so they'll just drop it after a year once they build up that in-house expertise. Um, so yeah, just asking yourself like do I actually need this today? And the last thing I want to dive in rather extensively to is is expertise. Um so again, companies are afraid that they don't know how to do open source. Um [sighs] especially if they're not necessarily a technology company. Um I mean look at the automotive industry. I'd say they're a technology company, but a lot of them are like, "No, we make cars. We don't make software." I'm like, well, a lot of you make a lot of software, but essentially they're just like, we make cars. I'm like, all right, all right, fine. Um, but there are a lot of companies, you know, we make widgets, we don't make software, right? So, they just don't believe that they have the expertise to do something like contribute to open source software. Um, so my my first thing I' I'd say to them is like you don't have to know how. Like there are foundations out there that will do this for you. Um, and they kind of one of my friends referred to them like foundation in a box. like they will give you all these resources which I'll talk about. So the big ones of course there's like the Linux Foundation, the ASF um there's other ones like Eclipse and other ones out there um that do very similar things and also there are like industry specific areas. So like if you're in finance or if you're in energy there's like sub areas where you can look for foundations that will support your journey in open source. Um but you just so first you see like you know which foundation aligns with your goals and then you're kind of set like they will help you through this whole thing. So they will provide things like proven governance structure. So they'll set you up with like say like okay you need a technical steering committee or a technical steering committee maybe you need a board of like executives. essentially they'll just lay out what the options are and you can kind of like work with others in your in your industry to figure out um what makes sense um and sort of pick and choose and make decisions. Um they'll also provide you with technology frameworks. So like if you need hosting or if you need code or if you need like all the other pieces that come together mailing list in an open source project they will provide that for you. Um and then they can also help with like growing your community. um which is I think a lot of um a lot of folks struggle with because like you know you're working in the motion picture industry you don't know how to build an open source software community you've never worked out there in the open with folks um and so the that's one of the things the foundation can help you do is like be more open-sourcy about how you approach your projects um and then for your you know contributors there's a lot of stuff inside so there's mentorship programs there's scholarship programs there's diversity and inclusion programs that the foundations s have expertise in administering and then they can use that expertise to give it out to your community and and benefit your contributors. So it's it's just having worked on open source projects where like I founded them and like I created my own little fifom like it's it's like going to a foundation is such a refreshing experience because I don't have to cobble together all that stuff myself. Um, another big one for companies is again they are so scared about licensing and intellectual property. Um and so one of the things that I saw when I was working on OpenStack was that when that all came together um with the member initial member companies um like HP where I was working like they contributed lawyers to like work with the foundation um to put together all the legal frameworks to make sure that all the member companies felt satisfied with the open source licenses that were being used with like the agreements that were being put in place and everything was all like put together in a way that the enterprises were happy with. Um, and that's something that the foundation can facilitate because your organization, you know, your Ferrari may not want to work with Ford's lawyers, right? Like, um, but if there's an intermediary of the foundation, they can get them together, um, to work through those issues. Um, it also means that as I mentioned earlier, like that means you're not throwing the software over the wall and just letting it sit there and not being able to accept, you know, recruit contributors. It really helps having that firm foundation from experts who have already done it before. Um, and it protects you as well because you're finally like your lawyers are like, "Okay, we can do this. We can contribute open source with our competitors." And that's a really good feeling when the lawyers say it's okay because they never say it's okay to me. Um, so anyway, so I I sort of talked in vagaries here, but just to give you an example of a project that I've I've worked on. Um, so I run the software discovery tool, which is really just like a NodeJS like web app with a database back end. It's nothing special. Um, but it's mainframe related. Um, and so when I said like we need this because we need to be able to search what's on open source software is out there. Um, the Linux Foundation helped me and the open mainframe project with like they created the project for me. Like they they gave me a logo like I I don't design logos. You've seen my slides, right? [laughter] Um so like they made our little logo and they like gave us options like how about this, how about that? I'm like oh that one's cute. Um they gave us um a production hosting environment. So we have like a virtual machine devoted to the project that I don't have to pay for which is nice. Um we're hosted in the open mainframe project GitHub organization. Um, they set us up with a channel on Slack. They set up us up with a mailing list. There's a whole like meeting and calendaring system that we can use that keeps recordings and does transcriptions of our meetings. Um, and then we also have access to like the security tools um, for scanning and things. Um, and they regularly send us reports that they run centrally to say like, hey, like you're in violation of this license, or oh, you're all good, or like you have this one piece of dependency that's that you need to fix up because it's got a security problem. Um they will also periodically come to the technical steering committee for the open mainframe project as a whole and do like mini training sessions to remind us um like what um badges are available through the Linux Foundation and what training is available for free for open source projects to make sure that that security um things are being checked off on the lists. Um so they've been helping our project with some of that stuff. Um we've also leveraged their um paid mentorships and this is one that I found incredibly valuable. Um so the mentorships are are financed by like the member companies. So the companies that invested in the open mainframe project um they fund those mentorships but it's kind of like they pay a bunch to the open mainframe project and mentorship is one of the places where it goes to. Um but essentially you get a student for like 12 weeks um over the northern hemisphere summer um and they will work on like a specific project inside your organization. Um but the reason that this was so valuable to me is because working on mainframes this weird niche little place that no student ever knows about. Um we were listed with all the other Linux Foundation mentorship projects. So there's like hundreds of projects for every session and we were just in that list with everyone else. So people were able to discover our mentorships without me having to like tell every student in the world that mainframe still exist which was a relief. Um so then we ended up getting like dozens of people applying for our things who had never heard of mainframe but are like hey let's I'll work on this. So that's been that's been huge for us. Um and those mentors that I the mentees that I've had through the program like some of them have gone on to speak at conferences and get great jobs around the world. So I'm just so proud of them. Um, the Linux Foundation has also helped our project get on things like they put us out on their blog which gets fed into Linux Foundation promotion machine. Um, and also like podcasts and interview style things. Um, even speaking slots at at conferences like Linux Foundation events and and like the open mainframe summit. Um, and just making sure that you're you're getting the the out there um as much as you want. We've definitely leveraged all of that. And this is all stuff that I could have cobbled together myself, but it was really nice that I didn't have to. Um, and it's it's really nice having that community there um of support even if I know what I'm doing, right? Um, the other thing that that came up a lot in my conversation is um open- source program offices. Um, so I remember being at an open source summit a couple years ago and there was a woman who was working at Ford and she was like like she's like my team does not understand open source and I think they were trying to develop an open source program office at the time. Um, and essentially what an open source program office does is they they coordinate um the uh like the the goings on of open source within your company. Um, and it's kind of like they they handle like how uh people in your company contribute, um, what licenses it's okay to contribute to, and then just sort of make sure they keep on tabs of like who's contributing what, and that your contributions are going in a way that properly reflects the company, right? Um, and so there's this thing called the to-do group, and that's what that QR code is there. It's just I think it's toddroup.org. Um, maybe. Um, yeah, toddroup.org. And that is like expertise from dozens of people working in OSO all over the world for a bunch of different companies in a bunch of different industries putting together their collective knowledge so that if your organization wants to create an ospo they can go to to-do group and basically like learn everything on how to create one and what is necessary and what kind of expertise you need in that. Um I run an ospo by myself. I would not recommend that but the benefit for me is that I I have like broader IBM above me. So I run the OSPO for IBMZ specifically. Um but I have like IBM above me like does all the legal stuff and contribution guidelines and stuff. So I don't have to worry about that. I mostly work about around like coordinating open source project which is the fun part. Um but there's a lot of resources. So there's like they wrote they wrote a book um like a PDF that you can download about about running OSOs and then there's the the OSPO definition there too. If my definition wasn't good enough which it I think it was sufficient but you can dig deeper. Um, the other thing, um, one thing I was talking to Nithia about about her experience at Comcast, um, was that the, uh, your developers may not know how to do open source yet either, especially if they're coming from more traditional like waterfall development workflows or where they feel like they need to land a whole feature in one patch. That does not go over so well in open source communities. Um, so there's also guidelines for how you contribute to open source um that are out there. And again, To-Do Group made a great one that the Linux Foundation that's in this QR code here. Um, it's an open source guide just to like tell you how to open how to contribute to open source. Um, and then there's lots of guides out there like GitHub has some good guides that cover like the technical parts of how to contribute, not necessarily the social components. Um, so there's just guides all over the place. And the really key thing is that you make sure that your developers in your organization get a hold of these guides so they can build up their expertise and then also doing like routine training internally or telling them to go to a conference um and meet other people um who are doing open source to sort of learn what the culture is because we do have a very distinct culture in the open source world and if someone tries to land a 1000 line patch in my project I'm going to not be happy about it. No, I'm going to be happy, but I'm going to tell them that that's not how we do it very nicely, and I'm tell them to break it up into like 10 patches. Um, but things like that, like companies just don't necessarily know that, right? Because if that's how they do things internally, that's how they're going to approach open source projects. But I'm not going to review a thousand lines of code. No, thank you. [sighs] Um, another thing that was that was came out when I was talking about this talk was the uh just in general like organizational reputation. Like there are companies in tech that we want to work for. Like they have a good reputation. We know they have a good tool chain. They work on interesting things and you want your organization to be one of those companies. Um, I know we're going through like a kind of dip like you know it's cyclical, right? right now a lot of people are looking for work, but I'm sure we'll come to a time very soon where companies are fighting over engineers again because we always go back and forth. Um, but I think, you know, you want your company to be desirable to developers and a lot of developers these days want to work on open source. Um so having that opportunity and making sure that your organization is you know your developers are being trained in a way that is open source friendly um is really um helpful to to attracting the the that top talent um that you want in your organization. So all right got time for questions. So just just to conclude my checklist is just you know identify what you can open source in your industry um to make um and make a foundation out of that. Um and then continuously address security concerns um continuously address and foster that support concern that that pops up in in a lot of a lot of companies and then you know support building open source um expertise right there in your organization. So, some references and how to get a hold of me. That is my cat sitting on 3D printed components of a typewriter that I'm building. And if you want to talk about that, that' be fun later. Okay. [laughter] Um, but yeah, any questions? [applause] Anybody in the audience have any questions for Elizabeth? Great talk by the way. >> Yeah. Um, I will start on this side. Anyone from this side since I'm already over here? Anyone? Anyone on this side that wants to ask a question? >> Oh, there's one over here. Back. >> Where? Oh, over there. Okay, perfect. >> All right. Thank you very much for sharing your reflections of two decades. Uh, it's really interesting to see how you navigate and through all these uh different projects you contribute. Uh what are the key uh lessons for um fresh for example who is like right now uh there are there is a community base from the developer side which was not ready I think in the in the past years. So uh it looks like from your presentation that you have been part of many projects. So what is your take about uh specific uh sticking to one open source project and make it happen u and sticking to it uh as opposed to hopping many projects. So what is your recommendations for uh uh developers out there who are in the market uh who want to make a difference apart from their 9 to5 jobs? Mhm. >> Um how should uh they what mistakes they should not make? Yeah, that is a very very good question because I I noticed you know you're you're paid to do a job and your job is working on that open source project like what happens when you want to move on from that and I I think I think I've left a little piece of myself in every open source project I've worked in and I to some extent I have somewhat stayed involved in that community or at least offered a gentle handoff of the work that I was doing because the fact is like people understand that people change jobs. Um they know that like open source stuff is is you know you do move on from things. Um but I will say just like being aware that when you join an open source project you become responsible for something. And just because your job changes doesn't mean that responsibility goes away. And so I've tried as hard as I can like when I'm transitioning jobs I'd be like listen guys like I have to go work on this other thing now and like now it's time for me to hand off. like here's what I did in the project and this is what you're going to need to replace and those transitions when you're upfront about it and also like I didn't I didn't fly to Mars right like you can still reach out to me and a lot of the work I did in OpenStack people were still messaging me like a year later and I'm like oh yeah yeah sure I I've even like hopped on pull requests and things like just like oh can you review this because I know you were really did a lot with git um and so sometimes I do just pop back and do a little free work right on something that I worked on in the past um and I still like in in Debian community. I'm still involved with the Debian community. That was like my first big open source project. I still work a little bit in the Ubuntu community here and there. Um, and I I still have some very good friends from that time. But just making sure that you I mean I wouldn't say that it's like a lifelong commitment to every open source project you touch. But understanding like feeling that commitment and understanding that that was something that you did and something that you were responsible for and just a gentle handoff would be my my strongest suggestion. Um, and for me, I mean, I never like I love doing all this stuff. So, it was never like work work for me, right? Like some of it was work work, but like, you know, I didn't mind hopping back on OpenStack for a few things here and there, even when it wasn't my job anymore, just to ease that transition because they they the people I worked with were my friends and colleagues and like I cared about them and I didn't want to leave them just, you know, without my without my expertise there just because my job changed. So, just kind of be mindful of that. Don't go overboard with it necessarily, but just be thoughtful about the fact that you are a key person to the project and don't just drop it off the floor and disappear. [laughter] >> Oh, we have another >> Thank you. Hi, thanks for the presentation. Um, I was curious about your experience with software defined vehicles. Um, did any of that work ever take you to transit agencies? like was there any overlap with that or was it mostly like you know light duty single-use vehicles? >> That's a that's a I it did not trend move over to other ones because the focus was really like I mean it's that one is more of a working group. So they really are focused on like doing research and like collecting input from the industry to just like put out into reports and then discuss of what the the like the biggest problems are I guess in in the space. So they really were like hyperfocused really on like individually owned vehicles in that in that case. Yeah. But I think there's there's plenty of opportunity and one of the reasons I put together this talk is there's so many industries we're not in yet that I think we need to be in. Um and the we're kind of like I think we got the lowhanging fruit already and by going into like automotive and stuff we're starting to do harder ones but I think there's industries out there that we have we really need to bring some more open source into um because there's a lot that can be shared between organizations. We have time for one or two more if anyone in the audience has any questions. I know everyone is um looking forward to lunch. So if not um thank you all for coming. Yeah, give Elizabeth a hand everyone. That was a wonderful talk. Thank you. [applause]