loading...
Cover image for Learn by Contributing

Learn by Contributing

agoldis profile image Andrew Goldis Updated on ・11 min read

Contributing to open source projects helps you to improve your professional skills and discover new opportunities.

Being a professional software developer requires continuous improvement and learning.

It doesn't matter if you are a boot camp rookie, university graduate or a software development veteran, it would be useful for your own professional development (and curiosity) to explore different approaches of doing software.

Keeping up the pace is quite difficult. You have grow "horizontally" - be aware and get experience with new technologies, improve your expertise with mainstream popular tools; also you'd evolve "vertically" by solving more complex and more abstract problems. 

Experienced developers are limited by the tech stack adopted by the team at their workplace. Being aware of different approaches would give them leverage and show a different perspective on the solutions that are common at the team/company and alternatives.

For the developers at the beginning of their career path, it is even more challenging. The variety of tools and techniques is overwhelming! It's very hard to know what to focus on and what tool is the best for a specific task without prior experience with similar kind of a problem.

Courses and tutorials, even advanced, usually, do not provide the required level of confidence. There's always a "beyond the tutorial" wall. You stumble upon a problem that is out of tutorial's scope and start looking for solutions elsewhere.


My main background is web development, and this specific niche of software development has undergone tremendous changes during the last years. There's a well-known phenomenon of "Javascript fatigue" caused by the number of new tools and techniques that emerge every week. The language itself changed a lot and became the most popular programming language on the planet.

Stackoverflow Developers Survey 2019 - Most Popular Technologies

Stackoverflow Developers Survey 2019 - Most Popular Technologies.

In this post, I want to share the technique of using open source projects for professional development that I've been practicing during the last few years.

The JS eco-system is particularly "open sourced" - that allows using the power of OSS to the full extent.

It is very good for you

Contributing to open source is good for you. Actually, it is good for everyone, and here's why.

You help others

No matter what your contribution type is - documentation, code changes or even just opening an issue - you improve the tools we all use and make other developers life easier.

Excellent projects quality

Open source software is not an underdog anymore. The quality of code is often superb to internal codebases. By working on projects of such a quality you see how others do good software.

Stackoverflow open source projects quality - survey 2019. link

Stackoverflow open source projects quality - survey 2019.

Glimpse into professional software development

You can literally see and learn how software is done at Microsoft, Google or Facebook (and many other companies that are known for good engineering) - the companies use an open source license to share internally written code. 

Collaborate with experts

It takes quite a lot of experience and expertise to recognize, implement and maintain a successful software project. 

People behind these tools have a passion for their creations and love what they do - they are true experts. The feedback you're getting while working with them is valuable.

You're creating a proof of your expertise

Having an impressive portfolio on Github (or whatever platform of your choice) is a solid indicator for your future employer. Moreover, many headhunters use Github to find talents.

Many companies hire core contributors that work on company-supported open source projects. 

Andrew Clark tweets about being hired by Facebook. Andrew contributed a lot to ReactJS eco-system prior to this tweet.

Some companies sponsor maintainers of open source project without hiring them.

Example of maintainers being paid for their support of BabelJS via Open Collective.

Example of maintainers being paid for their support of BabelJS via Open Collective.

It is free

Education and experience are expensive. While engaging and contributing to open source projects, you're getting valuable experience of practicing software development, getting feedback and creating a portfolio for free!

Stackoverflow informal education types - survey 2019.

Stackoverflow informal education types - survey 2019.

Now that we've agreed that contributing is awesome, let's try to break down the types of contribution you can do, depending on available time, required effort and expertise in the subject.

Every time you face a problem

It is hard to start contributing without any context or specific motivation - how do you pick a project that is interesting enough and would be useful for your professional development? 

Stackoverflow open source contribution survey results - 2019

Stackoverflow open source contribution 2019 survey results.

It is much easier to start when you have an actual problem with a third-party open source project. A problem that matters to you. 

Fortunately, Javascript development is very dependant on publicly available software (via npm packages) and the solutions are not perfect. 

Every time you see a problem - either it is a configuration, documentation or an actual issue, it is an opportunity to improve, contribute, and to learn/boost your professionalism!

The contribution checklist

Create an issue

That's the minimal, least time-consuming and most important type of contribution you can do.

One can say it is not a real contribution, but I do consider it very important. In fact, Github does count it as a contribution:

The contribution 4 types as considered by Github

The contribution 4 types as considered by Github

