On Open Source

FS: Most people would say you're one of the world's foremost gaming engineers. Do you think that in this world that there's enough of a range of tasks and depth to keep you intrigued for years to come?

John: Sure, there are a lot of different things. Right now, I'm spending more of my time in this lull or break, working on some things in Linux. One of the things I've done is written two 3D drivers for Linux or done a good chunk of the coding on them. That's useful for me as a developer, because I certainly do the high level stuff, the API level programming, but it's also good to go ahead and take it underneath that. Doing some implementation level stuff on the device driver down to programming the hardware gives me more scope, looking at things through the entire process. There are a lot of programmers who only know things from the top and don't realize why things are sometimes the way they are because of the structure that's "invisible" to them.

One of the other things that I'm considering doing is (because I like knowing things very clearly from the highest to the lowest level) spending some time implementing my own network stack for the research and the learning experience. I've also got some experiments I want to try, finding out how much overhead the operating system actually imposes on the routing time and queuing things down to a serial driver level and a packet driver level. There's some information that I'd like to get from below the layers that you're normally communicating with.

FS: Just in Linux or Windows and Mac also?

John: Well the thing is that it's just easier to do under Linux because you've got the ability to take anything you want out. While Linux is clearly not ready for replacing Windows on people's desktops, there is something fundamentally cool there.

The whole way I got into this is that someone had written a Linux driver for the Matrox cards. I had been reading about it for a while. Apparently they had it working barely with Quake 3. So I finally got around to downloading it and checking it out. I was pretty impressed by how well it worked. It was slow but it was pretty nearly feature complete, good quality implementation. But there was this really obvious bug with the way textures were swapping. They were swapping most recently used instead of least recently so you'd see it thrash on the screen.

I knew exactly what it was doing so I said "OK, this has the source code available." So I figured out how to download it, get access to the CVS repository and all that, worked my way through the code, found the bug and fixed it! That's just fundamentally neat.

The corollary of that is that Apple had exactly that same bug in their driver for a while. So here we had a case of the same bug appearing in two drivers, but the Linux one I was able to just go in and fix it. While there are certainly a lot of barriers to entry on a lot of levels with that, it's nice to have that ability. Fundamentally if you know that if you're working on this system that's all open source, if anything annoys you enough, you can spend the time to go fix it yourself. You don't have to wait for anyone. You don't have to ask nicely for it, or wait for a patch.

It's not usually cost effective time wise to go do it. But if something's really pissing you off, you just go find the code and fix it and that's really cool.