I Owe Everything To Open Source: Pradumna Saraf’s Journey.

Hey, I am Pradumna Saraf, an Open Source Developer/DevRel based out in India. I am also a Docker Captain, a DevOps and Golang Developer. I am passionate about Open Source and have mentored hundreds of people to break into the ecosystem. People in the community know me for the content I create on X (formerly Twitter) and LinkedIn, educating others about Open Source and DevOps tools. I also enjoy engaging with people in person and delivering talks at conferences.

My journey with Open Source began in 2021 during Hacktoberfest with the EddieHub Community (founded by Eddie Jaoude, shout out to him, I see him as my godfather and a good friend). When I joined the community, I was amazed by how people were helping each other and making their work public for anyone to see. At first, it felt a bit weird, but over time, I came to understand its importance. That spirit of openness and collaboration stuck with me, and here I am today, sharing my Open Source journey with you all.

Open Source: More Than Code

For me, Open Source is more than just code, it’s a place where people from all over the world come together to work on projects, solve problems, and collaborate without being judged on their knowledge, race, colour, or anything else. You can learn and share your learning at the same time while making things better. And with it comes trust, transparency, and security.

Open Source Projects that I am involved in

I have been involved in many projects, especially in the DevOps space. I’m actively involved in CNCF projects, Docker, and various community projects, like the EddieHub Community. In these, I contribute to everything from documentation to DevOps tools implementation, depending on the project’s needs. My key areas of contribution are Docker, Kubernetes, and CI/CD (mostly GitHub Actions). In addition, I also maintain a lot of my Open Source projects daily. You can check them on my GitHub.

Growing an Open Source community

To grow any community, the first and most important thing is creating a safe space where people feel comfortable talking and asking questions without hesitation. Having clear documentation, a README, and contributing guidelines helps people understand the project better. Also, having beginner-friendly issues helps people get started with the project much more easily. It’s all about making them feel supported. Another key aspect is making contributors feel valued and giving them recognition, whether it’s through regular shout-outs, mentioning them in different places like the README for their contribution, or just recognising their efforts. This encourages more people to get involved. Also, being vocal about the community on social platforms helps in building a strong, welcoming environment.

Maintainer’s Challenges

There can be a variety of challenges that come with being an Open Source maintainer. One of them is keeping up with the volume of notifications — by notifications, I mean opening a new issue on the project, comments from contributors on pull requests, or just general questions and feedback. Sometimes it feels overwhelming and can lead to burnout. Another challenge is keeping the docs, README, guides, etc., updated as the project evolves — and in Open Source, things change fast. Other challenges can include funding, saying no to feature requests from the community, and sticking to the original scope of the project.

Supporting Maintainers

There are many ways one can support a maintainer. One of the most important things is following the contributing guidelines before jumping into contributing, because that contains everything from expectations, code styles, to prerequisites, and that saves a lot of maintainers’ time if these things are followed. Another thing can be reviewing and triaging pull requests and issues, because the good thing about Open Source as a contributor is that you can do everything the same as a maintainer, you just can’t merge the Pull Request. Last one is having some patience when you are contributing because a lot of maintainers are doing it voluntarily, and they have other full-time jobs and families to look out for, so there might be some delay in getting back to you.

Open Source Security: Practices and Challenges

Security is one of the areas where we need to do much more. Using the latest versions of dependencies that are vulnerability-free is a good start. GitHub has a bot called Dependabot that automatically scans them, notifies you, and even creates a PR for you. Another important thing is that when you’re using tokens like GitHub tokens, make sure you give them the least privileges needed. A Security Policy (SECURITY.md) is really important, as it allows contributors to report security vulnerabilities privately so they’re not exposed to the public, which could make the project more vulnerable.

Not using the latest and greatest vulnerability-free dependencies can make the end product vulnerable to users — this especially happens with unmaintained projects that still have a large user base. Another issue is not having security audits or scans on pull requests. Specifically for containerised projects, using older versions of base images that contain CVES can make the whole system less secure. Last but not least, there’s often a lack of security and compliance knowledge among Open Source contributors and maintainers. On the other hand, if your application uses containerization technologies, it’s better to use image scanning tools like Docker Scout. You can automate that process with GitHub Actions to make sure your image is clean and CVE-free.

AI and Open Source

AI is both good and bad. On the one hand, it has improved development speed. Now developers can write and debug code much faster. It has also improved code quality and optimisation. On the other hand, as more code comes in, it becomes harder to review everything, and that can lead to major security issues, especially when people rely on AI tools for reviews. Also, with AI, it’s getting harder to identify how much effort a contributor has put in; someone might take 15 days to implement a feature by writing everything by hand, while someone else could do it in 15 minutes using an AI tool. So, there should be a right balance to address this.

My two cents for current and new maintainers

First of all, if you are reading this and you are a maintainer, congrats and thank you for making this community great. A couple of tips that help me in my maintainer journey are having great docs, a clear README, and contributing guidelines — these will help you save a lot of upfront time and effort with new contributors. Automate as much as possible. Run linters and tests using tools like GitHub Actions so you don’t have to manually do the repetitive task and can focus more on code and collaboration. Keeping security in mind, create a SECURITY.md file so that people can report vulnerabilities in private instead of exposing them publicly, which could make it more risky. One of the most important things is to set boundaries that carry your vision and goal of the project, because there are times when people will want to get new features added, but that’s not how you have envisioned it. Saying “No” is the most reliable option. And there are some others, like labelling the issues well and getting more maintainers on board.

On the other hand, have some empathy for the new contributors because they might have less knowledge compared to a maintainer, so try to help them get started, encourage and uplift them.

At this point, I owe everything to Open Source. From whom I connected with to the opportunities I received for career growth, I will keep the momentum going and continue to support Open Source. At last, I am here writing this piece of content you are reading because of Open Source only.

You can connect with me on these channels:

Read stories shared by other maintainers.
This story was published under CC BY-SA by the author.