The Relicans

Cover image for Getting Started in Open Source with Jayesh Ahire
Mandy Moore
Mandy Moore

Posted on

Getting Started in Open Source with Jayesh Ahire

Relicans host, Aisha Blake interviews Founding Engineer at Traceable AI, Jayesh Ahire, about four easy ways to contribute to an open source project as a beginner dev.

Jayesh suggests contributing to documentation, finding an issue you want to fix or a feature you want to add, evangelizing by sharing your experience using a particular open source project, and helping others by joining communities to answer questions or share your thoughts on open issues and feature ideas.

Should you find a burning need to share your thoughts or rants about the show, please spray them at While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @LaunchiesShow.

play pause Launchies

Jonan Scheffler: Hello and welcome to Launchies, proudly brought to you by New Relic's developer relations team, The Relicans. The Launchies podcast is about supporting new developers and telling their stories, and helping you make the next step in what we certainly hope is a very long and healthy career in software. You can find the show notes for this episode along with all of The Relicans podcasts on We're so glad you're here. Enjoy the show.

Aisha Blake: Hello and welcome to Launchies. My name is Aisha Blake. And we are here with a podcast for early career and non-traditional background developers where we offer advice on navigating your career progression and making a transition into tech. Today I'm here with Jayesh Ahire. And I'm really excited to talk about getting into open source and starting to contribute. Thank you so much for being with us.

Jayesh Ahire: Thank you. Thank you for inviting me, and I'm glad to be here. So hello, everyone, I'm Jayesh Ahire. I'm a Founding Engineer at And I work around various stuff, so I do product management, marketing, sometimes community management, open-source, and all that stuff. And I specifically work on our open-source project called Hypertrace, and I am the maintainer of Hypertrace. I manage the product and marketing side for Hypertrace and a bunch of stuff around it, so yup.

Aisha: Awesome. So we specifically reached out because you shared this article: 4 Easy Ways to Contribute to an Open Source Project. And I think that's opening up how we think about contributing to open source; it’s a really important topic. Because particularly new folks, I think have this impression that in order to work on open source, you need to be this brilliant coder who can start contributing features to a project, and that's not necessarily the case. Let's maybe start by talking about some of the other ways that you discuss getting involved. The first one is really near and dear to my heart because I spent a lot of time working on Gatsby documentation. So let's maybe start there. So how do you see documentation fitting into the process of contributing to open source?

Jayesh: So, in general, I will start with the general perception itself. So even as a maintainer or even before that, many people used to reach out and say, "Hey, I just want to get started with open-source contributions, and how should I?" And most of the people, as you said, most of the people think that you have to be a brilliant coder. You have to start coding and maybe writing code for some of the projects. And some people don't have enough context to get started with it. So to build context or at least to know how the project works, it's very important to go to the documentation.

And for many projects, I have observed that documentation is sometimes the weakest part of the project, and that's the face of the project. And that happens a lot. That happens a lot with many people because as someone who came up with the idea, as someone who wanted to create something, I might go and just write the code. I might go and build a project. But in my mind, it works. In my mind, it works in a certain way, and I will write the documentation in that perspective. But sometimes, it's not very user-facing.

And that's where the people from the community can jump in, and they actually can help with documentation. Because when you go to it, when you as someone new is looking at a project and go to the documentation, you understand that something is missing or maybe in the installation step you will find some quirks, and you are like, "This should be fixed." That's where you can jump in and say, "Hey, dude, this is not working, and you might need to add this for this particular operating system or for this particular environment I'm using. So that's how you can get started with contribution. The first thing is installing the project and then getting it working. And if you find something wrong about it, please fix it.

The second thing might be how that project works. So what is the purpose of that project? What are the use cases it's trying to solve? And even though as a maintainer or as a creator, I might have some of the use cases in my mind where I see people using the project, but maybe you have something else. Maybe you are using it for a completely different use case, and I'm not even aware of it. You can say, "Hey, I'm using it for this particular thing, and it works fairly well in satisfying my use case." So please go ahead and say, "Okay, you can do this or that with this project."

So there are lots of interesting ways you can actually go ahead and shape the documentation because the documentation eventually becomes the face of the project, and that's an entry point for anyone who is using it. So if there's something wrong with it, then people will be facing significant issues, and that will be an entry barrier for the project itself. And then some people feel that if they're not contributing code, they are not adding enough value, but that's not really the case. Even if you are contributing something to documentation, you are actually creating an audience for that project. You're actually helping people get started with the project and that I feel is very important.

