The Mozilla Platform’s Catch-22 Problem

Starting with Netscape 4.5, I’ve used Netscape, then Mozilla, then Thunderbird for email. I have a similar relationship with Firefox. I’ve watched with great hope and been disappointed over the years as Thunderbird bugs that really annoy me just… stay. I think I know why. It’s because Firefox and Thunderbird are built in such a way as to create a catch-22 situation — one that actually discourages new contributors.

Here’s a good example of a bug that would seem to be trivial to fix: “Entire message” quick search criteria is only the body. You can’t search the entire message in Thunderbird. Can’t do it. Never been possible, as far as I know. Lots of people noticed it; it’s been marked as an “enhancement” in “New” status for years, even though it’s quite obviously a bug in my opinion. So, go to the source code, find the part where it decides what parts of the body to search, and make it search the whole thing. Should be easy, right?

Hell no. Firefox and Thunderbird are built using an incredibly complicated set of tools and technologies created by the Netscape and Mozilla folks, specifically for the purpose of building Firefox and Thunderbird.

Low-level stuff is written in C++, but if you know C++ already you still have to learn their coding standards and class libraries. Yeah, it’s great that they have coding standards and libraries; I’m just sayin’, that’s more stuff you have to learn in order to write a single line of low-level code.

High level stuff is in a combo of JavaScript and XML. Of course you have to learn the XUL platform stuff, so just knowing JavaScript and XML isn’t sufficient. You’ll also probably need to learn to use the low-level classes from the XUL side, so that you can get anything done.

Now if you want to actually build it, you’ll also need to understand their build system, and maybe their installer. You might need to learn how their help system, documentation system, internationalization sytem, etc. etc. work.

Now, I’m in awe of the monumental amount of new and working code that the Mozilla community has created. But the problem is just that: they built this huge application stack, and in order to get working on Firefox or Thunderbird, you have to learn a big chunk of that stack.

In theory, this wouldn’t be any more of a barrier than if they had coded to a single platform’s GUI widget set, class library, etc. But if I were to learn .NET and Visual Studio, or Cocoa, or GTK+, I would then have skills that I could use to work on thousands of other applications, either open source or commercial. That’s because those technologies are designed for general purpose application development.

The Mozilla application platform, however, has no life of its own outside of Mozilla. There’s an effort to extract it and make XULRunner a viable standalone platform that you could build your own XUL applications on, but that’s currently just a “stable developer preview”. What that means is that it’s still not suitable for use if you wanted to, say, build your own iTunes killer with it. It’s almost there, and maybe if you throw a lot of effort at it you could hack it so it’s usable, but as-is, it isn’t readily useful.

So, when a developer (such as myself) looks at this technology set, they ask themselves the question, “can I justify spending this much time learning all this stuff just to fix a little annoying bug?” If you spend a week or two downloading and learning and hacking and that gets you a certain amount of skill with the technology set, was it worth it? Maybe you could go get a job working with this technology set, except almost no one else is using it, not even open source projects.

When a corporation looks at this technology set, they have to ask a similar question: “is this the platform that will give me the best bang for my developer buck?” If they invest the time and money in hiring developers to work on this mostly-complete platform, so that they can then build an application with it, will it pay off? What about alternatives? Will the pool of available developers be so small that the project will fail before it starts?

These are not insurmountable barriers; some folks know some of these technologies already or only want to work on a corner of the application, so the overhead is smaller. Or, they may really want to work on Firefox or Thunderbird very badly. For an employer or open source project, their goals may match the goals of the original platform designers very well, in which case the payoff of using the Mozilla platform would be much higher than if you were (for example) making a Windows-only IM client.

But the barriers do exist, and they discourage the platform and the applications built with it from being improved. Developers don’t want to spend all that time learning things they can’t use elsewhere, and employers don’t want to pay developers to fix the platform so that other projects could find it useful. A few projects do exist and obviously somebody somewhere is working on Thunderbird bugs, but for a platform this sophisticated with this much mindshare (via Firefox), it’s remarkably unsuccessful in terms of adoption by developers.

All it would take to fix this would be some cash. Somebody could donate (or spend, in pursuit of a business goal) money toward the completion of XULRunner for general use, and toward clear and useful beginning developer documentation for the rest of the Mozilla platform.

Any takers? I could thrown in a hundred bucks or so, but I have a feeling this is more like a $50,000 undertaking. Otherwise we’re stuck waiting for Joost and a handful of others to slowly move it along.

Leave a Reply

Your email address will not be published. Required fields are marked *