When PowerRuby was first introduced in October of 2013, I penned the following quote for the announcement:
There’s something special going on with Ruby and Rails. Never before has there been such coordinated community efforts to efficiently produce reusable code (aka gems) in such open and social fashions. Coding is fun again. We want to introduce that reality to the IBM i platform.
You see, I had spent the past 15 years contributing and promoting open source on my website www.MowYourLawn.com and had a blast doing it. Over the years many people used the free tooling and support I offered. That was all well and good but there was one problem — it was incredibly rare to receive contributions back to the code base. I’ve pondered as to why that’s the case and determine there were many reasons. Chief among them would probably be, “Was it easy to participate”? Meaning — Was it easy for somebody to add functionality and share it back with me so I can publish it for the rest of the world? Sadly I’d have to say the answer to that was a resounding “No”. The same paradigm still exists within the current RPG open source landscape.
It’s for that reason why I became enamored by the vast efficiencies the Ruby community offered to address many of the same issues I had. For example, they realized code sharing practices weren’t optimal so they came up with the concept of RubyGems – a simple means to publish, distribute, install, and maintain open source. Aspects of RubyGems (aka package manager) have been around for decades. The difference I found with RubyGems is I needed to be a lot “less geek” to actually make it work.
RubyGems was the answer to a problem. What I’ve continually seen is that the Ruby community is very efficient at not only recognizing inefficiencies, but also tenacious at addressing them. For example, a need came about to more easily specify and control the exact versions of Gems a Ruby application needed to run and ensure the same versions were used in all environments (i.e. development, testing, staging, production, etc). Enter Bundler – a tool created to address this need.
Then came the need to finesse deployment to servers so it could be done much more casually and automated. Enter Capistrano.
I’ll be elaborating on additional tooling created by the Ruby community in future posts. For now, of primary importance is to know how they collaborate and contribute. There’s a term named “social coding” (popularized by GitHub) that epitomizes the latest open source software revolution.
TechTarget gives a good definition:
Social coding is an approach to software development that places an emphasis on formal and informal collaboration. Although the term is often associated with social coding websites such as GitHub, BitBucket, CodePlex and Google Code, the term can be used to describe any development environment that encourages discussion and sharing.
GitHub, and others like BitBucket.org, have this concept of “fork” and “pull requests”. Essentially this means you can click a button to get an entire copy of a project into your own profile and make changes you deem necessary. Upon completing the changes you can issue a “pull request” back to the parent repository so they can have the option of merging it with the base code for others to make use of. Check out this video to see an example of fork and pull Requests. Basically it makes collaborating on source incredibly simple.
I’ll close with this: Selecting technology for your company’s future is so much more than finding a tool or language to meet a specific business need. I’ve learned you need to evaluate both the strength of the community behind it as well as the personality make-up of the community. Without a strong community, the long-term viability of any technology decision is at greater risk.
Questions? Comments? Chime in and share your thoughts!