Aisha: Yes, absolutely. Particularly the point about new use cases, I think, is one that maybe folks might miss. But if you're doing something unexpected with the project, that is absolutely ripe for all kinds of contributions.

Jayesh: That becomes a cool user story for creators as well. So they can go ahead and write a blog post like, this user is using this for such a cool use case. That becomes a good thing for everybody. That becomes a good thing for you. You contributed something. You added some value to the project, and it's very valuable for the creator or maintainer because they are basically understanding that these are some of the cool use cases we might have missed out on. So it's a win-win for everybody if you go with that path.

Aisha: Yeah, absolutely. I'm wondering how do you recommend that folks even find projects to work on? Do you suggest that folks add to projects that they are already using, or what are your thoughts on that?

Jayesh: So it makes sense. It makes sense as an entry point to go with the projects you are already using because you know some parts of it. You know what is missing. Because suppose I'm using one certain project for my particular project, and I want to really use it, and I went to it, I tried it out; it works for me. But during the process, I found something is missing because that's when you identify those issues. That's when you realize if it's working or not. But yes, so that makes sense. As an entry point, it totally makes sense to go ahead with the projects you are actually using or utilizing for your use cases or anything you are building around that project.

But even if you want to explore something new, there are a lot of projects that add those good first issues in documentation who even have groups set up for documentation itself where you can just attend meetings, where you can just go and talk to the people who are maintaining it and just ask them what help they need with all the things they are maintaining or all the things they're creating. So even if you want to find something new, it's pretty easy these days. With GitHub, it's pretty easy these days. You can just search for good first issues, and you will get a bunch of those. You can even look at the documentation, and you will get a bunch of documentation issues.

Exploring the new thing is very fancy, and it's very good maybe if you have enough time because that way you are learning something, something which you might not work with in your daily routine. Because if you are going with contributing to something which you are already using, it's not adding value to yourself maybe, your knowledge maybe. But if you are exploring something completely new and going and reading their documentation and using the project and saying, "I should contribute to this,” then that's good for you. That's good for you in getting better in a developing aspect.

Aisha: That makes a lot of sense. So let's say that someone does decide, okay; I do actually have some code that I want to contribute. How do you recommend folks go about that? I guess what does it look like for you entering into a new project? Or maybe a better question, for you as a maintainer, what do you hope to see from new contributors?

Jayesh: So that's an interesting question, and there are a lot of ways that can happen. It differs from project to project, but if you want to just go with the general workflow, I might expect, or some of the folks I know in the open-source world might expect something like if you have some idea, take this idea of yours...or if the feature you're building might add significant value to a project, you can raise an issue, or you can raise an issue about a feature request or something you are working on, and then discuss that this is the feature you think might add value to a project. And then explicitly mention that you are kind of working towards it, or maybe there's a PR attached to the issue. People can go to it, and people can discuss with you if that really makes sense or not.

If you don't want to go that far, it might be to reach out to the community channels. So there might be a Slack channel, a Slack workspace for that, or there might be some GitHub community. Nowadays, there are GitHub Discussions. So you can just start a thread saying that this is something you are planning to work on or you're trying to add to a project and what are the thoughts of maintainers, or what are the thoughts of people who are working on the project or contributors? And even just a generalized idea because if somebody is actually planning to work on that particular part, like, if somebody comes to me and says, "I'm planning to add this feature." And it might be that feature is in my own list two months from now, and that just gets removed from my list. I can just assign that issue to that particular person, and he can contribute that code back. And it will be helpful for all of us.

So mainly in my perspective, these two ways work all the time. You can either just go ahead and create an issue and start a discussion there and even go ahead create new PR and attach it to an issue and mention what you're trying to achieve with it. And most of the people in the open-source world are very nice. So people will give you good feedback, and they will be nice to you. And the second way will be just reaching out to folks through community channels and asking for their feedback around your thoughts, and then going ahead and creating an issue and contributing the feature you wanted to contribute.

Aisha: I think that makes sense. And then if the project has contributing guidelines, then you just defer to that, whatever they say they want you to do. [chuckles]

Jayesh: Yes. And some of the projects have these monthly meetings online, so you can just attend the monthly meetings. You can just attend the community calls. And you can even raise the question. You can even ask about feedback around your features because those are pretty open meetings. You can add it to the meeting notes. You can maybe just ask the question in the meeting and people will be helpful. People can give you real-time feedback there as well. Nowadays, there are a lot of ways to interact with people as everything is online. [laughs]

