The tragedy of the creative commons

Tuesday, 11 September 2007 — 11:50pm | Computing, Video games

I’ve long been reluctant to jump on the open source cheerleading bandwagon with quite as much zeal as most other people who work with computers, but I’ve become a convert overnight.

Oh, sure, I’ve been an end-user benefactor of the open source model’s more representative products for years, but that has only made me sympathetic to open-source software’s actual philosophical tenets to the same extent that feeling warm in a comfortable pelt on a winter’s day would make me exclaim, “Golly, it’s a joy that we still club baby seals.” By and large, it’s the product that matters, and as far as I was previously concerned, processes of production are pretty much interchangeable unless they hold things up or cause serious collateral damage. Like seal-clubbing, I liked open source when it worked, and it was not something I was ever clearly for or against.

No, what got me to believe in open source was a scenario where I really, really wanted something to work, and it just wouldn’t. Enter DarwiinRemote.

When it was introduced last December, DarwiinRemote got a lot of press for being one of the first solutions on any platform for linking a Wii Remote to a computer over Bluetooth. This led to some interesting experiments where the Wiimote was used for everything from World of Warcraft to sweet lightsabre action. For my part, I used the Wiimote as a convenient NES/Game Boy controller for homebrew games and emulators.

As it was written natively in Cocoa/Objective-C, DarwiinRemote had the advantage of being specifically geared to take advantage of OS X’s development frameworks and interface elements. All was well.

That is, if you ignore the lack of support for the controller extensions, the Nunchuk attachment and the Classic Controller. It seemed like most people were quite content to use the Wiimote alone as a mouse pointer, NES-style two-button controller or lightsabre, so there was no harm done. Considering the rapid pace of development from one alpha release to the next, one safely assumed that Classic Controller support was coming.

And so it ostensibly came, with version 0.5—only it didn’t work. And then the project founder decided to disappear off the face of the Web, leaving behind a handful of other developers who tweaked their own versions for a little while longer, only to disappear as well and go back to whatever it is they normally do with their lives.

The Subversion repository hasn’t been touched in months, and for all intents and purposes, the project on the whole looks deader than a headless possum. In the meantime, our distant cousins over in Windowsland have caught up to us with the likes of the Wiimote-scripting utility GlovePIE.

I wanted that Classic Controller support, damnit.

And here’s where open source comes in: there’s this exhilirating rush of initiative when you want something badly enough, and it’s neglected enough, that you are willing to set aside hours of your time and say, “Screw it—I’m fixing this myself.”

From a programmer’s perspective, working on open-source software has a few barriers to entry. Let’s list a few: 1) Reading somebody else’s code is often about the most unpleasant experience a programmer can imagine, short of being a baby seal and getting clubbed whilst inexplicably trapped in a segmentation fault. 2) With major, stable software projects that people actually use, there’s very little to do at the entry level aside from squashing a few bugs, about which you honestly don’t care. 3) With small, up-and-coming software projects, either they are so inconsequential that nobody benefits from your hard work, or the tasks in front of you are simply way beyond your ability. 4) It’s easy to get trapped in the mentality that you don’t need to fix it, because someone else will. 5) It can be a tremendous investment of time, and there’s no pay. 6) Because of the above barriers to entry, you can’t always rely on the commitment of the other developers, especially when it comes to a small project.

DarwiinRemote has the specific barrier that, being for a platform that doesn’t have a gigantic user base like Windows, or a disproportionate do-it-yourself user base like Linux, the open source community just can’t provide strength in numbers. In addition, many programmers who would otherwise be involved simply aren’t familiar with developing in Cocoa/Objective-C. (The solution, in this case, would not be to write something cross-platform in C++ or Java or whatnot; it’s important, I think, that there be a flourishing supply of applications specific and native to OS X.)

I wanted that Classic Controller support badly enough to outweigh all of these factors. So I just went ahead and fixed it.

I played around with the Xcode environment and picked up the essentials of Cocoa’s organization in no time flat. I studied what was going on in the code and jotted down the points of interest in my commonplace book, identifying what was going on structurally without having much of a background in Objective-C itself. I looked over how the application’s button configuration data model was represented relationally and in elegant XML. I consulted the invaluable WiiLi.org to get my head around the decryption and bit-shifting acrobatics necessary for verifying that the controller hardware and my computer were communicating properly.

It actually ended up being fairly straightforward, aside from a subtle but nasty bug in the underlying build of the WiiRemoteFramework that was retrieving the Classic Controller’s button data (i.e. which buttons are being pressed and which aren’t) from the wrong address in memory—and that was nothing that a little mental mathematics in hexadecimal couldn’t solve.

In one night, I learned more about OS X interface development and game controller hardware by trial and error than I ever could have writing demoralizing “Hello, world” tutorial programs from scratch, and I ended up achieving something consequential.

There’s still lots to do: in the development branch from which I was working, there were some fancy but half-finished interface elements done in Quartz Composer, which I’ve played with before, but never in conjunction with a Cocoa application. And the analog sticks on the Nunchuk and Classic Controller still don’t do anything useful apart from sending the computer their position; it seems to me, architecturally, that integrating the sticks with something like an emulator should be done via a plug-in on the emulator’s side using the positional data, and not in DarwiinRemote itself (which interprets and outputs the positional data). I didn’t fix any of the stability issues in the version I had, because I don’t know how (yet), and I’m not about to trudge through the debugger while I’m still having some semblance of fun.

I won’t be waiting until all of these issues are addressed before I put my build up for download—it looks like that’s the approach the actual development team is taking, to everyone’s detriment, if they’re still working on it at all.

The moral of the story, by the way, isn’t “Nick should pat himself on the back for not only using his CS degree in his spare time, but enjoying the act of coding for the first time in roughly two years.”

To begin with, I don’t think the process would have gone nearly as smoothly if I didn’t already have an intuitive grasp of object-oriented programming, Model-View-Controller design, and bitwise arithmetic. Without all of that, I wouldn’t have had a hope of finding what I was looking for, understanding unfamiliar syntax, replicating it by analogy in a manner that worked, and fixing the mistakes. This is a lesson in pedagogy: teach principles, structural paradigms and ways of thinking. Programming languages are fleeting and secondary, and can be learned on the job. So I suppose it’s also a lesson in hiring practices: look for the things that I just said should be taught.

There’s also a lesson here for the reluctant programmers who think that fixing open-source software is something that other, more qualified people do. Don’t. If you really believe that something should be fixed or implemented, learn what you need to in order to do it.

I admit that a lot of the above will sound platitudinous to many others with a CS background, as the most successful of the fellow students I knew were doing this all along; they’d actually work on programs or software systems outside of their course requirements, and be intellectually rewarded for going the extra mile. I don’t think it’s necessarily even “extra”—in many ways, it’s as essential to retain that drive as it is to take a foreign language home with you and speak or read it, even in small doses. Most education comes from yourself; lectures and professors are there for guidance, direction, clarification, demystification, and debugging.

I may be a staunch theoretician among computing enthusiasts, safely sealed in an ivory tower with my regular expressions, travelling salesmen and Cantor diagonalizations, but when it comes to the realm of the practical, there is no substitute for practice. (You think I would have figured this out that one time I fixed my own watch.)

Of course, it’s not really in the spirit of open source until I give my minute footsteps of accomplishment back to the community. So I hope to post my working binary soon. Wii!

Previous:
Next:

submit to reddit

Say something interesting: