The open source advantage: Firefox's leaky dam gets more fingers, yours could be one.

Yesterday, among other things, I ranted about how my Firefox was grinding to a halt. About the only pattern I noticed is that I can some times revive my system if I close the instance of Firefox that includes a tab that was spawned from Outlook (and that tab doesn't have to still be on the page that was called from Outlook). To be fair, I don't want to single out Outlook as though we can isolate such problems to Microsoft products. I'll bet the list of application interoperations that slow systems down or stop them altogether is miles long, involving all sorts of software that isn't from Mozilla or Microsoft. Believe it or not, all it takes is a visit to certain Web sites to give certain builds of Firefox a fit. Steve England wrote:

Today I set myself the task of visiting all the sites on the Alexa Global Top 500 Websites list to see if any of the pages caused memory leaks on the Firefox trunk....After a whole load of clicking (and putting up with anoying sites that used audio) I ended up filing a whopping two bugs: 385082 which covers apparent leakage on wordpress.com (oh, the irony!) and 385251 which covers a memory leak when adding or deleting a bookmark.

Read the entire post to get the details on the exact build (this shouldn't at all be treated as blanket condemnation of Firefox or Wordpress.com). For me, when I have problems, sometimes, closing the Outlook-spawned tab itself seems to work. But, resurrection seems more certain when I just shut that entire instance of Firefox down. To me, this makes no sense based on some of the other re-entrant Windows apps I use. For example, if an application supports multiple Windows the way Firefox does and one of those Windows starts to misbehave, usually all of them do. Oh well, such is the mystery of what shouldn't be such a mystery (shouldn't it all just work?).

Often, application slowdowns, halts or abends (an old mainframe term meaning abnormal end) are the result of something called memory leaks. Basically, this is when an application does something that requires a chunk of the computer's memory and then when it's done, it doesn't release that memory back to the system. If this happens a bunch of times before your next reboot, your system (and all the apps running on it) end up starving for memory and things come to a halt. This happens to me a lot. I often keep several memory-intensive applications running (eg: Photoshop) and it drives me nuts that I have to constantly be thinking about whether or not I'm near that point where the only option might be a reboot (I hate rebooting).

This is also one reason that I also think we're heading for a world where all applications will run in their own little virtual machines, completely partitioned (from a machine perspective), from the other applications. Through hardware-supported virtualization technologies from Intel and AMD, operating systems like Windows, OS X, and Linux will be able to transparently launch low-overhead containers (not nearly as full blown as today's virtual machines) designed to run one instance of one application. It's a better "protected mode" than the one we've come to know and love/hate. Should one of these VMs need to talk to another (eg: if the one running Outlook must call the one running Firefox), that discussion will happen using Web services over a virtual local area network that lives inside the PC (provided by the host OS).

Thanks to Moore's Law or whatever is making our systems blazingly fast at the time, there will be minimal performance penalties penalties when such interapp communications don't take the shortest path. Even cooler might be the way, once apps are bottled into their own network addressable containers, how that might lead to some interesting collaborations. For example, today, when I click on a Web address in Outlook, it launches a Web page in my default browser (Firefox). Imagine if I could right click on that link and had a choice of launching it on my machine, or my co-workers' machine (in the cube next to me or on the other side of the world). The security model is pretty clean. Because I'm remotely launching something into its own VM, not only would it be sandboxed from everything else, it would default to limited permissions that only the remote user could adjust.

In my dreams, right? Perhaps so, though there are some precedents for sandboxing applications as well as dynamic privilege adjustment. For example Sandboxie (my assumption on the etymology is Sandbox (v.) Internet Explorer) runs applications in their own sandbox, partitioned from the rest of the system. There are alternatives to Sandboxie such as GreenBorder, Virtual Sandbox and Shadow Surfer and in terms of dynamically adjusting the privileges of Internet Explorer, Microsoft has an interesting utility for Windows called DropMyRights.

But, for those sorts of protections to be baked into our systems (in other words, [1] not requiring third party add-ons and [2] involving standards for interprocess communications that are largely based on Web services), it may be a while before we see this sort of ubiquitous approach. In the meantime, we still have memory leaks in Firefox (what got me going on this in the first place) and the good news is that the community of developers working on Firefox are chasing those leaks down and asking for your help. According to Jesse Ruderman:

Many Mozilla community members, including both volunteers and Mozilla Corporation employees, have been helping to reduce Firefox's memory usage and fix memory leak bugs lately. Hopefully, the result of this effort will be that Firefox 3 uses less memory than Firefox 2 did, especially after it has been used for several hours....

You don't have to be a C++ programmer to help find leaks in Firefox....If you're a Firefox user, an easy way to help is to browse with a trunk nightly build wrapped in a script that calls leak-gauge.pl when Firefox exits. If it reports that documents or windows leaked, try to figure out how to reproduce the leak and then file a bug report.

Perhaps the most important part of this story isn't the whole memory leakage issue. It's that you don't have to be a programmer to contribute to an open source project and this is what open source is about. It's about communities of people with a common interest, all of whom can not only make contributions in a variety of meaningful ways, but who can also feel as though they've taken an ownership role in something that benefits everyone else (well, everyone who decides to take advantage of the open source projects' deliverables). This is different from a commercial software development model where no one really gets to the see the code and, if you're one of the people chosen to beta test and report bugs (yes, chosen... in some anti-social way, participation isn't always open to anyone who wants to help), you're ultimately contributing to the revenue-oriented profitability of a software company rather than the fuzzier profitability of an open source software community.