Aisha: Yeah. I think your point about getting involved in the community around a project is a really important one. I feel like sometimes we get caught up in the GitHub space of a given project and don't necessarily engage or think to engage even in other spaces then influence what happens on GitHub. Have you seen that? And I guess, what do you think makes a good community member for an open-source project?

Jayesh: That's a very interesting question because I have seen this happening many times. So people just stick to the GitHub tech because it's what shows up. It's what lets them show their contributions to the general public. And sometimes, there are people working behind those GitHub walls and actually helping the project as well. So there are a lot of ways to help. As I said, the community matters. The community helps this project grow because most of the time, they are just a bunch of people getting together to build something. And if they get enough feedback around things like architecture, things like UX, things like maybe a general UI part or some deployment, is it easy or not? So it is really helpful for this kind of project. Even I helped several projects in architecture reviews, creating architectures for them, or reshaping their architectures, or even evangelizing about those projects, helping them with the UX part of it, helping them with simplifying the deployments and helping them building these GitHub Actions pipelines.

So all those things really matter to a project for the greater good, and it really helps the community around the project to succeed in a way. Because if you can get the deployment simplified, it's really significant for users; if you can get the UX issue solved or if you can make the UX better, it is very helpful for people or users around it. If you can reshape the architecture if you can create architecture in a way, it's very efficient; it’s helping users in a way. But those don't count as your GitHub contributions. So if you want those GitHub contributions or the green chart, it won't satisfy that thing. But it will give you another satisfaction that you actually added some value. You actually helped a project build something which will be helpful for users, which will enhance the user experience in various ways. So, yeah, breaking those GitHub walls and actually getting involved with the community, actually discussing the issues behind the whole thing matters a lot. I guess I can go ahead and contribute, or I can write really good code. But if the project which is using the code…if the application which is using the code is not efficient, then at the end of the day, it doesn't matter. So if I can even help them get to the efficient architecture, it really helps those people. So yeah, there are various ways to break the GitHub barrier and actually get involved in the community, and talk to people, talk to users, and help them.

Aisha: Yeah. You mentioned in your piece the part about helping others, so either creating content around the project or potentially, I'm going to go ahead and suggest potentially mentoring people on this technology that you're really familiar with. What are some other ways that you see people helping the community around different projects?

Jayesh: So yes, that is a very interesting way to look at it, even mentoring, as you've said. So many people who are very new to the whole tech scene and many folks who are just getting out of college and getting started with their careers don't know about the technology stacks very well. They don't know how things work. And then they will need significant help in actually understanding the motivation, understanding the vision of the project to get started with it because that's what might be the entry barrier for them. Because if they are not able to understand the motivation behind it, they might not feel the need for it. But if you can really help those people with the small, small knowledge, maybe that this is what you're trying to build, this is why you are trying to build this, and these are the different ways they can actually use it, and these are the different ways they can help people, that might be very helpful for those people.

I've been deviating from your question, but one thing I would like to mention about open source is it really democratizes opportunities. And that's what I really like about the whole part. There are no barriers to entry. You can just see something out there, and you can start working on it. And there are people who will be actually helping you to get started working on that, even for us. So we have a Slack community, it's not like a 10,000-people community, but we have a small niche group which really helps us around it. And we will be discussing interesting stuff around it.

So there are many people who are just getting started with open source, who are just getting started in tech careers. And they reach out sometimes and say, "Hey, Jayesh, I'm just getting started with this. And I don't really understand the architecture because it's kind of complicated for me. And can you just help me understand it? Can you just help me understand the motivation, what we're trying to achieve? And I might be able to help you in some ways." Even if he or she they're not able to help out in any way or even if they don't contribute afterwards, it's there, so I helped somebody to understand some part of technology. And that might help them at some point in their careers, and that's how the other helping part works.

Even if I'm somebody who is using the project, I know the quirks around it. I know some issues with the deployment. So I know some issues with getting started, quick start guides. And if somebody asks a question on a meetup discussion or if somebody asks a question on Slack, just go ahead and say, "Hey, this might be the issue, and this might be the solution for it," because you know the solution. You went through it. And that actually gets the burden out of maintainers. That actually gets the burden out of contributors to answer those questions because you went through the process. You know the answers. You answer questions for those people. And that is also is very significant. You are actually helping people, and creating content is always good; creating content always helps you. It always helps a project you are talking about. It always helps people who will be reading it at one point. So for me, creating content is the best thing you can do for any project. [laughs]

