Slashdot Mirror
AOL Considers Ending Mozilla?
Wonko42 writes "Netscape is thinking twice about continuing to use Mozilla.org as the main tool to develop Communicator, and well they should. The project has received very little support from the open-source community, and the delays have been astronomical. While Netscape isn't sure that they could undo the open-source status of the browser, they're considering their options carefully. Also, according to the article, Communicator 5.0 is set to ship in December. "
That fact is, developing a valid and correct CSS browser is a very complicated feat that is not easily distributed amongst thousands of developers like Linux.
Expecting an army of OSS programmers to rescue Netscape was wishful thinking. Netscape was a poorly managed company and their development continues to be poorly managed. I mean, they *JUST* instituted milestones a few months ago. And they introduced and reintroduced several designs at the last minute (communicator, vs apprunner, vs XUL)
Slashdot users might have a hard time believing this but not all problems are horizontally scalable. (I say this because Beowulf rears its head way too much)
For instance, as mentioned, a team of chess players don't play better than a single one. A million OSS programmers are not neccessarily better than a team of 5 dedicated ones.
Linux can easily be decomposed into thousands of independent modules and utilities which can be maintained separately. But a rendering engine is a highly interdependent piece of code with a combinatorial explosion of use cases, where any change propagates throughout the entire system and requires reunderstanding how the flow works.
Thus, if an outside developer patches some code, understanding what the patch did may require a lot of work in and of itself. Just like understanding why a chess move was made by someone may be very difficult and affect your game plan well into the future.
Most Linux code isn't this complex and I would say that the most successful browser projects have been produced by highly cohesive small teams working together (ala Opera)
What does this mean? I believe the biggest contribution the OSS community can make to Mozilla is testing and feedback. I believe it is futile for them to get involved trying to develop the core display engine.
Oh, and before someone chimes and in and points to compilers like GCC as an example of complex software in the OSS community, keep in mind that compilers are taught as a standard course for CS students and there are well known textbooks on how to produce compilers (Dragon Book). On the other hand, rendering engines are not taught as part of any standard curriculum and there is little literature on the subject, so most people have to reinvent them.
When Mozilla does get released, I believe the OSS community will produce one thing more than anything else: Thousands of useless themes and graphic variations of the interface ala Desktop Themes, Winamp Skins, etc.
Conclusion: There are some problems that DON'T work very well with an army of people contributing to them, and in fact work better when a small closeknit team of competent people TUNE OUT everywhere, hole up in a garage, and pound it out. After its done, it can be released as OSS and let the legions of lemmings pound out bugs and contribute to featuritis.
The lack of huge well-produced office applications, games, and browsers from the OSS community, and the proliferation of small, simple, command line utilities and applets is a testament to the fact that OSS doesn't handle intrinsically complex (those architectures which cannot be decomposed) applications very well.
Beware, the story above is MAJOR FUD!
Anyone even remotely involved in the Mozilla project knows that what is claimed above is completly untrue.
Everyone is quick to dismiss Mozilla as a failure because of the lack of outside involvement and time it's taken, but that is so so untrue. The reasons for this are simple and have nothing to do with the viability of the project, in fact, they prove how viable of a project it is!
Mozilla has taken so long because less than a year ago they basically decided to throw everything away and START OVER, yes, that's right, start pretty much from scratch. This means completly redesigning the entire architecture and reimplimenting it according to those new designs. The fact that they have a usable browser that is quickly approaching completion in less than a year is nearly HEROIC!
The reason for the dearth of outside involvement is fairly simple to explain... it's complex, it's a rapidly moving target, and everyone who can help others jump in are too busy to do so. Very very few people could just download the source for this beast and be able to start hacking it, and even if they could, it's likely to change in a week or two.
Mozilla is an amazing and incredibly successful project. The tools available at mozilla.org and the modularity of the design are simply generations above and beyond any other open project ever attempted. In time everyone will start to see this, go check it out now and start getting involved now before the wave!
Mozilla's cross-platform story is one of the strongest parts of our charter, right up there with commitment to open source and a love of sugar. You'll have a hard time finding anyone to apologize for it. (And it does go beyond Unix, Windows and Mac: BeOS, OS/2 and QNX are well-represented.)
The vast majority of the Mozilla code is cross-platform, with per-platform differences abstracted under NSPR, widget and gfx code. What were you trying to work on that was in platform-specific code?
If you have a patch that you want to put in, and you don't have the ability to test it on other platforms, please send it along. File a bug describing what you're fixing, and attach the patch to the bug. Look in the owners list and send your patch to the owners of the affected module(s). If you do that and aren't happy with the results, please mail me.
Lots of people manage to work successfully without direct access to the other platforms; I don't have Windows installed here either, and I do just fine. We can find you ``platform buddies'' to help you check your code on other platforms, if need be.
What open source projects do you contribute to? Which ones have a small enough codebase and narrow enough platform focus to suit you?
I keep hearing in articles and here on slashdot that Mozilla doesn't have any external developers, and I'm starting to wonder where it comes from. There are 53 developers outside netscape.com with direct checkin privileges to the CVS tree as of last Tuesday. I sure hope they -- and people like Chris Nelson and L. David Baron and Jeremy Lea and Bert Drehuis[*] who don't have CVS access but do contribute in very real ways via patches and quality bug reports and advice -- don't take offense at this denigration of their efforts. (Even Mr. Baratz's own developers are working on Mozilla -- the Blackwood team are working on OJI and XPCOMJava connection technology.)
[*] And others whose names elude me, in my slightly adrenalized state. Apologies to the dozens I've forgotten, I really do love you all.
In addition to these major players, more than two thousand (2337 as of right now) bugs have been reported by people not at Netscape and subsequently resolved. (Many of those bug reports have patches attached by the reporter or other ``external'' contributors, but I can't pull those stats up right now.)
How many ``external developers'' is enough? If Netscape suddenly fired 2/3 of their Mozilla developers -- taking them down to about 35 -- would Mozilla all of the sudden be a greater success? (``But Ironhead, most of the developers work for Netscape!'') Literally every week, more developers apply for CVS access and get accounts to check into the tree -- we've more than doubled in the last few months. I can't speak for Netscape/AOL's HR policy, but if they start hiring at that rate I'll be really surprised.
What needs to happen to get more people involved? Answers like ``I feel like Netscape's pawn'' and ``the code is so big, it makes me afraid'' don't help me -- I'm not going to get rid of Netscape's developers, and I'm not going to throw out code -- but good, concrete suggestions on what would make you want to contribute are always welcome.
As a minor point of fact, nobody at Netscape, AOL or Mozilla has said anything about making Mozilla's development less open, and I can honestly tell you that this press release is the first thing I've heard about anything of that nature. It wouldn't surprise me a lot to discover that Mr. Baratz was talking out of an orifice that wasn't his mouth. (His left ear, of course.)
(You're making a lot of often-made objections, which is actually sort of handy: I can get my responses to all of them in one place.) That the plugins are part of the source tree is not a very damning observation, I don't think. Some build mechanics to permit you to build ONLY select portions of the code would be a nice addition, I agree, but it hasn't been a priority so far. We're taking patches, of course, and people have been discussing a SeaMonkeyBase CVS tag that would allow you to pull without the optional componentry. FWIW, the GIMP source tree also contains a fair number of plugins. (The Linux kernel is even more similar to Mozilla in this area, in that it contains various optional modular bits scattered all over the source tree.)
As far as using third-party components:
- Using GTK on non-Unix platforms was something that even the GTK authors counselled against. Making GTK work on the Mac would be a difficult and time consuming thing, and then you get to the best part: GTK widgets aren't suitable for our HTML-display purposes. You can't do all sorts of things that you need for HTML4, like partial opacity, and there isn't complete Unicode support (a major requirement, which is coming in GTK 1.3, too late for our 5.0 plans). So we really had no choice but to render our own widgets. Sorry, but there was lots of discussion about this in the newsgroups months ago, and that's how it turned out.
- Using libxml isn't really an option at this point, but we _do_ use an external XML parser: expat existed before Mozilla, and is being used by other projects.
- Um, pal, we do use the system libgif and libpng, if they're of the appropriate version:
/usr/lib/libpng.so.2 (0x4000b000) - There are no cross-platform graphical mail/news readers that I know of, and besides -- you can implement the required interfaces (not many: just a mailto: handler and some logic to get yourself in the menus) and have it call out to mutt or Eudora(tm) or whatever turns you on. (As an aside, you could do that in later 4.0x/4.5 incarnations as well. There's sample code on developer.netscape.com that shows how.) Netscape decided that they wanted to spend resources on developing a cross-platform, standards-based, etc., etc., mail/news client, so they did that.
So, I'm glad we think alike: using suitable existing alternatives is a great thing. But where they're not suitable, we make our own. Not a lot of choice there.[shaver@loonie:components]$ ldd libnspng.so
libpng.so.2 =>
Again -- research! =) And the JPEG library in Mozilla is actually owned partially by Tom Lane of JPEG Group fame, so if you send patches to the canonical libjpeg people, even those without an appropriate version will be able to take advantage of them. (Similarly with libpng and libgif, I believe.)
Now, your objection to having a mail/news client at all is a bit troublesome: are you saying that it was a failure of Mozilla that Netscape wanted a mail/news client that was cross-platform and tightly integrated, etc.? Perhaps you'd have had them work on other things, but then perhaps Netscape would rather have had you hacking on Mozilla for the past year, rather than whatever it is you were doing instead.
As far as ``a Java-specific-interface'', I'll agree that OJI is designed to allow pluggable JVMs, yes. I'm not sure why that's bad; the network protocol API is designed to allow plugging network protocols in as well: that's how those things are designed. There are a lot of rather generic and flexible interfaces in the Mozilla client, though -- what would you like to plug in that you can't? We'll almost always take patches to add better modularity.
(Lots of people will say ``you should be doing this instead of that'', but then...they can't help do that because they don't have the time. Kinda frustrating. At the end of the day, the person writing the code makes the call, though Mozilla exerts influence where it can to make sure that the right thing for the code wins the day. If you've got strong opinions about things, come to the Mozilla newsgroups and share them. It's getting late in the game for major design shifts, but there's still time to make your voice heard in many areas. C'mon out!)