A Place in the Forest

I was working on a highly constrained consumer electronics device, a little "satellite device" that spoke to the main device over a CATV RF coax cable and also received commands from an IR remote control. My code was failing in bizarre ways. I adopted an extremely paranoid defensive programming stance, filling my code with asserts and doing paranoid cross checking of all inputs. This didn't make the device work. Instead it consistently didn't work, instead of inconsistently, because the cross checks and asserts would usually (but not always) trip before it would crash. It also started to run out of memory because of the all the paranoia code I had added.

I asked for the source code for the driver for the IR receiver, and for the driver for the CATV RF digital transceiver, and for the peer code that was driving the cable digital that ran on the main device.

The driver for the CATF RF digital transceiver was handed to me the first time I asked. And by "handed to me" I mean that I was pointed to where it was sitting in the source repo.


The business partner / hardware supplier who was supplying the IR glue and drivers just , after giving me a runaround, finally just flat out refused, citing trade secrets, confidentiality, secret sauce, and similar bullshit.

So, I finally "stole" the source code with a disassembler. And found the sources of many of my problems. It was complete shit. "Unexpected" input from the silicon would cause wild random pointer writes. And random sunlight on the receiver optics would cause it. "Expected" input of undefined remote commands wasn't much better, generating and handing back blocks of garbage with incorrect block length headers.

I ended up writing, nearly from scratch, a replacement IR receiver driver.


The peer device driver code was written by a developer in a different group in my same company. I finally got the P4 ACLs to read it after loudly escalating, over the objections of it's developer and his group manager. It was also complete shit. I cannot even begin to remember everything that was wrong with it, but I not only figured out may of the sources of my own pain, I also found a significant source of crash and lockup bugs that afflicted the main device.

I was not allowed to rewrite the peer code, as it was not in my remit. However, I was able to sneak in and check in a large number of asserts, using the excuse that they were "inline documentation".


On, and the device driver for the CATF RF digital transceiver? The source code I got for the asking, without a fight? When I reviewed it was easy to understand, efficient, elegant, and as far as I could tell, bug free.


In the end, I made my part work. It just took over two months instead of the original guesstimate of less than two weeks. This caused a schedule slip in the release of the satellite box. Which would have been a more serious problem, except…


Except there was also major schedule slip for the main box. A significant reason for that slip was because the peer code that I had filled will asserts was now crashing with assertion failures instead of emitting garbage. I was lucky that I was not more officially "blamed" for that. The reason why I wasn't, was mainly because the people who understood what I did understood the problem, and the executives who didn't understand what the problem was were also too clueless to blame anyone, let alone me.


My lesson learned from this experience is: if someone is refusing to show the source to suspect driver code, citing trade secrets, confidentiality, secret sauce, partnership agreements, or similar excuses, it's not because they are protecting their magic. It's because they have screwed up, and they are trying to hide it.

A second rule of thumb I have is: source control systems that don't allow any developers to check out and review any arbitrary source code file are expressions of moral failure. It is unethical for an engineer, designer, or other technologist to ever sign off on a project that has been mutilated by such a broken tool.

For assorted reasons, I've become mildly interested in AOL's "newly opened technology", such as AIMCC and X-Drive. So I've been browsing their online docs.

When they say their products and interfaces are "open", they mean "open" in their own typical AOL way.

Check this out:

Q: Are there any restrictions on what I can build?
A: We tried to make the Open AIM Program as restriction-free as possible, but in order to help protect our network and users, certain rules apply. We have highlighted some below, but please refer to the Developers License Agreement for details.

• Developers are not permitted to build Custom Clients that are multi-headed or interoperable with any other IM network.
• Custom Clients developed for use on a mobile device or via a wireless telecommunications carrier's network and/or wireless services require separate licensing and business agreements with AOL. Any inquiries regarding mobile applications should be sent to AIMCommercial@aol.com.

No "multiheaded" free clients. So they still want to freeze out Pidgin and Adium, and they are still terrified of competition.

And no free clients that run on smartphones, or other "mobile devices" on a "wireless telecommunications network". They dont want their existing clients that they license to the telcos (for a lot of poorly spent money) to have to compete. And what happens when someone is using a laptop or handheld, and slides in an EVDO card, thus turning it into a "mobile device on a wireless telecommunications network"?

As I look farther, signing a developer agreement with them still doesnt net you a copy of the actual wire protocols. They instead give you a license to an overweight interface library for a "supported platform", and permit you to link against that.

That's not "open".


I run Pidgin (formerly known as Gaim). I have it client for my ICQ, AIM, YM, and MSN accounts just because so many friends and family insist on using them.

But if you want to IM me, I really prefer you use XMPP/Jabber, that is, Google Talk or LJ chat.