So Why Open Source?

So why am I so gung-ho about Open Source? Why am I frothing at the mouth to get back to working on Linux professionally?

Do I hate Microsoft that much?

Actually, no. While I do read Slashdot, my feeling is that what evil resides within the halls of Redmond is mostly limited to the marketroids and execs. I keep seeing evidence that the MS geeks are geeks of top quality.

So why? Am I that cheap? In part, yes. I see no reason to pay any more than necessary for things, and if I can get something good for free, why pay? But that's not enough to sway my heart like this.

I love freedom. Free as in speech. Free as in not restricted. Open Source gives me that. Allow me to explain.

Back in '98, I worked for a telco. We were putting wireless laptops in the hands of the 15,000 or so technicians that come to your house or business and install or fix things. The platform was a VB fat client running on Windows 95. (Don't laugh. Remember, this was '98. Also, I wasn't doing the VB; I was doing C++ on other parts of the project.)

Late in the game, we started getting an "Out of memory" message, after which the client app would crash. The problem was, we couldn't tell what memory we were running out of. System memory was plentiful. GDI resources and such had more than 50% free. From every measure we could see, we weren't running out of anything. We looked at the Knowledge Base. Couldn't find the error message. Used one of our paid tech support calls. Nobody knew anything. Even being 15,000 users strong didn't gain us enough clout to get an answer.

We got around the problem by moving things around. Shuffling code and calls. Eventually, we came upon a setup that we could run (in testing) without causing the error. We closed the bug and moved on. Deployed it. Life was fine. At the time I left in '99, it was in production without the memory messages and crashes.

Was it fixed? None of us thought so. None of us (3 VB'ers and two of us C++'ers) were confident that we wouldn't change something trivial and cause it to come back.

At the time, I used this story as a reason to use C++ instead of VB. My reasoning was that if we'd done the client in C++ and MFC, we'd have access to all of the code, and hence control over whatever was failing. I also felt (and still feel) that VB is fine for simple tasks requiring quick prototyping.

Since then, though, I've come to see this as more of a failing of the closed source model. Had we had the source, we could have grepped for the error message, put a breakpoint in the runtime, and seen just what we were running out of. And maybe even fixed it, if it was a bug in the runtime.

Okay, let's stop for a moment. If you're a manager, you should cringe at that last line. If you're a manager, the last thing that you want is for your hackers to take a couple of days off and go fixing someone else's source code out of pure altruism. Having access may be okay, using it to find bugs in your own internal code can be a win (as I hope my story has shown), but as a manager, you probably don't want me spending my time (or, more accurately, your time) messing around with the VB runtime code.

I agree, on two levels. First, a manager doesn't want to be using a different version of a development tool than the rest of the world. Even if I could fix VB, I wouldn't have, or rather, I wouldn't have fixed it and then used it on that project for production code. Second, my job is to write application code, not be a tool monger.

But now let's talk about why you as a manager do want me to work in this kind of environment. For starters, fixing the "Out of memory" error would have been accomplished in hours, not weeks, even if there was company policy that I couldn't change the tool. Not a common win, but a win just the same.

But let's stop talking about VB. Let's talk about a tool that I enjoy using. Eclipse. Let's say that I was using Eclipse, and found a bug, but couldn't fix it at work. I'm a fan of Eclipse. I'd either go home or go off on my lunch hour, and make the fix on a separate, non-production copy of the code. I'd be thrilled to be able to fix a problem in my favorite tool. I'd feed it back to the development team. They'd work it into the next version of the program. We'd download that next version, and get the fix, officially supported by the team. And be using the same version that the rest of the world is using. You, the manager, win.

You also win even more, because I now know considerably more about the tools we're using. In that particular area, I'm becoming an expert. If I groove on this, I become more of an expert on a variety of tools that we use. You win again.

Now look at this in the aggregate. How many people do you know that are intimately familiar with the VB runtime code? The Dev Studio code? The Windows XP kernel code? How many such people exist in the world? A dozen for each product? Do you have access to them? No. It's certainly possible that you could run into one of them on the 'net, but it's been my experience that none of them are allowed to talk specifics about what they wrote. What to do, what not to do, what to avoid, where the problems are. And they're even less free to go in and fix something you don't like.

Now think Open Source. How many people do you know that are intimately familiar with the Linux kernel code? With the Apache code? With the Eclipse code? Perhaps the answer to those is still zero.

But how many are there? I'd venture to say that the answer to each is between hundreds and thousands. You can buy a book from O'Reilly called Understanding the Linux Kernel. In its 2nd edition, it's 784 pages of info on Linux internals, with loads of source code examples. Any fan, anyone with interest or reason, can become an expert at any Open Source program they wish. And here's what's most important to you, the manager: people do.

Have I? Perhaps not. (I did read the 1st edition of the above mentioned book, but I'm not an expert.) But I have access to the thousands who have taken the time, and are experts. And so do you. For free. Free as in "without cost, via Google", and free as in "without their employer telling them not to answer your questions because of a non-compete or non-disclosure agreement".

Let's go back to my VB story. Let's say that there are 10 million VB coders out there. Let's say that 1% of them build something that's the same size as our client. And let's say that 1% of them ran across our error. Even at those extremely low rates, 1000 people would have had the error, and with access, most of them would have been inclined to understand the situation, and be confident that the fix was a certain one. I know everyone on our project would have.

You may be correct in not wanting to take company time to pursue some of these things, but wild horses can't stop some people from pursuing them, and you don't have to pay them overtime (or indeed even have them on staff) to get the benefit, if they love the tools. And if they have the freedom.

I suppose that none of this is really new. I suppose I'm blogging it more because it's my story than because I think it's something nobody's heard before. But I do believe it matters. I do believe it's better. It's better not just because geeks have more fun. It's better because when everyone knows or can know something, everyone benefits.

History is rife with examples of the controlling of access to knowledge, and every time a vault gets broken open, everyone wins. The Internet arrives, and the spread of knowledge gets really, really easy. And everyone wins bigtime. (Yeah, with the possible exception of those who don't control the knowledge any longer.) And that's what we're about here. Freedom to know what needs to be known, when it's needed.

It's a wonderful thing.