Aisha: I feel that for sure, for sure. More generally, thinking about getting started in open source, we talked a little bit about finding projects. And the suggestion was to start with projects that you are using. But I want to maybe go a little bit more in-depth on some other options that are out there. So we mentioned some tags earlier, but we didn't necessarily talk about what tags even are, so if you wouldn't mind, maybe going a little bit deeper into some other ways that folks can find projects to work on.

Jayesh: So a few other things will be if you attend some conference online or if you read some blogs around and find out that this blog talks about this particular project and these use cases intrigue me, or I'm reading about something, and this thing might make sense, or I can help these people, or I'm interested in that, go ahead and explore that tool. Go ahead and just look at it. Give it a look, maybe. Once you start with it, once you start exploring the whole thing, there will be significant things you might notice. You might notice something around documentation. You might notice something around the feature itself. And the meetup allows maintainers and owners to add these good first issue labels.

So if there are some issues labeled as good first issues, you might want to pick them up, and there will be enough details in those issues. And if you don't understand, you can just ask, tag someone. Or you can just ask in general on the same issue that "Can I pick it up?" or "If I pick it up, how should I address the issue?" People will help you with that. And that might be one way to get started with it. You found something interesting while you were reading a blog post or attending some conference, watching some video on YouTube, and you want to add some value to a project, go ahead and do that.

Then there are some major projects like Kubernetes, so they have focus groups. They have very detailed documentation around every single thing, how you can contribute. There are monthly meetings around the project. There are monthly meetings for every single feature, every single, maybe the documentation part, some cloud integration. For every focus group, there will be separate meetings. So if you are just interested in working with some integration around AWS maybe, there might be a focus group around it. You can join their meetings and understand what are the issues they're facing? What are the things that they're trying to build? And try to pick up something that might interest you. So that might be the one way because, as a small project, we don't have that much bandwidth to create this whole system right now, but some of the projects do that pretty well. As I said, Kubernetes does that pretty well, and they have people who will help you to get started with things. I know many people in the Kubernetes community, and they are really good people.

So if you get started with these big, big projects, so there are many small, small parts, which are very detailed, very well-explained. And you can easily pick those issues. You will find many good first issues in those kinds of projects. And it's very generic. When you start talking about something like Kubernetes or OpenTelemetry, it's very generic as a whole. It doesn't adhere to the particular stack, or it never goes to this very niche use case. It's very generic as a project. So if you pick it up, you might not even have to understand the whole tech scene around it pretty well because it's a single thing. You know how it works. It's very specific. So picking up such specific projects and working towards them is a second way to get started with it.

So yep, the first thing you find something interesting and go beyond that, find something around it and start contributing. The second way would be to go and explore a big project. Go and explore something you might have heard several times on Twitter, or you might have seen several times somewhere, and then find something around it you can add value to.

Aisha: I like that. I think that when we talk about getting into open source, with good reason, we focus almost entirely on contributors. But I wonder if you have thoughts around considerations that a new maintainer might want to make. Let's say I'm tagging along. I'm working on a project. I make something small that helps me in my workflow, and I decide I want to release that. What are some things that I should be keeping in mind?

Jayesh: Yes. So that's a very good question in my perspective because I did that several times. My first major project was something when I started working with a company that was creating that project. So before that, most of the projects I worked on something I created for writing a blog post or something I created for my own understanding. And then I just put that on GitHub, and people still reached out. People still were interested in trying out that project, or helping, or building something around it. I will go with an example, so one of the projects was Fake News' Foe. It was something was all just really in the back end. So what it does is whenever you find some article, or when you find some news, you can just copy the link or copy the article, some text, anything, and you just send it to that chatbot. So you WhatsApp, SMS, that particular number. You just send it to that particular number, and it will tell you if it's fake news or not.

Well, that was a little thing that was fancy, and it uses machine learning and all the new, fancy things. So it was pretty fancy for people. People really liked it. And I demoed it in several conferences. It didn't make a lot of sense that particular use case, but workflow made a lot of sense because now you can easily replace that text message with an image and say you're creating the image classifier or image object identifier or something like that. Because entry point and output can change, but the whole workflow remains constant. So people were very interested.

