Since my company is moving to a new office, I’ve been calling around trying to find an Internet provider. In Manhattan these days, you have a zillion choices. It seems like every Internet provider in the known universe offers service in Manhattan.

We’re probably going to get a T1 line from Savvis. Getting a T1 installed takes a couple of months, and we were worrying about what to do while we wait. ISDN and DSL are nightmares to install and take just as long to get installed. In desperation I was considering a dedicated dial up service, which is usually expensive as hell (something like $100 – $150 per month) and slow (modem speed). Or maybe a bonded modem service, where you use two modems and some expensive equipment to get double modem speed (realistically, that would be about 80kbps).

Then I found Juno Express, a service provided by my alma matter (I worked at Juno until about a year ago). It’s a wireless modem that runs at 128kbps. The service and modem are actually provided by Ricochet, which is really another name for Metricom. The one thing about the new economy is that nobody wants to get their hands dirty. Juno doesn’t want to get their hands dirty with messy hardware and infrastructure, and Metricom doesn’t want to get their hands dirty with customer service and billing (“ew”), and in fact, Juno even outsources their customer service to a company in Canada which answers the phone.

Anyway, I called Juno and ordered Juno Express Wireless. They will sell you a modem for $99, and the monthly service is $80 for unlimited usage. This is a fantastic deal if you’ve ever priced wireless Internet access in the past. (I remember when it was $25 per megabyte, not so long ago, for download speeds around 9.6kbps.)

The first Ricochet modems ran at 28.8 kbps. They are now transitioning over to a new technology that provides 128kbps, which is what I’m using. Wow! That’s dual channel ISDN speed! The trick is that the high speeds are only available in a few places. Luckily, Manhattan is one. Metrocom has been installing small shoebox-sized transmitters on light poles throughout Manhattan, since the technology they are using doesn’t have very long range (the cells aren’t nearly as large or as strong as typical cell-phone cells).

The modem itself is the size of a small paperback book, with a little antenna that folds out. It connects to your laptop computer via a USB port. (It can use a serial port, but the speed is slower if you do that). It has its own battery that runs for 6 hours so it doesn’t have to suck up your laptop’s battery. Yes, it’s really 6 hours… I ran it down today.

Installation was almost easy. Once I got everything set up, Juno was still giving me weird error messages. Luckily I remembered, from my time as a programmer at Juno, that the Juno system requires you to check your mail at least once when any features of your account change so that the Juno servers can update the client with your new service information. I think that if I didn’t have this “inside information” I would have been pretty frustrated, and I would have had to call Juno tech support. Anyway, by checking my Juno email once using my home DSL connection, everything was fixed up and I was able to start using Ricochet successfully.

My apartment is in the back of a big, brick brownstone in a dense part of Manhattan’s Upper West Side. So the signal wasn’t very strong. The maps on Ricochet’s site implied that they have more transmitters in midtown anyway. At home, the service was very bursty. When it worked, it was fast, but a lot of the time, it was super-slow (like 14.4 modem speed). This doesn’t surprise me or bother me very much… I can barely get cellular reception from behind all the masonry on my block.

So I took the modem out to a local cafe on Broadway and 70th, near a major avenue, and tried it from there. Tada! This is how it was meant to work. This thing is fast. You do get 128 kbps, sometimes more. I tried a whole bunch of the various line-speed-tests around the Internet, like C|net‘s. These tests are shockingly unscientific, since there are so many other things that can slow down a connection between your machine and the server where they are running, but I did get results between 70 kbps and 180 kbps. Nice! The overall feel of the thing is great. While I’ve been writing this article, I’ve been uploading pictures, sending email, browsing the web, and some people have emailed me some really huge attachments which I’ve forwarded on… the overall speed is great, much much faster than a “56kbps” modem which usually gets you more like 40 kbps. And it’s wireless! And it’s easy to install! And it only took two days from placing an order to being online! (They must have shipped the modem the day I called).

