MozillaZine

Tree Closes For 0.9.8

Wednesday January 16th, 2002

Mozilla.org has closed the tree to approved checkins only, starting as of 12am Wednesday, and will do so until 0.9.8 has branched. 0.9.8 will have a variety of new items including new natively drawn widgets on WindowsXP, Mac OS X, and GTK, when you are in the classic skin (We will have more on this later, including screenshots); the addressbook was rewritten, and now supports printing, a new "Get Map" button allowing you to query for a map based on a card address, and other stability fixes; Windows MAPI support; and a huge amount of performance and stability work.

Many believe this is one of the last milestones prior to 1.0, and that Mozilla.org will actually have 1.0 following 0.9.9. 0.9.8 should branch sometime next week, with a release two Mondays from now. We'll keep you updated on both the branching and the release.


#63 Your arguments

by sab39

Friday January 18th, 2002 9:13 AM

You are replying to this message

Your first argument is valid, but presupposes that there is somehow a single unified voice that represents "mozilla's opinion". There have *always* been different opinions about this, and there always will be. Some people made the "CSS properties" argument, others said that it was technically difficult to implement, others (such as yourself) said it should be done regardless.

What has happened here is the fact that, as always in an open source project, he who writes the code makes the rules. A particular talented hacker who either believed from the start that this should happen, or was convinced of that argument by someone else, figured out how to implement it and went ahead and did so. All that's happened is a minor shift in whose opinion is most prevalent in the project - not some sudden, dramatic shift of a single, unified "mozilla.org opinion".

This is a very important point which is often missed by critics of open source projects. Unlike within a corporate structure, decisions are NOT "handed down from on high" but rather evolve over time based on the decisions of individuals who are writing the code. Some of those individuals are influenced by their employers, but even then they don't give up their right to their own opinions; they can always use their free time to implement things their own way if they want.

So instead of "the big argument against native widgets" that you describe, there were in fact hundreds of people who all had their own reasons for not personally choosing to work on native widgets. Some of them, even most, may have used a flawed argument about CSS properties. Others may have simply known that they personally didn't have the skills to do the work, or any number of other reasons. But in an open source project, as you've discovered, you can't simply say "somebody should do this" and expect it to happen.

And instead of a big sudden dramatic "position shift" as you describe, what happened was one person produced an actual implementation - that is, decided that the "somebody" should be *himself* - and impressed a bunch of other people enough with what he had achieved that his work was checked in, and is now being worked on by other people too. If, instead of "arguing this issue since 2000", *you* had been the one to actually go ahead and implement it, as Hyatt did now, and done it with as much elegance and flexibility, this change would almost certainly have happened in 2000 instead.

Your second argument has already been addressed but I'll do so again, just in case you missed it. It is the *theme* that gives the CSS declaration that says "render this as native". In fact, the modern skin continues to use the traditional, non-native widget style. So this gives theme creators the power to use native widgets if they want to, without taking away any options they already had.

Stuart.