Let's start with an obvious observation - without creating an issue, maintainers would never know there's a problem with their software, neither they would be able to improve it.

But, you're the one who mostly benefits from doing that!

Have you ever found yourself trying to unsuccessfully solve a problem, and after a few attempts calling a colleague for help? As soon as you start to describe the problem - eureka! 

You've suddenly got it! (Usually, it's a typo, right?)

It is quite hard to describe a problem effectively and precisely ✍🏻. Most projects today use some kind of a template for new issues. By following the template, you're forcing yourself to look at the problem from a different point of view.

By describing the problem in your own words, you can suddenly realize what the solution is and… just apply it!

Alternatively, describing the problem in your own words could spark new ideas/hypothesis. If that's the case - 🙌🏻 great job - go ahead and tell your colleagues.

If not, you've just created an issue with a good explanation. It would help the maintainers. You help other developers - now they are able to confirm that the problem is not in their own code. People will discover your issue and add 👍🏻

By having this first engagement you create an opportunity for the maintainers to guide you, possibly propose a solution and motivate you to open a pull request with a fix (more on that later).

See, you're already helping lots of people!

Bonus: When creating an issue on Github, you get a nice auto-suggested list of already existing issues, that helps to discover solutions and prevents duplications! 👍🏻

Github auto-suggests similar issues

Github auto-suggests similar issues

Provide a minimal example

It would be much easier for the maintainers to deal with a very specific, minimal representation of the issue you're reporting.

Although it is more time-consuming, it is also beneficial for you. By extracting the problem you get:

  • confirmation that it is actually a problem with the tool/library itself and not with your own code
  • a better understanding of what the problem is (which can be used later to effectively describe the issue)
  • opportunity to solve the problem by dealing with a simplified context

By removing unnecessary complexity while composing a minimal example, there's a high chance that you understand the problem better, discover a solution or even realize that it wasn't a problem at all 😼

Here's a list of some platforms that can be used to create a reproducible example:

Example of an issue with a dedicated repository with a reproducible issue.

Example of a dedicated repository with a reproducible issue.

Find a workaround

At this stage the problem is confirmed and validated, or maybe not completely validated, but… you want to move forward and just get rid of it! 

Most chances you don't have time to dig into the 3rd party library source code, but you can probably find a workaround!

It could be an ugly monkey-patching, configuration change or some creative way you've found to overcome the problem. It is your obligation to share it with the world!

Either create a new issue or add a comment. You'll get tons of ❤️, 👍🏻 and 🎉!

Workaround and a lot of👍🏻 example

Workaround and a lot of👍🏻 example

Bonus: other people could comment and share a workaround that's better than yours. 

Suggest a solution in comments

Great news - you've just found a solution or have great confidence about what might be a good solution! 

It works great in your codebase, but you don't have time to create a pull request with tests and /or documentation.

It still might be valuable to just share your discovery - others will pick it where you left.

BTW, often the problem is not even in the code - it might be a configuration issue or lack of clear documentation that leads projects users in a wrong direction. 
The point is to share this little piece of knowledge - it is valuable, even if it doesn't seem like significant contribution.

Implement a solution in your own repository

What happens a lot is that project maintainers are not quite responsive. Most chances they are just busy with their life, or too busy at a workplace.
 
A good temporary solution might be forking the project and pushing the change in your own repository. 

Your peers can use your temporary repository as a dependency. While not ideal, it can help your team to move forward. ✅

Meanwhile, submit your fix as a PR. Eventually, the authors will review your fix and issue a new release. It is very important to create the PR though, otherwise, you're at risk of being stuck with a dependency that cannot be updated.

Sometimes, authors will suggest joining core contributors list, and that's awesome - you have the opportunity to take the responsibility and maintain a project with active users. 

Create a Pull Request

Pull requests are the bread and butter of open source development.

Everyone can contribute, take part in a bigger project, leave a digital trace of skill and expertise 🌟

Most important - it is the biggest, most effective opportunity for an individual to learn and improve 💪🏻

Contributing to open source projects gives you superpowers and helps humanity

Contributing to open source projects gives you superpowers and helps humanity

There're several layers of valuable experience you gain by submitting a pull request - let's list them:

  • You see how complex problems are solved, discover new architectural approaches, different ways to organize project and code

  • You discover new coding styles and techniques

  • You discover new or different use of testing frameworks, CI pipelines, linters and enrich your experience and knowledge of using other complementary tools

  • You are creating an opportunity to get valuable feedback from experienced professionals

  • You are learning the internal implementation of the tool you're working on - it will help you to use it better

  • You're creating an authentic, transparent record of your achievements and professionalism

  • You connect with other developers, which creates opportunities for collaboration, hiring and, is simply fun

