Mozilla Team Responds
About a month ago, we took your questions regarding one of the most contentious open source projects in existence. Two years ago, Netscape
Communications released the source code to its once mighty Communicator Web browser in an effort to save the browser - and thus the company -
from Microsoft's increasing market leverage.
Did the gamble pay off? That's the question we asked some of the Netscape-employed contributors to the endeavor that has become known as Mozilla, on the eve of its first commercial incarnation: Netscape 6.0.
First, eFront would like to thank everyone participating, especially Daniel "leaf" Nunes, for taking time out of their busy schedules to answer questions. Here with us today are several Netscape employees and people involved in the Mozilla project:
Daniel Nunes, known to most people as leaf, is the "Chief lizard wrangler" at Netscape, and is in charge of making sure that developers do
not cause bustage in the Mozilla source code tree. If someone checks in bad code that prevents other contributors from working on Mozilla, leaf
gives them hell until the problem is solved.
Eric Krock is the Senior Product Manager for Netscape Gecko, the next generation layout engine at the core of Mozilla / Netscape 6. Gecko
outperforms all other browser layout engines when rendering a Web page, yet also follows important web standards to make sure they appear as
intended.
Dan Veditz is the leader of the XPInstall / "SmartUpdate" team, which is
how Mozilla and Netscape 6 update and install additional software
components.
Eric Vaughan is a Senior Engineer in the XP Toolkit (cross-platform user interface toolkit) group. He's responsible for the box layout system used in Mozilla's front end.
Erik van der Poel, with Netscape since April 95, spends most of his time with fonts, and is responsible for Unicode Text Rendering in general. He is also working with IBM and Sun Microsystems to bring bi-directional text support to Mozilla.
Alec Flett works on Mozilla's mail and news client, including mail accounts and UNIX portions.
Many people are still confused about what the differences are between
Mozilla.org and Netscape Communications. Can you explain?
Leaf:
Netscape created an organization to act as the stewards for the source
code it released on 3/31/98... that organization is called mozilla.org, and has a pretty clear mission. This mission is very different from what
Netscape's mission, as a company, is. Netscape's mission is to provide useful products and services for profit.
The source code obtainable from mozilla.org is licensed such that
companies (any company) can take the source code, and link against it, add new source files to it, or simply repackage it. Netscape is a
consumer of the mozilla.org source code, and, since it has a lot invested in this source code, provides resources to make the source code better.
Netscape believed that by opening the source code up for public scrutiny
and contribution, via mozilla.org, they'd get an improved source base in return. I believe they were correct, but obviously, I am biased.
The people that contribute to mozilla.org who are not paid by Netscape to do so, believe that by contributing, they get a chance to improve a product they rely on every day. I am certain that they are correct about
that much.
How long do you anticipate the beta period of Netscape 6 to last? Will user feedback on this beta play a big role in shaping the product?
Leaf:
User feedback always plays a large role in open source projects. I would
bet that the widespread attention that the Netscape 6 beta will get will
generate a lot of bug reports and hopefully developer interest.
Dan Veditz
: I keep hearing that Netscape has historically taken six months from first
beta to final ship. I don't know the accuracy of that statement. That is
roughly the current schedule, but I don't know the realistic accuracy of
the schedule, either :-)
Where does the Communicator 6 beta fit into the scheme of things being
done by Mozilla and vice-versa?
Leaf:
To be totally clear: mozilla.org is not releasing a beta release any time in the near future. The target audience of mozilla.org's releases is developers. Developers tend to care about things like API freezing, and architectural completeness (or near completeness), rather than some feature set mostly working. Netscape's beta is meant to satisfy a need in the consumer market, not satisfy developers who would like a stable
point to dive into the mozilla source code.
The beta Netscape is producing is a snapshot of the mozilla source taken
at a stable time in it's life-cycle, with some additions that are
proprietary.
What benefits and differences will there be to using the Netscape
Communicator branded version or the Mozilla branded version of the
browser?
Dan Veditz:
My impression has been that "mozilla.org doesn't ship browsers", so does
it make sense to talk about a Mozilla "branded" release? There will be additional proprietary features in the Netscape version, mainly integration with various bits of the AOL empire. End users may really go for those things, people who like to tinker under the hood will definitely prefer the generic mozilla.org version.
Leaf:
Using the Netscape branded version also assures that some concerted
Quality Assurance process has been applied to the binaries being
released. The binaries that come from mozilla.org have much less of an
assurance of this, as our binary releases, done on a daily basis, are not
guaranteed to even start. The mozilla milestone binary releases tend to
be better tested, though only on the platforms we can find testers for =)
Why did Netscape jump to version 6.0, and skip version 5?
Leaf:
That's an excellent question. However, I wasn't let in on the decision, so I'm not sure what the exact reasoning behind it is. I have read in
other publications that 6.0 was selected to reflect the massive rewrite that began in November of 1998.
Dan Veditz:
Marketing.
As leaked on MozillaZine, [the name] was originally "Netscape 2001" at one point - an attempt to get off the version number treadmill. The AOL execs hated it, and it became "6". There are lots of reasons to justify/rationalize the "6", but ultimately it came down to one getting better response with focus groups.
Netscape 6 surprisingly shared the same Mozilla interface in terms of
toolbars, images, etc. Regarding the Netscape 6 final release, can we assume that it will have the look and feel of Netscape 4.7? Will users find it hard to adapt? How will the final version compare to the preview release?
Leaf:
Making any assumptions about releases that haven't happened yet is a sure
path to being wrong. I can't say what the Netscape [final release] will
look like, or even how difficult it will be to adapt to. I think it's
important to keep in mind that this is a beta, not a final release.
I can't imagine that Netscape would release software that was difficult
to use. I could be wrong, but it just wouldn't make any sense.
Dan Veditz:
[Version] 4.0 looked different from 3.0, Netscape 6 will look different
from 4.0. I don't think anyone knows what the UI team will come up with
for a final look. It may be pretty much the same with more polish, or
maybe someone will come up with a blinding insight that will
revolutionize the entire thing. The beauty of XUL is that it's easy to
play with and try different things.
It seems to me that there have been a few conflicts between the
open-source aspect of Mozilla, and the corporate Netscape folks who drive
it. When making decisions on the browser, how do you please both
Netscape, and the open source community?
Leaf:
The people that drive the development of the mozilla source code are the
people that check-in source, or submit patches that are eventually
checked in. In any project with more than one contributor, there are
going to be disagreements in how to do things. The staff of mozilla.org
is not meant to technically guide what the source code does, but rather
facilitate the cooperation of individual module owners. Collectively, the
module owners decide on the direction the source as a whole will take.
There are a few developers that take up leadership roles, and frankly,
mozilla.org doesn't care where they come from, or who pays them. So, as
far as technical issues go, the right thing tends to happen.
I think the conflicts you refer to are the development process conflicts,
and once again, it isn't really an issue of Netscape Corporate v.
mozilla.org; it is rather a difference of opinion between sets of
contributors. Development process is a touchy issue, and mozilla.org staff members are still trying to find a development model
that pleases the maximal set of developers.
Dan Veditz:
You focus on the common goals, which is a small, fast, stable browser.
The conflicts are about how you get there, and every project of any size
is always going to have some of that.
What is your opinion on implementing Richard Stallman's suggestions to
make the MPL and NPL more compatible with the GPL?
Dan Veditz:
I find it one-sided. His suggestions make it possible for GPL'd projects
to use mozilla, but do nothing to share reciprocally so that mozilla.org
could make use of GPL'd code. I also find his comments on how to deal
with the Qt license interesting since it has the same compatibility
problems. For that license he notes since the QPL is incompatible with
the GNU GPL, you cannot take a GPL-covered program and Qt and link them
together, no matter how.
However, if you have written a program that uses Qt, and you want to
release your program under the GNU GPL, you can easily do that. You can
resolve the conflict for your program by adding a notice like this to it: "As a special exception, you have permission to link this program with the Qt library and distribute executables, as long as you follow the requirements of the GNU GPL in regard to all of the software in the executable aside from Qt."
Well, if that's all it takes, couldn't a GPL'd program do the same for
the MPL license?
In any event, mozilla.org has started releasing some core parts of the
code dual-licensed [under the] MPL and GPL, and if GPL'd folks appear
willing to share, the idea could spread to more of Mozilla.
Leaf:
This has already been done. The MPL 1.1 allows dual licensing with the
GPL.
What were some of the hardest decisions to make and things to do in the
development of this browser?
Leaf:
As you alluded to earlier, dealing with differences of opinion in the
developer community is the most difficult part of doing development with
such a large group. I think that by and large the most difficult
technical issues are hashed out by a few people who actually write code.
The more difficult questions are of the form: "How do we keep the tree
stable from day to day?" and "What do we do to discourage people
checking in code that hasn't been run through extensive regression
testing?"
There are tools hosted by mozilla.org that help alleviate the problems
associated with herding this many cats, but the difficult policy
questions still remain, and still get a lot of cycles from some rather
large brains.
Many people say that two years is an awfully long time to work on a
product, and just now make it to beta quality. What do you say to the
people who think that Mozilla's development has been unacceptably slow?
Leaf:
As I mentioned earlier, a massive rewrite of the source code began in
November of 1998, so it's really only been about a year and a half.
Considering that this product is expected to have all the features of a
source base developed over the span of four years (the 4.x source code),
one and a half years is a very short amount of time. There is no way
Netscape could have done this without the help of the open source
community, in my opinion.
Dan Veditz:
Writing the project "in itself" is a cool idea, but not conducive to rapid development. If fast development time was the goal we should have scrapped the XUL idea and used a stable toolkit to build native browsers. That was what we did with Communicator, and the result was that Unix and Mac development falls behind because we can't justify spending 2/3rds of the front-end programming budget on platforms that make up < 1/5 of our customer base.
Once the toolkit stabilizes, though, watch out! Future versions should really start to rocket.
Quite a few people are interested in Netscape 6's new install process of downloading components from the net, but will there be an option for users to get everything in one big downloadable package?
Dan Veditz:
For Windows and Mac both [options] will be available, by beta2 we hope to have the Linux component install going as well. The reason for keeping the "one-big-file" version available is for people who want to host it on a local network (a school, say) that has better connectivity within the network than to the outside.
Will
users be able to install only the browser?
Dan Veditz:
There is definitely a browser-only option in the component installers (which are Mac and win only for beta 1 as mentioned earlier). All other components can be individually added or subtracted from the installation.
How will Netscape compare with IE in terms of features, standards, and stability?
Eric Krock:
Remember, this is the first preview release, not the final release. Netscape 6 Preview Release 1 is not feature complete, as we've been noting on mozilla.org for months now. So many features that will be in the final release aren't in this first preview release. In particular, the disk cache isn't implemented yet, and full HTTP 1.1 support with gzip compression isn't in yet, so don't expect to see the performance of the final release. However, you can already see dramatic improvements in such areas as table rendering. Our standard table torture test takes about 7 seconds to render (and also to window-resize/redisplay) in Navigator 4.72; the same table displays almost instantaneously in Netscape 6 PR1. Plus, in Netscape 6, you can resize the window and see it continuously, dynamically reflowing on the fly. Expect to see steadily improving performance as we further tune performance over the next two beta releases and for the final release.
What will the mail and news be like compared to previous versions of Netscape Communicator? It has been said that Netscape 3 had the perfect blend of ease of use and functionality.
Alec Flett:
It has also been said that 4.5 was the perfect blend of ease of use and functionality. :)
Mail will have a similar feature set as the 4.5-generation Communicator. There are some "edge" features that made 4.5 particularly nice which will probably not make it into the 6.0 version. For instance, we won't have LDAP support. This is not because we aren't interested in these features but rather that we're spending most of our time trying to ship a brand new mail client based on the new technologies in mozilla, such as XUL, RDF, and XPCOM.
On the positive side, 6.0 will have a few features that people have been requesting for years such as multiple simultaneous POP, IMAP and NNTP accounts.
Leaf:
It's pretty easy to use.
Can you comment on how Mozilla will handle the Unicode/UTF-8 encoding for fonts?
Erik van der Poel:
Mozilla supports Unicode and various other character encoding in documents, fonts, and several other areas. It uses a number of fonts if the document requires glyphs that are not all in a single font.
Will XUL let the user add wallpaper to the toolbars, like Internet Explorer 3.0?
Leaf:
XUL will let enterprising users do pretty much whatever they want with their UI. Right now, however, with mozilla, there isn't any UI for changing the UI, but there may very well be in the future.
Eric Vaughan:
Our entire UI is written in XUL, which is very similar to HTML but designed from the ground up to build user interfaces. So if you can write and HTML page you can learn to make any mozilla application look or act anyway you like. So yes you can add wallpaper to toolbars. Or you make something completely different. Maybe you don't like toolbars maybe you want mail to have a completely different layout. But we don't expect and average user to just start rewriting the UI. So we have something called "Skins" a skin can be installed that can make mozilla look like the old 4.0 UI. Or make all the widgets look like the Mac, Windows, or just have that seventies look. XUL is more like the structure of a building and Skins are the paint. You can add windows, elevators, whatever with XUL and then you can give it a particular look and theme with a skin. We expect skins to be very popular and 3rd party sites to appear that just serve them up. There is already one called MozillaZine.
How flexible will Mozilla be with cookies?
Leaf:
In the mozilla builds I use, there is some rudimentary cookie management.
Will XML support be W3C compliant? Can you comment on the status of Mozilla’s web standards compliance?
Leaf:
The mozilla browser uses James Clark's expat parser for parsing XML documents, and it complies to the standard quite well, I hear.
Eric Krock:
We crush IE5 on both Windows and the Macintosh on the breadth, depth, and cross-platform consistency of our standards support. Full support for DOM 1 Core is one of the notable areas of difference, and the DOM1 Core, which is crucial methods that work for both HTML and XML, is the foundation for next-generation, high-performance, XML-based, rich-functionality web applications that will run across platforms and devices.
RichInStyle.com has written that "Without doubt, Mozilla is the best CSS browser available."
In a recent analysis of combined CSS1 and CSS2 support by David Baron, Mozilla received the highest score, 36.5, compared to -8.5 for IE 5.0 for Windows.
Full support for alpha-blended transparency in graphics (PNG), Support for vector graphics (such as SVG), and Embedded fonts via CSS2 --- will these features make it into a release?
Leaf:
*A* release will have these things, probably, eventually. I don't believe they're in the mozilla nightly binary releases yet. I have seen screenshots of people building SVG support.
Erik van der Poel:
Mozilla does not support embedded fonts yet, and it is not known when such support will be added.
Is Netscape working with IBM to bring v6.0 to the OS/2 platform?
Erik van der Poel:
IBM is working on OS/2 support, and is checking it directly into the tree.
Is Mac Mozilla currently Carbon compliant, or will it be later on?
Leaf:
To quote a Mac mozilla expert, "No, it is not, nor will it ever be. Mozilla for OSX is a hybrid of MacOS and Unix code and will only run on OSX. Mac Mozilla will run on OSX, but only in the "classic environment."
Currently, Mozilla uses a lot of files in several subdirectories to hold components of the web browser. Wouldn’t it be easier to use something similar to a PAK file, and let the user save disk space?
Leaf:
I have heard it said that some day, all the UI files will be kept in .jar files or perhaps just .zips, but this isn't a high priority for mozilla developers at the moment. Perhaps one of your readers might be interested in writing the code to make this happen.
Dan Veditz:
If you're referring to the chrome, yes, there are several bugs/features aimed at getting them packaged up into jar archives.
It used to be that anyone could easily get a BugZilla account, but recently some restrictions were put into place. Why? Were you having problems with people messing with the database?
Leaf:
The restrictions were put in place to make it a bit easier to filter out bugs filed.
Dan Veditz:
We were getting minor amounts of easily correctable vandalism (one incident a month at most), lots of duplicate bugs of low quality, and tremendous fear of being overrun once the Netscape beta hit the streets.
With regard to form handling, will we be able to use the “enter” key to submit a form?
Leaf:
Most of the mozilla binaries I've used lately support this. There are fluctuations in the quality of the UI, however.
How will downloading plugins be handled in Mozilla?
Leaf:
I'm not sure what the plugin story is. Last time I installed a mozilla binary on a Windows box, it automatically recognized pre-installed plugins. Haven't tried this in a while, though.
Why include non-essential components such as e-mail, news, composer and skins to the already significant workload of just developing a Web browser?
Leaf:
Admittedly, writing just a browser would be far simpler than writing an application that handles all that other functionality. There is a good document that describes why all this stuff should come through the same interface.
With the new architecture, it's easier to add components and chunks of functionality, so the project is working just as hard, and a lot smarter, than it was before.
How much user interface customization can be made using XUL? Could the interface be made completely different depending upon the website? How much control will the user have on the interface? Will XUL features be able to be turned off?
Leaf:
I think this is mostly still up in the air, but XUL and XBL provide for an enormous amount of flexibility.
Eric Vaughan:
When you go to a Web site it will not be allowed to change the browsers XUL or Skin. That would be a big problem. A website could try and spoof you by changing your UI. Such as hiding close buttons, etc. But in the future we hope make it possible to just go to a .XUL file instead of .HTML page that could contain a full UI that would be imbedded in your browser. Imaging browsing to a word processor or a spreadsheet instead of having to install one!
How modular will the browser be? For example, say once the browser is released, will the gecko engine be updated as new web standards are released? Could different components be updated individually?
Leaf:
That's the goal of xpInstall, and it already works quite well. You install security components for the mozilla browser using xpInstall.
Dan Veditz:
Theoretically individual components could be updated. In practice Netscape is not likely to do so except as part of a tested upgrade, and as likely as not the upgrade version will update many components.
Right now the install treats layout and other infrastructure as part of the "browser". In the future we need to be able to separate this out. Right now you could have a browser-only install; in a future version some people might be interested in a mail-only install, which would require us to identify and separate these core components.
Which part of Mozilla do you feel was/is the hardest to implement?
Leaf:
If you're talking about the technically most difficult, I'm not sure (I don't actually do anything, I just make the builds and whine when something breaks).
If you're talking about mozilla.org, the organization, we're still trying to figure out how to let everyone get all the work done that they want, without having everyone step on each other's toes.
Mozilla on Linux uses GTK, but does not seem to adopt my GTK themes – this creates inconsistency with my applications.
Eric Vaughan:
Hopefully many of the themes in GTK will be reproduced as skins, so you can just find the matching skin. There has also been talk of a skin that uses native widgets. But that's much further in the future.
Will this new version support any kind of Vector Graphic format, like PGML, SVG, or VML? If not, are there any efforts being made to support these formats (plug-ins, maybe?)?
Leaf:
There is an SVG effort (and even code checked into the tree) already.
Many, many people have been curious about CSS2 support – it seems to be an important feature.
Leaf:
I believe that mozilla extensively relies on CSS... that's part of the beauty of the XUL UI, it forces our layout engine to adhere to standards, so that our UI can be written to spec, and laid out properly.
Eric Krock:
Our CSS2 support is the best of any browser. Note our above winning score on total CSS1/2 support in David Baron's evaluation. However, it's important to note that we've never at any time committed full support for CSS2 (as opposed to CSS1) in the first release of Netscape 6. (i.e. in the first release of the finished product) Areas we do support include CSSP features like positioning, visibility, and stacking.
What can you do to convince people that the incredibly long time testing it will be worth the consumer’s wait?
Leaf:
I'm not planning on doing anything to convince anyone. If you're wondering what Netscape is going to do, well, again, your guess is as good as mine.
Just how fast is Gecko?
Leaf:
I'm not sure what kind of metric you are looking for. Anecdotally, it "runs pretty quick" for me.
Eric Krock:
Again, since this first preview release is not feature complete, and much performance tuning is ahead, it's too early to get into detailed quantifications and really have a meaningful relationship to the finished product. But as the table example shows, the clean rewrite and new architecture are achieving dramatic gains.
Does Mozilla handle tables better than previous versions?
Leaf:
Tables layout wonderfully for me using the recent mozilla binaries. I would imagine that the Netscape beta would handle them just as well.
What companies have been directly cooperating with Netscape to complete the browser?
Erik van der Poel:
IBM, Sun and Intel, among others.
How do you think the industry will respond to this next generation Web browser? Embrace it? Reject it?
Leaf:
The Web developer community seems to be behind the mozilla project. Any time a project is made open, and it's development influencable by anyone willing to contribute code, standards compliance is going to win, and that's key for web development.
After two years, are you excited about the release of a Communicator 6 beta?
Eric Krock:
Excited? I'm thrilled and ecstatic!
This first beta release is the culmination of two years of effort developing the Netscape Gecko browser engine, and more than fifteen months of work on Netscape 6 since the decision was made to base Netscape's next client on Netscape Gecko. This includes work by Netscape, our partners, and all the open source contributors of the mozilla.org community. mozilla.org has succeeded in producing the most standards-compliant browser ever shipped!
As a content developer myself, I'm thrilled to have access to a browser that when finished will have full support for HTML 4.0, XML, CSS1, DOM1, and RDF as well as industry-leading support for CSS2 (particularly CSSP content positioning features) and DOM2 (particularly the CSS2 Interface and Events). Not only is our standards support already better than any other browser, we're also offering this breakthrough standards support across platforms (Windows, Mac, and Linux). Developers and groups like WebStandards.org have called on vendors to fully support HTML 4.0, XML, CSS1, and DOM1, and I'm personally proud to have participated in meeting that heartfelt need.
This rich standards support will also make it possible for the first time to build rich web applications with the performance and UI richness of native applications, yet to do so with web standards so that these web applications will run across platforms and devices. No longer will web applications be limited to web mail and web calendaring; our broad and deep standards support will unleash the creativity of developers worldwide.
Plus, because Netscape Gecko is free, open source, and embeddable and has a cross-platform architecture, you'll see the same great standards support showing up in Internet browsing set top boxes (such as those that Intel, Nokia, Liberate, and AOL TV have recently announced plans for) and appliances. This will deliver web browsing as rich as on the desktop without the complexity of the desktop, and will bring web access to millions of new users who would otherwise have never joined the Internet revolution. No longer will the complexity of PCs prevent people from enjoying the full richness of the web. This is a giant step forward for making the web available to everyone.
Thanks, everyone, for your time.