Love Letter to Github [December 17 2012]
I have one thing I want to say today: I love Github.
Since this would just barely be worthy of a tiny tweet (and not even a _good_ one), I’m going to stretch this as far as I can to get to a blog post length. Just because I feel like blogging today. Yes, that’s just how it’s going to be.
The past week was really great. Don’t you care to know why? Well, fine, I’m telling anyway.
It starts with me just trying to get some data on the distribution of the data across regions in hbase. I thought it was something we should be looking at.
In a few minutes, I had cloned it, built it and had it running against one of our clusters. The visuals are really good and it definitely increases our ability to quickly see where we’re at compared to a text output (which can also be done pretty easily with an hbase shell script).
With this running instance on our data quickly came the realization that we’d use this for real. And, like, right now.
On closer look, I noticed issues with getting compaction logs. Also, I started thinking of some things we might tweak to make it easier to have this deployed and running internally.
I’m not going to go into the details of the changes involved. The process is really the topic I had in mind when sitting down to write this. Or rather the lack thereof really.
Did you notice? I just lied straight to your face and I knew you wouldn’t budge. Actually, there _is_ a process but Github makes it all so easy and fun that it doesn’t feel like the drag we so often associate with processes.
Here’s how this lays out: You read about this thing or google your way to it. You need this thing and someone already wrote it. It starts here and then…
Clone, build, run and use the thing.
There’s something missing or that could use some improvement.
You feel the urge to fix it.
That’s the critical part right there. It’s often where things get complicated. You might need to file a ticket first with steps to reproduce. You might need to sell people of that feature you think _should definitely_ be in the scope of the project. You know, it’s complicated™. But Github helps. Let’s get on with how this goes with it…
You fork it. A one click step.
You do the work. And it’s the most fun part. You’re excited because this is something that bugged you. It’s something _you_ care about.
Done with the changes? Now it’s pull requesta extravaganza! This is when you get to show off the interesting work you’ve cared so much about. Also, because it’s cool to work with people excited about your project, interesting discussions follow. Meeting new folks. You know, _talking_ (or, more accurately, typing).
I’m just describing one scenario here but let’s say everything is right and your changes were merged into the upstream repo. Doesn’t this feel great? It’s almost silly but I just feel like a little boy and I want to show mommy how proud I am of the thing I just did. Even for a one line change. I’d like to show the whole world about this thing I just did. Please refrain though. People will run away screaming if you do this too often. And maybe even the first time you do it. So, please, don’t!
You just feel like smiling.
To be fair, you can get the same great rewarding feeling from contributing to any open source project even if that’s not hosted on Github. But the entry barrier is just a little bit higher. It takes more time. Some of that precious and limited energy that you have is spent on the _other_ stuff that, well, isn’t as much fun.
Anything to make the process so easy it just seems to not exist is an amazing feat. Github really enables tons of changes (okay, I just made that up but I really think it’s a good uneducated guess) by just making a path available from discovering a personal need to getting it done. Github is empowering people to fix it immediately. And we all know how momentum is important.
Dear Github, I love you. Never leave me.