h o m e
s c h e d u l e
a r c h i v e s
c h a t
f a q
t o o l s
a b o u t
dr. dobbs journal
mozilla.org: Open-Source Software
with Tom Paquin and Lloyd Tabb, mozilla.org
By its scope and visibility mozilla.org is the most ambitious open-source project to date and will influence how developers collaborate and build software in a connected world.
TNC: Hi guys, welcome to the program. Very quickly, can you introduce yourselves?
TP/LT: Sure. I'm Tom Paquin. I'm a fellow here at Netscape.
LT: I'm Lloyd Tabb. I'm responsible for process at mozilla.org. Basically I coordinate developers.
TNC: What is your background? How did you get involved with Netscape and mozilla?
TP/LT: Well, I was over at SGI when Jim Clark left so I tracked him down and came to Netscape back at the beginning. Before Netscape I had some experience with the X Consortium and spent a number of years working on open source there. And I have quite a bit of background with the client here at Netscape. So when we decided to do this I kind of fell into place that way.
TNC: Can you give us a quick overview of the mission of mozilla.org?
TP/LT: The whole idea is to take stewardship of the Mozilla sources or the sources for the Netscape Communicator, take them to the public and then do whatever is necessary to engage the public and keep them happy with the source. We figure that there's a pretty big difference between the goals and priorities of an organization shipping a commercial client to commercial customers and an organization which is responsible for managing publicly modifiable source. So noticing that difference, it seems to make sense to take somebody and give them the right priorities and tradeoffs that would be necessary to keep the stewardship happy. And that's what mozilla.org is all about. Whatever that may mean.
TNC: So the mission is really more coordinating and managing the software development process rather than the outcome of this process?
TP/LT: Yes. It's coordinating and maintaining a stewardship with an eye towards keeping the public developers happy, whoever the Net developers may be --companies or individuals. It means focussing on keeping them engaged, keeping that process turning, even to the extent that this may disagree with a particular priority that maybe Netscape has for its clients, and letting that struggle exist between, say, the Netscape client group as a customer of Mozilla and Mozilla itself.
TNC: But the result of this process is obviously one or more products.
TP/LT: The products of Mozilla are source code and their customers are developers. Whereas the products of Netscape Client Group is a program, a binary and its customers are users.
TNC: Does this mean that mozilla has no strategic or marketing objectives that may infuence the feature set?
TP/LT: Oh, but you want to be the best product. Mozilla's customers are developers. The developers need to provide the feedback as to what's important in terms of features, how you make tradeoffs versus things like size and performance and features and schedules and all those things. And certainly today, one of the biggest development customers for Mozilla is Netscape. But they don't have to be the only guy in town with a voice.
TNC: The relationship between the Mozilla and the Netscape Communicator development track has been the source of some confusion. They are two different products, aren't they?
TP/LT: I'm not sure what you mean by two different products. Mozilla is not engaged in producing binaries intended for users. It produced source intended for developers. And then we expect developers to turn those into binaries for users.
TNC: Is the development work on Netscape Communicator completely independent of mozilla.org?
TP/LT: They're doing some further work on the 4.x series. I'm not exactly sure what their release plans are for that. But the 5.x series will be completely Mozilla based.
Now, Netscape is free to add features that Mozilla either doesn't have or doesn't have yet. It is also free to build a client for their customers which perhaps doesn't have a feature that Mozilla has included for whatever reasons they may choose to go that way.
For example, certainly the Netscape brand of product will have crypto in it. And right now we still haven't completely figured out how Mozilla can pull that off.
TNC: Netscape recently contributed a layout engine to Mozilla.
TNC: So there's still some parallel development there going on.
TP/LT: Sure there is. There's people working on all kinds of things. From Mozilla's point of view, this is a contribution from somebody who said, "Here's a technology we would like to give to Mozilla and develop over time. At some point in the future it will be really cool and useful for everybody." That came from Netscape but it didn't have to.
TNC: Since we're on this topic, what specifically does this new engine provide? A more efficient model for decoupling a document from the rendering of that document?
TP/LT: This is a next generation layout engine. The layout engine that we have in Mozilla today is getting a little old. There are some architectural limitations that this new layout engine intends to move past. So, and what we're doing is we're developing it in public so that we can get support from the Net to do various things.
So for example recently, we only had the resources to do the rendering implementation for Windows and we've been getting a lot of help. We're getting rendering engines on other platforms to work with it.
TNC: The engine is completely platform independent?
TP/LT: Yes. Netscape always develops code so that is platform independent. What we do is develop abstractions, driver level abstractions essentially, to do ports to various platforms. Then there's a platform specific API that needs to be implemented in order for it to run on other machines.
TNC: What will using this new engine result in? Faster repagination? Improved document flow? Faster incremental rendering?
TP/LT: Really good incremental layout. I'm not really up on all the features on this particular product. Mozilla's focus is to host projects. And so our main focus is to get the people, the facilities to actually do their development in public. I'm not up to date on all of the details of what exactly their goals are.
Website and tools
TNC: Let's talk about the infrastructure that you provide to assist developers in building these source codes. What is the most important support elements that you provide?
TP/LT: Why don't we talk about what a developer sees when he starts out and goes to Mozilla.
TP/LT: Right. We can do it in the order we brought things up. Because we brought things up in what we consider priority order. The first thing that we brought up was the website. The website facilitates communication with what's going on with the source or with various projects. We provided places for, and we brought up a set of newsgroups for people to do communication. So projects that are hosted at Mozilla get newsgroups and get space on the website.
Additionally we provide source code control tools.
TP/LT: We brought up a CVS server. Right now it's a read-only CVS server. And that allows outside developers to download and build along with the project that's going on. They can download the source, they can update the source on a regular basis to see what's changed and modify the source. And using the CVS they can actually find out what changes were made to the source.
TNC: One of the interesting features of this particular product is that it is totally client-server can be deployed over the Web. Users can go and look at the source tree from their browsers, for example.
TP/LT: Right. That was actually the next thing we brought up. We developed a set of source code control tools that are entirely Web-based. The version control tool is called Bonsai. Every time somebody checks into a source tree, the revision information is put into a SQL database. And the SQL database is queriable using a query by example form to allow you to see what's actually happening with source code and what people have been checking in.
So if you are working on Mozilla, for example, and find a bug and fix it and send it back to Mozilla --and this takes about a second--the bug fix eventually gets checked in and you can query Bonsai to find out whether or not it's been checked in and who checked it in.
TNC: And that information is available to everybody. For example, now here on my station I can go and look at the build history of particular modules at mozilla.org.
TP/LT: Yes, you can. Right.
TNC: There's also a tool called Tinderbox?
TP/LT: At Netscape, our focus has been Netscape everywhere. And what that means is that Netscape runs on as many places as possible. And that's a very interesting hard problem in development. What happens is that we have a cross-platform API. We call it the XP code, or the cross-platform code. And we have different front ends. Right now there are, actually right now there are four. But historically there have been three. The X front end, the Windows front end and the Mac front end. The X people will tell you that there are a lot more than that-- X is a lot of different platforms.
TP/LT: And there's also two different kinds of Mac front ends.
TNC: Developers are also working on front-ends for other platforms, but these are not directly supported by Mozilla.
TP/LT: That's a whole other topic� What Tinderbox does is continually pull the source out of the CVS tree, build and send the output from the builds to a Web server, actually to a Tinderbox server. The Tinderbox server then stores that information in a database and renders pages in time that shows you what's going on on various platforms.
So it lets you find out how your change affected other platforms. So a guy checks in on a Mac, he might break a UNIX build. His responsibility immediately after checking in is to watch the status of the Tinderbox page to see how his change has affected other platforms.
TNC: I've looked at the output. It displays all the different builds. And you see if a particular build breaks one of the different platform codes, then it appears in red. And the name of the guy who checked in the code name is also shown.
TP/LT: This makes it possible to investigate the source of the breakage so that you can figure out exactly what caused the build to break and be able to track down who needs to fix it and be able to contact them from that page.
TNC: Now, how serious is it to break the build?
TP/LT: That's bad.
TNC: It's bad. What happens to developers that break the build?
TP/LT: Well, we've got this big board with nails and spikes in it and...
TP/LT: Basically they're called upon to fix it. If it becomes a habit, then we try to set it straight so that it won't happen any more. But most people learn after breaking the build once or twice...
TNC: I guess the difficulty here is you're developing for one platform and then you're...
TP/LT: If you're writing front end code, if you're writing, some kind of graphics routine or whatever, then presumably you need to know the platform you're writing for and it won't be compiled on other platforms. But if you're writing cross-platform code, then you do take the responsibility to make sure that you write code that will compile on other platforms.
TNC: What can developers do to make sure that their code will not break other platform builds without checking it in first?
TP/LT: Generally, developers who are doing feature work and writing a lot of code do their development work on branches. Before they land their branch into the main line, they're responsible for building it on all platforms to make sure that they're not going to have a problem during their branch landing.
Once they're on the tip and the feature's landed, generally the purpose of the tip is for a bug fix only. The kind of changes and the size of the changes that you're making are generally a lot smaller and the breakages are a lot easier to fix.
TNC: Is a build made every time a developer checks in a new source code? Or is it done continuously, every ten minutes, every fifteen minutes depending on how long it takes?
TP/LT: It's done continually. So we have a stable full of machines that are dedicated to continually building this. And as they finish building they start over again. There are two kinds of builds. There's a clobber build, which is a rebuild everything from scratch, and a dependency build, which builds just what's changed since the last build.
The dependency build can sometimes cycle very quickly. And so there's a minimum cycle time of ten minutes. But generally they, the machines just build over and over again.
TNC: And the result of the builds are executables and other modules -shared libraries, DLLs, whatever the case may be. Do those have any value to you? Are they used?
TP/LT: Actually, they're just discarded. The interesting thing is the output of the build, whether the build was successful. Tinderbox and Bonsai came around during Communicator 4.0 development. We had some 200 developers doing development on the Communicator code base. And what ends up happening is that you have somebody who checks in something that breaks the ability to build on a certain platform, and those people are out of business. They can't do any work.
And so we developed this strategy for keeping people working. And basically it's rules of citizenship. These tools are overkill if you have only five engineers. But you need them when you have a large number of developers.
TNC: How many developers are now developing for Mozilla?
TP/LT: Very hard to say.
TNC: Aren't they all registered? Anyone can check out a copy of the source code and then work on it in the privacy of their own home. But to check it back in you need permission. Someone owns that module. How does that work?
TP/LT: You download the Mozilla code, play with it for a while and fix a bug. Then you go back to the Mozilla site, find the owner for that area of code and send them a patch with the modification. If it's a good bug fix they'll just check it in for you and they'll put your name or your E-mail address in the check-in log. We've had a large number of those.
We also have an externally visible bug system. You can file a bug and attach a patch. The owner of that piece of code can look at it and do the same thing. Just a different communications mechanism.
TNC: So you can directly fix the bug and check the code in?
TP/LT: No, you can file a bug descrption report. Here's the bug. And in your bug file you can say and here's the patch that will repair it. And the owner can go ahead and grab that.
TNC: Ultimately one person owns the code and is responsible for any changes done to the code.
TP/LT: We allow the owners to deputize other people to be able to change code. And we are working on a process that involves a lot of defense against legal liabilities and stuff to allow people outside Netscape to change the code directly. But we haven't really gotten much going in that area yet. We're looking some small number of months out where that will really start to gain steam.
TNC: So this brings us to how the code is organized. How is it broken down and what are the different modules?
TP/LT: Sure. Well, they're the obvious things, which are the front end code, which is the essentially the windowing systems. And that's different on all different platforms, and those are called the FEs (Front-Ends). And then the back end is broken up into layout engine. There's a networking library, there's image libraries, imaging libraries.
TP/LT: Java script.
TP/LT: Java script. Java security. And Java insecurity are things that we can't ship right now and we're working on.
TP/LT: Oh, then there's the mail subsystem.
TP/LT: There are MIME libraries for breaking apart MIME mail messages.
TNC: Are new modules being added? If I want to add a totally new feature to the product can I come to you and say I want to add an IRC client?
TP/LT: Sure. If your work affects a large part of the code base and has no regard for how it's going to be integrated, we're less likely to accept your submission than if you figure out a way to actually make it work with the plug-n API, for example.
TNC: Okay. We talked about platform dependence in terms of front-ends. The code has to write to the operating system. You have a layer that also abstracts operating system services, is that correct?
TP/LT: Right. Yes. The FE stuff has got both FE and back end code. Sockets and file system calls and all those kinds of things are also part of the FE.
TNC: Is there documentation for developers to know how to use these abstractions, these layers, and how to write code for Mozilla?
TP/LT: There's some documentation on the site. There's a lot of...
TNC: Or is it just a matter of looking at the source code and digesting it?
TP/LT: Yes, it's mostly that.
TP/LT: Let me step back to the back-end code for a second. There's something called NSPR also which is a platform independent abstraction for dealing with file systems and sockets and networks
TNC: I assume that developers writing for mozilla must conform to certain rules. They must learn about the mozilla APIs and tools. They must know, for example, not to open a socket directly in the code but to call whatever mozilla uses to abstract the sockets interface.
TP/LT: Essentially when in Rome do what the Romans do. So they should take a look and see how certain types of things were implemented and implement them in a similar fashion.
TP/LT: And there's also the community there for asking questions about how to go about doing something. I anticipated more difficulty in this space than we've actually seen. I thought that it would take people more digestion time, given the sparse documentation and what I thought was our idiosyncratic mechanism to do things.
When it hit the world, the feedback was pretty positive in terms of people's ability to figure out what was going on and to duplicate it.
TNC: I guess that's because developers are really obviously in tune with reading source code and that's how they learn. You look at the source code, you see how it's done and then you duplicate that.
TP/LT: I think people are pretty much prepared for cross-platform issues when it came to something like the mozilla sources. They anticipated that sockets would be different from platform to platform and expected that they would be abstracted.
TNC: mozilla uses another interesting abstraction, a home-grown component object model. Basically you developed your own binary interfaces, very similar to Microsoft COM, for components to talk to each other at runtime within the Mozilla environment.
TP/LT: Interface negotiation is a really effective way of doing modular organization. And so there are benefits in working in the large when you have that form of interface negotiation.
TNC: Now, why, okay, why develop your own protocol here? Why not use COM? I guess com is not platform-independent...
TP/LT: Yes, but also, how do I include the COM header file in free source?
TP/LT: There's no choice. The solution also needs to be available cross-platform.
TP/LT: There's no way to ship a free version of com that I know of.
TNC: How about other technologies?
TP/LT: We wanted something that could be understood by anyone who spent a little time on it. I was only peripherally involved in the discussion and there was a lot of discussion about what was the right thing to do.
TNC: How widespread will the use of mozilla COM be in the source code? This type of technology can be used everywhere or sparsely.
TP/LT: Well, right now it's very sparse because it's new to the code base. It was submitted the same time as the new layout engine. But what we would like is for any kind of reasonable development in any module in the future to go in this direction.
TNC: To wrap itself in this interface.
TP/LT: Wherever it makes sense to do such a thing. And we think it'll make sense in a lot of places.
TNC: On the interface front, how did you make it possible for UIs to be standardized across all platforms?
For example, if I want to add a widget to a front end I am working on, and I want it to look a certain way, don't I have to make sure it's going to work in the other UIs too?
TP/LT: The UI stuff is designed with people from every platform represented. To some degree there are things on some platforms that cannot be done on other platforms such as some of the drag and drop type stuff. But if you were actually proposing a widget that's just nonsense on another platform, then you have to make a case that the users of your platform need it or care about it or naturally expect it.
TNC: Developers for the different Uis coordinate this together.
TP/LT: There are UI owners. There are owners for the X front end, Mac front end and Windows front end. And those owners work together. And they're not free to go off and do completely different UIs for different platforms.
TNC: I guess there is pressure on mozilla to support every standard and every pseudo standard out there. Specifically, what what are your plans for XML CSS Level support?
TP/LT: Well, I guess there's a difference between the pressure that may be brought to bear on the Netscape Client Organization and the pressure brought onto mozilla to support certain standards. mozilla can do a pretty good job of just listening to the developer community that forms its customer base and finding out what incipient standards are important to them.
But of course, since Netscape is one of the primary customers of mozilla right now or obviously the primary customer, I think their voice has a lot of weight. So I guess there's a difference between the current state of affairs and the steady state over time. But any public source effort has to pay attention to its constituents to decide what's important and what's not important. That goes for standards as well as features. And time will tell what becomes important and what's not.
TP/LT: Getting back to XML, XML solved some problems pretty well. It is a general purpose syntax that you can use to come up with tomorrow's features. You have all kinds of issues on defining and describing tomorrow's features' semantics, what it does, what it does not do, what its behavior is, what its exceptions conditions are. But XML solves the syntax problem.
So we believe in XML in that regard. And we're very, very happy that James Clark contributed XML Parser to mozilla. We think this is really cool. We've got like a definitive XML parser. We don't have to worry a whole heck of a lot about that.
As time goes on and XML moves this way or that way, we're pretty sure that Mr. Clark will make the XML Parser do the right thing.
TNC: Isn't that true of most standards? If there's a standard out there and somebody is willing to contribute code for it, as long as it's also possible to integrate it with the other existing modules, this person contribute to the project?
TP/LT: I love that model. I think it's really great. Unfortunately, not all standards work that way. A lot of standards are specs, and just a spec.
TNC: How about CSS Level 2? Or even level one, for that matter? What are your plans there?
TP/LT: Well, there seems to be a pretty broad support for CSS and XML based style sheets. I think there's some work in the next generation layout submission to support that kind of stuff. Mozilla's opinion, in our role as coordinators and stewards, is that we will facilitate and allow what the development community wants. And right now I think the best evidence of what we've got as request for support and style sheets is the code that's currently visible. If people don't like that, I'm dying to hear from them. I mean, that goes for a much broader array of topics than just style sheets. And anything that's out there that people think is wrong.
TNC: But there's currently no effort to make the browser CSS Level 2 compliant.
TP/LT: I'm not sure that that's correct. I think you need to look at the next generation layout stuff.
TP/LT: They've made a lot of noise about style sheet support. I actually haven't examined the code so I feel a little guilty about saying anything here.
TNC: Actually if you really have XML support you need some kind of rendering solution to display it, if you want to add presentation to your XML data.
TP/LT: Well, XML is nothing but a syntax.
TP/LT: It doesn't say anything about what you're going to do within that syntax.
TP/LT: I mean, you could come up with all kinds of wacky proprietary stuff, wrap it up in XML and you haven't really gotten anywhere.
TNC: But you need to associate it with style sheets for presentation, or some kind of rendering...
TP/LT: If you're going to do style with XML, yes.
TP/LT: You know, interesting would be -- way to answer to style sheet question that anybody can get the answer to the style sheet question is by looking where layout development is occurring within mozilla.org by going to the owner's page. So what you would do is you would go to the owner's page and you could mail a question to the layout guys or post it on their newsgroup, what are you doing with regard to this? And we're fostering a philosophy of living in a fishbowl. We did speak freely about it. I actually don't know the answer about what's happening.
TNC: Okay. Tom, Lloyd, we only have two minutes left. I do want to get also your comments on Java. Mark Andreesen called for developers to create an open Java implementation because obviously Sun doesn't seem prepared to do this. Where are we going there? What's going on?
TP/LT: Mozilla wants to make whatever java that can work, work. So our goal is to have a system where any Java VM will just drop in and work. We don't have our own Java VM. No one has given us one that we're allowed to distribute. So what we would really like to do is create a system where VMs can just fall in and work and we'll let the market fight the Java wars.
TNC: So you would just use whatever is available on the system.
TP/LT: That would be fine. It's up to the developers to turn around, ship a product based on either the Java VM that's available on the system or to ship their own VM. Either one should drop into and plug into the Mozilla code base.
TNC: I know your emphasis is not on a product but on simply providing the tools and the environment for people to maintain the source code and make additions to it. But when do you believe the first implementation of the Mozilla browser from this source track will be available?
TP/LT: There are some dates up there now I think Brendan posted that call for something in September? I think September. There are some dates on our website.
TNC: So coming up real soon then, a Mozilla browser. And obviously when it does come out it will be available across all platforms.
TP/LT: Right. If I can be allowed to toss one thing in to your listeners, the last few points that we went over, XML and style sheets, what we really want is participation. Anybody who has got an itch to scratch, by all means, mouth off, join in, come play along, and that's what it's really all about. And the more participation we get, you know, the more everybody wins.
TNC: The spirit of Open Source and mozilla.org. Tom and Lloyd, thank you very much for joining us today.
TP/LT: Thank you.
TP/LT: It's been a pleasure.