Nithya Ruff heads Comcast’s open source office, and is a widely recognized pioneer in the open source community. She embarked on her first open source software journey in 1998, at Silicon Graphics Inc., when she was asked to join an open source strategy group. Its task: To figure out how to create a community around x86-based servers, loaded with Linux or Windows NT, and nothing proprietary. Since then, she’s carved a path throughout the open source community as a leading light and wise advocate. She’s a featured leader In the web docuseries “Chasing Grace,” which highlights women in technology, and serves on boards including The Linux Foundation. Part of her power is rooted in her deep commitment to mentorship, mutual respect, and community health. In this edited Q&A with RDK contributor Leslie Ellis, Nithya shares her views on what it takes to build a vibrant open source community – and what should be on the RDK’s to-do list. 

RDK: What works and doesn’t work, when building a healthy open source community?

 Ruff: What works is when you make it dead easy for people to get involved. Such as documentation, such as onboarding, such as how-to-contribute guides. Open source communities are healthiest when they have sufficient members of people and mentors, who are there to answer questions in forums, and who are positive and encouraging when a newbie comes to contribute. It’s really the onboarding and the welcoming nature of the community that’s important. It’s the culture of the community.

What doesn’t work is if it’s so hard to understand how to navigate, or how to contribute, which can create a perception that there’s bias in the system – if you come from a certain company, your contributions won’t get accepted. Lack of transparency is the worst thing you can do in an open source community.

One of the worst complaints I hear from people is, it’s so hard to get involved in that project. There’s no description of it. The license is hard to understand and navigate. There’s no onboarding. There’s no coding style book. When I submit something, they don’t even look at it. And when I do, they’re nasty in their comments. In other words, there’s no welcoming, no nurturing.

Another thing that can happen is burnout. There are lots of open source projects out there which struggle because they only have one or two maintainers. If one burns out or wants to take a break, or if they get hit by a bus, there’s no one to take over. So, the sustainability aspects of a project are very important. A good project is a sustainable set of people contributing. It has money; it has governance.

RDK: What metrics illustrate the health of an open source ecosystem?

Ruff: A broad set of users, a broad set of contributors, and a frequent cadence of releases. There’s active communication, there’s debate, there’s a roadmap, there’s transparency. I love the fact that the RDK community really has the face-to-face conferences – that’s such an important part of building connections and trust and personal relationships.

RDK: You’ve said that trunk-based development, meaning staying close to the active release cadence, is a way to reduce “technical debt.” Can you elaborate?

Ruff: Technical debt is when we take an open source component, and we fix or modify it for our own use, and don’t contribute those changes or patches back to the main project. This means that they don’t get absorbed into the main project.  As a result, we’re left carrying the patches from release to release from the fork that we made from the main project. It costs a lot of money for a company to maintain patches, along with the main project, over the course of the project. Every time the main project moves forward, you have to re-integrate your special patches, and re-confirm that it works with the new release. So, if you don’t stay top-of-trunk you incur technical debt. If you do, you reduce technical debt. Ben Hilburn wrote a great article on this called “The Benefits of Upstream Compatibility and Upstreaming.” In general, the reduction of technical debt is a good concept to follow for all open source projects.

RDK: What best practices do you recommend, when it comes to designing / building code that ultimately builds trust with consumers?

Ruff: Customers reward us with loyalty when we are reliable, and we make sure we’re reliable. From a software perspective, reliability means working on best practices like up-streaming your patches; making sure, from a security perspective, that you’re up-to-date and using the best tools; that you’re collaborating on standard software. All of this allows us to be more reliable and effective and faster, because it leverages open source wherever possible. You’re not re-inventing the wheel, you benefit from hundreds of eyes on the code and as a result, you can go faster and more reliably.

RDK: In your view, what can RDK be doing better?

Ruff: I would like to see us showing up at more open source events. I feel that we have been somewhat insular, as a community and should work more with the upstream communities that we draw code from. For instance, I would like to see more of the RDK team come and talk about the real world RDK project at the Embedded Linux summit that’ll happen in August!  There is a lot of very interesting work being done at scale across a very large community who are using open source in production.  This will be of great interest to many in the open source community.