image from Open Source Friday
oh boy, I was so wrong.
Do you remember that weird “You wouldn’t download a car” spot?
I saw it so many times at my local cinema during my childhood, and — I have to admit — it always felt odd to me.
this one
I mean, stealing a car and downloading a file in my head had two completely different effects: in the latter scenario, you would end up with two files. It’s not like the original one disappeared magically once the download was over. The car, instead, well… it was always [just] one.
This dissonance, back then, was so easy for me to spot that I was weirdly surprised it took me years of daily usage of open source, and many months as an actual maintainer to comprehend that I was as off as that spot in the way I mixed the real world with the virtual one.
I used to interact with open source software as a customer getting a freebie.
There, I said it: I used to add that library or that snippet to my code to integrate a new feature, and, if something went wrong, I would go back to the GitHub repo and open an issue about it; I’d try to be a good issue writer most times, but I’ve also written my good share of dumb “+1/me too” comments.
I believed that the maintainers, the people creating the code I was using, were there to produce an excellent product — and by giving them feedback about how to add a feature, or asking for an ETA on something an issue was about, was a legit and standard way to cooperate. I expected that they would gladly accept my suggestion and modify their roadmap to accommodate my wish.
Even when I started helping out with react-navigation, I kept this “mindset” by seeing those who opened issues as customers; and, by doing so, I almost burned down by doing too much issue triaging (and handling way too many “bad customers”) and trying to keep everyone “happy”.
Then I joined Open Source Maintainers community on GitHub, where I was able to interact with some smart people that have been developing with open source for many years.
And something clicked.
I think I get it the right way, now: open source doesn’t mean “up for grabs”, but instead
“Hey, look, I did this — if you want to use it too, here’s how. I did it in a way that would fit my needs, but use it as you like.”
And that’s it.
The first person that should solve that issue, the one you wrote, should be no other than yourself.
That feature that you think it’s so useful and you need so much, how about you fork the repository and add your code to enable it?
Open source means that you use what’s out there how you want, and git & GitHub gives us all an easy way to merge our struggling so that another developer will not face them in the future.
But it starts with everyone rolling up their sleeves and actively contributing. Writing code is always the first way you should approach a problem you have in open source.
You think you are not good enough? Don’t worry. Do it anyway. Open that PR; when you put yourself on the line other developers will recognise it, and will help you grow and become a better coder.
Don’t feel like coding, still? Well, remember to follow guides like this when opening an issue.
And never forget that nobody is forced to do what you are writing; nobody must do work for you, on your issue.
Start your 2018 on the right foot, don’t make the colossal mistake I made.
Use open source responsibly, and lead by example: most people won’t read this article and/or won’t talk with an active maintainer anytime soon — but if they see that this is how everyone around them uses OSS “properly”, they will behave the same.
monkey see, monkey do
Happy New Year everyone, let’s make it a good one together 💪
Think I am wrong? Have I missed out on something? Write a comment, or tweet me — I’d love to hear feedback on this subject 🤖Many thanks to Phil Plückthun & Tasveer Singh for reviewing this rambling 🤓