linkedin Skip to Main Content
Just announced: We now support interviewing in spreadsheets!
CoderPad Open Menu
Back to blog

Dev Discussions: Breaking into Open Source with GitHub Star Ruth Ikegah

• Development , Getting Hired

By Ken Swearengen

Did you know you don’t have to know how to code to contribute to an open source project?

Ruth Ikegah first started contributing as a technical writer – fixing typos, creating tutorials, and writing how-to guides for projects she was interested in.

She’s now an experienced Python developer who is a maintainer on a handful of open source community projects and a contributor on many more. She also has her own blog, regularly speaks at open source conferences, and advocates for increasing open source contributions from developers across Africa.

Ruth readily admits this was not an easy path for her – finding open source projects to contribute to as a beginner was a struggle. Instead of giving up, she focused on figuring out ways that beginners could contribute (like documentation), which led her to become an advocate for beginners.

This advocacy propelled her to be nominated as a GitHub Star in 2020 – a program that recognizes GitHub contributors who are particularly inspiring or great community educators.

She recently sat down with CoderPad Developer Advocate Corbin Crutchley to give some tips on how beginners can break into the open source space and balance their professional growth with mental care.

Getting started with open source contribution

Often the most common path to open source contribution is through your development skills. 

For beginner developers, this could be something as simple as cloning the repo of a project you like and running the code to look for bugs. Submitting bug reports is a great way to start contributing to OS projects.

Do you think your dev skills need to level up before you’re comfortable with that? Or simply want to help out in a way better suited to your skillset?

There are several non-coding contributions that Ruth highlights to help you get started:

  1. Improve documentation: Documentation is often the last thought of developers. It can be outdated, riddled with typos, or full of errors – or it may even just be completely absent. If you have strong writing skills, this may be for you.
  2. Help organize conferences: If you’ve got more of an organization bent, you can help organize one of the many get-togethers that bring open source communities together. Getting speakers, doing administrative work, helping with logistics, and even giving a speech yourself are all ways to contribute to community events.
  3. Sponsor a project: Even all-volunteer projects need money! Providing the funding to help maintain a project is another noble way to contribute to the open source community.
  4. Lend your design skills: Those open source logos didn’t design themselves. Neither did the UIs. Designers can help make the product beautiful and usable.

You can use the GitHub Explore page to locate a project you may want to work on or an event you want to help out with.

Getting paid to contribute

Yes, there are ways to get paid for contributing to open source projects.

Ruth mentioned that for many people – parents, full-time students, etc. – the time commitment needed to work on open source projects could be a deterrent, especially if that time takes away from being able to earn money.

Open source internships hope to solve that problem. 

They’re exactly what they sound like – you work on an open source project for a short period, and you’re compensated for your work in return.

Perhaps two of the most well-known are Google’s Summer of Code for developers and Season of Docs for technical writers. In these programs, open source projects apply for a grant from Google to hire an open source intern.

In return for your work with these projects, you’ll get a stipend–the exact amount will vary depending on your location and the project size, but it’s generally in the thousands of dollars.

If you’d rather be an open source bounty hunter, BountySource.com may be more up your alley.

Here open source projects will list issues that need to be solved, with a bit of monetary incentive to help motivate you:

A screen shot of open source website bountysource.com that displays a list of bounties; one is Implementing vector-enhancements for facility 2 for s390x which pays $14000, the other is updating the altivec/vsx to be on par with the other accelerated architectures which pays $7505.
Some bounties on BountySource.com

Even if you’re not in it for the money, contributing to open source projects can be extremely rewarding. For some, it can even be downright addictive. 

Maintaining mental health for developers

Both Corbin and Ruth have struggled with burnout while working as maintainers and contributors to open source projects. 

It’s easy to want to do everything and take on too much. It can feel like you’re letting the other contributors or users down if you take a break and step away to rest. You don’t want the project to fall apart, so you make sacrifices in all the wrong places.

Ruth readily admits it takes courage to step back and make time for yourself when you have that pressure to deal with.

But she does have some tips to make taking a mental health break more manageable, and it all starts with project maintainers setting the example. They have to realize that: 

1) burnout can happen to anyone and actually decreases productivity, and 

2) the project won’t fall apart if they take a break. 

Now, this might take some planning – like delegating some of the work to some of the project contributors – but by taking a break themselves, project maintainers let the contributors know that it’s okay not to live and breathe the project every day of their lives.

The maintainers should also be aware of pending burnout in their contributors, like a drastic drop in activity. Additionally, maintainers can:

  • Have regular check-ins with contributors to ensure they’re getting rest and taking care of themselves. 
  • Encourage them to take breaks and let them know that their health is more important than the project.
  • Discuss the possibility of burnout with them and the steps they can take to prevent it.
  • Make sure they don’t overload new contributors with work, as they may not yet know how to say “no” to you.
  • Set a formalized roadmap or list of goals for new contributors so that they can more easily pace themselves.

Ruth emphasizes that maintainers should act as mentors to project contributors. 

Not only is this important for creating healthy working relationships for the sake of the project, but it allows contributors to feel more comfortable talking with the maintainers about burnout. It also helps maintainers to be able to take breaks and hand off work to contributors for their own mental health. 

Nevertheless, the responsibility for turning down work isn’t only on project maintainers – contributors too need to know when they’ve reached their limits and be willing to have a conversation with the maintainers to let them know that they need time to recuperate or hand things off to other people.

Parting tip: Always be learning

It’s not uncommon for open source contributors to become maintainers themselves after gaining some experience. 

But Ruth recommends continuing to educate yourself outside of your contributions to a particular project.

She’s currently taking courses in open source management to help improve her community management skills. When it comes to sources of learning, she recommends a few free or low-cost sites:

No matter where you take your courses, the important thing is that you keep improving upon your skills and growing yourself as a developer, designer, technical writer, or any other career path. 

And before you know it, you’ll be maintaining your own open source project.

CoderPad too believes in continuous learning – so please enjoy these informative articles we’ve published to help keep you on top of your engineering game: