9️⃣ Contributing to open source is overrated
Before we start, did you know I’m creating a React course based on a game? I’m really excited about it, it’s going to be so good! Check it out here.
Let me start by saying open source is pretty darn awesome.
If you want to implement a feature that you don’t know how to, you just search on npm or github, read the example code and see if it’s matches what you’re looking for.
Best case scenario: It does exactly what you need. Install and profit! Worst case scenario: It doesn’t do the thing you want, but it’s similar. You can read it’s code to see how they did it, copy it to your codebase and tweak it to fit your use case.
That’s a really cool place to be!
Contributing to open source, on the other hand is a whole different story.
Let me tell you about my thought process from 2 years back.
I used to think contributing to open source is cool. It’s the next step you take as a developer.
If I contribute to big open source projects, it will increase my credibility as a developer and help me get better jobs, right? Only if was that easy.
Contributing to popular open source projects is hard! You need to know a lot about the codebase before you can improve it. You can start by improving the documentation, but it’s not as gratifying as adding a new feature.
Imagine a new developer joining your team, how much time does it take that person to understand what’s going on? Definitely more than one weekend.
Even when you get there, landing a few commits isn’t enough. Your interviewer might not even take it seriously until you’re one of the core maintainers.
If that’s what you want, you can put in the effort and slowly get there. But the fact that you have to do this in your free time without getting paid is not very motivating.
So, I decided to screw that. Instead, look at these developers speaking at conferences all over the world about their open source project. That’s cool! I’d like some of that.
All I need is do is create the next cool project and get a few stars on my GitHub repo. After all, stars are the measure of a good project (and by extension a good developer)
I couldn’t have been more wrong.
Stars are not users. Starring is a way people tag projects that might sound cool.
Heck, I’ve starred 538 repositories till now. I haven’t used most all of them or even think they are great projects. I’ve just starred them so that I can come back to them later if I need to. It’s a bookmark, not an endorsement.
The other bad part about creating a project that you can’t fast track your way to thousand of stars. I thought I just have to think of a cool idea that every one likes and the stars will start flowing in. Nope, not all of your projects will be popular. In fact, most of them won’t.
Here’s how my projects look like:
Jun - September 2016: 14 projects that no one cared about
auto-install 903 stars
cost-of-modules: 2186 stars
Nov 2016 - Jun 2017: 27 projects that no one cared about
bundlesize: 2728 stars
July 2017 - May 2018: 35 projects that no one cared about
card-vibes: 237 stars
June 2018 - present: 10 projects that no one cared about
Your popularity plays a big role too. It’s easier for someone with tens of thousand twitter followers to get eyes on their project. But hey, they had to start at zero too. You have to build your way up.
There is another observation here: You have to be very privileged to be able to spend time on unpaid work that might never go anywhere. That’s a big reality!
For some, it’s not a matter of choice. They have other responsibilities to cater to. Family, kids, a second job?
Okay, but let’s assume you have the time and motivation and you keep at it until one of your project get’s popular. Awesome! All smooth sailing from here on, right? Wrong again.
Okay, not entirely wrong. It feels really good to build something that others use and appreciate. When developers you admire say nice things about your project, it makes you feel proud of yourself. (Addy Osmani mentioned bundlesize at the Chrome Dev Summit! Peak proud!)
The vanity wears off though, pretty quickly too. The appreciation gets replaced with complaints. People look at your project and report bugs, ask for more features, even demand customer support.
Some of them are really mean too, they criticise you personally because they don’t think the quality of your code is up to the mark. That’s the risk of putting your code out in the open.
Maintainer churn is a real problem in the open source community. Folks get tired of dealing with all the complaints/requests and move on. Sometimes they take the time to onboard someone else to do their job. But plenty of times, they just call quits. You need to remember this is unpaid work done in your free time.
I had a similar experience with bundlesize. When I created it, it was beautiful. It solved an immediate need I had, I would work on improving it bit by bit and really enjoy it. Eventually, I changed jobs and didn’t need bundlesize anymore, but the requests didn’t stop coming. In fact, they kept increasing.
I have no incentive to work on bundlesize right now other than guilt. There are 45 issues and 15 pull requests open on the project. Some people have taken the time to look at my project and suggest improvements, but I keep ignoring it. It feels bad!
I could take some time out to reply to each message, review the pull requests and onboard a new developer to replace me. But hey! When did this become a job! I didn’t sign up for this (at least, not intentionally)
Strange things happened last year, I’ve applied to speak at conferences and got accepted, I got invited to conferences! But none of this happened because of my open source work.
It happened because I was talking to other dev folks on twitter, I was helping others. It happened because I was writing articles, creating videos. I was teaching.
If you want to be increase your credibility in the community, open source isn’t the only way. Share your learnings with others, that will get you a lot further! (I can write a whole post on, maybe I will)
Okay, so building open source projects clearly sucks. Then why do I keep doing it?
For that you need to look at the 4 projects in the list that got some traction/stars, all have one thing in common: They were things I really needed. I made them for myself, turns out a bunch of people had the same needs.
In fact, that’s why I build anything that I’m not paid to do. I sometimes open source them because maybe someone else might need it too. I don’t think about it too much though.
If it helps someone, great! If no one cares about it, no worries, it already helped at least one person: me!
Above all, It’s great way to learn and get better at building new things. There’s where you should focus your energy.
Here’s an example from a few months back:
I bumped into a great tool CLI called nps, it let’s you write scripts and document them in a file than package.json to them. Super useful!
$ nps
Available scripts (camel or kebab case accepted)
default - nps help
docs.dev - Start site in dev mode
test - Check if applications build + Run visual tests
production.build - Build for production
production.deploy - Publish new versions of core packages
However, I’m not a fan of how it looks. So I decided to create an interactive version of it. I had no idea how to do it, but I’ve seen it done before in another tool called fkill-cli. I read the code of this project (sindresorhus is the king of tiny modules, so reading his code isn’t so scary)
I copied some of his code, changed a few lines and nps-interactive was ready. More importantly, I learned a new thing and can use it every day. So that’s really cool!
Another benefit of getting involved is to learn from the experts!
This one time I was trying to install next.js and realised it ran an extra prepublish script. This was super weird to me. So I created a pull request to remove it. I did mention in the PR that I might be wrong 😅
Naoyuki, one of the maintainers, not only told me that indeed I was wrong, he gave me a blog post which explained why. That was really helpful! He could have just closed the pull request saying “Nope”, but he took the time to find the blog post and link it in the reply.
Here’s another such example: I was playing around with Portals in React, a new feature at the time and was confused about how it was behaving. Because it was so new, it had some quirks, I created an issue asking about an unexpected behaviour.
The result was similar, Dan Abramov who’s a maintainer on the project, wrote a really long reply detailing out his thoughts which gave me an insight on how to think about React rendering.
If you’re nice about it and give a descriptive example, the maintainers of the project would usually give you a well thought out reply that you can learn from.
My fascination for open source contribution has definitely gone down in the last 2 years but I still believe that having access to the open source community is one of the best parts of being a developer.
Use it to learn, use it to teach. But, don’t do it because all the cool kids are doing it.
Sorry for the rant!
Hope this was useful on your journey
Sid