I also tried the service from a friend’s house around the corner; it works at around 128kbps there, too. Slick.

Now, $80 a month may sound like a lot for a home user. But for our small office of five people, for a temporary solution while we wait for the T1, it’s going to be great. And for working as consultants, where we’re all over the city working at clients’ sites, working from cafes and libraries, etc., it will also be great; I’m thinking of equipping my entire team with these so we don’t have to rely on clients’ Internet connections.

There are two things I would change. First, I wish there was a capability to attach a big antenna when you want to have a fixed installation with better reception. Maybe that’s an FCC restriction?

I also wish it gave you some idea of the signal strength as you moved the antenna around so you could adjust it for optimal reception. There is no way to tell which way to wiggle the antenna.

Note: Someone on the Yahoo message boards has since informed me that you can check the signal strength by pressing in the power slide switch, which gives you from 1 – 4 beeps indicating signal strength. Totally non-obvious and not in the documentation, but it seems to work!

Another big problem is the coverage. This thing works in the downtown areas of 10 cities. But in the past couple of years, the places where I want wireless access are not downtowns. Maybe I’m staying with a friend and don’t want to tie up their modem. Or I’m at the beach. Last year I was in the middle of the Navajo reservation and I needed Internet access. I suspect Ricochet ain’t never gonna have base stations in the middle of the Navajo reservation.

August 2, 2001: Ricochet Closes Down. They spent $500,000,000 and went out of business owing almost a billion dollars, with 51,000 subscribers. They would have had to make about $30,000 per subscriber for the business idea to have worked.

Until yesterday, the FogBUGZ license said that you couldn’t reverse engineer the program, attempt to look at the source code, or modify it in any way. Various honest people have asked how much we charge for a source license, so that they could customize a few things.

Hmmm. Why does the license say you can’t change the source code? I couldn’t think of a single reason. In fact I thought of a lot of counter-reasons, and immediately changed the license agreement. So now you’re going to have to sit through one of those old-fuddy-duddy stories from my past.

Way back in 1995, I was working at Viacom, where a small group of us hardy pioneers were building web sites for various Viacom properties.

In those days, there were no application servers. Sybase was so clueless that if you wanted to use their database on the Internet they told you that you needed to buy a $150 client license for every user that connects to your web site. Netscape’s web server was up to version 1.0.

A brave company called Illustra started telling people that their database management system was perfect for the web. You see, Illustra was designed to make it easy to add new data types by writing some C code and linking it in with their DBMS. (Any programmer who’s used a DBMS will tell you that this is already sounding a bit too dangerous. C code? linked in? Oy.) This was originally intended for exciting data types like Latitude/Longitude, time series, and so on. But then the web happened. Illustra wrote something they called a “Web Blade” and linked it in. The Web Blade was a sort of half-baked system that allegedly made it possible to extract data from the database and create dynamic web pages on the fly, which was the biggest problem everybody had in 1995.

A colleague of mine at Viacom was put in charge of building an ecommerce site so that Blockbuster could sell, I kid you not, CDs on the web. (Because that’s what people think of when they think of Blockbuster, right?) Anyway, he thought that Illustra would be perfect for the job. Now, Illustra cost something like $125,000, and shaking that much money loose from the Viacom Tree is like herding cats, so it took a while. My colleague taped a paper cup to his cube labeled “Illustra Fund” and collected a few dollars that way. The CTO negotiated hard and long hours with Illustra and eventually a deal was struck. We installed Illustra and got to work.

Unfortunately, disaster struck. Illustra’s Web Blade was barely half baked and completely not up to the task. It crashed every few minutes. When it did run, it proved to have the only programming language I’ve ever seen that wasn’t Turing-equivalent, if you can imagine that. The license manager kept deciding to shut you off and your site would die. Building a site with it was terrible, my colleague’s annus horribilis. So when they came to me and said, “Joel, you’re making a site for MTV,” I said, “uh oh.”

