Wicked Good Development is dedicated to the future of open source. This space is to learn about the latest in the developer community and talk shop with open source software innovators and experts in the industry.
In the latest episode, Russ Eling, Founder and CEO of OSS Consultants, sits down with Kadi Grigg and co-host A.J. Brown to discuss his journey with open source. Tune in to hear valuable lessons learned during his tenure as an Open Source Compliance Officer at General Motors and how that eventually led to the creation of OSS Consultants.
Listen to the episode
Wicked Good Development is available wherever you find your podcasts. Visit our page on Spotify's anchor.fm
Show notes
Hosts
- Kadi Grigg - Host - (Twitter: @kadigrigg)
- A.J. Brown - Co-host (Twitter: @adrianjbrown)
Panelists
-
Russ Eling- Founder and CEO of OSS Consultants (LinkedIn)
References
Transcript
Kadi 00:09
Hi, my name's Kadi Grigg, and welcome to another episode of Wicked Good Development where we talk shop with OSS innovators, experts in the industry, and dig into what's happening in the developer community.
A.J. 00:18
Hi, my name is A.J. Brown, I'll be your cohost. Today we hope to bring you up to speed on the latest in the community through our conversations.
Kadi 00:24
On today's episode, we sit down with Russ Eling, here to talk about a few different subjects within the OSS community. But before we jump into that, Russ, do you mind introducing yourself to everyone at home and telling us a little bit about who you are and what you're doing here today?
Russ 00:40
Yeah, sure. So it's great to be here today. Thanks so much for having me. So I'm the founder and CEO of OSS consultants. We're a business that's dedicated to helping organizations of all sizes design, implement and manage their open source governance programs, which can sometimes be referred to as an OSPO. Before starting the company, I spent over 20 years in several engineering roles at General Motors. I had responsibility for designing and implementing a successful open source software governance program at GM, which happened to be among the first of its kind–at least in 2013 in the auto industry–and was once regarded as amongst the most comprehensive open source programs in the auto industry. As the Open Source Compliance Officer, I had built and then staffed the OSPO responsible for reviewing software in every part used in every GM vehicle anywhere in the world. And then today, you know, myself and the rest of the team here at OSS Consultants, we offer our recognized industry-leading expertise to help companies of all sizes–from the world's largest and well known companies to even small companies and startups–create the most efficient, comprehensive, and robust open source programs and policies on the planet.
Kadi 02:06
Well, thanks for being here, Russ, and thanks for the intro. Let's dive in. So before we get started and kind of unpack all that goodness that you kind of just teased everybody, right in that intro, by telling us a little bit about who you are and what you've done. Can you tell us how you first got introduced to open source at GM?
Russ 02:26
Yeah, it was <Laugh> an interesting story. So I guess a little background about what I did at GM. Well, I guess my career at GM was as an engineer, and it was such an amazing experience. I joined at a time when vehicle electronics was going through so much evolution and change. So this was like 1999 and you didn't have anymore this like one electronic control unit, or control module for an engine in transmission. And then one for lighting and other interior type functions, or maybe one for antilock brakes or something. But now at this point, 99, we're getting into electronic control–or starting to get into electronic control modules for seats and doors–and radios with navigation screens and instrument clusters.
Russ 03:25
And then soon after that telematics like OnStar. So it was like we were getting a separate controller for all of these different functions. How would these devices communicate with each other and then how would they present that information, or any information, to a driver? And so not only was I really immersed in the electronics and software side, but also happened to be getting lots of exposure to the complexities of the automotive supply chain and the importance of bringing all these pieces together in a meaningful and, usually, hopefully, cohesive way to the driver, and eventually to other occupants in the vehicle as well. So I'll fast forward a decade or so to about 2012. I happened to be finishing my senior law classes in my MBA program that I was in. My director at the time was signing my tuition reimbursement for the last law class in the program.
Russ 04:23
And we were talking about what I learned, which happened to include copyright law and intellectual property trademarks. And then how did that apply to technology or specifically even what we were doing? And he said something like, you know, use of open source in the vehicle is becoming a thing. Well, I guess I'm paraphrasing a bit here. <laugh> But we need someone to lead this. Why don't you see if you can occupy part of your day with this? And you know, it's funny to look back now because it was like 25% of my time and then 50% of my time. And then all of a sudden it became my full-time responsibility. Then I had to hire people, and then we've got this fully staffed team, and then our responsibility was to review and approve all use of open source in any GM vehicle, anywhere in the world. So, you know, not exactly a small task.
Kadi 05:15
You mentioned that you were taking legal classes and I think that's interesting. What insight did that give you on using open source? I mean, fast forward to now, right? Like there's a lot of real world implications, but I feel like having that background or general understanding before it was even really something so prevalent in development culture. I mean, that's gotta be an interesting, like, lens to be looking at it when it's kind of like a fresh area of the market.
Russ 05:43
Yeah, I think so. And we didn't specifically–especially back then–I don't think colleges broadly were talking about, open source, and open source compliance, and things like that. But we did talk about software and software licenses broadly. But I think it was just this application of how did the software we were developing–or the technologies we were working on–how could you look at that from a legal perspective? Or maybe like, as an engineer, I was very familiar with how do we treat requirements? How do we define requirements? How do we comply with requirements? And then when you add this legal lens, and by no means I'm not a lawyer. I took two or three law classes. But it did give you that little bit of insight into, okay, well lawyers or the law might look at things like this. And I often give that analogy, I often end up being a bridge between the development community and the legal community.
A.J. 06:50
So it sounds like initially when you started up with the open source program at GM, it was largely focused on the legal aspect. Is that right?
Russ 07:00
Yeah, so the legal aspect was–I guess if we can narrow it down a little bit–it was more on the compliance side. So legal was aware that open source licenses were...we were starting to see this from vendors, from suppliers, and legal was managing it in those early days, and they could see the growth and they just weren't staffed to deal with it. So they were giving some pushback onto the engineering and product development teams. And it was through that, my director happened to hear about it and Volen told me to <laugh> to do this.
A.J. 07:40
Those are always the best tasks, the Volen-told ones. So yeah -
Russ 07:45
You know what, it happened to work out actually. <Laugh>
A.J. 07:48
Oh, yeah, yeah. <laugh> It's interesting that you kinda had this legal compliance thing that was working with open source and it sounds like there was already a security program, or team, or whatever, and then eventually those two kind of merged together.
Russ 08:04
They didn't really merge. The open source group ended up moving from product development into security. A large part was, as you've already talked about, this overlap of open source security and open source compliance, and I'm sure there'll be other topics that we'll get to that deal with both as well. But also they had the budget and the resources–as they were a fairly new group within GM at the time–that they could also help us grow from a staffing perspective.
Kadi 08:41
So I wanna back up a little bit. You know, you've come kind of a long way in your open source journey we'll call it right, Russ? So when you first started trying to look at how open source is used across all these different business units that you mentioned in the beginning what were some of the things that you noticed that were a little bit unique to the use of open source within the automotive industry?
Russ 09:06
Yeah, so there's a couple things there. In my years prior to open source at GM, I had often dealt with multiple processes for accomplishing the same task when there were multiple business units involved. So I knew that when I was starting up this process, that I really wanted to have a single process for managing open source so that no matter which part of the company you happen to work in, you'd be following the same basic process. And then we had a similar process for open source that came from our supplier's minor differences, but mainly due to the type of information that we would receive from the suppliers. And Kadi, what was the second part of your question?
Kadi 09:48
More on what you were noticing that was unique in open source in the automotive industry.
Russ 09:53
Oh, okay. So there are some interesting uniqueness <laugh> aspects here. So I think a big potential issue or uniqueness in the auto industry is managing in-vehicle compliance. So there's so many things to consider. For example, what do you do when you have an embedded control module that's using open source, and that control module doesn't necessarily have a display screen? So where do you put the copyright notices and the license text? So depending on the amount of open source you might be using, the licenses and notices could take up quite a bit of space in the owner's manual. And then what about all the other control modules in the vehicle? You know, are you gonna end up with this encyclopedia size owner's manual full of just licenses? And then what about all the different vehicle models that have different content and features, and therefore different types and amounts of open source? So I think that's pretty unique and I think that can bring a lot of complexity to managing this in some industries. And in this case, specifically, like automotive.
A.J. 11:06
That's the first time I've heard something like that, right? A control module, I gotta produce the license, gotta put it somewhere. It's gotta be in a manual. How does that affect downstream, like to developers when they're choosing their components? And let's say that from version one to two the license might change, right? Are there checks and controls that you have in place for that?
Russ 11:29
Yeah. So when you're talking about open source that's developed internally–so within a company, so within their own engineering centers–you would have an internal process for that, where something like that would be subject to scan and review versus if it was coming from somewhere in the supply chain. You might put that requirement on the supplier that they would have to declare when a license changed due to a version change, but definitely part of the process,
Kadi 12:06
You know, all these different vehicles, models, those different things. I would think that's an enormously complex project, especially when you're starting to kind of wrap your arms around the scope of this. How did you even go about doing that when starting this?
Russ 12:22
<Laugh> I really approached it from a systems engineering perspective. It was to come up with this holistic view, of how this would work broadly across the entire organization or the entire enterprise. Obviously there was a lot of learning and changes, especially in the earlier days. And then once we started adding people and functions, responsibilities to a dedicated team, it evolved again. But my goal, and still my goal today, I wanna make it very easy for a developer to do the right thing. And sometimes that means shifting that complexity to other parts. If you're talking about a dedicated OSPO, perhaps the scanning and the audit function goes to a dedicated or centralized OSPO, as opposed to having developers do their own scans. But that might be another way to achieve easier compliance.
Kadi 13:32
So once you kind of understood, right? Really wrapped your arms around the scope of this project and understood what you were working with, what were some of the hurdles that you came across in trying to get everything on an even playing field? You know, not even playing field, but when you're trying to stack rank everything right? And like make everything uniformed across all divisions.
Russ 13:57
Yeah. Despite the use, I think, of open source there's still employees, suppliers, etc that need to be educated on the compliance side of managing open source and why that's important. So, I guess, broadly it would be like awareness and education. And then this can lead to sessions over the years–or this did lead to sessions over the years–with different global engineering teams that were developing software. And I mean, this is probably pretty common finding at many organizations.
Kadi 14:39
I know that you've started your own consultancy practice. You're a founder at OSS Consultants. Having moved from open source compliance officer, what is it like now having transitioned into running your own practice and kind of how did that start?
Russ 14:53
I guess having been at the forefront of the growth of open source in the vehicle–or in the automotive industry–and with the vast number of other companies, and in the automotive industries I was dealing with, people started coming to me for guidance on how they could set up similar processes at their companies. And I love what I did at GM and how I was able to help others along the way. It just seemed to make sense that my next logical step in my career would be to do this. So I took the plunge and I left a very large, very stable employer that I was at for a long time and I went off on my own. And for me, while it's been really a lot of work, and a lot of stress, and new things to think about like employees and business and taxes and all kinds of things, accountants. You know, I absolutely love what I do. It's been some of the most rewarding work in my life. I love helping companies come up with strategic and efficient ways to manage open source so that it works for them. And as I mentioned earlier, I'm really interested in like a holistic solution that doesn't just cover developers, but also legal, procurement, security, or the overlap of security export controls, and others.
A.J. 16:12
So in your work as a consultant, do you have a list of–or a framework–of like philosophies, best practices that you can start off with for people that are starting off new, or that are trying to reimagine the way they're doing development?
Russ 16:25
I mean, I think everybody hears about the need or the importance of having a policy, and following a process and having an OSPO. But sometimes you really just need to start with the basics. If you're not really doing anything today to manage compliance, don't let perfect be the enemy of good. Every organization has its constraints, whether it's people, funding, tooling, support, whatever. It's important to start somewhere. Aim for the lowest hanging fruit. It's absolutely fine if you have to start with an Excel list of the open source you know that you're using until you can get support for a proper scanning tool, or resources to staff a team, or even to staff an office of one. Every company's at a different stage of maturity with this, but specific actions could be to get support from your leadership to make managing open source more robust. Engage your legal staff to help build your case for why this is important.
Russ 17:30
See what you can do from an automation perspective. Is there a way that you can somehow monitor your dependencies if you're not already doing that? And then some companies find themselves in a place where they need to do something more urgently. So whether that's due to customer demands or an external compliance request–which has been coming up more often–or possibly from new regulation, like ESPOM. And then they call in experts like us to help build something more quickly, or to help them with defining next steps, or a roadmap to getting to where they need to be with managing their use of open source.
A.J. 18:08
Earlier you said something that resonates well with me. It's you wanna make it easy for the developer to do the right thing, right? And so you're kind of shifting some of that information to the left. Do you have any advice for the developer who is experiencing the change that your company is coming in to help their business with to maybe convince them, or have them believe that this is the right thing to be doing?
Russ 18:37
Good question, AJ. <laugh> When I say that I wanna make it easy for the developer to do the right thing, it's because I want a process to take a lot of the heavy lifting off of the developer. You might be surprised to find out that when I do developer training my sessions are typically under 40 minutes with Q&A. And that's because I don't expect you, as a developer, to become a compliance expert. I really need you to remember like two or three simple rules. And then we let the process and the people that are in charge of the open source manage the rest of it. So they take that heavy lifting off of you and make it easier to do your job. Like, I mean, it's a crazy concept, but imagine if a developer could actually spend more time developing software.
Kadi 19:36
You know, Russ, I think it's interesting too. What success stories do you have that you can share? I know you've been a pretty big champion for OpenChain out in the community. Is there any success stories or stories involving OpenChain that you can share with us?
Russ 19:53
Yeah, so there's one company I can talk about–and only because it's been disclosed publicly–otherwise, you know, other customers, I can't disclose due to agreements we have in place. But I think first, a little bit about OpenChain. Some people might not be aware of what it is, and I mean, I could just boil it down a little bit and say it defines what a good open source program should have, but it leaves it up to the company to decide how. So you definitely see more companies that are regularly announcing this. To answer your question specifically, Kadi, we were the first OpenChain partner to ever help an organization attain whole entity conformance to OpenChain. It also happened to be the first whole entity conformance of any company headquartered in North America. So that was Blackberry, and that was announced earlier this year. I think it was in March.
Kadi 20:48
<laugh> So like, what does actually being compliant with open source mean nowadays?
Russ 20:55
<laugh> I think, in short, it means complying with the obligations associated with your use of open source. So are you doing what the license says you have to do in order to use that software in your product or your distribution? And then to what degree? You know, you can't be kind of half compliant. <laugh> There's lots of companies that do well on producing, or reproducing licenses and notices, but maybe they fall short in the area of required source distribution, or redistribution, for the licenses that require that.
Kadi 21:31
If someone had to focus on like three things to focus on, and they're just starting on this journey, what would you recommend that they look at first?
Russ 21:39
Believe it or not? I find this at most companies that bring us in. Understanding what are your products or your services, what do your distributions look like? Or or what are they? Just coming up with a product list in some companies is a tall ask. No single list exists anywhere in, surprisingly, only a lot of cases. So I think that's really important. I think it depends on every company's, you know, their goals are gonna be slightly different. And where is this push coming from? From the open source? Where is this open source compliance push coming from? If it's from security, maybe they would want better identification of open source. So you'd get a good tool in place to be able to identify that. Compliance, same thing. You know, legal might be more concerned about better documentation, so that might be an area you'd wanna focus on. And that's something we help companies with. It's like, we help them figure out what do you wanna do next? Like what's important to you, what lines up with your company values? And let's make sure that's incorporated or that's a priority, and that's how we address what you want to accomplish.
Kadi 23:03
Where do you see open source in the next, say five, 10 years? I mean, you've seen us come through. You talked about 1999, we're in 2022, where do you see it going in the next five to 10 years? And if that's too much, we can dial that back down to a year.
A.J. 23:17
This is my favorite type of question.
Russ 23:20
<laugh> Oh my goodness. <laugh>. I mean, it's a good question. Fair point. I think we're gonna continue to see the growth in open source. We haven't seen that reduced in any year recently. You guys put out some great data and materials on the growth of open source. And I think as we see today, we'll continue to see over the next five to 10 years. I think this will be, you know, mainly due to the use of dependencies, and containerization, and things like that. I think over the next five to 10 years, we'll have some real world SBOM experience and data by then. So I imagine we'd be leveraging the lessons from that. I think identification of open source will continue to be a priority for both security and the compliance folks. And I think that'll likely drive new or enhanced tooling that can support, perhaps, faster identification and analysis or more automation. I'm sure you guys are working on cool things like that.
Kadi 24:28
Russ, you gotta have horror stories. Are there any that you can share?
Russ 24:30
Yeah, probably a few. <laugh>
Kadi 24:32
Everybody loves a good horror story that they can learn from.
Russ 24:36
Yeah. So, I mean, I think there's a couple interesting ones that come to mind. So one, this one might not be too unfamiliar at many organizations. We had one project that they happened to be using lots of open source. That happened to be from a major software organization that primarily uses the Apache license on all its own work. I won't name names. There were several files where after scanning we found the code was like a hundred percent match to this known open source aside from one minor, but very important detail. They happened to remove the Apache license and there was really no need. You know, there was lots of other parts of this project that also were using the Apache license, but why induce the risk? I think this particular developer was new and maybe was unfamiliar with the process.
Russ 25:29
Didn't want to get slowed down by any process, didn't know maybe we had an efficient process in place. But that was, you know, I think that's a common finding at a lot of organizations. I dunno if that qualifies as a horror story, but... <Laugh> Another interesting one was, so I was asked to help with the assessment of a supplier in a different part of the world. And when I was asking about using open source in this particular part they assured me, they said, we are not using any open source. And because of the technologies and things they were using, I probed a little further. I was asking, so what operating system are you guys using? And they replied Linux, so <laugh> it became pretty clear. They weren't intentionally hiding their use of open source. It's just they didn't yet know about the need or the importance of open source compliance.
Kadi 26:28
That's always my favorite, when people are horrified and they're like, we don't use it. And you're like, are you sure about that?
Russ 26:34
Yeah, yeah. Or then you run a scan and you find all these massive amounts of open source that they have to comply with. And the leadership is so mad that how did this happen? We told them you can't use open source years ago. <laugh>
Kadi 26:49
Every time.
Russ 26:51
<laugh> Yeah.
A.J. 26:53
I am curious, if you go back to your GM days for a second, as you're building out this program. I'm curious how easy or hard it was to convince, like, leadership that software supply chain exists being at an auto manufacturer that already has a physical goods supply chain, right. Was it easy to make that parallel?
Russ 27:18
So at the time, I had the most exceptional leader. He was my executive director–not the same guy who was signing my tuition reimbursement that I spoke about earlier–but he got it right away. He understood the problem. He understood the risk. He understood why this was important. And he communicated up and across, so up to as high as the C-suite, and he had the executive team–the C-suite–informed about open source, and he had me presenting to them and then to all of his peers. And I was able to make a lot of progress because now I was at all these staff meetings where these other executives are saying, you gotta listen to this guy. He's got some important things to say and we're gonna follow what he is doing. So, I mean, I think that was a really big lesson for me, was that you had this support from the top, and it enabled us to be a lot more effective and cover a lot more ground. That particular leader has since retired. I still stay in touch with them though. Just a fantastic person. Honestly, I don't know if open source would've been as successful at GM without his championing the work I was doing.
A.J. 28:50
That's awesome. So on that same vein in your consultancy, do you ever struggle with like explaining scanning as you're not just scanning components, but there's a supply chain and understanding that supply chain? You mentioned like pushing requirements on vendors to do certain things, right? Do you struggle with that concept?
Russ 29:13
Not generally on the concept of making suppliers disclose, or providing scan results, or whatever. I think it's getting the boots on the ground and how do you make that actionable for everybody across the entire enterprise? Because every product team has a slightly different supply chain potentially.
A.J. 29:46
So at least in my experience here at Sonatype, when we're talking to customers, like the idea of I have these components that I need to understand and manage from security, legal risk perspective makes sense. But then the broader concept of a software supply chain exists there, right? And other developers are part of that, and other vendors are part of that supply chain and end up in your product. Do you ever...or I should say, is there a struggle to kind of explain that bigger picture of the software supply chain, understanding that when you're implementing these programs in your customer?
Russ 30:24
Yeah, usually not. Again, it's kind of that getting that broad awareness across all the different product teams and having them be able to push requirements to their suppliers. That this has to be disclosed, or scanned, or complied with, whatever that is for them for that particular product. That's often the biggest struggle. But fewer and fewer, I mean, like we're not seeing as much where people are not aware of supply chain issues. I think almost everybody is aware that they're part of a software supply chain and they have people providing software to them, whether that's commercial, or open source, or other proprietary software, and that we still have to consider what might the licensing implications be from an open source perspective?
Kadi 31:21
Well, that's music to my ears. <laugh> Yeah, that's amazing.
Russ 31:26
Yeah, no, I think, I think industry's done a...and I mean, the news certainly helps with all the security incidents that have happened. And I think there's a lot better awareness out there today for that.
Kadi 31:38
You know, I do kind of agree with you where it's almost like if you haven't heard about this now, I'm not sure where you're living or if it's under a rock or what, but, you know, it's in the news all the time.
Russ 31:49
Yeah. I think I saw a big spike after the Log4j, you know, that incident. I think that was in December last year 2021. And I saw a huge spike there where people–all of a sudden–it clicked and they got it that this could come from elsewhere, and they should be concerned about it. So -
Kadi 32:11
Yeah, I would agree.
Russ 32:12
Again, this year I found definitely fewer people asking about importance of supply chain, where most people recognize it's important. It's execution on how do you manage it?
A.J. 32:25
Yeah. The Log4j one had friends and family calling you up saying, what's going on with this thing? It was a great opportunity to talk about software supply chains–which of course bored half of them to death–but they gotta hear about it.
Kadi 32:36
Same with my family. My mom just like looks at me, and she's like boring Kadi and walks away. And I'm like, all right, you called me <laugh> Okay, well, I don't think I have any more questions, Russ. I don't know, AJ, do you have any others?
A.J. 32:53
I do not.
Kadi 32:54
But thank you so much for taking the time for this, this was really fun today. And it was really fun just hearing your story.
Russ 33:00
Thanks so much for having me.
Kadi 33:02
Thanks for listening to another episode of Wicked Good Development brought to you by Sonatype. This show was co-produced by Kadi and Omar Torres, and made possible in partnership with our collaborators. Let us know what you think and leave us a review on Apple Podcast or Spotify. If you have any questions or comments, please feel free to leave us a message. If you think this was valuable content, share this episode with your friends. Till next time.
