Images and article cross-posted from Opensource.com. Written by Matt Attaway.
It's not hard to come up with a dozen different reasons why the rise of open source development has been a watershed event in both the software and hardware industries. All of us can build new web applications faster with our feet firmly planted on the shoulders of jQuery, Bootstrap, and Apache. Languages like Ruby, PHP, and Python power the Internet, and operating systems like Linux and FreeBSD provide the foundation for thousands of companies and services.
But open source isn't just about the free tools we have access to, it's also about the community of developers that will help support crazy new ideas and give them a chance to thrive, grow, and change the world; ideas that would never see the light of day in a closed source world.
My favorite example of this is a tool near and dear to my heart because it made my little niche of the development world exciting again: Git. Before Git, the version control world had grown stale; the tumultuous 90s had given way to a Cold War between versioning superpowers in the noughties. Git brought back debates about version control workflows! Heck, just having people care about version control tools again was fun. For versioning nerds, it's been nirvana.
Git is a brilliant piece of software that has redefined how we do open source development, and software development in general. Certainly there were other distributed version control tools before it, but nothing in my time in the industry has so dramatically changed how we version and share our work.
It's a bit insane though. A huge amount of its power and flexibility is provided by a core versioned file system that can be used in any number of different ways. Built on top of that core engine are dozens of commands with dozens of flags that all manipulate that system in useful, if occasionally unpredictable ways. Many of those commands have evolved separately, written by different developers. As such, they can take very different approaches to similar problems.
Git was also written by a community that is very comfortable with a command line. They are accustomed to working in a guardrails-free environment: anyone who has accidentally run 'rm -rf *' in the wrong place will tell you it's a mistake you only make once. A side effect of that is Git doesn't have nearly as many guardrails as a user might expect from a version control system.
A personal favorite example of this is the reflog. If you're not familiar with Git, it can be roughly described as a local log of the version control operations that have changed your versioned files. The reflog is your savior when you run the wrong command and by all appearances lose all your work. The great thing about Git is it's never gone, you just need to know where to look.
Now imagine a world in which Git was created in a stereotypical closed source company. Imagine the board meeting where it is revealed:
Board: "That is an amazing piece of technology! This is going to change everything. Are there any challenges you see?"
Dev: "Well, we do find that occasionally we accidentally delete our current branch and lose all our work…"
Board: "Well, certainly that's just a bug? I imagine you'll just add a guardrail to prevent that data loss?"
Dev: "It's not really a bug. We just need to learn how to use the tool better. We have a solution to mitigate accidental data loss though."
Board: "Thank goodness! What is it?"
Dev: "We've gone with a more general purpose solution. We've put in a separate versioning system called the reflog so we can version your version control operations. If you delete your branch you can just scan the reflog for the appropriate SHA and recover it!"
The board slowly backs out of the room.
As posts like Steve Losh's Git Koans show, there is much zaniness to Git. I personally have a hard time imagining a company building and selling Git as it is designed today. There are too many inconsistencies and too many traps for new users. But those inconsistencies and traps are a natural side effect of being a powerful and flexible tool. Git without those rough edges isn't necessarily the Git we all know and love.
The good news is the open source development community was there to nurture and support it, adding awesome features like bisect and providing volumes of great documentation and tutorials to teach newbies the ropes. That support helped make a diamond in the rough very nearly the most popular version control system in the world.
We all have that crazy idea that we've pondered but aren't quite sure what to do with. It can be scary to try to bring those ideas to life — failure sucks. Spending your weekend building something that no one else ends up looking at can be disheartening. The good news is if your idea has some potential to it, there is a community out there that will want to help you make your crazy diamond shine. Who knows, that weekend project you've had kicking around in the back of your head might revolutionize software development, too.