That's how you learn and become a better professional - you do more of different stuff. 

You see and try different approaches, learn the good and the bad parts, apply what you've seen in different situations and get feedback about your decisions.

By iterating and regularly challenging yourself with more complex subjects you gain the professional confidence and experience 🥋

Discovering opportunities to contribute

As I have mentioned, it is easier to start to contribute when you have an actual issue that you have to resolve. But what should you do if you don't work with OSS tools and still want to find contribution opportunities? 

Online

Github recommends project owners to assign labels to issues that are easier to start with. A simple search by label: good first issue will reveal more than 200k issues to pick from 😄

You use label: help wanted search query to discover more complex issues that are not necessarily beginners-friendly. 

There're plenty of resources that do some kind of aggregation based on technology, difficulty, and popularity of a project.

Here's a list of few such projects to get you started:

And a lot, a lot more…

Offline

There's a good chance more people in your area are interested in open source contribution opportunities. Try to find a meetup event. 

One particular example I want to highlight is Goodness Squad. I personally participated in one of those events few years ago. It was extremely effective and helpful.

Summary

While writing the article and discussing it with my friends, we noticed that there are plenty of resources that help to discover projects that need contributors help. However, it is quite hard to find a project that you can learn a particular skill / coding aspect. 

That's why I have created an alpha version of such a list:

GitHub logo agoldis / learn-by-contributing

A curated list of open source projects that you can learn from

Learn by contributing

This is a list of open source projects I personally used to learn different aspects of Javascript development (backend and frontend).

It is very, very incomplete. I am trying to figure out an efficient way to discover and classify projects that others can learn by contributing. If you have any ideas, please help me!

Feel free to add your favorite project and what other can learn from it!

Javascript

Code Transpiling

https://github.com/babel/babel/tree/master/packages/babel-parser - learn how works javascript parser that powers popular tools like babeljs and prettier

https://github.com/kentcdodds/babel-plugin-macros - learn how to write a babeljs plugin

Architectural patterns

https://github.com/webpack/tapable - learn a generic hooks-based architecture that powers webpack

https://github.com/ncthbrt/nact - learn about nano-services from this NodeJS implementation

Frontend

https://github.com/GoogleChromeLabs/prerender-loader/blob/master/src/index.js - ???

https://github.com/tcoopman/image-webpack-loader -learn how to write a simple webpack plugin

https://github.com/willyelm/pug-html-loader - learn how to write a simple webpack loader

Animations

https://github.com/aholachek/animate-css-grid - learn how to animate complex…

This is a small list of projects that I personally found helpful for my own professional development (Javascript-related only for now). I hope it will help developers to find good projects that they can learn from.

The Cover Photo by Hello I'm Nik on Unsplash

Want to know more?

Check out The Definitive Guide to Contributing to Open Source by

doomhammerng image

P.S.

Edit (April 23, 2019):

I'd like to highlight a comment by

nickytonline image

