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!)
"Mozilla is an amazing and incredibly successful project."
If your soo sure, how do you explain this
I am all for open source, but when someone like AOL want's to exploite it for thier own profit or dump it, which would you really rather they did?
Maybe it would be good when AOL stops Mozilla. Because that would certainly mean that a lot of Linux/Unix-based volunteers would start developing their own Mozilla, based on the current sources, and give up all the Windows and Mac stuff. Then I would seriously consider to contribute. But I will never ever work with the Win32 API. I tried it once, and it so unbelievable ugly... under no circumstances.
Netscape can stop making contributions of Open Source code, but they can not take back what they've already contributed. Open Source developers will continue to use that, and will place their contributions under the MPL, preventing Netscape from reselling them under another license. The result will be an Open Source browser that competes with Netscape's own product.
Thanks
Bruce Perens
Bruce Perens.
It would be interesting to find out just how much the open source community has contributed to Mozilla. A /. poll would be good, I think... ask "how involved are you in the Mozilla project?"
I, like so many others, downloaded via CVS the whole seamonkey tree and tried to find my way through it. It was just so massive! For a week I did a "cvs update" every day and I noticed so many files were in motion that I couldn't tell what wasn't being worked on.
This may sound naive, but I think the primary reason Mozilla hasn't received much attention from open source developers is because there isn't a simple, graphical "map" that shows the progress of each section of code. I hope you can understand what I have in mind--it would look very similar to a real map but would be colored according to how much work needs to be done in each area. The areas would be zoomable to the point where if a developer wants to fix a specific bug, he just zooms in to the specific function.
I'm a developer who has precious little time yet has a lot of interest in seeing Mozilla completed under the current licensing model. Would you folks think this idea is worth the effort?
This should be a learning experience though. I don't think it is an opensource flaw so much as a netscape or mozilla flaw.
- It's been mentioned before, but it wouldn't compile at first. That is and was frustrating. Something that impresses me with most OSS/Free software is the remarkable clean build process. Mozilla didn't have that for a long time. I was very amped to start making tweaks but I didn't have the time to figure it all out, I just wanted "configure;make" like most other projects have. Maybe that was a poor expectation on my part, but I don't think so.
- Mozilla quickly splintered into countless groups and projects. The ports were easy enough to sort out but some of the other projects really confused me at the time. Again, maybe I had poor expectations but I've got a full time job and at best mozilla was going to be a spare time activity for me, I wasn't really motivated to figure out what was what and since I couldn't readily compile a lot of code...
- There were radical design shifts, I'm not sure where this came from. I agree with it and I think most of the community likes the idea of a mozilla component being available and componentizing the product but this is radically different from what they put out. Clear leadership is needed for that. I still don't know who's baby it is. I still don't know which baby it is that I want to jump in with, or are they not splintered any more? I've got things I would still like to do, I'd love to see GNOME and KDE components made out of it.. I kind of think Netscape had hoped to open it up and the world would just sort of know what to do and in 3 months there would be this radically different product. The code didn't compile and we were heading off into the night on a runaway train.
- Netscape really cut it loose after a short time, am I the only one who thinks Communcator 5 is going to be very different from mozilla? After it got off to a slow start, reading the newsgroups and listening to the "leaders" made it sound like the project was just floundering. I never felt like netscape was in on the project. I felt like they didn't see what they wanted in a few weeks and then bailed.
- Then the PR fizzled. Mozilla now is looking impressive. It's looking like a product, it's still rough and there is a lot of work to be done but there are areas to work on and things to improve and ideas to incorporate. I think a lot of us have dismissed it by now though. Some how the PR machine needs to generate that excitement again. We need some goals and some plans and wishlists, what are we aiming at, what needs aren't we filling? How can it be better? Someone will have to fork the code when mozilla get's to m8 or m9 and start working on a "new project" it will start to take off more then.
- The need isn't there. NS has been working very nicely for me. If I was browserless I'd be more inclined to perform miracles to make mozilla happen. At this point it's just a war of virtue. NS gave their code away and won my heart over, I had no problem using communicator because netscape "did the good thing"
I hope ESR makes some addendums to C&B, I also hope that the mozilla projects continues on. I think it is finally on a good track, it just needs to pick up some passengers and gain some speed.This is my signature. There are many signatures like it but this one is mine..
Netscape thought that they could go open source and suddenly get all the benefits of the Open Source Society. Unfortunately, it doesn't work that way.
:)
For people to support something that is Open Source, and do it for free, they must enjoy the work. If you don't make it enjoyable, then the people won't do it. There are lots of other Open Source projects that I want to work on and Mozilla is near the bottom of that list. I rather work on the Linux kernel or XFree86 or GTK+ or another project. Others may feel differently about this but only if they like to work on Mozilla.
I didn't join the Mozilla development so I don't know how enjoyable it was/is. Also, it takes time. Before you can help out, you need to know the system. Once you get a standard set of people who know the system, then improvements/bug fixes/ enhancements will come quickly. But you can't just release something Open Source and see the effect immediately.
Also, slightly off topic, but I worry that Open Source development will slow down drastically if there is a lot of Open Source projects. This will spread out the resources (people) and then the development slows down. The advantage of Open Source is that it is easier to work with something that is not a total black box. This is only true if you are a programmer and can understand the code. But that takes time as stated above.
I think that Netscape/AOL should give Mozilla more time, or at least keep it going. This way you can get a good set of developers. Also give some sort of compensation for those who submit a large amount of enhancments. Keep this going for the sake of Open Source, and you will benefit. Keep it going just to benefit, and you won't. I can't prove this, but the atmosphere is there. (what ever that means
Steven Rostedt
-- Nevermind
One of the reasons why it wouldn't compile, at least in part, is that if you look at the development environment for any major enterprise-level software project, it typically demands a very particular setup and environment to compile (i.e. you must be running the following apps with the following directory structure with teh following path and the following environmental variables just to get compilation, much less linking or debugging). Abstracting that away to a more general case of "I'm going to download the source and compile it because I'm bored" is a very very difficult proposition.
Most of the truly successful cases of open source projects have followed the "Release Early, Release Often" mantra. Perhaps if this is something that is that important to the community (which I think it is), it is worth starting from scratch. The problem is that starting truly from scratch would result in Mosaic, and it would take just as long to get something working. But in all likelihood the process and major contributors would be set by the time it got to have something useful in it, which would increase speed dramatically.
Kirk
I think that Mozillas biggest shortfall from my perspective is that when the initial source release came out, the code would not compile into a useful product.
While I was interested in attempting to revamp the bookmark code, it made no sense to me as I couldn't even get it to compile.
When Mozilla actually builds the foundation for an open source browser that is useable and that others can build upon, I might be interested in contributing.
Perhaps then it can meet the most basic Cathedral and the Bazaar requirements by my standards.