As a DevRel professional, I have the pleasure of collaborating with numerous open-source (OSS) contributors every week, while also indulging in open-source pursuits myself. I've come to recognize a set of unwritten rules (or at least, I haven't seen them documented anywhere) that, when followed, can distinguish you as an outstanding open-source developer. I'm assuming the reader is a developer aiming to leverage open-source contributions for building a portfolio, enhancing job prospects, or growing your brand while supporting projects you're passionate about and enjoy. If you're an OSS contributor doing it purely for enjoyment or as a hobby, there might be some tips on this list you might want to skip, up to you. The reality is that most, if not all, open-source projects aspire to serve and impact an ever-growing user base, where increased exposure is as crucial as ongoing feature development. You, as an open-source contributor, can assist with both. To truly stand out, it's essential to understand that your contributions can extend beyond just code. Let's explore how.

Coding related contributions

Address open issues first

If you stumble across an open source project that you like on GitHub and start diving into the README.md file to learn more, resist the urge to simply open a PR to add an adjective or rearrange the way a paragraph is written, if you see a glaring spelling mistake then by all means, correct it. But if your first instinct is to find and correct spelling mistakes, you are not starting off on the right foot to stand out. Most projects are going to have a good few open issues ready for the taking. This should be your first stop. This is the project being open with what they need help with, hear them out before you think of features to be added.

This would be my workflow when evaluating a project:

• Read the readme file from top to bottom to gain a general understanding of what the tool does and why it exists.

• Install or use the tool itself and make sure you understand its purpose and use case.

• Head on over to the open issues to understand in which direction the tool is moving and what work needs to be done.

• If you are new to the tech stack, look for “good first issue” tags.

• Read through at least 2-3 issues to understand the areas work is needed in.

• If you are not sure you are ready to take on any of the issues on your own then open up chatGPT and start asking questions to uncover exactly where your gaps are and what would be needed to bridge those gaps.

• Ask questions in the issue itself and ask for clarification on anything that is unclear without feeling obligated to claim the issue.

• Even if you don’t know exactly how to complete a full issue, try it! You will always be able to open a PR (even if your solution is unfinished) and can collaborate with the project maintainers directly on the PR, taking it one step at a time until completion.

My philosophy on choosing what to work on has been greatly influenced by people who I’ve worked with in the past and from the great open source contributors I’ve had the chance to collaborate with such as Mohamed Labouardy, Fotis Papadamis and Shubham Palriwala to name a few. A common thread in their work is that they focus on adding value first. It’s through adding value to open issues that they then gain insight and familiarity with a project and that’s when they feel ready to propose features and improvements.

Make impactful readme contributions

If you've gone through the open issues and you can’t see anything that you feel ready to contribute to, or perhaps you just can’t find anything that excites you yet but you still want to add value to a project here are a couple of ways to add value to readme files that isn’t simply fixing spelling mistakes.

Since these two ideas aren’t addressing open issues, I would always start by opening an issue to propose your idea and intention, before working on it. Keep in mind that even though you might think a contribution could be valuable or desirable, you will have to get the sign-off of the project maintainers. So let your intentions be known and open up an issue first!

Adding project demo animations (GIFs)

A great way to add value to a readme file if appropriate is to add animations in the form of GIFs. Even if the tool is a CLI or a GUI, an animation can be a great way to attract attention to the value proposition of the project or it can also be used to show how to install the tool for example. Below is an example of a GIF used in the Komiser repository.

Note that GitHub will only load GIFS that are under 5MBs

I use the Screen studio app to turn screen recordings into GIFS in case you were wondering.

Adding a Contributor’s section

Another useful feature that might be welcomed to a repository if it doesn’t have it already, is a contributors section which shows the avatars of the contributors to a project. There is no need to over-complicate the task by running a script to detect the authors of the closed PRs belonging to a repository and then also retrieve the image and format it nicely. You can simply use contrib.rocks, in which you can add the name of the public GitHub repo domain and then add the generated image URL to the readme file.

Non-coding related contributions

Write user testimonials

An incredibly understated skill in technology jobs is writing. Your work should speak for itself but how can you get people to even come across your work in the first place? One of the ways of by writing about it. There are some great thought leaders in the industry, such as Ankur Tyagi, who insist quite heavily on the importance of realizing that writing is as important a skill as the technical execution of the day-to-day tasks of a software engineer. If writing becomes one of your strongest pillars of expertise, you’ll go far, it’s as simple as that.

And as luck has it, this is an area where you can potentially have an outsized impact for an open-source project. Most projects don’t have a traditional marketing team working in the background, it's something that just doesn’t resonate too much with this ecosystem. What most projects focus on is Product lead growth, meaning that the effort is being put into making sure the product is at least minimally functional and useful from the earliest MVP, and from there they depend on feedback from users and contributors to continuously evolve and improve the project through monthly, weekly and ideally daily minor upgrades. If the project can stay lean enough, keep their ear to the ground and listen closely to the community they will be in a good place to succeed. And this is where you can help a great deal.

This is the context in which we find ourselves. If you, an aspiring OSS contributor write a user testimonial, you are pretty much guaranteed to have an audience. The worst case scenario is that it might just be the maintainers of the project who read it initially, which is already valuable since you will have a direct line of communication established with the project. But the best case scenario is that if your testimonial is positive and brings attention to how you found the project useful, it will be re-shared by the project and reposted everywhere serving as an incredible win-win for both parties. The project gains in visibility and you on the other hand grow your reach, and influence and more eyes will land on your work.

Record product demos

If you are not that keen on writing, open up a loom account and get more familiar with reviewing projects and recording demos. No matter how simple you might consider what you are talking about to be, always remember that for many people the content of your simplest video is going to be completely new to them. If you want to record a demo showcasing how to install a CLI tool, don’t think about what the project maintainers are going to think. Think about how the person who has never installed the tool is going to understand the video, is it easy for them to follow, have you covered the steps where they might get stuck? I want to repeat this point because I think it’s an important one, don’t cut yourself short. Don’t avoid doing something because it’s been done or it might seem redundant to you at first. A project will always find community-created content hugely valuable and you will be building speaking, video creation and reviewing skills that will surely be valuable in the coming years of your career.

Add value to OSS communities by helping other contributors

This is something that comes more naturally to some than others, you will have to look inside yourself and see what comes naturally to you and see if this is a way you might want to be impactful in your OSS journey. What I always try to keep in mind is that when I have a doubt and I share it out on a reddit thread or in a Discord channel and somebody responds and helps me solve my issues. That person decided to do that, that person for a second, stopped what they were doing and took the time to think about my issue. And that is something that I’m always grateful for. So I would advise you, if you have the chance, to try to help out others if you have the capacity do to so.