My subway ride was smooth as usual. Having left the office later, the subway cars were not as crowded and almost halfway through the trip I managed to snag a seat and sit comfortably for the rest of the stops leading up to the north end of the Yonge line, Finch station.

This is where the fun begins.

I reach the top of the three sets of stairs that lead from the subway platform to the bus platform. Then I move through a set of double doors to my left leading outside. The picture above fails to show the full magnitude of the crowd of people that I had to squeeze through to get to the location from which I shot it. The two lines of people that usually form for the 36 Finch West buses both curve in the same direction and run parallel to each other on the other side of the platform.

At this point, I know I’m in for a long wait in the cold and I’m visibly anxious. I watch all the buses that pass by.

Out of service. Out of service. 60. Another 60. 36C (to Jane, not far enough for me). Another 36C. A 36D (Weston, still not quite far enough). Out of service sign that switches to DETOUR ON ROUTE (wait, what?). Another 60…

As the 36′s stop to pick up people, I start to move closer and closer to the front of the line. But my bus is still to arrive. About an hour passes. I make fists with my hands to keep them a bit warmer. My feet hurt I am shivering. I continue to wait, wondering if maybe there was a detour on Finch West causing delays in getting buses back to the station.

Finally, a 36B. This one will go all the way down to Humberwood, well past where I need to get off. I’m close to the back door and desperate to get out of the cold. As we file onto the bus, I feel an unpleasant sensation between my shoulder blades: I’m being pushed from behind. Another passenger turns to yell at the man behind her, demanding to know why he’s pushing her. Clearly, the people behind us are as desperate to get on the bus as we are and considerably less polite about it.

The bus is packed as tight as a sardine can. The driver tells riders at the front door that he has no more room and that another bus is behind him; he doesn’t know if it is another B. The back door is particularly crowded. The riders there exit the bus and re-enter, playing a precarious game of human Tetris (no, not that human Tetris) against the two bars that trigger the door to open at stops. The driver tells people to try entering via the back door. Each time he does, the passengers near the back door groan.

We pass by the major stops: Dufferin, Bathurst. The bus is still roughly as packed as it began.

At Keele, a person further to the front squeezes past me to get to the back door. As he passes by, the messenger bag that is hanging on my right shoulder is pushed behind me and lifted way up. Finally, he manages to break through and exit the bus.

Not until Weston do enough people clear out to give me some space to breathe. There are still no seats however; I’ve been standing the whole time.

Now I’m home, quite irritated and wondering why my usual commute had suddenly doubled in length. TTC’s official Twitter feed for service notices says nothing about it. It reminded me of a customer service tip that might be useful to the TTC: perception matters.

Even if you’re doing the best you can, if that’s not what it looks like to your customers, you have lost them. That’s why the photo of the sleeping fare collector caused such a stir in the community. We now pay more than ever for each ride, including Metropass holders, and we want to see the return on that investment.

Robert Fischer wrote a post titled “Dear User of My Open Source Project” and many of the proggit comments were quite vicious. I noticed that some of these commentators seemed to have the same understanding of “open source”: that an open source project is a product, like any other product, that is simply distributed with its source code. Therefore, Robert is clearly creating and releasing “inferior” products and this behaviour should be punished. Being open source is not an excuse.

If this is your understanding of open source, you have missed the point. Entirely.

Yes, there are open source projects out there that are very well-documented, quite reliable, and have attracted large communities of contributors that tirelessly work to improve every aspect of the software. But by my count, that seems to be the exception rather than the rule. Most open source projects out there are maintained by just one person who scratched an itch and thought the solution might be useful to others. Some of these projects might be lucky enough to have a few passionate contributors. These projects may have some rough edges in their code or their documentation, and perhaps the contributors might be too busy to put on the appropriate polish.

You might think that irresponsible, or even reprehensible. How dare this person release this garbage and pollute the open source community!

News flash: it is these people who drive open source software. Those large, reliable open source projects with all of the sparkle and polish? They became that way because large groups of people found them useful enough that they decided to invest their time in making the project even better. But in all cases, for open source software to progress, people have to be willing to give up their time and energy for free and with no expectation of reward. Open source is driven by pure altruism.

And yes, as a programmer using open source software, you may sometimes have to roll up your sleeves, get into the code, and make the changes that you need. Or perhaps you can find other ways to contribute. But complaining like a petulant child that it doesn’t serve your particular purpose is, frankly, incredibly rude considering that you were given this software entirely for free and given the power to inspect its source code and change it to suit your needs. If that is the way that you’re going to approach these projects, go use something else.

Like Christmas, the true spirit of open source is giving.

Edit: Some one on proggit rightly pointed out that I’ve made a common mistake of grouping “open source” software with “free” software, a subtle distinction that this pagefrom the FSF makes very clear. However, I believe that Robert Fischer’s post and his complaints also referred more to “free” software than “open source” software. Consider, for example, that he prefers to use the WTFPL for his projects, the spirit of which is “I’ve decided to put this out here, and you guys can do whatever you’d like with it.”

This is not to say that all “open source” software doesn’t adhere to the values of “free” software or that all “open source” software necessarily follows the values of “free” software.

It’s the same reason why scientists have by and large stopped explaining away the world with “God”. Saying that something in our natural world is “magic” or the work of a “God” is a cop-out. Why even study the world at all? We could just say it’s all hocus-pocus and never have to worry about it! The same idea can apply to programming as well.

I used to think that Ruby meta-programming was dark magic. I didn’t understand any of it and felt like I just couldn’t break through the barrier of clever one-liners and idioms, but I started to read the source code of Ruby projects that I used in my day job and side projects. I studied carefully, taking the time to understand even the most complex-looking constructions. I learned some things about Ruby that I didn’t know before and picked up some common patterns. Suddenly, Ruby made a lot more sense and my skill with it grew rapidly. Every day, I’m learning more and more.

So here’s the first part of the message that Giles was trying to deliver: Rails is not magic. It’s Ruby.

(There are also some supplementary thoughts about how, from a Lisp lover’s point of view, languages like Ruby and Python, even with all of their meta-programming power, might be annoying because there is still a subtle distinction between data and code.)

This is not to say that Rails is perfect or pure. The Rails team is making great efforts to bring in ideas from Merb to reduce some of the pain that developers feel when trying to go against the grain of Rails’ conventions. I am very much looking forward to Rails 3 and I think many others in the Rails developer community are too. But it is not “dark magic”; it is a tapestry of abstractions (albeit sometimes of the leaky variety) that are weaved together with clever Ruby programming. Maybe some of the code is too clever for its own good but it is a potent demonstration of just how expressive Ruby can be. But the upshot of Rails’ design is that, inevitably, something in Rails won’t behave the way you might desire it to and you will find yourself forced to dive into the source code of the framework to find out why.

While I don’t disagree with the notion that Rails could be documented a lot better, I’ve realized that source code is the most reliable form of documentation. API docs and tutorials and blog posts may be out of date or missing details, but the source code is the current set of instructions that is being given to the computer. It is always the most comprehensive and accurate picture of how the system works at any given moment. And, more frequently than ever, we have the power to dive into the source of the software we use to enhance our understanding where its documentation fails.

Now here comes the second part of what Giles was trying to say:

If you love Ruby (as even some anti-Rails folks do) but you’re vexed by Ruby “magic”, read the source. Study it carefully, ask for help if you need to, and contribute your findings back to the community. But don’t just dismiss it as magic, or you might be missing out on a chance to learn some incredibly useful and powerful things.