Category: Mozilla

Let me get this straight—Mozilla added support for the usability decreasing Marquee tag because a few sites in China used it, but removes support for MNG, the only animated image format that supports alpha transparency and is currently used by Mozilla themes? Yeah, that makes sense. Reading comments in bug 195280 it appears that the current module owner wants to call it quits. No big deal—someone else has offered to take over. There’s also a complaint that at 166K, MNG support is too big, but that seems grounds for improving it, not removing it. Finally, some said that it wasn’t a W3C standard, so it should be gone. Standard or not, it’s being used and supported by a number of apps. The discussion in the bug got pretty heated. As near as I can determine, the only reason it’s being removed is because they said they were going to and had a patch. I’m just cynical enough to believe that this means the next version of Netscape (based on 1.4) won’t have MNG/JNG support, although currently the removal only applies to the trunk. (Netscape 6 and 7 did.) If you disagree with this removal, go vote for bug 18574, now one of the top 20 most voted for bugs in Mozilla.

Some people have suggested that Mozilla’s SQL support is unlikely to confuse anyone. I would say the same but that doesn’t change the fact that courts often try to prevent potential confusion. Two companies can, and frequently do, share the same trademark if they are competing with different products or are in different markets. I think that Mozilla SQL support might cause confusion with the FireBird SQL database, as I mentioned earlier. The Pilot pen vs. PalmPilot case makes me think the FireBird database people might have grounds for a legal battle. In that case, the makers of the Pilot pen made the claim that because you used a writing stylus to use the PalmPilot device, there was potential market confusion, despite the fact that the PalmPilot was a totally different market and that the stylus did not resemble a Pilot pen. This is why Pilot is no longer a part of the name of the company or products produced by Palm.

I hope that Boris Zbarsky is correct in his understanding of how Mozilla plans to use the FireBird name. If Mozilla uses it simply as an internal component name like “Necko” this is all overstated. However, given that the browser formerly known as Phoenix will be distributed as a standalone product, I doubt he’s right.

I’m sure it is quite expensive to pay for lawyers and trademark searches, but I believe the right thing for Mozilla to do is to pick a new name and forget about using FireBird. Potential legal issues aside—who knows, the lawyers may have already said there’s no concern with this—it just doesn’t feel good to trample on another open source project’s name.

Mozillazine has an announcement that the Phoenix browser has been renamed FireBird. This has provoked furious discussion about the legality and morality of stealing the name of the FireBird SQL open source project. Helen Borrie of the FireBird SQL project harshly responded saying “we of the real Firebird Project ARE incensed about this filthiest of dirty tricks, launched without warning by a crowd which has pretensions to being ‘open’ in the broader sense espoused by the OSI. This is not a ‘free and open’ tactic in any sense except that by which felons believe others’ property is ‘free for the taking’ and ‘a glass door is always open’.… The heart of this dispute is not ‘legal comfort’, however. It’s the doing of this dirty deed in the heartland of open source, where we are all supposed to be above such things. If Open Source is to win, we can well do without brother cynically stealing from brother.”

Given that the Mozilla browser has added native SQL support, I believe there could be some confusion that would have legal teeth.

I assume the browser formerly known as Phoenix picked up this SQL support from the Mozilla code as well. If it did, then people may well ask: did the FireBird browser use FireBird database technologies to add support? I know the answer is no, but many will not know that or may be confused.

As much as I like the name FireBird (I liked Phoenix even better) I find it appalling that Mozilla would steal a name from another open source project. Yes, I know that it is typical for open source projects start out by accidentally using the name of another. This is usually easy corrected. I expected better from a well established project like Mozilla.

Just after the fifth birthday of the code release, Mozilla.org draws a new roadmap that charts a bold course for the future. Partially a response to the failures and experience of the past development years, it is also a natural progression and recognition of Mozilla.org projects already leading the way.

Key points:

• All future apps will leverage the Gecko Runtime Environment (GRE).
• The browser component will utilize the work on Phoenix.
• Similarly, the standalone Minotaur/Thunderbird project will become the basis for the mail application.
• The full everything-in-one-process Mozilla suite of apps will be replaced using a more modular approach.
• Bless the 1.4 release as the new stable release and discourage the use of 1.0 for future work.
• Fix architectural bugs in the Gecko layout engine to enhance performance, extensibility, and maintenance.
• Give more power and responsibility to module owners and have fewer people with blanket check-in rights.
• Relax super-review requirements for those people, such as the module owners, that demonstrate good judgment and ability.

It remains to be seen how this will play out, but I like the essence of the plan. The Phoenix browser is worlds better than Mozilla in some areas and even Mozilla 1.3 is fabulously better than 1.0. Having a more modular architecture should benefit not only Mozilla apps, but applications and products built by other organizations. Having better defined module ownership and the ability and desire to say no to poor quality code should also improve the project.

Still, I have concerns, primarily about user interface. The roadmap has this to say about UI:

It is almost always better to have a competent owner who rules decisively, than to have no owner and live in a state of indecision (N.B.: a committee of more than one or two is not an effective owner). This point is especially true for top-down application design and policy setting, particularly for user-interface design. For coherent UI within an application, there is no substitute for leadership by an “application czar”. For cross-application consistency where it is needed, we expect such czars to communicate, cooperate, and consolidate things such as common default keybindings.

That’s true, as far as it goes… where Mozilla, and open source projects in general have broken down is in actually having the application czar. (Or more to the point, in having good ones that understand user behavior and can design well—most open source projects effectively have an application czar that is the lead programmer.) Having UI involvement and management just at the module level isn’t enough. UI decisions frequently affect overall architecture, from the network on up to the browser chrome and everything in between. Add to the mix that for good or bad, the best designers are rarely top-notch coders. So how does the application czar get elected and respected in the community?

A related challenge is in determining target audience for the application. I’ve seen many end-user complaints that the mozilla developers just don’t work on the things that are most annoying and need to be fixed. Unsurprisingly to me, Phoenix is a better browser than Mozilla because it set out to be a browser for real people. Will the ficticious “Mozilla isn’t for users” mindset continue? Or will the Phoenix practice win? With many more companies deploying and shipping Mozilla (see RedHat and HP for examples) and with this roadmap it’s time to admit that Mozilla is for users.

But who is the user, specifically? I’ve often thought that using a Persona approach such as described by Alan Cooper and others could provide an answer for open source developers. It’d be worth a try. Until then, design for mpt’s mother.

Back to the big picture, the idea of providing an extension mechanism is quite appealing to geeks, but the average person wouldn’t even know to look for extensions. There’s also the shared-computer / internet café to contend with. How will the question of the default set of capabilities be answered? Whatever was in IE? Whatever the module owner likes?

Regardless of these concerns, I believe this is a step in the right direction. Even if done for reasons other than concern for the user, it will benefit them. I just hope Mozilla.org can take the additional steps to create processes and products that will result in joyous and satisfied users.

Five years ago yesterday, Netscape released the Communicator source code. In the years since then, Mozilla.org community members have hammered on the code to create an extraordinary browser that leads the world in standards support and is a platform for other browsers as well as other products.

By coincidence, the 200,000th bug was logged in the bugzilla bug tracking system on the five year anniversary of the source code release. Although bugzilla tracks many components and tools other than the browser and includes features and duplicates as well as unique and real bugs, the magnitude of that bug number is amazing. Many, many bugs have been found and fixed over those five years, making Mozilla a solid and stable tool. A number of these fixed bugs include security exploits that remain unpatched and troubling in other browsers.

Happy birthday, Mozilla!

I’ve been waiting with much anticipation for the final release of Mozilla 1.3. I expect this will be an excellent Mozilla version and a highly recommended upgrade. There have been a number of terrific changes, including ones that allow web developers to create rich-text edit controls like htmlArea by interactivetools.com. Profile switching is another recently added feature that will be very nice for those that share computers.

In other Mozilla.org news, the Chimera browser for the Mac has been renamed to Camino™ and has a new 0.7 release available. They were forced to change the name due to trademark infringement. Shame that they picked something so bland. Camino is a Spanish word meaning “path” or “road”, so at least it has some loose relationship to a web browser.

Yay! Boris Zbarsky has a blog.

Mike Pinkerton is pondering what to do with Chimera:

I’m torn about what to do with Chimera. It’s obvious it will only ever be a marginal product on a even more marginal platform. AOL and Netscape have no interest in supporting it. Who aspires to be number two in an already over-commoditized space? Working my ass off for 3% just isn’t any fun any more. Safari has already won, the rest is just to see by how much.

12 days before, he sounded much more optimistic and pointed to Chimera’s strengths:

So I bet you want to know what I think about Safari? … What does it mean for Chimera? Well, we have the ability to be much more flexible simply because we don’t answer to one man: Mr. Happy.… We’re also a real open-source project, not just one that dumps its changes back at the 11th hour because we’re mandated to. That means we get the help of everyone on the net not just in testing, but in development and feedback that is crucial to the success of the milestone releases.

We’ve come a long way in less than a year. Where do we go now? Now that the cat is out of the proverbial bag, we have a chance to openly evaluate what each browser brings to the table and ensure that we’re going in the right direction. Then probably 1.0 after a couple months of polish, then back on the Mozilla trunk so we can pick up a lot of the cooler features that have gone in, as well as speedups (15% by bryner’s latest numbers, and that’s almost as much as we need to catch Safari).

I think it’d be a shame to lose Chimera, even though I don’t directly benefit from it (well, I am using the Chimera theme for Phoenix at the moment) I’ve heard many good things about it from Mac-using friends. It also seems to be an important option for those that aren’t using the latest and greatest version of OS X as Safari requires. This whole conversation is a bit strange to have about an open source project. It may not matter whether there are other options if Chimera still fits some users’ needs.

David Hyatt discussed in more detail why Apple would chose KHTML over Gecko as the engine for the Safari browser. Unfortunately it has been taken down now. John Gruber apparently saw it, too, and quotes the following snippet over on his Daring Fireball site:

Imagine that your number one priority for a browser is speed. You want a browser that launches almost instantly. You want a browser whose page load peformance can be improved dramatically. This is your number one goal, because you want to address what has been a fundamental problem on your platform (OS X) ever since it was launched: that no browser has accomplished the goal of fast startup and fast page load. Your job is to find an existing open source engine and improve it to the point where it does have fast startup and phenomenal page load times.

Hyatt also pointed to David Baron’s review of the Gecko layout engine for examples of the challenges facing a company seeking a layout engine. Hyatt essentially said that in order to use Gecko to accomplish Safari’s speed goals, Apple would have had to significantly rearchitect some parts, drastically trim or remove several libraries, such as the image and network libraries that were redundant with Mac OS X libraries, and learn Gecko’s unique terminology for everything. With KHTML they did not need to rearchitect because they found it already small and well-designed. But it cost them the unmatched standards support of Gecko. It will be interesting to see how these comparisons motivate improvements in both engines.

Update: jwz saw it too and points to the LiveJournal archive of Hyatt’s post. He says Hyatt says he is working on a more accurate version.

Aaron Swartz alludes to Safari having spell check in HTML form fields. If only Mozilla had implemented it back in 2000 when it was suggested. See Mozilla bug 23421 and bug 16409. This will be a killer feature for anyone that writes text in HTML forms, especially bloggers. Unfortunately, both bugs are still marked helpwanted.