And one particular thing you should be taking care of when you're open sourcing these kinds of projects is to write good documentation. Documentation and just a good README. Because README is something, if I just open-source the code and I say, "Let people figure out how that works," [laughs] that might be a major barrier for many people to try it out. So if you really want people to try it out, if you really want people to build something around it, use it, just write a good README explaining what your motivation was, why you created this particular project, and how people can use it, how people if they want to use it, how they can use it, and if they even want to build something around it how they can do that.

So I took care of a few of those things. I even wrote a blog post around it which got a lot of traction at that time. So yes, the README is kind of a major thing, I will say. Apart from that, write good code. Good code, as in document your code pretty well. People should be able...if somebody is going to the code, they should be able to understand why you used this particular function or why you're using this particular variable where you're using it. What are the data sources? So for my project, maybe there is some particular data source I'm using. So what was it? Why I used that particular data source, where I'm displaying the output, how that looks like. So just document your code well. Write a README. Yes, those should be two major things you should be taking care of.

And yes, the third thing I remember is that many people don't have a good directory structure. I don't know how they pull it up but just have a good directory structure. Because these days you get a lot of IDEs, you can...they will provide you with out-of-the-box tooling, and you just need to add files to the structure itself. Just use that kind of a structure. If you just put together five Python files and a README, it might not make sense for a lot of people. [laughs] So yep, stick to a standard directory structure which some IDE might provide you. You will get it when you have some experience that this should be the ideal thing to do. But yes, the directory structure, documenting your code, and writing a good README will be a good entry point for any new maintainer.

Aisha: I love that; very focused on making it easier for other people to help you.

Jayesh: [laughs] Yeah. Because if you really want somebody to use it, and if you really want someone to build something on top of it, you really have to help them to understand how that works.

Aisha: Absolutely. I've certainly come across so many projects where I go to look at the README. That's the first thing I do is I read the README. It's called README.

Jayesh: [laughs] For a reason.

Aisha: Exactly. And if there isn't one, that's a red flag for sure. And if it doesn't tell me how to use whatever it is that I'm trying to get familiar with, it's definitely a big turnoff. Unless I already know that I must use this thing, I'm going to go find something else.

Jayesh: And another interesting is so over the years, I found many interesting projects which don't have any documentation or any README. But I was desperate. I went to the code because I had to find that particular thing somewhere because I knew people would have done that. And I don't want to read all of it. So I just went to the code, and the script is very well-written. It's very well-focused, and it actually solves the problem. But if that person would have written a README, it would have been very helpful for me. Now I had to go to the code to understand how that works. And then I eventually realized that okay, this solves my issue. I will just use it. But if there was a README, I would have saved those 30-35 minutes I spent reading the whole thing.

Aisha: Yeah, for sure. So we're getting low on time, and I want to make sure that we talk about any projects of yours that you're working on right now that perhaps folks can contribute to and the best ways for them to do that.

Jayesh: Yep. So, currently, I'm working on the Hypertrace project, so it's something we created at Traceable, and we kind of open-sourced it. So it's a distributed tracing observability platform, which you can use for different use cases. And yeah, we are pretty open. We are a small community, but we are growing. So if you want to contribute something, if you want to help us with documentation, if you want to help us with creating sample applications, if you want to help us with the UX or even, as I said, deployment, simplifying the deployment, anything, you can just reach out to me on Twitter @Jayesh_Ahire1, and we can discuss it. Otherwise, you can visit our project on GitHub at That's our deployment repository, so that will be the face of it, and you can find some interesting issues there. You can tag me on GitHub and say, "I want to pick this up," and I will be surely happy to help you with it. So if you have something, if you want to contribute to Hypertrace in any way, we will be very glad to help you out with it. We even have a Slack community. I don't know if we can link it out, maybe I will send you a link, and she can add it. But yes, do join the community. Do reach me out there, and we can talk about it.

Aisha: Awesome. Thank you so much. I had a great time.

Jayesh: Me too. [laughs]

Aisha: I really appreciate you being here. [laughs] And thank you, all, for listening. Be sure to check out our other podcasts: Polyglot, a podcast where we talk about the patterns and the systems that we use to write software, and Observy McObservface.

Jayesh: That’s a podcast I can never pronounce the name of.


Aisha: So it's kind of about observability, and it is also what you get when you ask the internet to name a podcast.

Jayesh: Yep.


Aisha: Awesome. Well, I really appreciate you being here. Thank you so much.

Jayesh: Thank you for inviting me, and I'm glad to be here. I really had fun, and thank you, all, for listening in.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.

Discussion (0)