The Inside Track on Firefox Development.

« Extension/Update Manager Screenshots | Main | More SmartUpdate Screenshots »

April 24, 2004

A Call To Arms

Mozilla has always been concerned with finding new talent - this is important not only to reach new goals in the codebase but because the set of people working on the project changes over time, and when someone steps down a capable replacement must be found.

I was discussing this with Dave the other night - I was wondering how Mac apps always seemed to look so good - not just polished, but decidedly pretty. Dave hypothesized it was because of the relatively large number of graphic designers in the Mac community, with a vested interest in the software that they use, and a desire to make it look better. I think Dave is right.

The best and only way to attract the best talent, in my opinion, is to strive to create top notch products that encourage like-minded folks with ability and dedication to participate. I like to think that this has been the case thus far with new-generation Mozilla browser products like Firefox and Camino which have attracted a much more diverse set of contributors (such as the members of our Visual Identity Group) that Mozilla's older generation of applications may not have reached.

I'm firmly against outreach programs - anyone who needs their hand held in order to contribute is not someone that I think can be a mover in this business. Mozilla's key contributors are highly motivated, talented, dedicated individuals who are largely self-taught. Every so often a new person like this pops up and it's great. I don't mean to demean the value of simple patchmakers - but Mozilla really needs a stock of resources willing and able to design and implement large scale features. These people need to be able to take on existing components and not just own them idly but bring them forward. It's only by this means that Mozilla can remain at the cutting edge, and remain relevant.

As a side note, part of what I think creates a great engineer is someone who thinks about what is possible, rather than what isn't. That might sound cliched, but it's true.

Mozilla needs more talented people in all areas, but especially:

• User interface design and implementation
• Documentation for new developers (I realize highly detailed documentation on a project with as lean a resource budget as we have is a fool's errand, but some more module layout/interaction maps would be good - offering developers an easy way to navigate the code base while they're learning it and allowing them to answer more of their questions for themselves rather than rely on the attention of experienced engineers whose time is needed elsewhere).
• Product Marketing with a true consumer focus and an understanding of that consumer market, their desires, motivations, and so on. These traits are similar to those required of good UI designers.
• New Applications Developers - people with good ideas and an appreciation of our technology platform and a desire to build interesting new applications on it. Our current crop of applications suits the needs of a good many of today's consumers but what about tomorrow? How will we be ready for tomorrow if we don't have people thinking of new things, stressing aspects of the codebase that our current apps make little use of in new and interesting ways, and so on.

If you want to help, first believe that you can make a difference - that you can impact the lives of millions of people in a positive way, then find something that interests you, something you might have some skill in. Then find the appropriate channels in which to contribute. Mozilla's products will be better for it.

Posted by ben at April 24, 2004 3:34 AM

Comments

I think more people would be interested in the Mozilla suite if it received the same visual polish as Firefox - e.g. customisable tool bars and a new default theme, similarly eye catching as Qute and Pinstripe but maybe more subdued.

Mozilla suite looks crusty and old like Netscape, if you appeal for makeover help (Mr Hicks?) I'm sure it will be of great branding benefit.

Posted by: Rob C at April 24, 2004 5:28 AM

I don't want to sound negative, but new people and new talent do not appear in an instant. Yhey start to work on small things and in time move on to larger stuff.

But this will only happen if they stay interested in Firefox/Mozilla and IMO that's not going to happen, when patches which have been available via Bugzilla wait there for months or even years and when you only get the patches reviewed if you get on IRC and bug the developers long enough. I know I have often enough done that for my small patches and for other people's patches.

Posted by: Simon Paquet at April 24, 2004 5:35 AM

Four years from now I'll have a degree in MIS/CS...talk to you then.

Posted by: rgw at April 24, 2004 7:51 AM

You say documentation is too much effort, but it's Mozilla's infamous lack of documentation (or worse, overabundance of things that looks like documentation but havn't been updated since 1999) that frustrates and discourages new developers, application/plug-in developers, and embedders.

I've often dreamed of trying to do something about it (I'm developing/writing for an online help system on top of embedded Mozilla, and the lack of API and XUL docs is a constant problem). But as you touch on, it's nearly impossible to create effective docs when it's not possible to sit down with the developers and go over things in depth.

