The journey to becoming a successful open-source contributor can be intimidating, frustrating, or confusing depending on your level of confidence, commitment, and expertise.

I have had my fair share of all sides of the emotions that come with contributing to open source in the one and a half years (at the time of writing this article) that I’ve contributed to open source, and I am inspired to share some of those insights with you.

Some of the insights here are relatable even beyond open source and tech, and could be applied in your daily life while making choices and strategies.

Let’s begin!

A Useful Analogy

The world is a global village. I could move between continents in hours thanks to air transportation. I can be in my room and know what is happening in a city thousands of miles away in real time thanks to the internet. Also, someone can know about me without us having to meet physically depending on how much public information they have about me.

Pause for a second, open a new tab, search your name (or digital username), and see what results are returned first. Are they a reflection of how you want the world, your potential employer, your next business opportunity, or your next potential customer to see you?

If you are a developer, designer, community manager, or documentation writer, do the search results reflect that?

Did you know that every time you make an open-source contribution it leaves a digital trace of you on the internet that later translates into a search result?

Most times when people are starting out in a field or career, they are scared of building or growing in the open because of fear of criticism, ego, impostor syndrome, or even lack of platform.

The more you distance yourself from public scrutiny, the more likely you are to have your own work surprise you once you let it out. How? While you are building alone, you think you are the best because you have created your own world but in the real world, you are most probably not the best at what you are doing.

The earlier you put what you are building out there, the faster it will be for you to create healthy competition, receive constructive criticism, and be challenged by those who are doing what you are doing better than you.

I am not a huge fan of building personal projects that are going to sit on my local machine or personal computer because then, they will only be available in my world and not to the world out there.

The best way to challenge myself with a new tech tool is by looking for an open-source community using that tool and making a contribution. I get better knowledge of how the tool I am learning is used on a real project and in the end, I am contributing to my digital footprint and increasing my meaningful search results.

Let me create another analogy here. If both of us are going for an interview and all you have are personal projects on your computer or GitHub account, and then all I have to show are commits that were merged into projects that are used by thousands of people, who do you think will pique the interest of a hiring manager with a technical background?

Experiences and Lessons in My Open Source Journey

I quit a job at a local tech startup because I didn’t see more growth in my career. At that time I knew what I wanted but didn’t know where to find it. I wanted to be challenged to grow and experiment on more challenging things in my tech career and get better opportunities.

I also had colleagues who had done some paid internships that changed their lives for good and could not stop thinking of how I could make similar achievements. I once decided to look for any community or project that matched the skills I wanted to be good at. At that point, I started learning a lot about how to navigate the world of open source, and here are my takes:

One of the quickest methods I used to find open-source communities or projects that is open to contributors was by checking sites that offer internships and are looking for participating organizations, both past and present. The most common and easier resources are Google Summer of Code (GSoC), Google Season of Docs (GSoD), and Outreachy.

Once you find a community/project you’d want to contribute to, do some background study to make sure that the community is active.

Note: Some communities are open source but are not open source friendly (mostly to new contributors).

Find out when they last merged commits, how many issues on their repositories are open and when the last one was closed. How many contributors do they have?

Most importantly, check if they have an active community that has real-time interactions through communication channels like Discord, Slack, Discourse, GitHub Discussions, IRC, and emailing lists.

Go the extra mile and check whether they have a meeting calendar and attend some of those meetings. Most times, public meetings always have public minutes and if you can dig into those resources and check out the discussions they’ve had, it will give you a perspective about the meetings before you even attend.

A distributed community that works remotely but doesn’t have a way of synchronizing is most times a red flag.

Communities that communicate actively are easier to navigate faster than those that don’t because you get a chance to ask the experts. This saves a lot of time in researching a particular subject in the community and understanding a large codebase, and gives you a feeling of being welcomed.

Once you find that community, make the “dramatic entry”. Make the “noise” that you are there, that you have arrived. Introduce yourself in the right channels, and talk about yourself (but only the important information). I like calling it the “dramatic entry”.

They won’t see you unless you show up and shout out.

Most communities have a lot of people (most times more than 500 or 1000) in their communication channels from different time zones. If you don’t make the “noise” then no one will notice you. And it is not a one-time introduction thing. Keep the “noise” going but make sure you are not bugging the members in the community.

It would be a weekly or bi-weekly update on how you are progressing in setting up the project and running it on your local machine, sharing articles that you have found over the internet that align with the community channel’s description, or even appreciating someone whose work or efforts you found helpful to you or to the community at large. Make sure they don’t forget that you are around — out of sight, out of mind.

Making the necessary noise is not enough

You have now settled down on a repository/community/organization. You should make meaningful contributions to the project. Sometimes it takes longer than you’d imagine but you need to show effort.

I remember when I joined CHAOSS, it took me more than 3 months to make a successful contribution of fixing a typo in a documentation. Just a typo! Mostly because the build process of the documentation and the contribution process was a little more abstract than that I’d interacted with before.

But while I was at it, I made sure that the maintainers knew that I was not quiet during that time and that I was putting in the effort to understand the large codebase and the contribution procedure and they were willing to help.

Magnets attract magnet materials. Seniors, Experts, and maintainers are more willing to help when you show that you are putting in personal effort and commitment to make things happen. And that is a general rule in life.

No one is responsible for you and everyone is busy doing something else but you have to show that you are putting in the necessary effort. This is enough to pique the attention of whoever should help you.

Now that you are putting in the necessary effort, it is important that you are putting the effort into meaningful contributions. As you progress and get assimilated into the community, you will get a grip on their codebase, knowledgebase, the inner workings of the community, and grow your network.

With time, you can take on harder tasks, issues, or open roles. You may be a non-code contributor and working with documentation, design, or community management. At a certain point, you’ll become familiar with the direction of the whole community and you can make a suggestion to change a process, design, workflow, introduce new knowledge, or even facilitate a weekly meeting.

Whatever you do make sure it adds value to the community. Remember, good work never goes unnoticed.

If you have to show around your work more than it shows itself or other people show it off, then it is not yet good work. For those making code contributions, writing code in the community is not enough. There is more to the community than commits and merges. Communities need designs, brands, meeting facilitators, media managers, mentors to newcomers and interns, publicity teams, and QA teams.

There is usually more that a strong community does other than writing code. Look around and get involved in more community initiatives. I did most of the things I have highlighted above during my first year of joining open source.

That is Not All

I have come to appreciate that putting in the effort is not enough. Working hard is not all there is to success.

There is always a percentage of luck and opportunity in every success story.

While you put in the necessary effort you must deliberately position yourself in the path of opportunities. Build healthy networks with seniors, board members, or in general, people who make the decisions in the communities or projects. Check on them in their DMs, give them mentions, and credit them for their significant works in the community where necessary.

The easiest way for your name to be mentioned in a room of opportunities is when it is on someone’s mind.

If you join communities with the motive of being a prospective intern for internship programs, make sure that the community that you are joining participates in those internship programs frequently.

You’d probably also want to join before the internship periods, and create networks, and community bonds. Look for the projects that are usually selected for the internships and show effort around those. By the time a task in one of those projects is listed for the internship, you’d already be an insider and can even influence the decision-makers to bias their choice toward you. That is working smart and hard at the same time.

Conclusion

The road to becoming a successful open-source contributor may be different for all of us but I believe there are things that cut across.

Success has a domino effect. One successful task, internship, job, or solution creates an opportunity for the next.

I wish you luck in your journey and if you are already there, share this information with someone who may need it.