In which I reach no particular conclusion about open source

I'd originally expected to file this under "not really about the web but I'm posting it anyway," but all roads lead back to the web. Perhaps it's more germane than I'd originally thought. Nonetheless, you may wish to skip the geekly details (which I've indented) and go straight to the lack of conclusion at the bottom.

I've been experimenting a bit with video capture on Ubuntu as a means of smashing old analog tapes to bits. To that end, I bought an inexpensive video capture device that takes video in one end and puts USB out the other. It worked out of the box, sort of, on an aging Windows box, but seemed to drop frames, probably because the aging Windows box lacked the horsepower. So I tried plugging the thing into my Ubuntu box.

At first, nothing at all happened. The kernel wouldn't recognize the device as anything but a random USB device. A little googling (see, I told you the web was involved) and a look at dmesg showed that the device wasn't being recognized at all. This turned out to be because it wasn't in the driver's list of devices. But at least I could hack the driver that comes with the distro to put it on the list. As it happens, all I really needed to do was change one byte of the driver (better fixes were possible, but that's enough to make the driver recognize the device).

Ah, but while modern distros are still hackable -- and have to be, to qualify as open/free -- they're not shipped that way. A modern distro is a bunch of binaries along with the artifacts needed for their care and feeding. Source is separate. So ... download the source and requisite tools, and find out the preferred build command, Ubuntu conveniently provides this on a page heavily larded with "are you really sure you need to do this?"

The preferred build command rebuilds everything, as it's aimed more at someone trying to create a package for a distro, not a casual developer. In my case all I needed to do was change one byte of one driver. Further, I couldn't figure out where the giant build had put the results of my one-byte change. Somewhere, probably. After a while, using different instructions on the Ubuntu page, which look much more like what I'm used to, I'm able to build a driver that recognizes the device.

Unfortunately, that version doesn't quite work, for reasons I no longer recall. More googling determines that the latest version of the driver supports the card directly without the problem. Like many major distros, Ubuntu doesn't ship with the latest and greatest version of many components, so it's not a surprise that there would be a newer one. In this particular case, Ubuntu lags a bit farther behind the the latest because the main developer, who has ready access to the actual chipsets and so is pretty well technically qualified, has had some sort of dispute with -- I forget who, but some segment of the community.

However, the source is readily available, and even better, the driver is nice and self-contained (they generally are), so I can rebuild it quickly and modprobe it in. Sure enough, I do that and it "just works". The device is recognized. The other problem I'd been having is gone.

But the picture looks funny. It looks like NTSC is being interpreted as PAL, or something similar. Sure enough (after stumbling down several blind alleys), I check the source code and notice the driver expects the card to be speaking PAL. Not a surprise since the main developer lives in Europe. One three-line copy/paste later, the grabber is working fine. I post the patch to what looks like a relevant forum (look ma, I'm an open source developer!) and feel pretty good about myself.

But, while I can watch the incoming video on screen just fine, I can't figure out how to record it to disk. Which is what I came here for. There are approximately 5,923 different video programs to choose from. OK, more like a half dozen. On the one hand, there is Kino, which works just fine for devices with a FireWire connection, but doesn't seem to know anything about the USB family. Likewise with dvgrab. There appears to be some combination of kernel modules that will get you around this, but I haven't chased that down yet.

On the other hand are the approximately 5,922 programs for watching TV on your computer, which assume you have a USB device hooked up to a TV tuner. Each of them has its own quirks and requires its own special bit of hand-holding to get something showing on the screen, but the ones that can display seem to have trouble saving the video and the ones that might be able to do that can't seem to talk to the device.

That's where I am at the moment. I'm sure I'll chase down the last bit pretty quickly, but an out-of-the-box experience it wasn't.

So ... are closed systems inherently better? You don't see problems like this on Windows, partly because the manufacturer always ships a Windows driver along with the device and often ships a compatible application for good measure. It's even less of a problem on the Mac. Simply place the device in the same room as the Mac and the Mac will install the appropriate drivers, figure out what you want to watch, draw a nice facsimile of brushed chrome around the video window and fix you a latte.

In comparison to that, the Linux experience is pure chaos. In particular, even if I'd just grabbed the driver source and installed to begin with, delving through C code seems a poor way to say simple things like "the device ID is actually 1234:abcd and not 1234:5678" and "no really, this card also understand NTSC."

Except ...

My experience is that modern distros, for the most part, "just work." I've been running Ubuntu for years, now, and this is the first time I've found any need to recompile anything. Conversely, it's certainly possible to have driver problems of the same sort under Windows. Given that the driver ships with the device, detecting the device and figuring out what it supports are much easier. The problem is how the device driver interacts with the rest of the system, and that can vary depending on which of the zilions of different setups you actually have.

The Mac gets around this by tightly controlling the hardware and the software around it. This works, but the flip side is that some aspects of the system are fundamentally closed. For this and other reasons, Macs are considerably more expensive.

Yes, this particular corner of Linux seems fairly messy, particularly with the USB/FireWire split -- why should I care what kind of wire the video's coming over? -- and the apparent disconnect between the driver developer and the rest of the kernel community.

But these aren't open source problems. They're software problems. Any sufficiently large software organization is going to have occasional arbitrary distinctions and political friction. The threshold for "sufficiently large" here is probably a handful of people. The more relevant question is to what extent is open source more or less liable to have such problems. Dunno.

Against that, you have the fundamental advantage of being able to fix it yourself if you need to. It's annoying that things don't just work out of the box, and annoying that the most effective way of fixing the problem involved digging around in the driver source, but at least I could do that. In the proprietary world, you're generally stuck waiting for the next release [which, to be sure, has always worked before and nearly worked this time].

Is hackability worth the trouble? For an everyday user, having to fire up obscure tools, or even a command line, is not really acceptable. The real benefit is that any everyday user might also be a qualified developer who could help with a problem. Hackability maks it much easier for that person to get involved. The benefit to the everyday user is indirect: the larger pool of developers means a better system down the line.

So. Conclusions, or lack thereof? Not much, but maybe this: open source and the web together are powerful, but not all-powerful. But then, neither is anything else.