Show Notes
This conversation covers:
- Laying the groundwork for a successful open-source program office (OSPO).
- Why legal and engineering are usually the two main stakeholders in open-source projects.
- Why engineering teams tend to struggle at articulating their perspective on open-source. Tobie offers some improvement tips.
- How Tobie defines open-source strategy. Tobie also explains the risk of not having an open-source strategy, as well as his process for helping organizations determine the best strategy for their needs.
- Common challenges that businesses face when deploying open-source software.
- The secondary — or non-code — benefits of open-source, and why many organizations tend to overlook them.
- Tips for engineers in non-technology organizations like pharmaceuticals or finance to approach business leadership about open-source.
Links
Transcript
Emily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.
Emily: Welcome to
The Business of Cloud Native. Today, I am talking with Tobie Langel from
UnlockOpen, and I wanted to start, Tobie, by just asking, you know, what do you do? Can you give us sort of an introduction to what you do, and how you tend to spend your days?
Tobie: Sure. So, I've been back into consulting for a number of years at this point. And I essentially focus on helping organizations align their open-source strategy with business goals. So, it can be both at the project level—so sometimes helping specific projects out—or larger strategy at the corporate level.
Emily: So, I actually recently had Nithya Ruff, who's the head of the OSPO at Comcast on the podcast. For listeners who don't know, that's an open-source program office. So, are you sort of an outsourced OSPO for companies that aren't Comcast’s size?
Tobie: So, that's a really good question. My answer would be no, but it tends to happen that I help companies build that capacity internally. So, I would generally tend to come up before an OSPO is needed, and help them figure out what exactly they need to build. For OSPO, my pet peeve is companies building OSPOs like they need to tick a checkbox on the list of the things that they have to do to be up-to-date with good engineering practices, if you will.
In general, if you want to be successful, with an OSPO, it has to meet the particular needs of your company, and that's usually kind of hard to figure out if you just leave it to whoever in the organization is more interested in driving that effort. And so essentially, I sort of help in the early stages of that by bringing all of the stakeholders at the table, and essentially listening to them and making sure that what they want out of an OSPO is aligned between the different stakeholders and matches the overall strategy of the company.
Emily: And who are the stakeholders that you're generally talking to?
Tobie: So, essentially, open-sources is strange, for one reason, in terms of how it was adopted in companies from a historical perspective. Adopters have always been essentially engineers who just wanted better tools, or the package or the software that best fitted their current intention, and there's a very, very grassroots process by which companies start using open-source. And what happened at some point is companies sorted to see all of the software, and got concerned, and started trying to assess the risk. And so companies just tended to bring in the legal arm and lawyers at this point. And so to fulfill compliance questions, you bring in lawyers, and then the responsibility of grown-up open-source kind of falls on to lawyers, which tends to be problematic from the perspective of good engineering practice and velocity that you want from your engineering and product side in a company.
And so clearly, the two stakeholders or the two main stakeholders tend to be legal and engineering, and there tends to be a tension between these two sides. And in lots of companies this tension, instead of being resolved to some degree, tends to be won by the legal side that understands business concerns better and is better able to praise or explain what they do in terms of business impact and business risks than the engineering side. And so this equilibrium tends to create OSPOs which are legal heavy, process heavy, and don't really give engineers the kind of freedom that they would need to be effective in their daily engineering practice. And the reason behind that being essentially over exaggerated risk perception of open-source because, to be frank, open-source is not well taught in legal school and clearly not part of the curricular that most lawyers are familiar with when they move into helping tech companies out. So, essentially, I sort of tried to bridge these two worlds.
Emily: I can imagine that being an open-source lawyer, that's a niche, that's a very specific niche.
Tobie: Yeah, actually there's a running joke in that community, which is, “As soon as you get your law degree and you’re an open-source lawyer, you’re one of the 25 best open-source lawyers in the world.”
Emily: [laughs]. That's awesome. Why do you think engineering teams are so bad at clearly articulating their perspective on open-source, and what can they do to improve?
Tobie: So, there are clearly multiple reasons why engineers aren't the best at articulating how open-source matters. So, I think one of the key ones, it's just, it's something that's part of their daily practice, and they don't really understand and never have been taught the actual intellectual property—IP—impact, that open-source has on their company, and they don't really understand how others in the company might perceive this IP impact. So, I think, one part of it is, essentially, this is just how engineers work. Like, you want to use a piece of software, you put it in it, right? If you want to fix something, well, you do a pull request. This is sort of, like, a common practice. And it's always hard to articulate things that are essentially part of your, like—you know, like a native language, like part of your culture. It's really hard to describe, why you would do this, and why it matters. So, I think that's one reason.
The other reason, I think, is that there is a lot of overlap between the way legal works, and the way business works in general. Few examples of that are, engineers tend to think really like in binary way, like, you know, something is true or false, something is on or off, whereas business and law a much more spectrum thinking and into the gray area of things. Similarly, law will share with executive manager’s schedule, versus a maker’s schedule. So, there's lots of cultural artifacts of law culture in corporations that are much closer to business culture, and so, just a better understanding. So, I don't think engineering is really bad, per se. I think it's just bad when you compare it to legal, essentially.
Emily: I mean, and clearly, like, lawyers, their whole training is about making arguments for things that they believe to be true. So.
Tobie: Fair enough, but honestly, when you hear engineers talking to one another, that could be said, of engineers, too.
Emily: That's fair.
Tobie: Your second question was, how can engineers improve that?
Emily: Yes.
Tobie: And I think that's actually something that they can do and that has way more benefits than just making it easier for them to contribute to open-source, or to have a strong open-source culture at their company. And I think that's essentially focusing on the customer-facing business value, if you will, of what they are building. And if you can start articulating all of what you do in terms of how it affects the business, how it affects end-users or end-customers of your products, it gets way easier to have weight in conversations with other people within an organization that reason about this that way.
Emily: And I would imagine this applies not just to making a case for open-source, but everything in engineering. Making a case for using containers, making a case for changing something in your architecture, investing in engineering, hiring a new person—
Tobie: Absolutely.
Emily: —you have to learn to make the case in terms of the business impact.
Tobie: Yeah. It's interesting because we always look as growing up or leveling up as an engineer in terms of actual ability in your craft. But what really makes a difference is how you can leverage your craft to pursue broader goals, organizational goals. And yeah, you're absolutely right that skill set is useful, just, like, across the board. So, are soft skills, by the way, which is another thing that engineering tends to forget about, unfortunately.
Emily: So, going back to what you do in crafting open-source strategies, what is an open-source strategy, and what's the risk of not having one?
Tobie: So, by strategy, I sort of think about the plan that you have to meet certain goals that you care about meeting. And so an open-source strategy can be widely different depending on what those goals are, and what those organizational goals are. Some companies will have—their main business will be extremely tied to open-source software—you know, think like a company like MongoDB, or Redis, or Mozilla, for example—but for most companies, their business is kind of far away from actually producing open-source software. And so, an open-source strategy for those will be one that is more aligned with, like, how exactly can open-source help our organizations serve our clients better? The same way you would use DevOps to some degree. Or even, like, you know, Cloud, for lack of a better example. So, really, about how can you leverage these tools to help meet organizational goals?
Emily: And then what happens if you don't have a strategy?
Tobie: Oh, well, what—that's what happens when you're missing a strategy for anything else: you essentially end up at best copying what others are doing—so, you know, you're sort of late to the game—and that worse, just running around aimlessly. If you don't know why you're doing something, you don't know what to measure. And this is true of everything. I mean, this has nothing to do with open-source. You don't know what to measure, you don't know where to invest, you don't know if what you’re investing is actually giving you a useful return on investment. You know nothing, and so you're probably better off just not doing anything.
Emily: When you meet with these different stakeholders in a company, how do you help them figure out what the best strategy for that particular company is going to be, in relation to open-source?
Tobie: So, if we're looking at companies who are not essentially trying to monetize an open-source project, the way I usually start looking at that is looking at what are the current points of frictions? What are the challenges and the problems that a company is facing to run its software, its engineering operations with the kind of performance level that it would want to do? And this can be broadly different things. It could be an organization finds itselfs to be fairly siloed, and finds it really hard to collaborate with teams in different parts of the organization. It could be having a really hard time filling in their hiring pipeline, or having retention issues. There are just plenty of different problems that show up.
Then the second thing that we tend to look at is if they had a magic wand, if you will, what would their future look like? What would they want to achieve? And once we have this current situation and future desired state, we look to see at what part of open-source can actually help this transformation. And for that, what I do is I—there's a talk that I've given a number of time, called, “Making the Business Case for Open-Source,” which essentially focuses on all of these different aspects of open-source that are beneficial to companies, which I called byproducts, or second-order benefits of open-source, which is not the output of the code itself, but all of the benefits that having a strong open-source culture brings to a company. And we'll look at those, and we see if there's a good fit.
Emily: And how aware do you find business leaders to be about the secondary benefits of open-source? The sort of non-code benefits of open-source?
Tobie: Mostly not, honestly. I guess it's actually surprising how few companies get that, outside of the tech giants, by the way. All of the large tech companies understand that really well. Everyone from Google to Microsoft to Facebook to Mozilla, everyone is doubling down on these aspects and knows that open-source is where you tend to find a lot of really good engineers and that open-source really benefits engineers and helps them level up, and helps them build things that are actually, then—end up being really useful internally, like soft skills.
I mean, I know that open-source has a really bad rap, and there are reasons for this, and there are lots of things that, as a community in open-source, we have to improve. I don't want to be dismissive of that at all, but if you’re actually able to collaborate and get alignment in a large open-source project will you have—you can't go through like your manager to get your manager to speak to the manager of the person that's not complying with whatever it is that you want because it turns out, they're in a completely different company. When you're able to be effective in an environment that is as hostile as that one, once you bring that skill set back internally, you're highly effective. So, these benefits exist, and large tech companies understand these benefits really well. Outside of tech, though, that's not the case.
And when you look at the data, it's that's really telling because we have today really good datasets, per industry, of how much different industries use open-source, and frankly, at this point, pretty much there's open-source everywhere, in every industry, and in every project in every industry. But, however, when you look at what industry—what vertical—actually has, built-in, a large, a strong open-source culture and is contributing to open-source, like outside of tech—where it's roughly 50 percent of tech companies contribute to open-source, often on a regular basis, outside of tech I think the closest is finance and financial services, and it's like 12 percent, or like 13 or 14. It's really, really low. So, tech has it, the rest of the world, not yet.
And to some degree, that's also why open-source is actually a real accelerator of how companies are able to build the kind of tools that they need to respond to their business needs. It's not by accident that you find that the companies that have the highest growth—market growth as a company are those that are heavily invested in tech and heavily invested in open-source. And so it's not surprising that incumbents from all the verticals are having a much harder time to adapt, and as a result are also, in verticals where there's lots of competition, lots of new players, lots of new startups that are, sort of, like, stealing market share, and disrupting those different markets.
Emily: You've said a lot of things that are really interesting. I wanted to ask, though, again, about this idea of helping people develop soft skills because honestly, I had never considered that as an advantage of open-source. Could you just sort of talk a little bit about how that happens, and how individual engineers can use working on open-source projects to develop soft skills, and then how it translates to better success in their employment situation?
Tobie: So, if you look at how software is built in a closed-source project, you will essentially be working with your peers. I mean, that's not always the case, but in most cases, people that you can literally, like, turn your chair around and tap on the shoulder to get help. In open-source that's very different. Large open-source projects will have people across lots of time zones, and completely different stakeholders.
You will have in the same project, someone that is just passionate about this project and is a teenager in a high school that just really cares about whatever it is that you're working on. You’re going to have a bunch of folks in academia, actually using that project to run some data internally or something like that. You will have small companies building plugins on top of it or doing agency work. You will have large corporations leveraging that project. So, you will have this very broad stakeholder set of people with very different backgrounds, very different interests, very different reasons to be involved, essentially.
And I mean, just that, just this diversity of background and culture will make you up your communication game because you will not be able to speak to these very different stakeholders. If you want to get something out of them, if you want to review one of their pull requests, if you want to get them to sign the CLA, it's not the same as turning around and tapping your colleague on the shoulder that, unfortunately, tends to be roughly the same skin color, age, and gender as you are in lots of different teams, still today. So, I think that's the first point is just, lots of stakeholders, with lots of different interests, coming from lots of different places.
The second bit is, a lot of software is about communicating what you want to do and what you're hoping that they're doing. And that's harder to do in return, frankly, for most people. And it's harder to do, again, when you have sociocultural gaps. So, learning how to do that properly to get alignment on something, this is a skill, you have to learn. Thirdly, the absence of formal leadership in—which is what I was mentioning before—in projects and by formal leadership, I mean, yeah, sure, there's like a technical steering committee, or a [
00:21:05 unintelligible], or someone's leading the project, like maintainers and stuff, but they don't get to tell who does what.
So, if you want help from someone on a project, you will have to learn how to use your soft skills to do that because you can't make anyone comply to anything. It's this completely soft, smushy thing. We don't really have—you can't hold on to someone and tell them, “Go do this PR now,” or, “Go review this.” You will have to figure out ways of getting people to be involved using a completely different skill set then force compliance.
And this is—I mean, I might be cutting corners here, but to me, this is what leadership is about. Leadership is about aligning people in the mission without a whip. And this is precisely what you're doing if you want to do anything in open-source. And this set of skills, once you’re back in a company—I mean, any kind of serious project, impactful project in a company will be across multiple teams, multiple orgs, you'll have to get approval from, like, policy, you'll have to go see legal, you’ll have to get designers involved, you’ll have to get product involved, you’ll have to get infrastructure invol—like, all of these organizations that you don't have direct power over, learning this set of skills inside of an open-source project prepares you for this so much.
Emily: Interesting. Yeah. You know, you could have a project, and legal could say, “No.” And you don't get to just override what legal says if they say no. You have to have the skills to negotiate a way out of that, basically.
Tobie: Yeah, and frankly, I mean, if you look at sort of the career ladder of an engineer, it's essentially around growing your impact inside of an organization or company. And growing your impact, I mean, that is done laterally. It's done by getting others aligned on your vision early in the process. And again, it's interesting because there's lots of parallel between what I'm describing right now and what I do for a lot of my clients, which is to get alignment from all of the different stakeholders along a specific set of goals. And this is only soft skills: it's listening to people, figuring out what their needs are—when legal says, “No,” I mean, no one ever says, “No.” People say, “No,” and they mean, “Oh, this is going to make me too—too big of a cost for me. I don't want to do this right now. It's easier for me to just say, ‘No.’ I don't really understand the risks. I don't really understand the value of this project.” I mean, behind the, “No,” there's a bunch of information. And building soft skills lets you have the tools to go figure out what that, “No,” that legal just gave you really is about. And it's way easier to address something like, “Oh, there's actually—I'm concerned about this specific risk at this specific place,” than addressing something that's as vague as, “No. Legal said no.”
Emily: And how would you say that an engineer that’s, say, in a non—technology company, as in you know, not in the technology vertical, they are in a company that sells cars, or pharmaceuticals, or financial services or whatever, what are the specific ways to to make those business arguments to talk effectively with business leadership?
Tobie: So, one of the consultants that is a consultant for consultants, David A. Fields, talks about ‘right side up thinking’ and he's essentially talking about, put yourself in the shoes of the people that you're talking about. Understand what it is that they care about, and then have answers to that. Which, to me, is also something that you can build in open-source, but it's essentially listening to people. I mean, there's so many times I've been in a meeting with lawyers about a particular topic for a client or for a company I was working with, where I got out of a meeting with much, much more than I expected, essentially because instead of opening my mouth, I just shut up and listened to what it is that they were concerned about, and really tried to understand from their perspective.
And then realize that all of the schemes I had in my head of what it is that they wanted, and the solutions I had for what I thought it was that they wanted, were not necessary at all; what they cared about was something completely different that I just couldn't know about. And so, that would be my biggest suggestion is, just shut up and listen to what people want. Same for customers, by the way. I mean, when you're facing customers, just actually listen to what people say.
It doesn't mean that you have to essentially implement precisely what solution they're giving you, but you have to listen to what their problem is. As an expert—and that's true of an engineer in a non-engineer context: the engineer is the expert, but your expertise should be applied to turn the need, the requirement, into something that's implementable. That's its only purpose, really. It shouldn't be about asking people, “Well, so would you want to use PHP or Rails for this?” And then giving them a lecture on both. This is not what someone some business wants to hear about.
Emily: Excellent. We are going to go ahead and wrap up pretty soon, but anything else that you would like to add about bridging the gap between business and engineering?
Tobie: Yeah, so I think that at the end of the day, what really works is when everyone is aligned, and pulling on the same rope, aligned with the same goals. If you're in a company, where the underlying goals really don't match at all your vision of what you want to do, you're in a bad place, regardless of what vertical that company is in, whether it is a tech or a non-tech company. So, I think that engineers, if they're able to and, again, I mean, not everyone is in position to change job or hop to find a different job, and the job market right now is particularly difficult, but I think that if you want to be happy in your job, you have to make sure that there's alignment. And if there isn't, at least try to carve out areas of alignment.
And don't try to win every fight: really go for the things that matter to you that make a difference, and make concessions. Actually, that's the other, for me, the really key point is, make concessions. If things don't really matter to you but make a huge difference for the person that's in front of you, make a concession even if you think it's silly. As engineers, we really have, again, this really binary way of thinking. Admit that there's a lot more to all of this then yes or no, and that there's a whole bunch of area in the middle where people can meet and find agreement, and focus on that stuff.
Emily: Excellent. All right, just a couple last questions. What is your favorite engineering tool that you couldn't live without?
Tobie: That's an interesting question. I don't think I really have one. I think that's deliberate. My goal would be to be able to jump on a new machine and be effective within seconds, and not have to go through the whole ordeal of having to set everything up just to right for me. So, I tend to try to work with whatever is there. I also don't believe that a good engineer is an engineer that types fast. Actually, I'm a really slow typer, so maybe that's why. But yeah, I really believe that it's not about tooling, it’s about all of the other things, and that tooling should come last. So, I don't have any is my answer.
Emily: Fabulous. And then where can we listeners connect with you or follow you.
Tobie: So, I tweet quite a bit under
@tobie. So, T-O-B-I-E. There's lots of politics there, too, so if you believe that tech and politics are not linked, you probably don't want to follow my account. And then there's the website of my consultancy, which is
unlockopen.com. So, unlock and open in one word, dot com.
Emily: Excellent. All right, well, thank you so much for joining me.
Tobie: Well, thank you for having me. This was fun. Thank you so much.
Emily: Thanks for listening. I hope you’ve learned just a little bit more about
The Business of Cloud Native. If you’d like to connect with me or learn more about my positioning services, look me up on
LinkedIn: I’m Emily Omier—that’s O-M-I-E-R—or visit my website which is
emilyomier.com. Thank you, and until next time.
Announcer: This has been a HumblePod production. Stay humble.