Besides, the Mozilla project has a reputation for being slow, insular, and haughty. A lot of it is simple lack of resources, sure. But dude, the *top developers* had to fork their own codebase to get anything done. How many toes would I be stepping on if I tried to whip the vast sea of disconnected docs on mozilla.org into shape? How much cooperation could I count on/compel from developers? Ask mpt how easy it is to get things done in Mozilla land.

You attribute the success of Camino/Firefox to being attractive... I think if you look one step back you'll find that they're attractive because of a deeper cause: they were disconnected to some degree from the core Mozilla developer culture. It's a culture that denegrates "mere patchmakers", dismisses documentation as "handholding" that's out of reach, and one for which usability is an afterthought.

Posted by: Matt Chaput at April 24, 2004 9:02 AM

I just realized my last post was not written in the right spirit. You've called for people to join Mozilla and make it better. I support that *fully* and would actually like to help. What I'm saying is that the call to arms fails to address the some widespread perceptions that keep people like me on the fence:

1. The people working on these things now don't seem to make any progress, so why bother?

2. Signing up is just setting yourself up for frustration and abuse.

3. Getting up to speed after joining is made more difficult by a general anti-newbie attitude.

These reasons might all be BS. Maybe you don't even want people who would shy away from these things. But *IMHO* these are the reasons why rah rah encourgements to join sound slightly hollow.

Posted by: Matt Chaput at April 24, 2004 9:22 AM

Matt, to work on this project you need a thick skin. You should read the abuse that gets hurled at me. I try not to let it bother me - there's more important things to do. What I said in my posting is true - you need to think about what is possible, not set up obstacles to assist in your failure. Think about what you'd like to achieve and work hard to achieve it. That's all I can say.

Posted by: Ben at April 24, 2004 12:27 PM

Docs for users are certainly a must, which is why I've been helping out with the Firefox Help project. They're not perfect, and I expect some feedback from 0.9 users should help greatly with quality before 1.0, but they're a good start. If I actually knew anything about large-scale (or even small-scale) industrial coding I might be able to help out elsewhere, but without knowledge of C++ and the workings of the Mozilla implementation I really can't touch anything.

Also, what Simon said rings true. I may not know enough to try any more comprehensive backend patches without help, but I can sometimes do little patches. Currently, I've got three *one-line* Firefox patches waiting for review right now for various lengths of time from a couple weeks to a couple months. Each is completely risk-free, but I doubt any will get in before 0.9 or even in the foreseeable future. Perhaps I should do the IRC thing to get them in the tree.

Posted by: Jeff Walden at April 24, 2004 1:29 PM

Make that "the IRC thing" - I've used Chatzilla before but have no real interest in IRC for anything other than special-use cases.

Posted by: Jeff Walden at April 24, 2004 1:31 PM

I think documentation is the lynchpin here. No one wants to do it, or it'd be done. It is so un-glamorous, it's probably nothing less than a paid chore. And even if the Mozilla Foundation mandated that everyone in the place would spend the next year working solely on documentation, I suspect there'd be an exodus.

Features keep coming, and interfaces keep changing, and I think it a monumental task to get ahead of (or caught up to) the curve. I think at some point the culture will have to change such that the high-level peers, like you Ben, will not consider abandoning a code contribution until it's documented. I think you have to just start documenting-as-you-go. It will give others a starting point, a template, and a shining example of commitment to the process which may ultimately change the culture. (And kudos to you on the stuff you put together for the new extensions mechanism.)

Until "self-taught" means "reading docs" instead of "criss-crossing back and forth and all around in lxr", no one will answer this call.

This "call to arms" post has generated a little bit of venom. The current "what are the goals" thread on n.p.m.seamonkey has generated a little bit of venom. I think they are common in this respect because people CARE, and are constantly disabused of their hope.

Posted by: Ran at April 24, 2004 1:39 PM

This is pretty much all accurate, especially the thick skin. The review process is a pain, because we're at a stage where we have a limited number of top-level resources available for code review. I'd be happy to take on reviews for UI fixes/minor C++ stuff, letting ben et al (is there really an et al right now?) focus on the high-level review stuff. But I don't know whether I've done enough to show my abilities on that level as of yet, so I'll just keep doing what I'm doing until someone says something.

I can certainly vouch for the frustration in working on Firefox patch-like things, but the day is coming when that stops being an issue. Feature hell still is a factor, and once that's done ben has already committed to reviewing all of the outstanding patches. Attach the patch, move on, keep finding other things to work on. Trying to work linearly isn't always possible. Hell, I ended up as a peer for Cookies and Permissions on one detour from Firefox.

