Did you know that nearly every JavaScript tool you use is open sourced?

In fact, the JavaScript spec (also known as ECMA-script) along with its implementations (v8 engine for example) are also open source.

Anyone (including you) can access the source code of your favorite tool and look through its history — or rather, it’s commits — to see how it has evolved. And not only can you see the history of the code, you can also help to shape its future.

That means you can participate in the development by making changes to the code, suggesting improvements etc, which is extremely exciting and maybe a little bit daunting at the same time. You might be wondering whether contributions to the most well-known open source projects are reserved for only those who may be considered to be ‘experts’, or ‘leaders’ in the field. While this may be true to some extent, there is enough room in the open source scene for people of all skill levels to play a meaningful part.

Just like anything worth doing in life, getting yourself familiar with the open source scene will take some effort and time, but being a part of this momentous community may be the most rewarding and transformative experience you get to go through as an engineer.

Historically modern web technology evolved without a single centralized entity that overlooked the whole JavaScript development scene. So it takes some time to wrap your head around all the different pieces (my favorite resource at the moment) that comes into play.

Its decentralized nature allowed individual projects to move fast by being organized into smaller communities for example React, GraphQL, WebPack, Babel.

Behind each one of these ecosystems is a group of people that maintain it and have their own expectations and principles about accepting contributions to their project.

Some of them are very well articulated and can typically be found in files such as CODE_OF_CONDUCT.md and CONTRIBUTING.md. Those principles might be things such as “be nice”, or “assume the best intention” — all important basics of working with people.

But some are more subtle, unspoken expectations — such as “do you create an issue before opening a Pull Request (PR) or not?”

The only way to understand how to work with a new team is to observe and pay attention. It is a good idea to follow some of the developing and closed PRs to get a feel of the culture in a particular project you would like to contribute to.