Empty Thoughts

I’m not really sure how I missed out on this. The Pragmatic Programmers has a new offering of Pragmatic Screencasts that cover subjects such as Core Animation, Erlang, Ruby, Active Record, and Expression Engine. At $5 per episode it’s definitely a great buy. I just got the four episodes in the Erlang by Example series and I’m making my way through them. The screencasts are professional, well done, and great resource for get up to speed on a focus subject. I’m looking forward to seeing new topics down the road. Perhaps something on Django? I highly recommend them!

There’s been a lot of commotion over the recent fork of the Pidgin IM client by the folks behind FunPidgin. The community at large has grown accustomed to the idea that forking is a “bad thing.” On the other hand the use of distributed version control systems (DVCS), like Git, Mercurial, and Bazaar, have made the idea of forking a project something that is part of the standard process. The fact that there is an “official” repository is one of community agreement and not anything dictated by the software. Large open source projects are investigating how to gain the benefits of a DVCS while still maintaining control of their code base. Some, like the Ruby on Rails project, have decided recently to make the jump. I am encouraged by this, and I’ve been watching the IRC discussions in #github pretty closely as they attempt to figure out the logistics of working in a distributed yet overall centralized fashion.

So the real question in my mind is why do we, as a community, have a general distaste for forking? A lot of people will say because it divides the resources and the end result is two half-assed projects instead of something that could adequately compete against closed source solutions. Although, that may be the case in some situations, it certainly doesn’t have to be the case. The drive for providing a permissive license is so that we can all benefit off the work that came before us and help propel it to that next level. In a lot of ways that is what forking is all about. If we look at an analogous situation in the research world, it is dependent on the idea of forking research. Each project takes prior research and throws something new into the mix, and moves it along to the next level, for the benefit of all. Why do we not see it the same way in the software world?

What is interesting to me is that we seem to have no problem of forking ideas if it is to put them on another platform. Consider blogging software. Every time a new framework / language comes out there are multiple development efforts to do a WordPress clone, or a Typo clone, etc… on the new platform. The same holds true for Content Management Systems, and a host of other types of applications. We could argue that those efforts do not work to help strengthen the open source offering. But I feel differently. I think competition and choice are beneficial to the community at large. If WordPress provides integrated Flickr support, then Mephisto feels compelled to add Flickr and Magnolia support. We also can not discount the learning opportunities that these types of forks provide. In the end we all win.

I think one of the real reasons that many are uncomfortable with forking is because because the most successful open source examples we have to look at, projects like Linux, Gnome, or Rails have all been these monolithic efforts driven by a single individual (Linus Torvalds, Miguel de Icaza, or David Heinemeier Hansson). The success of those projects in large part are a result of the charisma, intelligence, and management of those individuals. This has left us with the impression that this is how it should be done. While it has been clearly a successful approach it is not the only approach. There have been truly community driven projects like PostgreSQL that have been hugely successful, with no one individual clearly at the helm.

Clearly a lot of open source dictators of the day have no interest in seeing their projects forked. That has direct impact on their ability to render influence in the community, and works to dilute their personal brand. Quite honestly this is a real issue because this influential capital translates into real dollars for these individuals. That said, where I have seen forking or competitive offerings the end result is that both projects benefit. Most recently I feel that the Merb project has forced Ruby on Rails to get after it and address some of the performance issues. Even if Merb has no impact at all on Ruby on Rails, for a lot of people it will be exactly what they are looking for in a framework. That does not make the Merb approach correct and the Ruby on Rails approach incorrect, just different.

I am actually quite excited that this issue is being brought to the forefront by the DVCS systems. I am also eager to see the forking of more projects. There is no requirement that says the things I’m interested in seeing in a blog platform needs to be the same things that you are interested in seeing. There is room for both of our ideas, whether we work together or separately. Some people will be compelled by my offerings and some by others. In my opinion the community benefits from this plethora of ideas and options. This is a “good thing.”