As for designing and implementing major features, if this is within Firefox then we need more feedback coming from somewhere higher up as to what needs doing and in what order (as least as a preference). Using the helpwanted keyword on Bugzilla would be a good start though.

Posted by: Mike at April 24, 2004 3:27 PM

Currently Firefox is on a "must ship" footing and as the only full time engineer I'm responsible for seeing that it does. I've developed a fairly careful product plan (as far as Mozilla product plans go) for the 1.0 release that will see a late summer launch.

After 1.0, who knows what we'll do next. That's what I'm trying to get people thinking about. Not all of this work needs to be done in CVS, especially considering we don't even know what it is yet. I'm looking for bold new ideas from creative people, prototyped as extensions or new applications. Creative solutions to problems. Develop good ideas and they'll be utilized.

The way I run Firefox is like this - if there's an area I can easily delegate without too much concern I do. Help is run by RJ Keller. Our branding and some theme work is done by the Visual Design Team. These modules didn't come around because of bug system efficiency tweaks. These modules formed because people sought to create something new on their own initiative. At this stage I really need to be as disengaged as possible from this process because of my other commitments (which are numerous) - all the bug flags in the world mean nothing when I don't follow the bug system - I'm tired of people telling me this is a problem - this is NOT a problem, what would you rather have me do, spend all day reviewing patches or write thousands of lines of code on much needed new features? I tried to hand off the Extension work (and I've delegated many of the lower level details to Darin, Benjamin Smedberg, Dan Veditz etc) but there was no one else capable of doing the higher level work that had the immense time commitment it required. Anyhow, I'm tired of talking about me. My point is - don't use my necessary inattentiveness as an excuse not to innovate, if that's what you want to do. There are plenty of ways to do so.

Posted by: Ben at April 24, 2004 4:12 PM

Hm, I wonder - how about getting some corporate support, letting 'em pay the salaries of more full time developers? Companies like Sun (Java Desktop Environment), Novell (SuSE, etc.) and others in the Linux arena would be wise to do that - Mozilla technology is a *huge* asset to their business, after all.

Posted by: Eike Hein at April 24, 2004 4:44 PM

Sun has a bunch of engineers working on Mozilla in Beijing. IBM has a some in Menlo Park and Austin. However, they're not focused on front-end development issues at this point. They do provide support on certain things (like Darin helping with the extension manager stuff) but there's also bigger fish to fry with the backend improvements and that's unfortunately the way it works.

I'm probably going to go through the Bugzilla 0.9/blocking0.9? lists at this point and push out everything that isn't critical for 0.9. Too many people are not paying attention to roadmaps/plans and trying to push their own pet bugs. Stuff that should be fixed for polish-like reasons should be targeted for 1.0beta unless it manages to get review for 0.9. However, this is unlikely to happen besides stoppers and reasonably visible regressions. 1.0beta is for bugfixing/feedback, and 1.0 after that.

The only problem with disengagement with the process is that the little things build up and the people who are using said little things as their learning process to move into bigger things can get discouraged. But, that's beyond what Ben can do, short of adding peers, since everyone else is unavailable. His priorities are completely right, if pch/hyatt/blake were around, the issue would be hugely diminished, but they're not and we have to make do as best we can.

Anyone who really wants to help can hop into #firefox and I can help get them pointed in the right direction (since my own bits of innovation are basically more interesting/important to work on than docs).

Posted by: Mike at April 24, 2004 5:11 PM

Using money to throw engineers at a problem will certainly almost always solve it in some way, shape or form. But that's not what I'm looking to do. I don't want to create another Netscape (which had lots of money for a while, lots of engineers, and mediocre products - you can argue with me on this, and indeed you can effectively argue the merits of Netscape's releases against IE, but Firefox is the browser we wanted to build in 2000, not 2004).

We need engineers, technical writers, artists and product marketeers that CARE about this technology and have strong skills. One would hope this is the set of people that would be hired by an organization that has a similar care for Mozilla.

Posted by: Ben at April 24, 2004 5:28 PM

Well, caring for something is a lot easier when you got your bills covered. Let Sun, Novell, IBM & Co provide the money while you select who receives it?

Posted by: Eike Hein at April 24, 2004 5:44 PM