Nick gives us few hints and provides real-world examples of his contributions to OSS. Here's a brief summary of what Nick mentioned, more details in the conversation thread:

  • I would say only work on stuff that you find interesting and challenging. Otherwise don't bother. You won't enjoy it.

  • When I first started learning react, I started contributing as a way of learning. I found a react boilerplate project, react-slingshot and just started offering suggestions that became PRs, and also did bug fixes. Takeaway from this is open source is a great way to learn from others and if you contribute enough to a project, you may be asked to become a maintainer (if that's your jam).

More

Posted on Apr 20 '19 by:

agoldis profile

Andrew Goldis

@agoldis

A curious web developer since 2006

Discussion

markdown guide
 

Great write up. I couldn't agree more.

There just isn't any better way to learn than by solving real problems and working with others more experienced than you.

Not to mention the confidence you'll gain and the satisfaction you'll feel!

 
 

I think a mentor helping out would be a good idea. Assigning issues, being hands on through the first couple of issues. Maybe even working on issues together. Would be a great way to assess skill level too.
I think that could be helpful.

 

Definitely! That's why I've mentioned the Good Squad meetup - I've had a great experience attending it!

 

I've been thinking about organizing something similar in my town, but I feel like there wouldn't be much interest here.

What about a virtual event? May be that'd work

That would be interesting, especially with live share extension for vscode/vs2019. This could actually for for mentoring too.

Oh, that's a cool idea to use live share! You can also stream on twitch or livecode.

The format I saw goes like this:

  • The organizer(s) discovers repositories that needs attention
  • The organizer(s) contacts the owners and asks to reserve few issues (+ mark with a label) for the event
  • The organizer(s) provides instructions for each project - how to setup, what's the issue and how to get started
  • The participants are assigned to issues (singles or pairs)
  • The participants submit PRs
  • Party, beers and happiness 🎉

That sounds really interesting.

 

Great article, @agoldis ! I tried to approach the topic from a different angle at medium.freecodecamp.org/the-defini... . We seem to have some points in common, while we also mention separate ones.

I wonder: can you recommend any more good articles on contributing to Open Source?

 

Thank for reaching me! It is a great read what you've posted! Seems like you have mentioned few points on OSS that I didn't cover - that's great, readers can discover the various aspects of contribution to open source.

As for other articles, I can't quite remember... your post is great though! What do you say about posting references to our publications so readers could discover the content?

 
 

I've really been enjoying contributing to open source and I definitely agree with you that even documentation is valuable to OSS.

I'm still feeling really good about my past week, so I'm just gonna drop this here as it relates to the post.

This week, I got a PR merged that I've been working on for quite a while for the Refined GitHub browser extension. Feels pretty good.

Enable strict-mode for TypeScript #1783

Basically going with the non-null assertion operator in almost all places, because as mentioned in github.com/sindresorhus/refined-gi..., the assumption with the extension is that the DOM nodes referenced in most cases are expected to be there. If they aren't, the extension breaks, a bug is filed and it's fixed.

One thing to note @bfred-it, is currently dom-chef types need to handle JSX (Element and IntrinsicElements) or we import @types/react.

In the process of working on that PR, I discovered a bug in the TypeScript types that ship with TypeScript.

Missing string indexer on NamedNodeMap interface in lib.dom.d.ts? #30928

For context, see github.com/sindresorhus/refined-gi..., specifically this commit, github.com/sindresorhus/refined-gi....

Also, just posting my tweet about this so that people can find discussions about the issue. See twitter.com/nickytonline/status/11...

I'll restate what I tweeted as I probably should have posted my question here originally.

The NamedNodeMap interface in lib.dom.ts does not allow for a string indexer, even though vanilla JS supports this in browsers, e.g. someDomElement.attribute['aria-label'].value.

We have code like this in the Refined GitHub extension, so for the time being, I've gone ahead via a declaration merge for NamedNodeMap

interface NamedNodeMap {
      [key: string]: Attr;
}

I can't tell from the MDN docs for NamedNodeMap if it's standard or not. All they seem to mention is "Attr nodes' indexes may differ among browsers" which wouldn't apply to access by the attribute name.

Just wondering if this was omitted by mistake or is it because this is not considered WHATWG DOM standard? I went to dom.spec.whatwg.org/#interface-nam... and unless I'm reading it incorrectly, I believe it states that using a string indexer is valid.

Thoughts? Happy to PR this up if it's valid.

And finally, I've made a few PRs to dev.to to get back in the swing of things of contributing there as well.

Fixed some frontend linting issues #2495

What type of PR is this? (check all applicable)

  • [x] Refactor
  • [ ] Feature
  • [ ] Bug Fix
  • [ ] Documentation Update

Description

Fixed some linting issues being reported in the frontend.

Related Tickets & Documents

#1828

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

Added to documentation?

  • [ ] docs.dev.to
  • [ ] readme
  • [x] no documentation needed

[optional] What gif best describes this PR or how it makes you feel?

Richie Rich robot

Boom!






 

That's awesome!!! May be you can share a few tips about how to do what you have done successfully? E.g. how did you discover the problem and what did you do to isolate, solve and deliver the solution? What did you learn on the way?

 
  • I would say only work on stuff that you find interesting and challenging. Otherwise don't bother. You won't enjoy it.

  • When I first started learning react, I started contributing as a way of learning. I found a react boilerplate project, react-slingshot, and just started offering suggestions that became PRs, and also did bug fixes. Eventually I was asked to become a maintainer to which I said yes.

coryhouse / react-slingshot

React + Redux starter kit / boilerplate with Babel, hot reloading, testing, linting and a working example app built in


Build status: Linux Build status: Windows Dependency Status Coverage Status

A comprehensive starter kit for rapid application development using React.

Why Slingshot?

  1. One command to get started - Type npm start to start development in your default browser.
  2. Rapid feedback - Each time you hit save, changes hot reload and linting and automated tests run.
  3. One command line to check - All feedback is displayed on a single command line.
  4. No more JavaScript fatigue - Slingshot uses the most popular and powerful libraries for working with React.
  5. Working example app - The included example app shows how this all works together.
  6. Automated production build - Type npm run build to do all this:

React Slingshot Production Build

Get Started

  1. Initial Machine Setup

    First time running the starter kit? Then complete the Initial Machine Setup.

  2. Clone the project

    git clone https://github.com/coryhouse/react-slingshot.git.

  3. Run the setup script

    npm run setup

  4. Run the example app

    npm start -s

    This will run the automated build process, start…

Takeaway from this is open source is a great way to learn from others and if you contribute enough to a project, you may be asked to become a maintainer (if that's your jam).

  • In terms of problems/solutions, the more recent one I had while converting the Refined GitHub extension to TypeScript (TS), I had converted everything to TS, but webpack builds were failing. So initially, I tried some configuration changes in regards to webpack and the TS config, but no dice. I compiled each entry point from webpack directly with the TS compiler and they built fine, so clearly something was not right with webpack/TS situation.

At this point I started to debug webpack, specifically the ts-loader plugin. If you've never debugged webpack code, you can run the following command to get started with the debugger. node --inspect-brk ./node_modules/webpack/bin/webpack.js. I found the error that was being thrown from webpack in the code and put a breakpoint there. First I saw that the files weren't being generated. When I reran the debugger, this time I saw that a particular boolean was not set properly which was related to webpack/TS configuration. Once I fixed the configuration, I was good to go. Takeaways, use your tools. Also, I was probably tired at this point and probably missed the obvious misconfiguration. 🙃

Awesome!

  1. I started using refined-github :)
  2. Would you mind if I copy your comment to the article? It's very inspirational and a good showcase of real-world example
 

I am a dev for many years now and I am currently on "analysis paralysis" to start contributing to OSS. Thanks for the links, they will help a lot! I'll start digging straight away!!

Have a good one! :)

 