I just happened across the Passenger website. Passenger claims to provide “Easy and robust deployment of Ruby on Rails applications on Apache webservers.” The metric graphs show it performing as well as Mongrel and Thin. It will be interesting to see how this plays out in community and the hosting companies. In true Ruby on Rails fashion there’s screencasts, lots of pretty colors, big fonts, and rounded corners everywhere. Hopefully there’s some there there.

It’s that time of year again. Yes, when we all have the privilege of calculating how much money we get to fork over to Uncle Sam. But, it’s also a nice annual reminder, for those of us that have the privilege of programming in Ruby, that we are the fortunate ones. Last year at this time someone on the Ruby-Talk mailing list suggested that individuals that made their livelihood by programming in Ruby, should do something to benefit the community at large. And, I agree.

So if you’re wondering what to do, how you can help out, in what way you can give back, wonder no more. There are many ways to help out. In the Rails community there are individuals like Jamis Buck devoting a significant amount of time to produce in-depth quality documentation on the internals of Rails. Drop a dime in his tip jar next time you think of it. But Jamis isn’t the only one. There are many other individuals out there that are working hard, contributing to open source projects, and lending a hand in general. Feel free to Pay it Forward.

Perhaps you should consider giving a donation to Ruby Central, Inc. If you don’t know who Ruby Central is, it’s a non-profit organization founded to support Ruby internationally. Ruby Central is run by Chad Fowler, David Black, and Rich Kilmer. They are responsible for putting on the annual International Ruby Conference, the Rails Conference, and several regional conferences as well. At RubyConf 2006 in Denver, Colorado a participant asked Matz how the community at large could best support the development of Ruby and the team that is working on the future of Ruby. Matz replied that he thought the best way to support Ruby was to support Ruby Central, the public international voice for Ruby. Sounds good to me.

Last year I made a commitment to donate a portion of the money I made from writing Ruby code to support the Ruby community at large. Why don’t you join me and together we can do our part to keep programmers writing happy code.

Pragmatic Studio has announced that they will be offering Advanced Ruby Training in Reston, VA on July 18 – 20, 2007. I don’t know if I can swing another training this year, but if I do it will most certainly be this course. Those of us at Advanced Rails Training in Chicago got a little taste of what will be offered. We were fortunate to get an hour or so of meta programming and discussion of Ruby bindings by Chad Fowler and Dave Thomas. I left certainly wanting a whole lot more of it.

This past week I attended Advanced Rails Training in Chicago that was put on by Pragmatic Studio. Pragmatic Studio is Mike Clark’s training company and includes Ruby / Rails heavy weights Chad Fowler and Dave Thomas.

It was a great experience and I highly recommend that you attend one of the Pragmatic Studios in the future. What is always interesting about these types of events is that the value in attendance has to as much with the offline discussions as it does with the training program itself. There were so many great people that I had an opportunity to get to know and others that I got to get reacquainted with. I was especially fortunate because Mike Mangino, founder of Elevated Rails, put me up and chauffeured me around. I learned so much from Mike during my stay. I highly recommend his company if you need a quality solution for your next Rails project.

There was also another unique opportunity for the attendees of the Advanced Rails training program. David Chelimsky, lead developer on RSpec, was also in attendance and was kind enough to give us all a special presentation (including fine libations donated by Object Mentor) on RSpec one evening. David discussed RSpec, it’s history, it’s use in Rails applications, and how to make the transition. His presentation was exactly what I needed to get me over the BDD hump. I’ve decided that my next project will be using RSpec and hopefully I’ll have more to say about that as I get into it.

All in all it was a whole lot of fun. If you want to god deeper into Rails development, or if you’ve had your head down and need to get updated on the latest Rails approaches, like Simply Helpful, Capistrano deployment, Restful Routes, etc…, head on over to the Pragmatic Studio website and get signed up for the next available course.