[Project_owners] A MozDev Mission Statement?

GuruJ GuruJ at mbox.com.au
Wed Sep 17 01:11:05 EDT 2003


Hi everyone,

This discussion has obviously touched a fairly deep nerve in the MAD 
community.  However, at the risk of sticking my neck out and getting it 
chopped off, I think we've been approaching this all backwards...

Let me recap.

All the talk so far has been centred around getting *Mozilla.org* to 
change the way it conducts the project.  However, as Pete so eloquently 
put things:

"I think what we have is a very distinct developer base for Mozilla: 
Browser/MailNews and MAD Platformers."

The vast majority of people out there just want a killer IE and OE 
replacement.  But our needs are vastly different:

THEY don't care about interfaces that break, or any of the 
byzantinely-complicated plumbing that lurks underneath the surface.  But 
WE do!

THEY don't care about having access to PyXPCOM, PlXPCOM or Jslib.  But 
WE do!

THEY don't need documentation more in-depth than how to navigate the 
built-in menu system.  But WE desperately do!

Application Suite fans have different requirements (common UI, 
Composer/Chatzilla/Venkman, all tools available as a single download) to 
MozillaFirebird users (speed, simplicity, small size).  That's why the 
fork exists!

Similarly, our needs are different from both MozillaClassic and 
MozillaFirebird.  There can only be one logical conclusion to all this ...

Ladies and Gentlemen, I give you:  MadBird.

If we, as a community, *truly* believe that Mozilla has a future as a 
development environment, then *we* must make it one.  Here's a sample 
roadmap:

1.  Contact Mozilla.org project leads and canvass the idea.  Get 
quasi-'official' status (eg. link on front page).
2.  Fork Mozilla 1.4.1.  MadBird lives!
3.  Give trusted MozDev developers super-approver status, and set up a 
(hopefully simple) approval chain.
4.  Link in PyXPCOM, PlXPCOM (if it's ready for primetime), and JsLib 
and enable by default.
5.  Hell, let's even add in SVG and MNG support -- I'm sure they would 
be killer tools for developers, even if they are still incomplete.

(Now things get tricky...)
6.  Get a working GRE core.  Document in painstaking detail the process 
for creating standalone apps that link to this core.
7.  Identify what 90% of Mozilla developers would need to easily create 
standalone applications (easy GUI-building toolkit, File I/O, Text 
Editor (vanilla and/or rich text), etc).  If the techniques needed to 
use these technologies are too advanced, create wrappers (eg. JSLib) 
that make these technologies easily accessible.

(Down the track...)
8.  Highlight core inadequacies in the current Mozilla toolkit. 
Examples might be:
     - RDF functionality only 80% complete.
     - Components and interfaces aren't frozen.
     - No JavaScript events for PNG.
9.  Fix these inadequacies.

If the changes we make are positive, there's a good chance they will be 
incorporated back into the tree.  And if not, at least we're doing 
something positive towards creating the cross-platform application 
programming environment that we all want.

Okay, that's me done.  Who wants to shoot the argument down in flames?

-- GuruJ.



More information about the Project_owners mailing list