The money being spent is pretty well invested, from where I sit. Don't forget there's stuff like networking, layout, printing, cross-platform compatibility and performance improvements that all go into the project and are equally important.

Posted by: Mike at April 24, 2004 5:56 PM

True. I read the Mozilla 1.7b release notes earlier today, and was pleasantly surprised by what's going on under the hood.

Still, most Linux distros ship Mozilla more or less unmodified, and will probably do the same with Firefox and Thunderbird, except for rebranding and maybe a skin change or something like that. It has to be possible to get these guys interested in funding UI techs picked by Ben & gang.

I'd like to point out Lindows - they're funding Nvu (formerly known as Mozilla Composer) and lots of other indepentent stuff, after all.

Posted by: Eike Hein at April 24, 2004 6:15 PM

Ben, I couldn't agree more on the documentation for new developers bullet point. Further, I will say that we have modules where even the old developers have no idea what the code does or how it works; the only way to deal with such modules is to document them in enough detail that understanding develops. Doing that is crucial in resolving some issues we have on the table....

Posted by: Boris at April 24, 2004 8:15 PM

I've read the discussion so far and even though I'm not a programmer, I found it quite interesting.

However, being an economist, I think Ben's post is very vague on details on the marketing part(understandably maybe, Ben's a programmer, not a marketeer), and maybe wrong as well. Specifically, I think that a marketing project that focuses on end consumers in little more that a waste of time, because there is no way in hell that Mozilla/MZ Firefox will get enough awareness among regular, non-geek users to make them download, install and setup the browser when(let's face it) IE gets everything that these people want done without much hassle . Mozilla may be a much better browser, but communicating that fact that to end consumers would require a marketing budget of McDonald-ian proportions. Think about it: If Mozilla/MZ firefox are to get a reasonable market share (25%?) a 100-150 million people would have to download the program. It just isn't realistic and end user effort should therefore be limited to end user help pages and such.

What needs to be done if we want mass appeal is to get Firefox PREINSTALLED on as many computers as possible. Eliminate people's need to download and install the program.

This boils down to that the marketing focus should be directed at one very specific group: large computer sellers like HP, Dell, IBM and such. If you manage to convince these big guys that it is to their advantage to preinstall Firefox on the machines they sell, you have a winning situation. What's more, I believe that these companies' business people could relatively easily be persuaded to do it, simply because it really is to their advantage to do lessen their dependence on Microsoft. Less dependence on Microsoft means greater negotiation power over MS when software licences are renewed, which again will lowers costs and raises profits, which is what these guys in reality are interested in.

In short, don't try to conquer the market on your own. Instead, make the big guys conquer the market for you:-)

Posted by: Terji at April 25, 2004 4:29 PM

I've been trying to break into development on mozilla for a long time. I've filed bugs, written a couple of patches, and some Firefox extensions. I would have been lost without the documentation at XULPlanet. I think one of the reasons Microsoft succeeds so well is that they have great developer resources with MSDN. There could be some huge benefits if we had an official document repository at the mozilla site similar to MSDN.

Posted by: Richard Klein at April 26, 2004 6:38 AM

I for one would like to see a marketing push targeted at the users of "internet". The people who don't know they are using a browser, much less that their browser is called IE and comes in different flavors. I would love to put some kind of a banner on my pages promoting mozilla, but such material is not currently available.

If enough unwashed masses get using Firefox, (say 5-10%), and start complaining to webmasters when something doesn't work, firefox will be taken into consideration by web developers much more. Once they try it, they will have no choice but to love it and start using it.

So in my opinion, making some type of grassroots markering material available for public consumption (in the vein of "Netscape Now" buttons of yesteryear but more informative) should be a top priority...

Posted by: levik at April 26, 2004 12:08 PM

I would love to get into Moz/Firefox development, i have tried but allways find barriers in my way. My expertise is in UI, not in programming, although i do understand XUL and its quite easy, my main issue has been trying to work out how to edit/change elements through extensions, i have not been able to work it out, stopped trying because i post on mozillazine about wanting to help out or needing some help and no-one cares. We need a group of people that can help others get into the loop, getting into the loop is what really makes it in the end.

Posted by: George Dekavalas at April 27, 2004 6:47 AM

http://forums.mozillazine.org/viewtopic.php?t=64378&highlight=university+builds

This thread had some good ideas :)

Posted by: John at April 30, 2004 2:21 PM

I'd love to become part of the Mozilla Firefox project; I don't want to be presenting a resume here, so I'll just mention the fact that I am very experienced in nearly the entire computer area - Programming, UI design, Graphic Design, Digital Photography, 3D Modeling and Animation, Music and Song Production, Networking, Website design, Database-driven (dynamic) Website programming, even Robotics; I've had experience in both Windows and Linux (I currently favor the latter), and of course I'm an avid gamer. (so much for not posting a resume ;-)). I definitley think I could help with UI and documantation - I've also converted a few of my neighbors and friends to Firefox and Thunderbird so I suppuse I could fit into marketing too. The only problem - I'm a High School student, so not all the time in the world is available to me. If you're at all interested, send me an email.

Posted by: Andrew Keyser at May 1, 2004 8:50 PM

We should not still be having problems with patches going unreviewed. There may still be patches languishing in bugs where no-one's paying attention. Please bring such cases to the attention of drivers@mozilla.org.

Posted by: Robert O'Callahan at May 3, 2004 10:00 AM

I wouldn't mind getting hired to write docs for Mozilla. I can't find anybody with a budget to have someone do that.

Posted by: Alex Vincent at May 3, 2004 4:46 PM

Robert: do you mean backend gecko/necko/layout/etc. patches, UI patches (as for Firefox/Seamonkey/Thunderbird), or both?

Posted by: Kevin Jordan at May 4, 2004 7:43 PM

In addition to full-time engineers, Mozilla.org may need someone dedicated full-time to filling the needs identified above (and many other places): Supporting developers, both established and new.

They could handle the roles that everyone sees as lacking:
* Project management (including managing patches, priorities, etc)
* Documentation and other developer resources
* Communication and a contact point for the developer community.

Filling these roles would greatly multiply productivity, as it would,
* Enable many more contributors to contribute, especially those more skilled who are likely to have less time.
* Make all contributors much more efficient
* Relieve existing high-level engineers of these roles, allowing them to do more actual engineering.

I'd say it would 'pay for itself many times over' and well worth the salary, if we actually sold something.

Posted by: guanxi at May 5, 2004 12:54 PM

There are ideally two parallel 'paths'. It is great to see the new & fresh & shiny & polished. We all want that. But I am reminded of the Toyota Camry when we talk of "sales" So many reviewers derided the Camry for appearing "ordinary" externally but the sales figures totally upend the reviewers arguments. We are creatures of habit & many of us are "comfortable" & dont want things too frilly. A little bit of crunchy, old, dry crust is still nice even with a rocket sled.
Don't neglect the "Camry buyers" as well, or we may have to learn the lessons of its reviewers. Now let's go find those graphic designers - great idea!

Posted by: Geoff at May 7, 2004 12:16 PM

The type of marketing that will take Mozilla from it's current 10% market share to a 50% market share, will mostly be word of mouth. And we need the following criteria met first before many people will put their reps on the line:

-Mozilla.org should heavily promote 1 stable browser (right now that should be the suite, at Fx 1.0 we can switch)
-Have "qualified" extentions available on the browsers "start page" as well as new themes (like ben says, where are the GUI people?)
-Convince people with cool websites (not bank websites) to create them with new technologies that make the site (purposely) look ugly in IE, use a browser sniffer and a popup warning that the "uncool" use a browser which is years old.
-Make Fx virtually uncrashable. I don't want to recommend it to someone and they try and print and it blows up on them (which has happened with the suite, and the suite people continues to ship with that @#$! because they've "shipped with it before")

-I want to be able to convincingly belittle developers who think it's better to use IE. I want to walk into an MS dev shop and laugh in their faces. Just like we can convincingly laugh at people who use NN4.

Posted by: Pete at May 8, 2004 9:09 PM

All very interesting.

I agree completely about graphic designers, MacOS X got it right. People desire it. We need people to desire Firefox in the same way. It needs to look 'better' in screen shots, like MacOS screen shots do compared to Windows 2000 screen shots. Beauty, without going over the top.

Something else has stood out above. Those who expressed desires to get involved, but only have one skill when they need three. For instance, you could have the greatest graphic designer in the world, but if she can't code XUL then she's lost to the Firefox project.
At the same time, another keen user can write some beautifully optimised JavaScript but couldn't draw a line-art poodle if you hit him with a brick.

Therefore, There needs to be a concerted and well promoted effort to 'connect people' - have big links on the Mozilla homepage to a scheme whereby you can volunteer your skill. If I'm an artist, I can say "I'm an artist and I want to make beautiful skins". I can check that my skills are "Art". The system will look up and see that to make a skin I need XUL skills, and will pick out a previously signed up XUL developer with a skin interest, who speaks the same language and maybe lives in the same country (corresponding time zone). The two of them are put in touch and starting developing together.

-- think of it as like dating for geeks. :D Probably better to call it "Developer Network" or something though.

Posted by: Ben Ward at May 9, 2004 6:27 PM

I'm a Flash Developer interested in bringing Flash to the desktop, running on top of the Mozilla framework. Why Flash? It's very easy/quick to create UI's, and you can crate some very stunning visual effects (which may be good/bad depending on your point of view).. but the Flash plugin on it's own is only marginally useful on the desktop because of it's security sandbox. The Mozilla framework brings much more to the table (like local file access).

I created a quick proof of concept not too long ago (http://www.darronschall.com/weblog/archives/000108.cfm), but ran into issues on the Mac. There seems to be a JavaScript problem on the Mac, but the example code runs fine in both Linux and Windows.

I wanted to post here for 2 reasons.

#1 - I'm hoping to take this idea further and build a XUL based application to allow Flash developers to leverage os-like functionality for "useful" desktop applications. As much as Flash is generally looked down upon, you can do some pretty amazing things with it, and sometimes its much easier than you might think. It's come along way in the latest release, and capable of more than just those annoying banner ads that give Flash developers a bad name. As an example, there's a Flash Player for Sony PS2 that is used to create the interfaces for a handful of games since it's saves time and arguably produces better results than coding by hand.

#2 - I was hoping to find a channel to get the Mac bug fixed. I'm not sure if it's a Mozilla problem, or a Flash Player problem, but I found it odd that the functionality works on both Linux and Windows, but not OSX.

Posted by: darron at May 11, 2004 6:30 PM

I'm an example of someone who wants to help out with Mozilla, but can't seem to find a way in. My expertise is in UI, visual design, usability. I can't code at all. In my day job I support average-joe end users for a "well known" computer company, and my background is actually in web development. I'd love to work on developing workflows for information design issues within the browser, and I know the web, and its users. But I don't code. Everyone says the downfall of open-source is the usability for average folk. I can help with that. Point me to the door, and I'll take it from there. Maybe y'all need a recruiter.

Posted by: ~bc at May 15, 2004 7:37 PM

I agree with the earlier comments that it is easy to get discouraged and walk away. I've got about 5 bugs sitting waiting for reviews, that have been waiting for a while despite contacting relevant people.

I'm quite happy to sit back, pick up a bug every now and then and fix it. In fact I find it more enjoyable then trying to implement new functionality - it's a lot easier to understand existing code than try to find where to hook in new code. Plus a quick bugfix every now and then is possible during work, large scale development on other projects isn't.

The trouble is that if bugs aren't reviewed and checked in, the developer quickly feels that there is no point in creating the fixes. There needs to be greater attention by developers who are allowed to review, to actually reviewing patches submitted by other developers. Patches which may not add the latest and greatest new feature, but fix existing bugs and add to the stability of the software.

I wouldn't be surprised if there are a number of developers that contributed, got discouraged from a lack of interest and then walked away. I know I'm close to doing it myself.

Brodie

Posted by: Brodie Thiesfield at May 20, 2004 6:53 AM

It's a simplification to say handholding and documentation don't help. It helps the people who are motivated and skilled but not knowledgeable in enough areas yet.

For example, 3 years ago I knew C very well, but had no C++, JS, CSS or COM experience. Now I own wrote find as you type as well as most of the accessibility module. So I proved myself even though I was considered a longshot newbie at first. More docs would have helped quite a bit.

There should be some high level docs as to what an nsIDocWebContentElementPresContextShellNodeStateManager is. I've found in the past, if it's too hard to document, then something might be wrong with the design.

In fact it saves a lot of time when people ask questions, because you can give them a link rather than right individual answers.

Just to show I'm not a hypocrit, here's the docs I've contributed:
http://www.mozilla.org/projects/ui/accessibility

Posted by: Aaron Leventhal at May 20, 2004 10:41 AM

Yep, "Developer Network" is what we need. Anyone keen? ;)

Posted by: Chris Wood at May 27, 2004 10:05 AM

©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by Jon Hicks, and is a trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz