In the past few years blogging has taken the geek world by storm, and lately it's started to pull in the non-geeks as well. The act of maintaining a weblog, or blog, isn't too impressive in itself, but it represents an interesting change in interpersonal communication models.

While phone calls, e-mail, and especially instant messages have an intended recipient and carry an assumption that the recipient should reply, blog entries have no explicit recipient and no etiquette regarding whether readers should reply or not. As a result, blog authors are free to write as often as they want, without overwhelming their audience. Also, it's common for blog authors to write more personally than they might if they were addressing a specific recipient because there's no pressure on recipients to reply to what might be a sensitive issue. We're also seeing blogs popping up in political campaigns (Howard Dean) and inside corporate firewalls as collaboration tools.

I didn't foresee any of these aspects of blogging when I launched LiveJournal.com in April 1999. In fact, I don't think the name "blogging" was even coined or in widespread use until the launch of Blogger.com later in the year. No, I started LiveJournal.com just to add another dynamic trinket to my already gaudy personal Web site.

Never a fan of boring static content, and weary of personal Web sites that grow stale, I wanted everything to be dynamic. My age on the "About Me" page was calculated on the fly, and down to the second just to make it obvious. But a dynamic age isn't enough to keep people coming back to a Web site. I wanted the front page of my site to list what I was up to at any given moment. My first blogging client in November 1997 was a single-line text-entry box that sat at the bottom of my desktop. Typical entries, often 30 per day, were of the form "going to the basement to get a Dr. Pepper" or "played Frisbee, got muddy," and certainly not the deep, emotional posts I would log later.

Once friends started using my client and were writing multipage posts in this single-line text field, I decided a bigger client was needed. The original message board functionality was hacked out during a two-hour break between classes for the sole purpose of leaving a sarcastic comment on a friend's post. And that's pretty much how every feature came to LiveJournal: the users wanted it, or it was simply too fun to resist.

The LiveJournal codebase wasn't originally open source, but I never hid it too much either. If people wanted to help out I sent them a copy, and they sent me back patches. I finally released the codebase under the GPL (GNU General Public License) in March 2001.

Today LiveJournal is a full-blown blogging and community platform with journals (blogs), message boards, and a built-in news/friend aggregator. Everything's dynamic, with optional security restrictions on just about everything. We've just passed 1.5 million accounts, we do over 20 million page views per day, and have three (going on four) full racks full of servers and hardware, a dozen employees, and an office. I never thought a little open source hobby project would turn into this. But we're still open source, still trying to not be evil (as too many companies seem to be nowadays), and still having fun.

Why Open Source?

So, why did I open source the code? For a community site, it felt like the community thing to do. But that's just the tip of the iceberg. I wouldn't have even known about open source if I hadn't previously been exposed to and impressed by it.

LiveJournal.com is built on an open source framework: Apache, mod_perl, Perl, MySQL, Debian GNU/Linux (previously FreeBSD). I have a lot of respect for these projects and their leaders because they're doing it for fun, their development process is open, and they put out releases when the code is stable, rather than on a strict product cycle driven by corporate marketing departments driving customers to continually upgrade and keep paying.

The cost of software was an obvious factor when LiveJournal was small and the budget was tight, but now that we're bigger, why don't we upgrade to commercial offerings? Because commercial software is downright frustrating.

With open source, I don't have to worry about making purchase orders, talking to salespeople, fighting for good prices, counting the number of processors in machines, accidentally violating licenses, product activation, product end-of-life cycles, etc.

I also don't have to worry about documentation that is dumbed down, treating me like I've never handled a computer before. Open source documentation isn't always as long as commercial documentation, but it's dense and to the point. And if it's missing anything, the source code answers all questions. Even if you're not a C or Perl wizard, basic programming knowledge is usually sufficient to follow code enough to answer your questions. In all honesty, though, it rarely comes to that. I've been extremely satisfied with open source docs, which are usually written by the designers of the software. These explain how to use the product and why it is how it is, which teaches you more in the long run.

Finally, with open source, the code is available to inspect and fix if you suspect there's a bug. Most end users don't read the source of the packages they use, but boy is it ever helpful when you do need it.

Over the past few years we've dug into the innards of Perl (debugging segfaults), Apache (mod_proxy table handling and mod_rewrite locking), libevent (fixing poll and epoll support, which required digging into Linux/FreeBSD code as well), and other projects. Half of the time we found the source was correct, and it pointed us at our bugs. The other half of the time we were able to forward along a fix to the maintainer, or find an existing fix in a slightly newer version we weren't using yet. This is all a lot more gratifying than filing a support request with a vendor to get ignored, getting a kludgy workaround, or waiting six months or so for a new version that you may have to pay for.

To be clear, though, most users don't need to debug open source projects. The quality is so high in stable releases that you can generally just sit back and relax. With new bleeding-edge development releases, though, it can occasionally help.

So obviously we've been sold on open source. But what's the advantage of us open sourcing our code? Why don't we just use everybody else's and keep ours private? Many people do that, and for many people that makes sense. But as I mentioned earlier, we're a community site, and releasing the code to the community feels like the right thing to do.

Long Live LiveJournal

Because we're open, our users need not fear that if we were to go out of business that LiveJournal would die as well. Somebody else could take our code and set up a nearly identical site for everybody to flock to. In fact, over a dozen such clone sites already exist, quite a few of them commercial. They're all quite a bit smaller and niche-related, but they're out there. The first was DeadJournal.com, which was started as a joke, a play on our name. The creator, Frank Precissi, just changed all the colors to be white on black instead of black on white and changed the happy user icons into skulls. Intending to shut it down shortly after its launch, he found it getting popular with the goth users who preferred the darkness of the site, so he kept it running. Most DeadJournal users also have LiveJournal accounts because a lot of their friends are on LiveJournal. I suspected all this would happen when I released the code. Clone sites will keep popping up, but as long as I keep LiveJournal fast and interesting, people will continue to use the site with the largest user base. As such, there's little harm in releasing the source code. It just forces us to constantly work hard, which is good. DeadJournal and other sites contribute back bug fixes and features and everybody wins.

In addition, our code being open forces us to code clean and document well. It would be embarrassing to have poor code out there with our names on it, so we make sure we only commit high-quality work. When we do introduce bugs, they're found quickly, either by people just reviewing the patches, or by people testing on their development server or clone site. (A few times DeadJournal has put our code live before we have, gotten bitten by a bug, and we've fixed it before our users ever see it.) Anybody who's read Eric S. Raymond's The Cathedral and the Bazaar or who has been around the open source world long enough knows the statement, "Given enough eyeballs, all bugs are shallow." Here's one more guy saying that's totally accurate.

Conclusion

The best part of open source is that people scratch their own itches. If you want to see a feature, you make it, get people to test it, and submit it. We don't accept all contributions, but we accept quite a few. Often we may not accept a patch directly, but just the sight of a poor patch or something implemented a little less than ideally motivates us to do the remaining 10% and fix it up for inclusion in the main tree. LiveJournal is what it is because of the army of volunteer hackers working on everything from little details to huge features. There's stuff to work on, regardless of skill level, so everybody can find some way to contribute if they want to, and so many people seem to want to. I think that's what I'm happiest about, that LiveJournal has introduced the concept of open source to tons of people who might have otherwise never heard of it.