Next month comes Hacktoberfest, which for 6 years has been involved in the promotion of open source contributions in order to support these projects which are now part of our daily life as developers.
In order to discover the opportunities to be part of the open source community, let me share you my journey, from a open source project consumer to a regular contributor.
There is no standard that defines the types of projects that can be open sourced. We can thus find projects as varied as a programming language, a framework, a documentation, a toolkit or even just a simple list of useful resources. However, these projects have in common to be in capacity of having a significant impact on the life of a developer, both during his initial learning path and later on during his professional life.
Soon after I landed my first job as a developer, I decided to take a closer look at open source projects in order to help them out.
My first contribution
How to identify a project
One of the biggest challenges for a new contributor is knowing how to find projects on which he can intervene. For active, untargeted research, search engines such as http://issuehub.io/ are a great way to quickly identify contribution needs.
During the Hacktoberfest period, labels such as hacktoberfest, help wanted or good first issue are effective ways to filter out more affordable contribution needs. For the most part these are subjects with a limited workload on which the team being in charge of the maintenance of the project (so called maintainers) can provide you support.
While these subjects are useful for the project, they are also a good opportunity for the maintainers to make it known to the public and to introduce it to people who might contribute more regularly thereafter.
Another solution to identify these projects is through latest discovered trends or your professional needs: this is a great opportunity to learn more about the tools you use on a daily basis and to be able to improve them both for you and the whole community.
My choice was to take an interest in Angular's open source ecosystem for my first contributions. This gave me the opportunity to :
- improve the readme of a course
- correct the styling of a search engine
- add content to a list of best practices
- fix a typo on tslint documentation
None of these contributions required in-depth technical knowledge about the project: either there were issues awaiting to be assigned to a contributor, either there were bugs discovered while exploring the project itself.
Be part of the community
These previous contributions did not require me to communicate that much with the maintainers, so the know-how was sufficient to deliver contributions. But to participate more actively in bug fixing or submitting new features, i knew i needed to be more confortable on the way to explain concepts i was using without having to make the effort to explain them.
I therefore decided to orientate my contributions towards discussions around the projects in order to participate to their support and their understanding.
The first solution was to participate on the project directly. The more important and popular a project becomes, the more the project team is solicited with requests for bug fixes or for support on the proper usage of the project.
It is then possible to support the team by participating in these discussions:
- by requesting more complete information to speed up the work of the project team on their understanding of the problem
- by trying to experiment a reported problem yourself to validate the reproduction
- by providing information on the ways to solve a problem when not the fact of the project itself
All these contributions are greatly appreciated by a project team as they allow them to free up time to focus on the problem directly (this is why Github offers the integration of templates in order to format the communication to make it more efficient for issues and pull requests).
My second approach to this effort to improve my communication skills was to provide answers to questions on third-party platforms such as gitter or stackoverflow.
First Hacktoberfest participation
Then came the opportunity for me to participate for the first time to the Hacktoberfest event in 2019. Beyond the promotion that the organisation does through support for open source related events and the production of documentation to encourage contributions, Hacktoberfest offers to win a t-shirt each year to contributors, by submitting 4 pull requests by October 31st.
Having so far focused my attention on a small number of projects, reaching this challenge prompted me to take an interest in other projects, this time opting for a less interested and less focused discovery.
During the event, the issue trackers are flooded by issues tagged with hacktoberfest and good first issue, making it easy to find out opportunities to help projects!
Be part of a project
I discovered the Scully project, a static site generator for Angular applications, in March 2020. So still at the start of its alpha phase, it was a great opportunity to follow Dan Abramov's advice (even if i wasn't actively using this project):
Considering the alpha phase, my goal was to discover the evolution of the project, through the issues raised and the addition of new features.
An opportunity to contribute appeared really quickly: while the documentation was a very good way to understand the project, it also allowed me to identify ways to fix it or to improve it.
When it comes to think about the ways to contribute to an open source project, we often think more naturally about fixing a bug or adding new features. However, contributions to the documentation of a project are just as important because they "contribute" to the success of a project. This step allowed me to learn more about the project itself, thus opening doors to fix bugs as well as getting a broader vision of the gaps in the documentation for further contributions.
Still active on the project, I mainly devote myself to discussions on issues and code review.
Be part of an organisation
The most recent step in my journey as a contributor came last July in response to Netanel Basal's tweet:
ngneat is an github organisation providing utility libraries for Angular projects, well-known for projects like Transloco (internationalization) or Spectator (testing utilities).
My first task was to create a library based on an old blog post written by Netanel Basal.
As the blog post was a proof of concept of this feature, i had to go further.
When you need to add a new feature in a project, your goal is to make sure it fits with the project, providing all required features. An open source project can't work that way as it isn't related to a project and therefore needs to provide an api with a wider scope.
For this project, one of the good practices was to use the OCP (Open / Closed Principle). By being opened to extension, you don't need to cover specific usages, giving the control to the users through extension. By being closed to modification, once deployed, the library should only be updated to fix bugs.
After the release of the library, I was given the opportunity to participate into other projects within the organisation, thus continuing my activity as a contributor.
Conclusion
Entering my third year of experience as a developer after joining a bootcamp, this experience was a real springboard to accelerate my learning and boost my skills.
Through the projects and the needs of the public, it is an opportunity to be confronted with a compendium of diverse and varied business realities and constraints, thus making it easier to face real customer needs.
It is also an opportunity to meet and discuss with technical experts on their solution and thus to challenge oneself on the quality of the contributions that we offer: from communication to technical implementation, including good practices when using git.