Author: JT Smith
The Mozilla project holds an almost legendary status in the Open Source world. On the one hand it’s faced defections of major contributors,
and critics accuse the project of being buggy and behind schedule. On the other hand, the 4-year-old project serves as the foundation for Netscape, the only serious competition to Microsoft Internet Explorer. And if you link to a story calling Mozilla buggy and behind schedule, watch out for the email from fans as zealous about their project as Mac users are about PPC architecture.
On February 22, the project released a description of its 1.0 development cycle, suggesting the elusive 1.0 release is not far off. Just before that, the team released an
NewsForge: Tell those who aren’t familiar with the project about the Mozilla community. How many developers are currently working on it? Why are developers drawn to the project?
Blizzard: It’s hard to gauge how many people work on the Mozilla project on a day-to-day basis, but I can say that there are several dozen people working
on the project full time. I’m not just talking about programmers here,
either. This includes project management people, QA people and people
that fill various other important functions as well. Coders do not live
in a world on their own.
Most of those people whom I would call “full time” work at some company
that has a vested interest in the Mozilla project. In my experience
there are a few different kind of people who are drawn to the project.
You’ve got your hacker types who just want a browser that they feel
empowered using and want to make different in some unique way. You’ve
got students who are hacking on the browser because they want to learn
something for school. And you’ve got businesses supplying manpower
because they have a vested business interest in the shipping browser.
Of course, there are those who don’t fit into any sweeping category, as
well who might be doing it for altruistic reasons or because they are
experiencing a bug that’s really bothering them and they have the skills
to fix it.
Baker: A recent study of Mozilla found abut 100 different developers check into the source tree in a month. There are other developers working who are not checking in because they do not have CVS access. So I would say that there are a couple of hundred rather than a few dozen working on the code. Of course, many of these developers are not working full time on the code, are working on particular areas of interest to them, and may contribute infrequently.
There are also the QA contributors, who are actively working on the project but not checking in code. The same study mentioned above found that during the week we released 0.9.8, there was a daily average of 5,000 unique visitors to Bugzilla. A mozilla.org Milestone release now get close to 200,000 downloads, so there are a huge amount of people looking at the Milestones. Of course, the core of active QA contributors is much smaller, in the “several dozens” category.
Another element of the Mozilla community is the group of people building applications on top of Mozilla, or using Mozilla as an application framework. Many of these projects are hosted by mozdev.org. Mozdev.org itself is a project created by two Mozilla contributors, and provides infrastructure for Mozilla-based projects that aren’t in the mozilla.org CVS repository. Occasionally a project will begin on mozdev.org and make its way into the mozilla.org tree. “Tabbed browsing” in an example.
Another element of the community is the set of projects and companies shipping Mozilla-based products. A partial list of these projects can be found at http://www.mozilla.org/docs/ora-oss2001/state-of-mozilla/04_Out_and_About_8.html. This list is incomplete as it was compiled in June of 2001, but gives an idea of this community.
NewsForge: It seems from the outside that the Mozilla project is run kind of like a
business more than many Open Source projects. Is that a correct impression? If
so, is it because Mozilla comes from those Netscape corporate roots, or because
the project is just so big it needs more organization?
Blizzard: I don’t think that the comparison that we’re run like a business is a
fair one. We don’t have the same goals, that is, we aren’t doing this
to make money. I think that you might have that impression because we
do operate in a highly structured way.
We are forced to have that structure in place because of all of the
interests that we have to balance. We’ve got some pretty large
businesses who are using our project as part of their products so they
need to be able to depend on us to maintain stability, have achievable
goals and be able to plan ahead. Plus, the fact that we have more than
one of these groups to work with at the same time means that we have to
find the common ground that makes it possible for all of them to work
together in order to make the project successful.
We are set up with a good bit of structure, but at the same time it is
set up to work as a system of decentralized management. We don’t do
anything like actively working a developer’s bug list, except in the
rarest of circumstances. We depend on strong code owners to make the
best decisions for their modules and make sure that they are aware of
the schedules and try to get them to keep those schedules in mind when
accepting patches or working on changes for their modules.
Another reason that we have to be so structured is technical. We’re
trying to build highly portable code here that runs on a variety of very
different platforms. This means that when a developer is writing code
they have to be cognizant of what it takes to write cross-platform code.
When they check that code into the tree, they have to make sure that
the code hasn’t broken any of the other platforms that Mozilla runs on.
They are responsible for that checkin and any of the fallout that
occurs as a result of it.
The final reason why we have to be so organized is because of the sheer
size of the code base. We are constantly striving to create modules
with well defined interfaces that are independent of each other but it’s
a hard task and occasionally takes a back seat to getting something out
the door that works. Because of these inter-dependancies, we have to
enforce some structure to make sure that people don’t step on each
other’s toes too often.
NewsForge: How many lines of code is Mozilla now?
Blizzard: A completely non-scientific count shows about 14,500 files with about 4.8 million lines of code. This is including white space, licenses, xml
files, some build files, and rdf files as well, so it’s kind of
misleading. The real number of lines of code is probably somewhat smaller.
NewsForge: You say you’re moving toward the 1.0 development cycle. Any estimations of when 1.0 comes out, or is it too early to say?
Blizzard: Our roadmap (http://www.mozilla.org/roadmap.html) has some good clues as to when the 1.0 release will be blessed. Assuming nothing goes terribly wrong, we should be branching for 1.0 around the end of March with a release some time after that. It could be a few days or a few weeks after we branch before that particular release will make it out the
door. It’s hard to say before we get there since it really depends on
the quality of the code and how far we are from having the bugs that we
care about squashed.
NewsForge: Will there be major changes from the 0.9 versions, or more fixing of detail stuff? What will be the difference between 0.9.9 and 1.0? Is the that step more
evolutionary — essentially a number change with small fixes– or more revolutionary?
Blizzard: The changes for 1.0 will definitely be evolutionary in nature. If
you’ve seen the 0.9.8 and the upcoming 0.9.9 releases then you’ve seen
most of what 1.0 will be. Our main task between 0.9.9 and 1.0 is going
to be fixing bugs. Revolutionary changes usually introduce bugs and
that’s exactly what we’re trying to avoid.
NewsForge: I guess I’m asking is, what’s the Big Deal about a 1.0 release in this case?
Blizzard: The big deal about the 1.0 release is how we’re going to be treating it
in the future. I should probably talk about what we have done in the
past with milestones in order to get some perspective.
In the past milestones have fallen into two categories. Many milestones
have been “fire and forget” in nature. That is, we get the tree stable,
branch, fix some more, and then release and keep right on running along
the trunk doing development. There have been some releases where we
have left the branch open after the initial release because one or more
of our contributors have wanted to do additional work on that code in
order to build it into a release. This is why sometimes we have had
releases ordered like this: 0.9.4, 0.9.5, 0.9.4.1. The 0.9.4.1 release
is off of the 0.9.4 branch, but baked a lot longer than the 0.9.4
release did and is generally more stable than the 0.9.5 release was.
1.0 is going to be different because the branch is going to be long
lived. We expect to keep 1.0 in shape for probably a year, although I’m
not going to commit to anything at the moment since we’re not completely
sure when we will stop supporting it. This means that you will see bug
fix releases off that code well into the future. 1.0 is about long-term
viability, not any specific set of features. We’ve discovered that
because we are limited to where our contributors take us, we can’t be as
feature driven as we like. This means that our releases are really
based on when the branch was made in the tree with the features it
contained and how long we want to keep maintaining it.
Another aspect of the 1.0 release is it’s going to be one of the first
releases that’s going to include API stability for some frozen APIs that
are used by external users. Some of these people include plugin vendors
and people embedding Mozilla into their products. We’ve already got
some APIs that have been frozen. 1.0 will just have more of them,
that’s all.
Baker: The Mozilla Roadmap has been updated to show our thinking on Milestone releases after the 1.0 release. We’re planning a series of quarterly releases. Each release will have an alpha and beta phase, followed by the final release. This way we hope to have destabilizing changes land in an early phase of the Milestone, and have time to shake out the bugs and release a good quality Milestone.
NewsForge: What are the major issues left to be resolved before the 1.0 release?
Blizzard: We’ve got a good number of issues left to work on before we can release 1.0. The biggest is to take the list of bugs that are assigned to the
1.0 release and figure out which ones we care about, which ones we
definitely need, which ones we don’t care about, and keep that list up
to date as more bugs come into the system.
We also have to work out tree management rules for the 1.0 branch and
the trunk through that milestone release. We’ve got most of that
hammered out, though, that’s just a question of posting a policy and
getting feedback on it.
Another aspect of 1.0 is trying to work with all of the various vendors
to make sure that they are onboard for the 1.0 release. This means that
they are aware of our release schedule, how we want them to participate,
and make sure that they understand what this release can mean to them if
they want to make use of it.
All those aside, it’s just a question of doing the day-to-day work to
get to the 1.0 date with bug fixes in hand, doing constant measurement
of performance and stability.
NewsForge: The 1.0 management plans talk about stability being the major goal. What stability concerns to you have about the latest 0.9 releases?
Blizzard: The last few 0.9.x releases have been pretty stable, at least in my
opinion. The kinds of bugs that we have seen have been minor in nature.
We haven’t seen the kind of big re-architecture bugs that were present
in previous milestones. I don’t expect to see any more as 1.0
approaches, either.
NewsForge: What are your plans when 1.0 comes out? A big party? If so, how does a big party happen with hundreds of developers spread out across the globe?
Blizzard: Well, I don’t know what other people are doing but I’m going to take
some time off if I can. I don’t know of any solid plans at the moment.
Baker: Mozilla.org staff hasn’t spent much time thinking about this. The Mozilla community in Japan is way ahead of us, and it may be that the most well-organized Mozilla 1.0 celebration is in Japan. These things have a way of coming together at the last minute, so we’ll see what happens here.
NewsForge: There have been reports of how many bugs are in the Mozilla code. Can you explain Bugzilla reports and how much or little they impact how well Mozilla works?
Blizzard: Bugzilla is really the heart and soul of the Mozilla project. It’s
where developers interact with each other and external folks, it’s the
tool that we use to track releases, and how QA gets its work done. It’s
where most of our peer review and code review take place and where
architecture issues are hashed out. Simply put, when Bugzilla doesn’t
work, no one else does either.
Bugzilla reports are issues that people have with the project. They can
be filed by developers and end users alike and can either encompass
larger issues, like “support CSS2” or something that is as simple as a
problem someone is having, like “Mozilla crashes when I visit page xyz.”
The are usually targeted at specific modules within the code and
are assigned to the owner for that code.
When a bug report comes in, that bug is automatically assigned to a
specific owner based on a guess made by the bug reporter as to where the
problem might be occurring in the browser. That owner then has the
responsibility to determine if the bug report is valid and whether or
not it needs to be assigned to someone else, to make sure that the issue
is addressed, much like a sieve.
Once a bug is solved through a patch, that patch is reviewed by code
peers and is checked into the tree. The check-in message includes a
reference to the bug so if you are looking through the code, you can
find out where that code came from, who wrote it, who reviewed it, the
reason the code was checked in and all of the discussion around that
bug. Bugzilla is probably the most important tool that we have in the
Mozilla project.
That’s probably one of the reasons why people see so many bugs. We run
everything through Bugzilla. In addition, with this much code and this
much functionality there will be bugs, and lots of them. It’s as simple
as that.
NewsForge: What happens next after 1.0 is released? Do you all take a break or get right back to coding for 1.1?
Blizzard: Our post-1.0 plans are still pretty hazy at this point so anything that
I said in response to this question would be all smoke and mirrors.
That having been said, I think that we’re going to make sure that any
larger development takes place on the trunk of the tree to bake for
longer periods of time with good fixes being committed back to the
branch. So, the trunk of the tree is where the testing takes place and
will always be more unstable than the maintained branch.
NewsForge: What would you like Mozilla to include that probably won’t make it into 1.0? What’s next for functionality?
Blizzard: Oh, there are tons of blue sky things that I would love to have for
Mozilla 1.0, but I’m just one man and can only do so much coding. It’s
up to everyone else through their effort to determine what features I’m
going to see for the next release.
I think what you’re going to see is more of the same, but faster and
with more stability. There are lots of small features that people might
be adding, but I can’t see anything earth shattering at this point.
We’ll see what people come up with.
NewsForge: What’s the ultimate goal for the project? If you could see into a crystal
ball five or 10 years from now, what would you hope for Mozilla?
Blizzard: I would hope that Mozilla would be at least partially responsible for
the de-monopolization of the Internet. That is our ultimate goal.
Category:
- Open Source
