The Importance of OSPO with Nithya Ruff

Nithya Ruff has been working in open-source since 1998, when the trend was still new for companies. Today, she is now Executive Director of Comcast’s Open Source Program Office (OSPO), where she is running their open source program. In addition, Nithya is the elected chairwoman of the board for the Linux Foundation.In this episode of The Business of Cloud Native, host Emily Omier and Nithya take a deep dive into the role of OSPOs, and explore why many large companies are choosing them to implement them.

The conversation covers:

  • The main function of an OSPO, and why Comcast has one.

  • How Nithya approaches non-technical stakeholders about open-source.

  • Where the OSPO typically sits in the organizational hierarchy.

  • The risk of ignoring open-source, or ignoring the way that open-source is consumed in an organization.

  • Why every enterprise today is using open-source in some way or another.

  • The relationship between cloud-native and open-source.

  • Some of the major misconceptions about the role of open-source in major companies.

  • Common mistakes that companies make when setting up OSPOs.

  • Why Nithya and her team rely heavily on the TODO Group in the Linux Foundation.

 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, my name is Emily Omier, and today I'm chatting with Nithya Ruff, and she's joining us from the open source program office at Comcast. Nethya, thank you so much for joining us.Nithya: Oh, it's such a pleasure to be here, Emily. Thank you for inviting me.Emily: I want to start with having you introduce yourself, you run an open source program office. And if you could talk a little bit about what that is, and what you do every day.Nithya: So, just to introduce myself, I started working in open-source back in 1998, when open-source was still kind of new to companies and organizations. And from that point on, I’ve been working to build bridges between companies using open-source and communities where open-source is created. At Comcast, I have the pleasure of running our open source program office for the company, and I also sit on the board of the Linux Foundation and recently was elected chair. So, it gives me a chance to both look at the community side through the LF and through corporate use of open-source at Comcast.So, you also ask what does an OSPO do? What is an OSPO, and why does Comcast have one? So, an open source program office is a fairly new construct, and it started about 10, 11 years ago, when companies were doing so much open-source that they really couldn't keep track of all of the different areas of open-source usage, contribution, collaboration across their companies. And they felt that they wanted to have a little more coordination, if you will, across all of their developers in terms of policy for use, the process for contribution, and some guidelines around how to comply with open-source licenses and, on a more strategic note, to educate both executives as well as the company in terms of open-source and opportunities from a business engagement and a strategy perspective. So, you find that a lot of large companies typically have open source program offices.And we, frankly, have been using open-source for a very long time as a company, almost since the turn of the century, around 2005. And we started contributing and our number of developers started growing, and we didn't realize that we needed a center of excellence, which is what an open source program office is, where people can come to ask for help on legal matters—meaning compliance and license matters—ask for help in engaging with open-source communities, and generally come for all things open-source; be kind of a concierge service for all things open-source.Emily: And how long has Comcast had an OSPO?Nithya: I came on board in 2017 to start the OSPO, but as I mentioned before, we’ve done open-source organically throughout the company for many, many more years before I came on board. My coming on board just, kind of, formalized, if you will, the face of open-source work for the company to the outside world.Emily: You know, when we think about open-source in the enterprise, what sort of business opportunities and risks do you have to balance?Nithya: That's a great question. There are lots and lots of great business value and opportunity that companies get from open-source. And the more engaged you are with open-source, the more business value you'll get. So, if you're just consuming open-source, then clearly it reduces the cost of your development, it helps you get to market faster, you're using tried and tested projects that other companies have used and hundreds of developers around the world have used. So, you get a chance to really cut cost and go to market faster.But as you become more sophisticated in collaborating with other companies and contributing open-source back, you start realizing the benefit of, say leveraging a lot of other developers in maintaining code that you've contributed. You may start off at contributing a project, and you are often the only one bearing the burden of that project, and very soon, as it becomes useful to more and more people, you're sharing the burden with others, and you benefit from hundreds of new use cases coming into the code, hundreds of new features and functions coming in which you could never have thought of as a small team yourself. I believe that the quality of code improves when you're going to open-source something, it helps with recruitment and thought leadership because now candidates can actually see the kind of work that you do and the quality of work that you produce, and before that, they would just know that you were in this space, or telecom, or other areas, but they could not see the type of work that you did. And so, to me, from a business value, there's a tremendous amount of business value that companies get.On the risk side is the fact that you need to use it correctly, meaning you need to understand the license; you need to understand how you're combining your code with the proprietary code in your company; you need to understand if the code is coming from a good community, meaning a healthy community that is here to stay, and that has a good cadence of releases and is vibrant from an activity perspective; you need to also understand that you need to be engaged with the open-source community and understand where that particular project is going and to be able to sit at the table to influence or contribute to the positive direction of that project, and sustainability of that project. So, if you just consume and don't engage, or don't understand the license implications or contribute, I think you're not getting all of the value and you risk being considered a poor citizen in the community. And frankly, if people don't collaborate with you or cooperate with you, sending a patch upstream may take months to be accepted, as opposed to someone who's part of the community, who's accepted, who's seen as a good citizen. So, I think you've got to invest correctly through either an open source program office or a really intentional and thoughtful program to engage with the community in order to really mitigate risk, but also get the full benefit of working with open-source.Emily: And what do you find you have to educate the non-engineering stakeholders about, so the business leadership when you're talking about open-source?Nithya: That's also a very important function of an OSPO in my mind, is really making sure you have executive sponsorship and business buy-in for why open-source is a key part of the innovation process in the company. Because as you correctly said, there is a level of investment one needs to make, whether it is in an OSPO or in the compliance function, or for engineers to take the time to upstream their patches or to engage with communities. It all takes investment of time and money. And business needs to buy into why this is a benefit for the company, why this is a benefit for the business. And very often, I find that leadership gets it.In fact, some of my best sponsors and champions are executives. Our CTO, Matt Zelesko, completely gets why open-source is important for the business innovation, competitive advantage. And so, also my boss Jon Moore gets it. And I found that in a previous company where I was starting an open source program office, I had to work a little harder because it was a hardware company and they did not understand how working in open-source would fit into the engineering priorities. And so we had to, kind of, share more about how it allowed us to optimize software for our hardware, how it allowed us to influence certain key dependencies that we had in our product process, and that customers were asking for more open-source based software on our product.So, yes, building the business case is extremely important, and having sponsors at the business is extremely important. The other key constituent is legal, and working with your legal team hand-in-hand, and understanding their role in assessing risk and sharing risk with you, and your role as a business saying, “Is this an acceptable risk that I want to take on? And how do I work with this risk, but still get the benefits?” is as important. We have a great legal team here, and they work very closely with us, so we act as the first line of questions for our developers.And should they have any questions about, “Should I use this license? Or should I combine this license with this?” we then try to give them as many answers as we can, and then we escalate it to legal to bring them into the discussion as well. So, we act as a liaison between us and legal. So, to your point, it is important for the business to understand. And the OSPO does a great job in many of my companies that I’ve worked with to educate and keep business informed of what's happening on the open-source side.Emily: You mentioned working with developers; what is the OSPO's relationship with the actual developers on the team?Nithya: So, we don't have many developers on our team. In my OSPO, I have one developer who helps us with the automation and functioning of the open source program office tools and processes. Most of us are program managers, and community managers, and developer relations managers. The developers are our customer. So, I think of the developers in Comcast as our customer, and that we are advocates for them.And their need to use open-source in a frictionless way in their development process as our objective. So, we've worked very, very hard to make sure that the information they need, the processes they need are well oiled, and that they can focus on their core priority, which is getting products to market to really help our customers. And they don't need to become experts at compliance, they don't need to become experts at any of the functions that we do. We see them as our customer, so we act as advocates.Emily: Where exactly in the organizational hierarchy, or structure is the OSPO? Is it part of the engineering team?Nithya: Yes. I think that is the best place for an OSPO reside because you really are living with the engineering organization, and you’re understanding their pain points, and you’re understanding the struggles that they have, and what they need to accomplish, and their deadlines, et cetera. So, we live in the product and technology organization, under our CTO, who's also part of the engineering organization. So, I find that the best OSPOs typically reside in engineering or the CTO office, there are some that reside in legal or marketing. And whenever you decide, it tends to flavor the focus of your work. For us, the focus of our work is how can we help our developers be the best developers and use the best open-source components and techniques to get their work done?Emily: And what do you see is the risk that organizations take if they ignore open-source, they don't have this, sort of, conscientious investment in either an OSPO or some other way to manage the way open-source is consumed?Nithya: This is how I would put it. Everything that you see in technology development today, a lot of the software that we consume, whether it’s from vendors, or through the Cloud—public cloud, private cloud—is made up of open-source software. There’s a ton—I would say, almost 50, 60 percent of infrastructure software, especially data center, cloud, et cetera, is often open-source software. So, if you don't know the dependencies you have, if you don't know the stack that you're using and what components you have, you're working blindly. And you don't know if one of those stack’s components is going to go away or going to change direction.So, you really need to be cognizant of knowing what you're using, and what your dependencies are and making sure that you're working with those open-source communities to stay on top of your dependencies. You're also missing out on really collaborating with other companies to solve common problems, solve them more effectively, more collaboratively. It's a competitive advantage, frankly, and if you don't intentionally implement some sort of an OSPO, or at least someone is tagged with directing OSPO type of work in the company, you're missing out on getting the best benefits of open-source.Emily: Do you think there are any enterprises that don't use open-source?Nithya: No. I believe that every single enterprise, knowingly or unknowingly, have some amount of open-source in their product, or in their tools, or in their infrastructure somewhere.Emily: And what percentage of enterprises have—this is obviously just going to be your best guess, but what percentage of enterprises have an OSPO?Nithya: I think it's a small percentage. New Stack and the TODO Group do a very, very good survey. I would refer us to that survey. And that gives you a sense of how many companies have an OSPO. I believe it's something like 45, 50 percent have OSPOs, and then another 10, 15 percent, say we intend to start one in the next two to three years. And then there's another, I don't know 30 percent that say, I have no intention of starting one. And the reason may be because they have a group of volunteers or part-time people across their organization who are fulfilling those functions between their legal team, and a couple of expert developers, and their communications team, they may think that they have solved the problem, so they don't need to have a specialized function to do this.Emily: I wanted to ask a little bit about the relationship between cloud-native and open-source. What do you see as that relationship?Nithya: If you ask anyone—and this is my opinion as well—that cloud-native technologies are very open-source-based. Look at Kubernetes, or Prometheus, or any of the technologies under the CNCF umbrella, or under any of the cloud-native areas, you find that most of them have their roots, or are created in the open-source way of development. So, it is an integral part of participation in cloud-native is knowing how to collaborate in an open-source way. So, it makes a lot of sense that CNCF is under the Linux Foundation, and it operates like an open-source project with governance, and technical body, and contributors. So, for us as well, being a cloud company—or a company that uses Cloud to host our infrastructure, and also a user of public cloud, we think that knowledge of open-source and how to work with open-source helps us work more effectively with the cloud ecosystem.And we have contributed components like Trickster, which is a Prometheus dashboard acceleration component. We've also contributed something called Kuberhealthy, which allows you to really orchestrate across Kubernetes clusters to open-source because we know that that's the way to function, and influence, and if you will, kind of take advantage of the ecosystems in the cloud-native technology stack. So, cloud-native is all built on open-source. So, that's the relationship in my mind.Emily: Yeah. I mean, I think actually, the Linux Foundation defines cloud-native as built on open-source software. I forget the exact words.Nithya: Yep. I think so, too.Emily: What do you think are some misconceptions out there, particularly among the enterprise users, about open-source and about the role of open-source in a major company?Nithya: There are a number of misconceptions. And we talked and touched upon a few before, but I think it's worth repeating it because you need to confront these misconceptions and start engaging with open-source if you want to compete with the other companies in your industry, who all are becoming digital companies and are digitally transformed. And they need to work with open-source as part of their digital framework. So, one of the misconceptions is that vendor-supplied software or products don't have any open-source in them.In fact, a lot of vendor-supplied software, maybe even from Microsoft has some open-source in them. Even from Apple, for example. If you look at the disclosure notices, you'll see that all of them consume open-source. So, whether you like it or not, there is open-source and you need to understand and manage it.The second is not knowing what your engineers are downloading and using, and hence what you're dependent upon as a company, and whether those components are healthy, and whether those communities are doing the right thing. You need to understand what you're using. It's like a chef: you need to know your components, and the quality of the food that you create will depend upon the components you use. You'll also need to understand licenses and watch needed to comply with those licenses, and need to put process in place to comply with those licenses.You also need to give back; it's not enough to just consume and not contribute back things like bug fixes, patches, and changes you make because you end up carrying all of that load with you as technical debt if you don't upstream it. And, frankly, you also consume, so you should give back as well. It's not sufficient to just take but not give. The last one is that open-source is free.And so, many people are attracted to open-source because they think, “Ah. I don't have to pay any license fees. I can just get it, I can run it anywhere I want, and I can change it,” et cetera. But the fact of the matter is if you want to use it correctly, you do need to invest in a team that knows how to support itself, knows how to work with the community to get patches or make change happen, you need to build that knowledge in the house, and you do need to have some cost of ownership associated with using open-source. So, these are some of the major misconceptions that I see in companies that are not engaging with open-source.Emily: And what do you see as, in your experience, some of the mistakes that companies can make, even when they're in the process of setting up an OSPO? What have you learned—maybe what mistakes have you made that you wish you could go back in time and undo—and what advice would you give to somebody who was thinking about setting up an OSPO?Nithya: Couple of mistakes that come to mind is releasing a piece of code that's not been well thought through, or properly documented, or with the correct license. And you find that you get a lot of criticism for poor quality code, or poorly released projects. You end up not having anyone wanting to work with the project or contributing to the project, so the very intent of getting it out there so that others could use and collaborate with you is lost. And then sometimes companies have also made announcements saying that they want to release a particular piece of software, and they backtrack and they change their mind and they say, “No, we're not going to release it anymore.” And that looks really poor in the community because there are people who are depending upon it or wanting it, and it can affect the reputation of a company.There was one more thing which I was going to say is, is really not being a good player. For instance, keeping a lot of the conversations inside the company, in terms of governing a project or roadmap for a project, and not being transparent and sharing the direction of the project or where it's going with the community. For an open-source project, is really bad. It can affect how you're perceived and how you're trusted or not trusted in the community. So, it's important to understand the norms of open-source, which is transparency, collaboration, contribute small pieces often, versus dumping a big piece of code or surprising the community.So, all of these things are important to consider. And, frankly, an OSPO, helps you really understand how community behaves: we often do a lot of education on how to work with community inside the company, and we also represent the company's interests in communities and foundations and say, “This is where we are going. This is where we need your help.” And the more transparent you are, the better you can work with community. So, those are some areas where I've seen companies go wrong.Emily: And when a developer who works at Comcast contributes to a project is he or she contributing as an individual or as part of the company? And how is that, sort of, almost, tension navigated?Nithya: Most companies have a policy that any work that you do during your workday or on work equipment, is company property, right? And so it's copyrighted as Comcast, and most of our developers will contribute things under their Comcast email id. And that's fairly normal in the industry. And there are times when developers want to do work on their own time for their own pet projects, and they can do it under their personal emails and their personal equipment. So, that's where the industry draws the line.Of course, there are some companies that are very loose about this type of demarcation, and some companies are incredibly tight depending upon the industry they're in, regulated versus high tech. But we are very encouraging of our developers to contribute code, whether on their own time or during company time, and we make the process extremely easy. We have a very lightweight process where they submit a request to contribute, and the OSPO shepherds that contribution through legal, through security, through other technical reviewers, and all in the interest of making sure we provide guardrails for the developer so that he or she does it successfully and looks good when they make the contribution. So, 95 percent of the time, we approve requests for contributions. So, very, very rarely do we say, “This is not approved,” because we think it's the right thing to do to give back and to share some of the work that we do with others, just like we get the benefit of using others’ work.Emily: Is there anything else that you want to add about what OSPOs do, what they bring to the business, the relationship between cloud-native and open-source, anything that I haven't thought to ask that I should have?Nithya: The OSPO, if you will, is a horizontal function that cuts across the entire enterprise development and helps coordinate and direct the intelligent and judicious use of open-source. So, that's why it touches all of the software development tools, apps, vendor-supplied software, public clouds, internal clouds, et cetera. Wherever open-source is used, which is everywhere, we touch it. And we also serve as the external face of the company to the open-source community so that the open-source community has one place that they can come to for questions, or to give feedback on something they're doing, or to ask a license question, or to ask for sponsorship or support for a conference or a foundation. So, it really makes open-source navigation very, very effective for the community, as well as for inside the company.So, I'm a huge, huge fan of OSPO. I also love running an OSPO, and the kind of people that are typically in an OSPO. They tend to be very versatile, very general, they can pivot from legal to development matters to marketing and communications to really assisting a developer navigate something challenging. So, they're very versatile and terrific type of people. They also tend to have very high EQ and tend to make sure that they have a service mentality when they take care of questions that come in. So, I would say an OSPO is a great role for someone who wants to help and wants to know the breadth of software development.Emily: It sounds like you're making a recruitment pitch.Nithya: Uh, yeah. I don't have any openings right now, but I'm always encouraging and mentoring other OSPOs. I do at least one or two consultations with other OSPOs because we enjoy what we do as an OSPO and we want to help other OSPOs be successful.Emily: I mean, is it hard to find people to work in OSPOs?Nithya: It's kind of hard, in the sense that there are not too many people who do this work. So, I know, practically, I know all of the OSPO leadership and people who do this line of work in the industry. And it takes—some who come from a developer background. They have grown up as a developer using open-source and know the pains that they faced inside their company using open-source and not having certain processes or certain support or tools, and they go out to change the world in that way.I came from a different direction. I came from strategy and product management, and I came with the notion of, “How do I connect the dots better across the organization? How do I make sure that people know what to do and how to build relationships?” So, I came from that perspective. Frankly, I think it's something that innately people have, which is the ability to absorb a lot of different types of knowledge and connect the dots and work to change things. You don't have to be born in open-source to be a good OSPO person. You just need to have a desire to help developers.Emily: Was there any tools—it doesn’t, obviously, have to be a software development tool, but any tools that you could not do your work without?Nithya: More than tools, I would say the organization that we rely on very heavily is the TODO Group in the Linux Foundation because it is a group of other OSPO people. And so it's been a great exchange of ideas and support, and tips, and best practices. The couple of tools that we use very, very heavily, and the love using, clearly, is something like GitHub or GitLab which helps you coordinate and collaborate on software development and documentation, et cetera. The other tool we use a lot to build community inside the company is things like Slack, or Slack equivalents because it helps you create communities of interest. So, when we are doing something around CNCF, we have a CNCF channel. We have a very, very large open-source channel that people come in and ask questions, and the whole community gets involved in helping them. So, I would say those are two really good tools that I like, and we use a lot in our function. And the TODO Group I think is a fabulous organization.Emily: And where should listeners go to learn more and/or to follow or connect with you?Nithya: There are two places I would say. comcast.github.io is where we publish all of our open-source projects, and you can see the statement we make about open-source. We also feature job openings at Comcast as well as our Innovation Fund, which is a grant-based fund request, so people can make a request for us to contribute money towards their project, or to research. And I'm on Twitter at @nithyaruff.Emily: Well, thank you so much, Nithya. This has been really fabulous.Nithya: Thanks, Emily. And thank you for helping me share my enthusiasm for what an open-source office is, and why everybody needs one.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.

The Business of Cloud ...