Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Mozilla The Internet

Mozilla's Year In Review For 2003 192

An anonymous reader writes "Like last year, MozillaZine has published a review of Mozilla's world in 2003. Obviously, the year was dominated by AOL's decision to murder Netscape (though various acts of 'brand necrophilia' will ensure that the Netscape name lives on in one form or another). This, combined with Mozilla Firebird's and Mozilla Thunderbird's steady progress towards replacing the Mozilla suite, made 2003 very much a transitional year for the open source project. Other memories to tell your grandchildren include mozilla.org's fifth birthday, the new roadmap, the Firebird name debate and a new chapter being added to The Book of Mozilla."
This discussion has been archived. No new comments can be posted.

Mozilla's Year In Review For 2003

Comments Filter:
  • by Yorrike ( 322502 ) on Thursday January 01, 2004 @09:10AM (#7852212) Journal
    There are many rendering problems with /. on my build of Firebird (0.7, Xfree 4.3), but I believe this has more to do with the fact that /.'s html is a hack on a hack on a hack.

    When they decide to bite the bullet and switch away from a table based layout to a CSS based one, rendering problems will disappear for everyone who's bothered updating their browser in the last 2 years.

  • > ...they failed completely to incoperate the rising new mark-up technologies like XML-Signature or WebCGM. If this development continues this year, Mozilla might lose it's technical lead to IE or Opera.

    Are you just pulling this stuff out of your arse, or what? Neither of these are new (WebCGM has been around since '99), both are fairly irrelevant, and WebCGM is a binary format in any case.

    Given the *cough* rapid pace of MSIE development *cough* these days, if Mozilla stood stockstill for the next two years, it wouldn't lose any ground to IE (which still doesn't support all of DOM Level 2), and Opera is also still playing catch-up, although it's farther along than MSIE.

    It would be nice if they'd start including SVG support in the standard releases, though. Especially since the Adobe SVG plugin for Moz/NS is broken and appears likely to stay that way for some time.
  • by Zontar The Mindless ( 9002 ) <<moc.liamg> <ta> <ofni.hsifcitsalp>> on Thursday January 01, 2004 @09:37AM (#7852264) Homepage
    > Mozilla will be a thousand times more useful if it could offer an IE-compatibility mode (Javascript model, plugins) which works on Unix platforms.

    NoooOOOOoooOOooOoooOOO!!!!

    Then Microsoft wins and standards don't mean anything. The task which must be accomplished is to get site developers to code to standards, in which case 90% of the compatibility issues disappear (and the Web becomes about 75% safer due to the disappearance of ActiveWreX crap).
  • by tomstdenis ( 446163 ) <tomstdenis@gma[ ]com ['il.' in gap]> on Thursday January 01, 2004 @10:13AM (#7852350) Homepage
    Why people stick with MSIE [for home use] is mostly why many peole use MS MSN for chatting instead of Gaim or trillian or amsn or ...

    It came with the OS install, does what they want and they don't see any added benefit of another install. Sure Gaim is cooler than MSN but if all you do is chat on the MSN protocol why bother?

    Similarly, sure tabs are cool but if you never use them who cares? Personally I do a fair bit of research and I find no use for tabs. I can only read one screen at a time so I don't care for tabs.

    MSIE + google bar is a decent experience. I get no annoying popups and a browser which for all its faults works reliably.

    Tom
  • Re:Although... (Score:4, Insightful)

    by macshit ( 157376 ) <snogglethorpe@NOsPAM.gmail.com> on Thursday January 01, 2004 @10:18AM (#7852365) Homepage
    With that being said, one could quesiton whether Mozilla has a relevance outside developing a rendering engine. GNOME has standardised on Epiphany for the browser and Evolution for the eMail/Contact manager, so where does the Mozilla foundation.

    Keep in mind that `Gnome has standardized on' is not equivalent to `users will use.' I've used epiphany recently, and well, basically it sucks compared to firebird.

    I'm sure Gnome wants to have a `native' browser, just so there's something in the standard install, but really, epiphany has an incredibly long way to go before it's anywhere near as usable as firebird (and given the current religion at the Gnome project, they may never let it get there).
  • by Ender Ryan ( 79406 ) <TOKYO minus city> on Thursday January 01, 2004 @10:37AM (#7852415) Journal
    I think there is plans to still ship a whole suite of apps in one package, except now they'll really be separate apps. The distinction shouldn't get in the way of using it like you always have.

    Really, it will be much better.

  • by Haeleth ( 414428 ) on Thursday January 01, 2004 @10:43AM (#7852429) Journal
    Personally I do a fair bit of research and I find no use for tabs. I can only read one screen at a time so I don't care for tabs.

    Well, that's your choice and (IMO) your loss; at least you know the alternatives exist, and you obviously considered what would be best for you before deciding to stick with IE.

    I can only read one page at a time, too, but with tabs I can have the next X pages I want to read loading in the background while I read the current one. I think I've probably saved more time that way than I spent installing Firebird.

    Now, if only I was doing research, instead of browsing Slashdot articles and webcomics... ;)
  • Not to mention... (Score:3, Insightful)

    by Kjella ( 173770 ) on Thursday January 01, 2004 @11:27AM (#7852578) Homepage
    The task which must be accomplished is to get site developers to code to standards

    Not to mention tools that code to standards. For all those of us that don't want to write HTML tags (even if we know how), that is the main issue. Because most sites I see that render incorrectly, I kinda doubt there's any real "web developer" behind that wrote the code. Think more code monkey with a WYSIWYG (on IE) HTML editor...

    Kjella
  • by jonadab ( 583620 ) on Thursday January 01, 2004 @11:36AM (#7852616) Homepage Journal
    > Personally I do a fair bit of research and I find no use for tabs. I can
    > only read one screen at a time so I don't care for tabs.

    You must have broadband. For dialup, tabs are vitally essential, because it is
    critically necessary to be able to queue a number of pages, do something else
    (e.g., read an already-loaded page) while they load, and then get to them when
    they have finished downloading. You can *theoretically* do this with new
    windows, but who wants 30+ browser windows open, when you only ever intend to
    look at one of the pages at a time? Plus, most window managers (including, I
    might note, the one in Windows) don't handle switching between windows in a
    fashion that preserves the order of the windows, which makes it a real pain
    to queue pages and read them in order (which you want to do, because the page
    you queued first is most likely to be finished loading). The tabs are a real
    life saver for this sort of thing.

    Tabbed browsing also makes web-based discussion fora like slashdot and
    perlmonks viable. Before the advent of tabbed browsing, I found these things
    totally unusable (over dialup, at any rate) and stuck to usenet. Tabbed
    browsing has made it possible for me to mostly migrate from usenet over to
    web-based discussion fora.
  • by oconnorcjo ( 242077 ) on Thursday January 01, 2004 @02:34PM (#7853666) Journal
    The development team focused mainly on minor technical and legalistic issues like the naming of firebird, code clean up etc. But they failed completely to incoperate the rising new mark-up technologies like XML-Signature or WebCGM. If this development continues this year, Mozilla might lose it's technical lead to IE or Opera.

    I will bite the Trolls bait:
    What the !@#$ are you talking about. One of the reasons the original Netscape code was dropped in favor of starting over was that the original code was a total mess. I should hope Mozilla would not fall into that trap again. Cleaning up code and fixing bugs should be of a higher priority than implementing obscure features only a handfull of people know about. Clean and well working code make it easier to implement new features while also making it easier for new developers to contibute to the project. As soon as those obscure features mentioned above really become desired by a substantial subset of developers/users, I am sure someone will come along and implement it (especially if the current code is laid out well).

  • Even worse (Score:4, Insightful)

    by axxackall ( 579006 ) on Thursday January 01, 2004 @02:51PM (#7853800) Homepage Journal
    It's even worse:

    SVG development is still going nowhere, while Calendar development has just stopped. No need to mention that nobody in Mozilla development team understands the importance of MNG and XForms. In Bugzilla you can even find their comments saying that "HTML forms work, what the reason for Xforms?"!

    So, Mozilla becomes the best web browser accoridng to requirements of mid-90s. However, development teams of other browsers (read: IE and Opera, not sure about Apple) are more informed about web-browser requirements of mid-00s. No need to predict who will be a winner.

    I love Mozilla (both Suite and Firebird) and I love XUL, and that's why it's so sad to see that my favorite browser is a big loser.

  • Re:Even worse (Score:3, Insightful)

    by BZ ( 40346 ) on Thursday January 01, 2004 @04:42PM (#7854511)
    I think all the Mozilla developers fully understand the usefulness of XForms. What XForms proponents fail to understand, it seems, is that XForms relies on a whole slew of other XML technologies, many not well-supported by off-the-shelf XML parsers, that XForms is very complicated to implement, and that XForms is very difficult to author (instead of making the easy things easy and the hard things possible, it focuses on making the easy things and the hard things equally hard (a little easier than doing hard things with HTML forms, to be exact)).

    So Mozilla developers would be just fine with having XForms support, but they are not about to write a new XML parser and hundreds of thousands of lines of form implementation code just to add another feature that almost no one really uses (quick, how many sites use XML documents at all? Answer: none that want to work in IE).

    This is not to say that XForms would not be accepted into the tree if someone implemented it. It probably would be. It's just that spending time now reinventing wheels to implement XForms is pointless -- it can be done more quickly when the XML parser Mozilla uses (expat) is updated with the necessary features by its own development team...
  • Re:Although... (Score:3, Insightful)

    by swillden ( 191260 ) * <shawn-ds@willden.org> on Friday January 02, 2004 @01:37AM (#7857881) Journal

    The unfortunate thing is that there is now a lack of developers but hopefully with the new political structure, more developers can be encouraged to help out with the same vigor and determination ones sees in other projects, for example, FreeBSD or the Linux kernel.

    The problem with the historical lack of non-Netscape/AOL development in Mozilla is partly political, but I think the real reason was most definitely technical.

    There is an interesting phenomenon/problem that often arises with large object-oriented projects, and the Mozilla codebase can be used as a case study for this phenomenon.

    OO is valuable -- don't get me wrong; I got hooked on C++ and Objective-C in 1990 and I've never seriously looked back -- but developers can and often do get carried away with abstraction and data hiding. I certainly do it! And in a large, long-lived project with a fairly small and tight-knit team of developers getting "carried away" often turns into a severe case of frameworkitis. Everything has to fit into a powerful, flexible, general-purpose framework. Any time a bit of code starts looking complex, it's time to design a new infrastructure for decomposing and abstracting the elements of the problem being solved. This approach can produce some very nice, very clean code, but it does so at the expense of creating a huge, complex mass of abstractions which must be understood, in all their subtleties, before the code can be understood at anything more than a very superficial level. And forget trying to write new code within the system without a massive investment of time spent exploring the marble hallways.

    Open source software has a natural counter to this tendency: Since very few (if any) developers are in a position to devote their whole working life to this beautiful and elegant monstrosity, the code must be accessible to competent but casual readers/writers. If you want to get contributions, the general structures and key abstractions have to be understandable in a few minutes, and the details of any particular sub-module have to be understandable in a few evenings *at most*.

    Until AOL shut everything down, Mozilla was a project with a dedicated, intensely focused team that was very capable of understanding the structure they and those who had come before them had created. As just about anyone who tried to contribute to Mozilla learned, just getting yourself educated enough to be able to contribute was a massive task, even if you were a highly competent C++ developer. I wanted to add a couple of small features to Mozilla, but gave up because I simply couldn't afford the investment of time. So I implemented them in Konqueror in a couple of evenings.

    What we're seeing now, with the rise of Firebird and Thunderbird, is the morphing of the Mozilla codebase into something that is easy to get your fingers into. Something that can work as an OSS project. By stripping Mozilla down to bare bones, keeping just the core engines and building everything else back up in a more transparent and accessible structure (though one that may be less flexible, extensible and... pretty), the software is becoming something that can be more easily enhanced.

    If you read that last sentence carefully, you'll notice a paradox... how does making the code less flexible and extensible make it more easily enhanced (i.e. changed and extended)? The answer is that it doesn't, really. What it does do is exchange simplicity of development for accessibility, and making the code accessible to many more developers turns out to provide greater leverage than making the development easier for a small set of developers.

    The Mozilla codebase is a study in how, exactly, a cathedral is different from a bazaar, and how one can or can not be turned into the other.

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...