Hey, thanks for the comment here! Wondering what "analysis paralysis" is :)

 

From wikipedia :P

"Analysis paralysis describes a moment when over-analyzing or over-thinking a situation can cause it to become 'paralyzed', meaning that no action was taken therefore a solution is not reached."

I am always wishing to contribute but took no action since I am always trying to find the "best" repo to contribute and also there is a hidden fear of not being good enough... I code since I'm 13 though... I'm 29 now. People call this "The impostor syndrome"

oh, enhanced my vocabulary, thanks a lot! :)

 
 

Personally, I think it's hard to find open issues that are available to work with. Usually someone has already commented on an issue and sometimes didn't even deliver for months... 😢

 

Hey! Sorry to hear you find trouble finding issue to help with.

Did you try one of the tools mentioned to discover available issues?

Also, from my experience it's ok to take over an issue if someone is not getting it done in reasonable amount of time. As an alternative, you could, may be suggest your help in a comment.

 

Besides PR there's another way to contribute which is documentation which I think is much easier to do it instead of contributing code.

 

Totally agree! Every type of contribution counts! Good documentation is very valuable for every project.

 

Great article, but I've missed about that problems in contribute OSS. An example, when the maintainers are rude or people in conversation aren't polite.

There are projects that you want write an issues or create a pull request but involved people in project don't accept arguments or simply ignore and deleting your contributions. It's frustrating because you want help it but you have fear to contribute.

 

Yeah, that's a good point! I wanted to focus on the positive part of OSS and how an individual can harness it for her / his own good.

 

I was thinking about writing a very similar post! But yours is very complete and well made! Cheers :)

 

Thanks a lot for the feedback! If you have some observations / ideas that I have missed, please share!

 
 
 

Thanks for sharing. Last fe month i am contributing in open source. Its feel awesome. Also I am learning more and more.

 

That's awesome! I hope you keep getting good experience with OSS!

 

Thank you I love the final URLs to get started and avoid reinventing the wheel or the annoying google ads to sell you something every time you search

 

Thanks for pointing out they are useful, I was in doubt about those links 😀

 

Brilliant.This gets me wanting to contribute already