[Project_owners] A MozDev Mission Statement?
davidf at sjsoft.com
Tue Sep 16 17:47:42 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
> 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?
> -- GuruJ.
I think the key issues are:
1) How many of these aims are different or in conflict with the aims of
other mozilla project developers
2) (most important) How many real developers who could achieve these
aims and are available to help do so are there who are available,
willing, want to work on it.
3) To what extent is a fork needed to help the developers in 2) achieve
4) How much of the above could be done without a fork? (e.g. 4,5 would
be simple and advantageous - just make different builds).
More information about the Project_owners