First of all, thank you, this isn’t said enough.
Devoting your free time to create things that serve as the building blocks of our community makes you extremely awesome.
“Any fool can criticize, complain, and condemn—and most fools do. But it takes character and self-control to be understanding and forgiving.” – Dale Carnegie
Now I like to think that whenever a large group of people behaves in a certain way, the behavior’s origin comes from an underlying process which pushes them towards that behavior.
For example, In Austria, more than 90% of people participate in organ donation when they die. In the United States, the organ donation rate barely scratches the 15% mark.
One could argue that Americans are more selfish by nature. Or maybe that there’s a vast cultural difference between the two nations which accounts for the difference. Perhaps Austrians are raised on the notion of altruism from a young age.
Whatever the reason is, you decide to do something about it.
You come up with the idea to start a nation wide campaign urging US citizens to do the right thing and donate their organs after death. You’ll even invite the Austrian ambassador to give a speech on national television, telling Americans about the importance of selfless giving and the Austrian culture.
You could do all that, and it’ll certainly be helpful to some extent.
But what you should really be doing is figuring out that in Austria, every citizen is an organ donor by default. Austrian citizens have to explicitly opt-out to stop being organ donors. Only about 10% of Austrians choose to do so.
You see in this case, Americans are selfish by default while Austrians are generous by default. These statistics are similar in all opt-in vs. opt-out organ donating nations. This is the single factor that makes all the difference.
So the open question I think we should be trying to answer is: How can we make the JavaScript community more generous by default?
“Critique by creating.” – Michelangelo
The Open Source JavaScript Toolbox
Imagine you’re a builder trying to build a house from scratch. This seems like a daunting task, but you know you can manage it. This is in large part thanks to the unprecedented access to tools that can help you with the job.
You’re fortunate enough to live in a special kind of bizarro world as well. A world where all your tools materials are given to you freely. You can even look at their schematics and see how they were forged.
All of these great tools are given to you freely, and you use or modify them as you see fit. And free of charge. How lucky are you!
But wait, there’s a catch.
These tools come with absolutely zero guarantees. They could work, they could break, and they could update without notice. Sometimes the tool’s maintainers flat out abandon them.
In fact, almost every tool in your toolbox contains the following warning:
”THE SOFTWARE IS PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES…” – MIT License
We get all these amazing tools with no cost and no strings attached. But when they break, change or malfunction, our frustration is real.
Our anger is real.
Since we got all of these amazing tools for free, is it OK for us to complain when they breakdown, have breaking changes or aren’t well maintained?
“To escape criticism: do nothing, say nothing, be nothing.” – Elbert Hubbard
When A JavaScript Developer Snaps
Frank is a normal JavaScript developer. Most of the time he loves his job. He’s currently building a complex dashboard for an amazing new product he believes in wholeheartedly.
He used to love to write everything by himself. Citing Vanilla JS as his favorite library. But those days are long gone now. He understands that modern web development requires that you use libraries and stand on the shoulders of giants. Perhaps too many giants.
Frank’s dashboard is now built with React. He makes mostly mainstream choices. He currently uses Webpack + Redux + React Router + Babel. The whole shebang.
But Frank’s just getting started. By the time the project went live, his dependency list is a mile long. He’s now an addict and loves using open source libraries whenever he can.
But then things start to break…
Every major library release brings its own set of breaking changes. “Those are what major versions are for,” Frank keeps saying to himself. But that doesn’t make the frustration any less real.
This situation might be manageable when you have a handful of dependencies. But when your dependency tree has 30+ dependencies in it, all of which have dependencies of their own, shit gets real pretty fast.
And when Frank saw that that one of his dependencies had a completely different API, he just flipped.
This is just a random tweet. I have no idea if the actual sender’s name is Frank, but that would be pretty cool.
The Science of being grateful
The truth is we can keep complaining all day long about how our tooling sucks and keeps breaking all day long. But that’s hardly the truth.
Every tool in your toolbox has a reason for being there. And while every tool brings its own complexity, it hopefully abstracts away a much greater complexity as well.
Let’s take webpack for example. Sure, I’ve taken a jab or two at the complexity of the webpack config file, which definitely looks scary at first.
But without webpack, I would still be piping together 20 different gulp plugins and pretend like I understand what’s going on. And without gulp, I would still be maintaining a 1,000 LOC grunt config file. And without grunt, I would have to create and maintain my entire build process manually. You get the picture…
So instead of being gloomy about having to use a gazillion dependencies to setup and run our projects, we should all be grateful for all the of the different tools we have at our disposal.
In fact, research shows that being grateful is good for you.
So the next you stumble upon an open source project that you use and like, I urge you thank its maintainers. Saying thanks on Twitter, or opening a “spammy” thank you commit could go a long way. It might feel weird at first, you might feel that you’re being spammy and don’t want to bother anyone.
But trust me, if the number one issue open source maintainers would have to deal with was a barrage of “thank you spam,” our JavaScript community would be in much, much better place.
On the flip side, the next you find yourself angry at an open source project that broke your shit, hold off for a minute. Remember that on the other side of the fence there’s a person who spent their free time creating something that helped you do your job better. And no matter how stupid the error/breaking change/whatever might be, you still got a bargain for the $0 you spent on this library.
“He has a right to criticize, who has a heart to help.” – Abraham Lincoln
The Credit Goes to You
Regardless of what anyone says, open source maintainers should be proud of the work they do. You can be proud of having the guts to put your best effort out there for all the world to see. And you can be proud of having the courage to say “Look I made I this, and I think you should use it.”
The credit goes to those who put themselves out there, not to the critics who stand on the sidelines and mumble “I could have done it better.”
So thank you open source JavaScript maintainers. Thank you for daring greatly.