Slashdot Mirror
Mozilla at One: An article by Frank Hecker
thaths writes
"Frank Hecker, the person who wrote the paper that
led to Netscape's release of the source code, has written
a birthday piece on Mozilla ,
"
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
I'm confused. I thought Cathedral and the Bazaar was the paper that led te Netscape's release of the Mozilla source. CandB was by ESR. Has the poster misidentified the paper, or is there another paper I don't know about?
--JTWell, if you only give me the XOR there, I'd also prefer a core group of savvy engineers. But if I could have both, I'd jump at the chance. God knows some of the stuff I've written professionally could have used a hundred extra eyeballs, even though it was good enough for a corporate environment. Most of my early ('96) stuff would have brought me acute embarrassment if the source was freed... and yet, frighteningly enough, it's still being used because nobody's bothered to do better.
So, yes, I guess corporations aren't in style on /. Perhaps it's because corporations tend to settle for sloppy code where they can, and the average FS developer is something of a perfectionist?
Or maybe we're all commies. :)
--
--
#define private public
I had the 'opportunity' to take a look at the latest version of AOL a weeks back. For the most part, it was exactly the same as the version I ran on my Mac LC (for about 3 weeks) in 1990, except the graphics were bigger. Not very much progress for 9 years.
AOL's problem for the last few years has been scalablity, and I'm sure that there aware that the only real solution is to junk their current client-server architecture and move to more web-based solution. This is going to take an excellent HTML renderning engine that is very customizable.
I guess that Mozilla is one of the big reasons AOL bought Netscape. That and a bunch of very smart server software engineers that can help them re-architect their network.
--
Business. Numbers. Money. People. Computer World.
Once there is an open Communicator 5 out, I'm sure that people will be all over that code like flies on you-know-what.
The big problem seems to be (as the Halloween document states), who wants to volunteer to do QA Engineering on things like the rendering engine and the javascript interpreter? However, lots of people want to scratch UI itches or add little features here and there.
--
Business. Numbers. Money. People. Computer World.
People seem to forget that AOL is a computer company that survives while making no direct revenues from their software product.
To AOL, Mozilla will be the equivalent of their AOL software for the Internet user, with one big difference: it will be positioned towards Internet users, not AOL users. AOL knows that to win in the Internet marketplace, you have to be willing to play by their rules. That's why they're taking a hands-off approach to Mozilla.
Microsoft has railed about how Mozilla is bound to be the default browser in the AOL software sooner or later. I disagree. I think Mozilla, with it's extendable UI, will *become* the AOL software.
Another thing nobody's mentioned is the ridiculous amounts of memory it officially takes to build the thing. We starving programmers don't usually have 128M of RAM lying around in our home boxen. Until recently, in fact, I did all my non-work development on a 486 with 16M. I still only have a K6/233 with 96M of RAM. I'm sure there are lots of very good programmers in the same situation.
Remember that the mozilla project isn't just trying to build a better browser - it's building a better development model. There's a lot of work going into the planning and execution of this.
It's also an experiment in OSS. It's success may be the defining factor in how many businesses see the idea later on.
And guess what, boys and girls, is the best way to conetrate [sic] a group of engineers? Thats right kids - pay them and put them in the same building. Oops, I forgot, corporations aren't in style with the /. crowd, are they?
It's a problem, all right: how do you eat, pay rent, and buy electricity and network connectivity if you're not selling your work? On the other hand, I'm seeing some positive movement in this area. My boss, for instance, has said that he'd like me to see if I can't help get the next version of Navigator to render pages more quickly so that users can see our company's website without waiting for minutes for all the tables to render. So here's an example of a startup (HomeShark) directing engineering resources to help out with the open source development.
The way I see it, though, the documentation is a big problem. I know I'd much rather bang out code than documentation, but in trying to come up to speed on Gecko I'm doing an awful lot of grepping through the source tree, trying to figure out where the hell stuff happens.
Oh, go on, check out my job.
In some areas I think Jamie is absolutely right (like it being a bad thing not to have a working release yet), in other areas I think he is in effect objecting to technical decisions that were made for what other people consider good and sufficient reasons (like dumping Mozilla Classic for NGLayout), and in other areas I think he had unrealistic expectations (like speed and size of developer contributions to Mozilla).
But in any case, if I really had wanted to try and put a "happy face" on the Mozilla project then I could have skipped writing a large chunk of the article.
This is probably a better sort of guideline for commercializing open source software than the article posted yesterday. It should give pause to those who think that it's practical for corporations to open source everything immediately. The JWZ comment about open source not being "pixie dust" comes to mind. On the other hand, that there are significant positive developments strengthens the position that commercial software can also be open source. If nothing else, it should serve as a mini-case study for others that are planning to do something similar so they can avoid some of the problems that Mozilla encountered.
You have a choice: tax and spend Democrats, or borrow and spend Republicans. Choose wisely.
Highlights, in my opinion:
Like it or lump it, Mozilla's biggest problem is that their competition actually has out right now something that may be superior to most of what they are still building. Like it or lump it, IE is pretty slick.
The short answer is yes; as is often the case, reality is more complicated than the sound-bite. To be as brief as I can without distorting history: Over the years several people at Netscape floated the idea of releasing source code for Navigator/Communicator; some did so in postings to internal newsgroups (like Jamie Zawinski), and some did so in private lobbying to management (like Eric Hahn, formerly Netscape's CTO). Prompted by two such newsgroup postings by Jamie and Eric Krock (now Gecko product manager), in the fall of 1997 I wrote a 30-page internal paper lobbying for release of source by explaining the business value for doing so; I also addressed various objections to releasing source, either showing how they were not really problems or describing how any problems could be handled. I sent that paper to Marc Andreessen, who in turn circulated it to other senior managers at Netscape. This paper was IMO one, but by no means the only, factor in the decision by Netscape management in January 1998 to release source. (For example, it was also important that Netscape decided to make Communicator binaries totally free at the same time; this removed a major objection to freeing the source code.)
Eric Raymond and "The Cathedral and the Bazaar" came into the picture as follows: I was finishing up my paper, and was working on a section addressing the problem of coordinating development between Netscape and the net. (A major objection I thought would arise was how this could work successfully, or even if it would work at all.) I asked Jamie for advice, he gave me some, and then also pointed me to Eric's paper; I thought it addressed this particular problem quite nicely, and included a reference to "C&B" and a page or so summarizing its conclusions. Some of the senior managers (like Eric Hahn) liked "C&B" just as much as I did, in large part because of the implication that Netscape could potentially successfully leverage the work of lots of non-Netscape developers, even to the point of their driving the future direction of the product; Eric and others in turn promoted "C&B" within Netscape.
Once the decision to release source code was made, Netscape management then decided to bring in Eric and other people (Richard Stallman, Bruce Perens, etc.) for advice. However the decision itself was a purely internal decision, in the sense that neither Eric or anyone else outside Netscape (to my knowledge) actually lobbied Netscape management on the source code issue; "outside" input was restricted to that provided by papers like "C&B", the GNU Manifesto, etc., and examples of free software businesses like Cygnus Solutions, Red Hat, and so on. (The Slashdot discussions about Netscape releasing source came in right before the Netscape decision was announced, but I don't know if they were actually a factor or not, because I don't know if the internal decision had actually been made by then.)
Incidentally, my original paper is not on the net, but I did a public paper "Setting Up Shop: The Business of Open Source Software" which incorporates huge chunks of my internal paper. In particular, the sections "Making the Business Case" and "Issues and Tactics" are close to what I wrote originally. However the licensing and business models sections of "Setting Up Shop" are new.