Photo by Toufic Mobarak on Unsplash
If you don't like tango but want some practical tips, jump to the paragraph the lazy programmers's guide to hacktoberfest.
I am doing two great things in october, and cannot resist the temptation to connect the dots between them. Here is my claim:
Dancing argentine tango and contributing to the open-source is essentially the same thing.
Not convinced? Read on.
I suggest that you put your headset on and listen to Shakira's tango like I did while writing this article.
- The social side of open source
- Electro, Tango or Madison?
- Dancing with a total stranger feels weird
- Dance both sides of the game
- It's all about creating a connection
- Your dancing partner is not you
- The lazy programmer's guide to # hacktoberfest
- Cool articles on dev.to
The social side of open source
To contribute better to open-source, you need to develop both your technical and your social skills.
For the former, I will refer you to this very useful collection from Kim Arnett
What about the social skills?
Well, contributing well to open-source is much more than putting a LICENSE.TXT in a GitHub repository. You have to answer some pretty hard questions:
- Who do you want to work with?
- What do you want to work on?
- How do you want to work together?
So what can we learn from a social dance like argentine tango?
Electro, Tango or Madison?
There are many ways you can dance, but a pretty stark difference between the ones you are dancing in a group, like the Madison and the ones where you are dancing alone, like electro.
For me the sweet spot is right in the middle, when two people are dancing together a social dance. Like with argentine tango.
I am not really a fan of contributing to an open-source project that is owned by a group that has its own logic and rules. I may have the skills to contribute to the Android Open-Source Project, but I very much intend to never do so.
At the other side of the spectrum, there are some repositories that are made by a lonesome cow-boy for himself. Those are fine, I have some of that to try out new things, but that's not where you want to contribute obviously.
In the middle you have a large number of open-source projects that are mostly made with love by one person, but that are also well organised, maintained and open to new contributors. Your contribution could mean a lot for that maintainer, it may even be the first real contribution he gets. The repository may have multiple contributors like https://github.com/thepracticaldev/dev.to but you can still feel when you contribute that you are talking with one human who cares.
This third group is obviously my favorite. Now, I have to warn you, it ain't easy:
Dancing with a total stranger feels weird
Picture your first tango course. Each of you learn to do some basic steps individually. All fine. But soon you will have to cross the Rubicon when you hear the teacher say:
And now, ladies and gentlemen, please choose a partner and start dancing together.
It is really weird the first time. It gets less weird with practice but it never stops to feel weird. The weirdness can not be erased, only balanced with curiosity.
Stepping into the work of another fellow programmer is no different. Even when you have used this software a lot as a user, you realize there are so much more you don't know about how it works. And you don't know yet anything about the maintainer.
What can be done then? Let me share with you the greatest tip to become good at tango.
Dance both sides of the game
Chances are that when you started a social dance like tango, you learned to be a leader if you were a man, and a follower if you were a woman.
There is something magical about experiencing both perspectives that will change you. By feeling both side of the same game, you inevitably gain a much deeper understanding of the dance. It becomes also much easier to empathize with the fellow members of the other gender.
The analogy is here obvious: you cannot really get open-source if you have only been a maintainer or only a contributor.
If after contributing your four pull-requests in October, you start your first open-source project in November, you will learn a ton about why maintainers act and think the way they do. Disclaimer: it will probably be a lot of work, so you should focus on something simple. No, simpler than that.
The reverse can also be true. Some large companies decide to release some things under an open-source license, but it still feels like they continue to work on it just like before, which is not very welcoming to outside contributors.
So, what can learn from this new understanding?
It's all about creating a connection
Experienced tango dancers focus on doing very well the most simple steps. Learning to walk can keep you busy for months, years.
Beginners not so. When they go to their first Milonga, they feel a deep imposter syndrom. To counter-balance it, they try to show off the most impressive things they learned. It usually ends badly.
Sounds familiar?
That's me with my first pull-requests. I git cloned a repository from a group of very experienced developers, talked with no one, tried do something huge, spent weeks or more on it, had to merge origin/master many times. The experience was essentially frustrating.
What I learned later as a maintainer is that it doesn't feel great either to have a mister nobody that obviously spent a lot of time on your repositories, but whose work you cannot really use. Frustrating.
The way out of this trap is to remind yourself of a simple fact
Your dancing partner is not you
To build a successfull open-source project, there is more than enough to do with everybody, so everybody should work on either
- something that she is especially good at
- or something where he gives a lot of fucks.
For example I contributed runnable Kotlin Playground snippets to dev.to. I give a lot of fuck about Kotlin so that was a good area to focus on. I was modest enough to not work on areas that requires a deep knowledge of the codebase, or of Ruby on Rails.
The lazy programmer's guide to #hacktoberfest
The first criteria is even more interesting if you want to complete your #hacktoberfest challenge in no time. To maintain an open-source project, we need a deep knowledge of a small numbers of things, and a superficial knowledge of a large number of things. This is your chance to help a lot with the minimal amount of efforts.
Here are some simple things that you can learn, and then apply to a large number of projects:
- Give feedback to the maintainer of what you struggled with or misunderstood when you first discover the project. This is super valuable! It's very hard for us to see our projects with the perspective of beginner's mind!
- Updating the year in the copyrights (smart way to get started!)
- Adding good smileys to the documentation
- Add metadata badges for open-source projects that lack it. Head over to https://shields.io
- Add an EditorConfig file https://editorconfig.org or any such small, useful configuration files.
- Improve the build system like I did with Gradle builds
- Report bugs! Obvious one, but never useless.
- Add useful Github Actions for the projects that lack them
- Add good GitHub issue and pull-request templates
- Setup a continuous integration if that's something you are good at https://travis-ci.com/
- Setup a static website for the documentation if that's something you are good at
Become good at any of those things and you can complete Hacktoberfest in no time!
Cool articles on dev.to
There are no shortage of great content on dev.to about open-source and hacktoberfest. Here are some of my favorites:
Top comments (4)
That's so true. I contributed to
Elastic Searchand I found it to be a little challenging to set up the environment especially when it comes to configuringdifferent versions of java, and knowing how to runspecific build tasks. In comparison,spring-bootanother huge project but, they provideeclipseinstaller which makes it very easy to get started.Great article Jean! π
Ah ah so true, java is suprisingly hard to install. I had to post this internally to explain it:
This is great thank you. I have been working on the Umbraco project and improving accessibility in the back office and learned the following:
Thanks for the tip number 4). I just added a link to a slack channel on my own project.