The strength of the open source community is that it’s made up of people with diverse backgrounds and experience levels, but it takes leaders like Nikhita Raghunath to make the community an inclusive place.
Drawing on her leadership experience across the Cloud Native Computing Foundation (CNCF) ecosystem, Raghunath joins us on the Open at Intel podcast to share tips for getting started in the world of open source. Raghunath and host Katherine Druckman discuss how to research projects you’re interested in, how to use diplomacy to help get your contributions accepted, and ways to contribute to communities beyond writing code.
Listen to the full episode here. This conversation has been edited and condensed for brevity and clarity.
Nikhita Raghunath’s Journey Into Open Source
Katherine Druckman: I want to dive into your whole story, but will you start by telling us about yourself?
Nikhita Raghunath: I work as a staff software engineer at VMWare where I lead the Kubernetes engineering team. I’ve been involved in Kubernetes for a while, and I’m on the CNCF Technical Oversight Committee, which oversees technical and governance issues across the ecosystem. I’m also a KubeCon + CloudNativeCon cochair, so I help determine the event program, such as what the keynotes will be and which talks get selected.
Katherine Druckman: Let’s go back in time. How did you get into programming?
Nikhita Raghunath: I grew up in India, and it gets a little too hot in the summer. When I was in the fifth grade or so, the only place in my school that had air conditioning was the computer lab, so I’d find excuses to visit it. I’d ask the older kids if they could teach me about what they were working on in their computer programming classes, and I’d offer to help them with their homework. So it was actually my love of air conditioning that introduced me to programming. However, I didn’t really pick up programming until I was in college. If you didn’t start programming early, you can pick it up later in your career. It’s not necessary to start early.
Katherine Druckman: Can you tell us about how you got involved in open source?
Nikhita Raghunath: In college, I started playing around with toy projects, like creating websites and other small projects and putting them on GitHub. But it didn’t give me the feeling that I was creating an impact. That’s when I learned about open source and how you can write code that’s run in production for enterprises. I only knew Go back then, but everyone was talking about Kubernetes. I Googled more about it and learned Kubernetes had an internship program called Google Summer of Code; CNCF worked with the program. I applied and got in. I didn’t know much about Kubernetes, but the maintainers were so nice and open to people learning things on the fly. A lot of people think they need to know everything before they apply for an internship. That’s not true. You can just jump in, and as long as you’re willing to learn, you should be ok.
During the internship, I helped create a Kubernetes feature called CustomResourceDefinitions (CRDs), which allows you to extend Kubernetes; pretty much all of the operators or custom controllers that we see today are built on CRDs. The cloud native ecosystem just exploded after CRDs came out, so I feel proud of the work I did there. After the internship, I loved the experience so much that I continued working on it. What helped me stay on were the friends I made during my internship. It didn’t feel like working with just another community member. It’s an amazing experience to see the impact of the code you write and the people you mentor. The people I mentored got jobs in cloud native, so it feels like you can be a force multiplier in open source.
Tips for Getting Involved
Katherine Druckman: You got involved at a young age, but a lot of people come from all sorts of different backgrounds and get into technology later in life. What advice would you have for people getting started in the open source community?
Nikhita Raghunath: Many engineers I work with at VMWare are interested in open source but don’t know how to find the time. Time is the biggest barrier because you don’t want to come home from your day job and code. I usually suggest a four-hour-per-week model. Spend one hour attending meetings about the project you’re interested in. Spend one hour skimming through the mailing list, being active in Slack, and so on; people need to know who you are, so keep the communication going. For the other two hours, focus on heads-down stuff. It doesn't have to be coding; it can be anything else. Spending four hours per week is usually doable for most folks. A lot of people have gotten started this way and are able to grow up the contributor ladder. Another thing is around different skill sets. There’s a myth that open source is always about writing code, but there are so many other things you can do. For instance, Kubernetes has a non-code initiative, such as a contributor marketing team and project management work. There’s room for everyone in open source.
Katherine Druckman: What are the major challenges you see that prevent people from getting involved and contributing what they can—whether it’s code, documentation, leadership, or marketing?
Nikhita Raghunath: One aspect that I don’t think people think about is that many open source projects are North America-centric. There’s just another set of challenges involved when you’re spread across the globe. For instance, one of the things I’m going to talk about in my keynote is financial barriers. I’ve been privileged, but many students or early career folks don’t have the right set of laptops to work with. Honestly, you open Slack and Google Chrome, and you can’t compile Kubernetes anymore. We have initiatives that let people test on the cloud using the CI infrastructure the CNCF has and things like that. Relatedly, to attend KubeCon, you need visas, which are expensive and hard to get. Many people who get KubeCon scholarships still can’t attend. And it’s not just about India; I’ve talked to people who faced similar challenges in Brazil and Peru. So I’m very glad the CNCF is trying to do a KubeCon India next year.
Language barriers also play a role. I’m doing a panel, and a panelist from Tokyo shared that many people have trouble understanding his accent. Some folks are comfortable with written English but not spoken English, so they don’t speak up in meetings. When you don’t speak, people don’t get to know you, and it prevents you from growing up the contributor ladder. My own bias was challenged recently when I attended a meeting with someone who jumped right in without saying “hello.” I felt it was a little rude, but my panelists told me they sometimes just forget to say salutation phrases—they’re not trying to be intentionally blunt, it’s just a language barrier. It’s a reminder that we all need to be empathetic and know that not everyone has the same privilege.
Getting Your Work Accepted
Katherine Druckman: What advice do you have for people who have done the work—such as a pull request—and need help using diplomacy to get something merged?
Nikhita Raghunath: I typically follow up with the maintainers who are supposed to review the pull request. I’d say to wait two or three days after you create a pull request because people have busy lives, and then message them on Slack. If you’re still not getting a response after that, I usually ping someone who works with the maintainer—colleagues are good because they can ping them on their internal Slack channel. Folks may not check open source Slack, but they’ll definitely check their internal Slack. Sometimes the maintainers are just taking a break from open source and will review your pull request when you ask. If you’re still not getting a response, escalate it to the Kubernetes Steering Committee. Make them aware of problems, so they know what areas are not staffed well and can make decisions about how to solve these problems better.
A Meaningful Seat at the Table
Katherine Druckman: We’ve talked about many challenges in open source. What are your thoughts on how open source communities like Kubernetes can address limitations? Beyond empathy, are there concrete steps communities can take?
Nikhita Raghunath: I personally prefer free-flowing communication over meetings. One thing we’ve tried is setting a Slackbot to post reminders every week about particular topics, and people can share updates and have free-flowing conversation in the channel instead of in a meeting. That’s helped to get more people involved. Another thing: Some people try splitting meetings into two time zones—so there may be an APAC-friendly meeting and a North America‒friendly meeting. That works if you have a sizable contributor base in both regions; otherwise, some communities start out as being North America heavy and most of the senior maintainers end up attending that one, while the other meeting is made up of folks who are just getting started. That kind of imbalance doesn’t help anyone.
Regarding language barriers, closed captioning helps, and Zoom has support for it. We also need to support deaf community members. CNCF has a Deaf & Hard of Hearing Working Group working on improving accessibility. They mentioned that closed captioning is actually not enough because if deaf or hard of hearing members want to speak, they usually have to type it out. What they need are interpreters, and you’ll see a few interpreters moving around here at KubeCon. When we say we want to be empathetic, we’ve got to take actionable steps to make sure that people are comfortable. It’s not just about inviting diverse voices to the table—we also need to ensure we give them a meaningful seat.
Do Your Homework
Katherine Druckman: Is there anything you wanted to say that you didn’t get to?
Nikhita Raghunath: Coming back to the advice for new contributors, one thing we’ve seen over the years is many people coming in and asking maintainers to tell them where to get started. Honestly, many maintainers don’t have the time to handhold and point out areas you can contribute to. My suggestion is to do your research. It could be simply reading documentation or looking through open issues to see if there’s something you’re interested in. Then come back and tell us what you did. It’s ok if you don’t know what areas to jump into, but if you tell us you’ve done the research, maintainers are more likely to invest time to help you because you’re going to stick around.
To hear more of this conversation and others, subscribe to the Open at Intel podcast:
- openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Your favorite podcast player (RSS)
About the Author
Katherine Druckman, Open Source Evangelist, Intel
Katherine Druckman, an Intel open source evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she’s a longtime champion of open source and open standards.