“Please can I not use Illustra?” I begged.

“Well, OK, but what are you going to use instead?” There really weren’t any other app servers in those days. There was no PHP, no AOLServer with TCL stuff, perl had to fork, we didn’t have penicillin, life was terrible.

And my reputation was on the line. And I decided that the scariest thing about Illustra was that when it crashed, you couldn’t do anything about it. At least, if you had the source code, I thought, if Illustra crashes, well, it falls into your lap in the debugger and you can try to fix the bug. You may have to stay up all night for a week debugging someone else’s code, but at least you have a chance. Whereas, without the source code, you are up the proverbial tata without a tutu.

And that’s where I learned a key lesson in software architecture: for your most important, mission critical stuff, you have to use a tool that is one level lower in abstraction than ideal. For example, if you’re writing a cool 3D shoot-em-up game (like Quake, around the same time period) and your key number 1 differentiator is to have the coolest 3D graphics, you do not use whatever 3D library you can find. You write your own, because it’s fundamental to what you do. The people who use 3D libraries like DirectX are using them because they are trying to differentiate their games on something other than 3D performance. (Maybe the story line.)

That’s when I decided not to trust anyone else’s poxy application server, and decided to just write my own, in C++, using Netscape Server’s low level API. Because I knew that at least, if anything went wrong, it was in my code and I could eventually fix it.

And this is one of the greatest virtues of open source / free software, even if you could afford Illustra’s $125,000 piece of tata: at least if anything goes wrong, you are going to be able to fix it, somehow, and you won’t get fired, and the nice-if-hyperactive people at MTV won’t be all pissed off at you.

When I sit down to architect a system, I have to decide which tools to use. And a good architect only uses tools that can either be trusted, or that can be fixed. “Trusted” doesn’t mean that they were made by some big company that you’re supposed to trust like IBM, it means that you know in your heart that it’s going to work right. I think today most Windows programmers trust Visual C++, for example. They may not trust MFC, but MFC comes with source, and so even though it can’t be trusted, it can be fixed when you discover how truly atrocious the async socket library is. So it’s OK to bet your career on MFC, too.

You can bet your career on the Oracle DBMS, because it just works and everybody knows it. And you can bet your career on Berkeley DB, because if it screws up, you go into the source code and fix it. But you probably don’t want to bet your career on a non-open-source, not-well-known tool. You can use that for experiments, but it’s not a bet-your-career kind of tool.

So I got to thinking about how to make FogBUGZ a safe bet for smart engineers. Almost by accident, it ships in source code form — because that’s how ASP pages work these days. Which doesn’t bother me. There are no magical, trade-secret algorithms in bug tracking software. This stuff is not rocket science. (In fact, there are very few magical, trade-secret algorithms in any software. The fact that it’s fairly easy to disassemble an executable and figure out how it works just doesn’t matter as much as intellectual property lawyers think it should.) It doesn’t matter to me that people look at the code or modify the code for their own use.

There’s another risk when you modify source code that you bought from a vendor: when the vendor upgrades the code, you are going to have a heck of a time migrating your changes to their new version. There’s something I can do to ameliorate that, too: if you find a bug in FogBUGZ and fix it, and send me the fix, I’ll incorporate it into the next version. This is intended to make people feel a little bit more comfortable that (a) FogBUGZ works, and (b) if it doesn’t work, in some mission-critical way, they can fix it rather than get fired, and (c) if they do have to fix it, and their fix makes sense, it will get back into the source tree so that the next version will incorporate their fixes and life will be less brutish.

By now I can hear the open-source and free software advocates practically screaming, “you silly goose! just make it open source and be done with it! open source doesn’t have any of these problems!” And that’s nice. But my wee company with three programmers costs $40,000 a month to operate. So we just charge for our software, and we don’t apologize, because it’s worth the money. We don’t claim to be open source but we can make sure that FogBUGZ is a safe decision to make, by adopting two or three nice features from the open source world.