Thursday, September 13, 2007

Contributing to IronRuby

In an ideal world, John Lam would email me personally begging me to write him an efficient YAML parser using the DLR, because Microsoft just doesn't have the expertise to pull this off internally. In reality, he's obviously more than competent, and based on the IronRuby mailing list activity in just the first couple of days it looks like he's going to have no shortage of people willing to step in and help out getting IronRuby off the ground. He's posted a Getting Started guide for contributions to the IronRuby project, in which he says his most pressing need is for C# implementations of a YAML parser and zlib.

I've been toying with the idea of contributing to an open source project in my spare time (for me, spare time only exists in my delusional, ideal world by the way - not the real world), and I've been trying to decide which project is worthy of all the free time I'm going to have after I go polyphasic at the end of the year. Here's a brief list of the best candidates, as well as the reasons why I don't think the relationship would work out:

  • NHibernate - Appears to be stable now and I'm not sure if I want to do lots of maintenance coding. Also, with LINQ coming, I'm not sure where NHibernate's future lies. Lastly, although I do use it on occasion, I'm not nearly proficient enough to know how/where to contribute.
  • Boost - Although I am part C++ programmer, I'm mostly (98% at this point) focused on Windows development, and as such I'm worried I'd be writing non-portable code, which they'd naturally reject. Plus, the complexities of hardcore template meta-programming, and the issues involved in compatibility between different compilers scares the hell out of me. Just looking at the boost source code (we use a couple of the libraries) is enough to discourage one from contributing.
  • Subversion - For me, source control is a tool, not a domain. All my professional development is focused on financial software, and while it's true that I couldn't get by day-to-day without subversion, the mechanics of source control just aren't that interesting to me. Plus again there's platform issues, and while C is notably easier than boost-level C++, it's still not that pleasant to work in for a .NET junkie.
  • Mono - Not enough Linux experience. I would say this is sort of my holy grail, my Everest if you will. Perhaps one day I will be fit to join the ranks of contributors to the Mono project. All Hail Miguel!

Since starting to work in the real world and thereby having all day internet access, I've been exposed to the wonders of RSS and more recently to One of the first things you learn when reading the likes of Martin Fowler and Uncle Bob is that the language that all the cool kids are using these days is Ruby.

Similarly, when listening to .NET podcasts and screencasts, one of the first things you learn is that Microsoft is aware of the rise of Ruby, and has launched a Dr. Evil (or Pinky and the Brain maybe) -style plan to take over the world by having .NET run in all modern browsers on all modern desktop platforms, with John Lam as the Number 2 Man. ("This is my Number 2 man. His name... is Number 2.")

Coupled to these two nuggets is Microsoft's recent stance reversal in the areas of open/closed source code and source code licensing, and together this trinity of events has presented me with what I believe to be the ideal target for my over-eager programming zeal. So, I'm going to explore the possibility of contributing to the IronRuby project.

This is of course easier said than done - John's contribution guide and request list is rather threadbare at this point (to be fair, the project isn't even two weeks old yet from a public point of view). With only two items on the wishlist (the YAML and zlib bits), and seemingly a plethora of people with more time and ruby knowledge than myself eager to contribute, it looks like I'll have to wait around in the cold until things mature a little more. At least, this is what I thought after my first read through of the Getting Started Guide.

However, when I read it through a second time, an innocuous little sentence jumped out at me and gave me a really good idea: "We're also looking for bug reports and bug fixes." I realized that I don't have to be an idiom wielding ruby wizard to contribute, and I also don't have to have tons of free time on my hands. All I need to do is write ruby programs and make sure that they work in IronRuby. Surely at this point in the implementation it wouldn't be hard for me to write something (albeit perhaps not in idiomatic ruby), that runs under MRI but fails to run under IronRuby?

I've already got a few pet-project ideas (a simple RSS reader, a Sudoku game and a html-screen-scraper for my country's satellite TV guide (for which the service provider doesn't provide an XMLTV service for fear of losing sales of their proprietary PVR system)) which I think I could pull off without too much effort in ruby, so for now my strategy is going to consist of making a start on one of these pet projects in MRI and make it work in IronRuby and on Moonlight as well.

I do also have a fallback strategy for helping with those parts of the code which I may not be allowed to contribute to at the present. Martin Fowler appears to have started a rumour a while back that John and his team may not be allowed (from a corporate legal policy point of view) to look directly into the source code of MRI (for fear of being blinded I guess) when implementing IronRuby. This will naturally make it difficult for them to make a compliant runtime.

One possible remedy I see to this situation is for those of us who have no such restrictions to write a suite of unit tests for the core developers - a set of guide rails (no pun intended) which they can use to flesh out their implementation. That is - if I can write a unit test which exercises some portion of MRI's standard libraries (which I can do easily as I have access to the source) and which passes under MRI but fails under IronRuby, then I can pass that test along to Microsoft and have them write the code to make the tests pass.

By doing this, they aren't exposed to legal issues of looking at the source directly (there's a geeky solar eclipse metaphor in here somewhere I'm sure), and the community develops a set of unit tests for core library functionality which will be useful not only for IronRuby, but for MRI as well (for backwards-compatibility reasons) as well as JRuby and also to anyone else who wants to write or fork a ruby implementation.

In all, I think the future looks bright for Microsoft and Open Source and myself. Now if I could only get around to sleeping less than 3 hours a day...

No comments: