[Project_owners] A MozDev Mission Statement?
GuruJ at mbox.com.au
Wed Sep 17 01:11:05 EDT 2003
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
"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
THEY don't care about having access to PyXPCOM, PlXPCOM or Jslib. But
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
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
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.
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?
More information about the Project_owners