What are the goals of Mozilla.org?

15 views
Skip to first unread message

Andrew Schultz

unread,
Apr 3, 2004, 8:39:43 PM4/3/04
to
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.

http://www.mozilla.org/mission.html
8) mozilla.org is a group chartered to act as the virtual meeting place for
the Mozilla code.

:)

but, ya. I wanna know too.

--
------------------------------------------------------------------
Andrew Schultz | The views expressed might
ajsc...@eos.ncsu.edu | not represent those of NCSU.
http://www4.ncsu.edu/~ajschult/ | They are however, correct.

Boris Zbarsky

unread,
Apr 3, 2004, 8:42:37 PM4/3/04
to
Robert Mohr wrote:
> I think <http://www.mozilla.org/roadmap.html> covers this fairly well.

No, as a matter of fact it does not. It has tons of verbiage, whereas I
am looking for an answer that should take about 5-6 lines of text, no
more. It also doesn't handle the "what are the relative priorities"
question, which is the important part of what I asked. Finally, the
roadmap page describes what mozilla.org is doing, not what it should be
doing. Or rather, it describes what mozilla.org was doing a year ago.

-Boris

Robert Mohr

unread,
Apr 3, 2004, 8:31:02 PM4/3/04
to
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.
>
> These are not mutually exclusive, of course. Which of these are actual
> goals (as opposed to accidental byproducts), and what are their relative
> priorities?
>
> Inquiring minds want to know,
> -Boris

I think <http://www.mozilla.org/roadmap.html> covers this fairly well.

--
Robert Mohr
moh...@osu.edu
mo...@cis.ohio-state.edu

Boris Zbarsky

unread,
Apr 3, 2004, 8:28:27 PM4/3/04
to

Benjamin D. Smedberg

unread,
Apr 3, 2004, 8:55:57 PM4/3/04
to
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:

Do you mean "mozilla.org the collective of developers who work on
mozilla", or "mozilla.org the Mozilla Foundation that runs the CVS
server, owns the firefox/mozilla trademarks, and has a few staff members"?

I don't see why various groups of developers cannot order their
priorities as they see fit. The only real problems occur when there is
conflict between priorities, such as the current controversy over
attribute and style reordering.

The role of the mozilla foundation should IMO be primarily service to
users and developers, and should not revolve around marketing.

also, there is no reason why goal #1 in your list could not be "create
several good web browsers", since this is in fact what we already have.

--BDS

Boris Zbarsky

unread,
Apr 3, 2004, 9:10:57 PM4/3/04
to
Benjamin D. Smedberg wrote:
> Do you mean "mozilla.org the collective of developers who work on
> mozilla", or "mozilla.org the Mozilla Foundation that runs the CVS
> server, owns the firefox/mozilla trademarks, and has a few staff members"?

I definitely do not mean the former. I don't quite mean the latter,
though it's closer. I mean what we have passing for project management
(drivers, super-reviewers, mozilla.org staff, etc).

Perhaps a good start is to come up with the list of projects "we"
(whoever that is) have and figure out what their goals are.

> also, there is no reason why goal #1 in your list could not be "create
> several good web browsers", since this is in fact what we already have.

Fine. Like I said, if I'm missing goals, feel free to add them.

-Boris

TenThumbs

unread,
Apr 4, 2004, 7:31:50 AM4/4/04
to
Boris Zbarsky wrote:
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>

All it wants to do is survive. It will use any of your possibilities (and
anything else) as reasons. Right now it's have a hard time because it's
realizing it can't do all the things it once could.

--
Hebe
2004-04-04 11:29:47.555 UTC (JD 2453099.979023)
X = -1.699572719, Y = 1.751356802, Z = 0.675100307
X' = -0.008854341, Y' = -0.005721169, Z' = 0.000304818

Boris Zbarsky

unread,
Apr 4, 2004, 11:13:35 AM4/4/04
to
TenThumbs wrote:

> All it wants to do is survive. It will use any of your possibilities (and
> anything else) as reasons. Right now it's have a hard time because it's
> realizing it can't do all the things it once could.

That doesn't answer my question either. I'm looking for some specifics
from people who are setting mozilla.org policy here.

-Boris

Robert O'Callahan

unread,
Apr 4, 2004, 1:52:58 PM4/4/04
to
TenThumbs wrote:
> All it wants to do is survive.

This just isn't true. Furthermore, it's unfair and insulting.

Many, probably most, of the people involved with the foundation would
make more money with less stress doing something else, and have no
incentive to keep it going for its own sake.

Rob

TenThumbs

unread,
Apr 4, 2004, 1:46:34 PM4/4/04
to
Boris Zbarsky wrote:
>
>
> That doesn't answer my question either. I'm looking for some specifics
> from people who are setting mozilla.org policy here.
>
> -Boris

Their only asset is the mozilla codebase which is a elegantly engineered
product but that elegance requires a large support staff which is now gone and
is unlikely to return. I don't think they know what they can do with it now or
in the future. Difficult times.

--
Flora
2004-04-04 17:45:36.999 UTC (JD 2453100.240012)
X = 1.893180897, Y = 0.141424982, Z = -0.140028831
X' = -0.001584516, Y' = 0.012257855, Z' = 0.004948048

KaiRo - Robert Kaiser

unread,
Apr 4, 2004, 2:04:01 PM4/4/04
to
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:

Do http://www.mozilla.org/about/ and http://www.mozilla.org/mission.html
not provide enough of that? Or not compact enough info?

> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.

The "about" page says "The mission of the Mozilla project is to preserve
choice and innovation on the Internet."

And that's really the base, I'd say from how I see mozilla.org acting.
The goal is not one project (browser/platform/whatever), it's not facing
one competitor, it's choice and innovation.
Of course, the limited resources make that focus to a (well, relatively)
small set of things that can be provided by the Organisation itself.

The "about" document also has a list of things that mozilla.org does. I
basically believe this is nice - perhaps this should be under some other
topic or precised, but I'd think that's bacially it.

Will be interesting for me to hear people of drivers/staff speak on that
issue ;-)

Robert Kaiser

Boris Zbarsky

unread,
Apr 4, 2004, 2:26:59 PM4/4/04
to
KaiRo - Robert Kaiser wrote:
> Do http://www.mozilla.org/about/ and http://www.mozilla.org/mission.html
> not provide enough of that? Or not compact enough info?

Not goal-like enough.

> The "about" page says "The mission of the Mozilla project is to preserve
> choice and innovation on the Internet."

That's so fuzzy as to be useless. It's not a goal one can use to
reasonably set priorities of work. Moreover, it's not a goal that can
be "reached" (it's an ongoing endeavour rather than a target). So there
need to be more reasonable goals that can actually be used to prioritize
work.

I'm not asking a philosophical question, but a project management
question. Perhaps better rephrased as, "What, if anything, should we be
focusing effort on and why?"

-Boris

Chris Hofmann

unread,
Apr 4, 2004, 2:56:10 PM4/4/04
to
KaiRo - Robert Kaiser wrote:

The things written above sum it up pretty well. To preserve choice and
keep the technology relevant we need to do all these things. We need
to create great software that people enjoy using and can use
effectively. We need to maintain and build market share so content
developers have choices to develop interesting and valuable content will
not get sucked into proprietary technologies that lock in businesses and
users to a single provider. We need to promote and seek wide
distribution of the technology in many applications, on many platforms,
and in many languages. We need to foster innovation; both in the way
that people use the web now, and provide ideas and technology that can
improve things and provide choice in the future. The six items Boris
lists above all plug in one way or the other to these goals. We need to
apply good judgment when there appear to be conflicts that arise in
reaching any of the goals or objectives.

It sounds like you have something on your mind Boris. Is there
something that we need to study? Is there something that we need to
consider and apply some good judgment on? Is there some part of the
goals or objectives that seems unclear or out of balance? Are their new
solutions that will help us toward breakthroughs that will allow us to
move faster or more efficiently toward these goals and objectives?

> Robert Kaiser
> _______________________________________________
> Mozilla-seamonkey mailing list
> Mozilla-...@mozilla.org
> http://mail.mozilla.org/listinfo/mozilla-seamonkey


Boris Zbarsky

unread,
Apr 4, 2004, 3:13:07 PM4/4/04
to
Chris Hofmann wrote:
> It sounds like you have something on your mind Boris.

I suppose the thing on my mind is that the project seems to lack clear
goals and clear direction and that project management decisions are
consistently made in an ad-hoc, reactive manner ("oh, no, X finally
happened, must do Y") instead of being made in a proactive manner
("should do Y so that when X happens (as we know it must) we are ready
for it").

The thing on my mind is that as a developer I'm not sure where to apply
my efforts to reduce the chance of them coming into conflict with
Mozilla.org policies, because said policies are always announced at the
very last moment (or indeed sometimes later than that), after claimed
months-long secret deliberations, often without the people affected by
the decisions being consulted or even warned.

The thing on my mind is that I never know when work I put in will
effectively be wasted and that it's not clear what the purpose of me
putting in work is. And most importantly, that I'm not the only one
finding himself in that situation. It's just that so many people have
simply given up on getting any of the above changed.

-Boris

Michael Lefevre

unread,
Apr 4, 2004, 4:02:37 PM4/4/04
to
On 2004-04-04, Chris Hofmann <chof...@meer.net> wrote:
[snip]

> The things written above sum it up pretty well. To preserve choice and
> keep the technology relevant we need to do all these things. We need
> to create great software that people enjoy using and can use
> effectively. We need to maintain and build market share so content
> developers have choices to develop interesting and valuable content will
> not get sucked into proprietary technologies that lock in businesses and
> users to a single provider. We need to promote and seek wide
> distribution of the technology in many applications, on many platforms,
> and in many languages. We need to foster innovation; both in the way
> that people use the web now, and provide ideas and technology that can
> improve things and provide choice in the future. The six items Boris
> lists above all plug in one way or the other to these goals.

But in what way do those things plug into which goals - what are the
timescales on the goals, which are the priorities? If you decide that
you have 20 goals which are all important and everyone should work on
everything all the time, you end up with everyone going off in different
directions, and then you have conflicts and you have to go backwards in
order to try and untangle things.

> It sounds like you have something on your mind Boris. Is there
> something that we need to study? Is there something that we need to
> consider and apply some good judgment on?

The fact that you (staff/drivers) seem to be deciding what the branch
schedule should be, and what kind of things (like API changes?) should go
into the branch, a couple of days before the branch is scheduled to happen
is probably something that most people would think indicated a lack of
planning. The fact that the website still has a roadmap which is nearly a
year out of date, and is still confusing the media and users is something
of an issue.

Mozilla has a bunch of broad and fuzzy aims with indefinite timescales,
and then plans for Seamonkey/Firefox/Thunderbird releases with plans a few
weeks into the future (a bit longer for Firefox/Thunderbird).

In clearly defined project management terms, what are the goals and the
schedule for the next 3 months, 6 months, 12 months? It should be
possible to follow this stuff from a single source, rather than having to
keep up with a bunch of blogs, news sites, newsgroups and forums...

--
Michael

Gus Richter

unread,
Apr 4, 2004, 7:01:35 PM4/4/04
to
Boris Zbarsky wrote:

You are seeking what is what capable companies implement in order to
clarify for all exactly the purpose, goals and method to get there.

Companies have a Mission Statement. Every department has another Mission
Statement. Every departmental division has a Mission Statement. Every
lower level has to keep the upper level in mind. Every lower level
Mission Statement clearly outlines the goal and method. All involvement
at a certain level, must comply with the Mission Statement. The lower
the level, the Mission Statement is more and more pinpointed.

How difficult is it to apply this to Mozilla Foundation? I thought that
with the newly created entity, this would be the first thing that would
be taken care of. It, of course, always depends on upper management's
knowledge and/or abilities. If this method of Mission Statements were
implemented, your questions would clearly be answered. In fact, life
would also be much easier for management.

i.e. Mission Statements for:
Mozilla.org:
Provide the best Browser, the best Mail/News Client, etc ...
Mozilla Browser:
Develop a W3C compliant Browser ....
Moz Browser HTML:
Support all elements per W3C Recommendation with backward compatibility
M-B HTML / Soft Hyphen:
Add full support for Soft Hyphen (&shy;) as IE and Opera do.
etc.

In this simple scenario, a developer intending to work on providing Soft
Hypen support for Mozilla Browser, would have to comply with its Mission
Statement plus all those in the upper levels. Not only does this give
direction for the developer, but other interested parties will know what
to expect. If desiring, for whatever reason, to deviate from the stated
Mission Statement, approval to change the Mission Statement must first
be obtained. Discussion, concerning the request, would alert all
interested parties.

Just my thoughts. Yours?

--
Gus

James Graham

unread,
Apr 4, 2004, 7:10:17 PM4/4/04
to
Chris Hofmann wrote:
>
>>> As the subject says, what are the goals of Mozilla.org? I see
>>> several possible answers:

>>


>>> 1) Create a good web browser. (What definition of good?)
>>> 2) Create a web browser that can successfully compete with IE.
>>> 3) Successfully compete with IE.
>>> 6) Create a platform for delivering apps over the network (not quite
>>> the same as a web browser, but close).
>>> 4) Create an embeddable rendering engine to enable creation of web
>>> browsers.
>>> 5) Create a technology platform on top of which applications (not just
>>> web browsers) can be written.
>>> 6) Something else I'm missing.

>

> It sounds like you have something on your mind Boris. Is there
> something that we need to study? Is there something that we need to
> consider and apply some good judgment on? Is there some part of the
> goals or objectives that seems unclear or out of balance? Are their new
> solutions that will help us toward breakthroughs that will allow us to
> move faster or more efficiently toward these goals and objectives?
>

The conflict between the different goals that Boris mentioned was
plainly apparent in recent discussion at Mozillazine [1] following the
'announcement' that 1.7 is destined to be a stable embedding branch. In
summary, according to Asa, there have been discussions about the
creation of a stable branch for several months but the decision to make
1.7 stable wasn't made until the developer day and wasn't announced
until very recently - after 1.7 went beta. Consequentially developers
have been unable to use the 1.7alpha/beta cycle to make the changes they
feel should be in the next stable branch. It also appears the the
decision that 1.7 should be stable was largely based on the fact that
Firefox 1.0 is going to be released from the 1.7 branch.

This decision clearly conflicts with some of the goals stated above.
Arguably 1) has already been achieved both with Seamonkey and Firefox.
2) will benefit from having a stable base for 1.0 not just because
crashers can be fixed but also because security updates can be released.
In general, one would expect the quality of Firefox 1.0 to increase from
the decision to make 1.7 stable.

On the other hand, the goals relating to /other/ embedders would
generally suffer from this decision. Since people haven't had the
opportunity to get API changes in, embedder are stuck with writing
against substandard code for a year. Therefore, the late decision to
make 1.7 final actively works against goal 5.

Obviously this probably isn't the only thing that Boris had in mind but
it's an interesting example because, had decisions been made proactivley
before 1.6 branched in January there would have been no conflict of
interests. However it appears that the decision was made reactively and
at the last possible moment. Of course, if the goals of mozilla.org
don't encompass the full range of objectives mentioned but only the
first 3 then waiting for Firefox / Thunderbird / Camino to make a
decision on which branch they want to be stable makes a lot more sense.
I assume this isn't the case, but without a very clear idea of what the
actual goals of mozilla.org are (as opposed to the rather nebulous
statements on the website), it's hard to tell if this is simply poor
management or if it reflects the priorities of the organization.

james

[1] http://www.mozillazine.org/talkback.html?article=4544#3

Mooquackwooftweetmeow

unread,
Apr 4, 2004, 7:48:28 PM4/4/04
to
Boris Zbarsky:
vaguely related: bug 233851
http://bugzilla.mozilla.org/show_bug.cgi?id=233851

-- Greg “The Twaddle” Nicholson

Boris Zbarsky

unread,
Apr 4, 2004, 8:18:33 PM4/4/04
to
Gus Richter wrote:
> If desiring, for whatever reason, to deviate from the stated
> Mission Statement, approval to change the Mission Statement must first
> be obtained. Discussion, concerning the request, would alert all
> interested parties.

That sounds very cumbersome for simple day-to-day decisions like "what
will I code today?" by volunteer developers.

Unless I'm misunderstanding you and your scheme would apply to some
higher level of planning?

-Boris

Laurens Holst

unread,
Apr 4, 2004, 9:02:47 PM4/4/04
to
James Graham wrote:
>>>> 1) Create a good web browser. (What definition of good?) 2)
>>>> Create a web browser that can successfully compete with IE. 3)
>>>> Successfully compete with IE. 6) Create a platform for
>>>> delivering apps over the network (not quite the same as a web
>>>> browser, but close). 4) Create an embeddable rendering engine
>>>> to enable creation of web browsers. 5) Create a technology
>>>> platform on top of which applications (not just web browsers)
>>>> can be written. 6) Something else I'm missing.
>
> On the other hand, the goals relating to /other/ embedders would
> generally suffer from this decision. Since people haven't had the
> opportunity to get API changes in, embedder are stuck with writing
> against substandard code for a year. Therefore, the late decision to
> make 1.7 final actively works against goal 5.

About 5), I don't know if it belongs in the list of mozilla.org goals.
The browsers get a lot of attention (so does their extensibility).
However, the XUL and related abilities as a platform doesn't really seem
to be promoted. I have seen some people comment on this with things like
that it is incredibly powerful and a wonderful cross platform
technology, and that the little attention it gets is a shame, but that
seems to be the case.

I have also never seen this 'technology' platform on which applications
can be written. Or I must be missing something big here :). It's at
least nowhere to be found on Mozilla.org's frontpage. So far, when I
want to write an application using XUL, JS and CSS, I have to make it as
an extension of one of the Mozilla products (Firefox / Thunderbird /
Seamonkey).

Compare it with Microsoft's .NET's and its Windows.Forms therein. Say
that I have created an application for it, which I want to distribute as
a full-fledged standalone application. With .NET, I can tell users that
the software only works if .NET has been installed. If it has not been,
I could choose to include a redistributable, but that's of lesser
importance.

In the case of XUL, there is basically no way to do the first (except
from making it an extension of some other product), so we have to do the
second and include the entire platform, which would mean the entire
Gecko engine (not the smallest). And doing this afaik also isn't the
easiest task, as there is no such thing as a ready-made redistributable,
you'll have to extract the Gecko engine from the CVS yourself and set it
up to autorun your XUL app. Or er, something.

Anyways, my 2 cents (or less, if I'm dead wrong here :)).


~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san!!

Laurens Holst

unread,
Apr 4, 2004, 9:41:35 PM4/4/04
to
Laurens Holst wrote:
> I have also never seen this 'technology' platform on which
> applications can be written. Or I must be missing something big here
> :). It's at least nowhere to be found on Mozilla.org's frontpage. So
> far, when I want to write an application using XUL, JS and CSS, I
> have to make it as an extension of one of the Mozilla products
> (Firefox / Thunderbird / Seamonkey).
>
> Compare it with Microsoft's .NET's and its Windows.Forms therein. Say
> that I have created an application for it, which I want to
> distribute as a full-fledged standalone application. With .NET, I can
> tell users that the software only works if .NET has been installed.
> If it has not been, I could choose to include a redistributable, but
> that's of lesser importance.

Btw, there might ofcourse be reasons for not wanting to promote XUL &
co. as a platform :)... Aside from the UI stuff something like that also
needs a number of support-functions, amongst others related to security
issues e.d... A platform which is still shaping itself, changing, and
merely used by, developed for and tested with 2 specific products might
not (yet) be fit for use as a full-fledged platform.

It would probably cause many many more enhancement requests, bug reports
and security issues because of the different uses the product is put to.
And if Mozilla is under-staffed, as I understand from other messages,
that may be an extra responsibility they are not willing to take upon them.

That said, now what I'd /really/ like to see is an XUL API for .NET as
an alternative for Windows.Forms... Combined with the rest of the .NET
API (designed for and already existing cross-platform as Mono) it would
offer a very, *very* powerful and cross-platform development
environment. I really like XUL (with its great functionality,
skinnability, ease of editing and L10N abilities), and I really like the
.NET framework (with its great API with many functions for XML, hashing,
file access, e.d.)... you do the math :).

Gus Richter

unread,
Apr 4, 2004, 11:59:13 PM4/4/04
to
Boris Zbarsky wrote:

> Gus Richter wrote:
>
>> If desiring, for whatever reason, to deviate from the stated Mission
>> Statement, approval to change the Mission Statement must first be
>> obtained. Discussion, concerning the request, would alert all
>> interested parties.
>
>
> That sounds very cumbersome for simple day-to-day decisions like "what
> will I code today?" by volunteer developers.

You may be right about being cumbersome, certainly during start-off. I'm
sure that question was posed prior to implementation in companies that
are presently using it. It don't see it helping to decide, but would
provide guidelines.

> Unless I'm misunderstanding you and your scheme would apply to some
> higher level of planning?

It would meet all your concerns from the developer's point of view and
that of management as well. Perhaps there is a better, simpler or
modified way and then there's still the present method. Sorry that I did
not address your concerns directly, but if implemented, this method
would have.

--
Gus

Chris Hofmann

unread,
Apr 5, 2004, 2:27:15 AM4/5/04
to
James Graham wrote:

If you agree with the premise that the freezing of API's won't be
completely resolved in 1.8 and that we would just continue incremental
progress to reaching that goal then the trade off of would be

-some incremental freezing of selected APIs to help reduce the cost of
milestone migration for embeddors
v.
chance for a large bump in distribution across several apps

then I hope the rational for the decision becomes more clear.

We could always choose to wait for more API freezing, More features,
and More bug fixes. If we did so we would never ship releases...

I'm not sure how you define "substandard code", and I'm definitely
unclear about how that relates to the freezing of APIs. Perhaps you
could clarify.

When we freeze API's we generally stamp them as frozen, or we make some
final round of modifications and freeze them. When we do this we
effectively make a contract with the embeddors that they can count on
the interface not changing.

Groups that are embedding mozilla currently use a combination of frozen
APIs and unfrozen APIs. Arbitrary changes to APIs (a bad thing and to
be avoided), or changes that help lead toward the freezing of APIs
(general considered a good thing) both imply some cost to embeddors has
they attempt to migrate or upgrade to a new long lived stable branch.
We definitely want to continue along the road to reducing this cost to
embeddors and reach frozen API nirvana at some point. 1.7 won't be that
point, and it is unlikely that 1.8 would be that point either.

>
> Obviously this probably isn't the only thing that Boris had in mind
> but it's an interesting example because, had decisions been made
> proactivley before 1.6 branched in January there would have been no
> conflict of interests.

Its possible that more progress might have been made to freeze a few
more API's, possibility at the cost of a few fewer crash bug or
compatibility bug fixes. I'm not sure if I agree with the statement
that earlier and better clarity in the communication about 1.7 being a
candidate would have removed all conflicts of interest. There will
always be conflicts of interest, trade offs, and balance to be made on a
project of this size and scope.

> However it appears that the decision was made reactively and at the
> last possible moment.

The decision was made as the result of looking at all the data that we
could gather and digest, and with looking at what we thought was
feasible to accomplish in the next 6 weeks.

> Of course, if the goals of mozilla.org don't encompass the full range
> of objectives mentioned but only the first 3 then waiting for Firefox
> / Thunderbird / Camino to make a decision on which branch they want to
> be stable makes a lot more sense.

Embeddors can be successful in producing applications based on Mozilla.
Many groups are doing this, and more are starting projects to do this.
The plan is to continue to freeze APIs in 1.8, 1.9, and beyond to help
reduce the cost to embeddors as they migrate to new milestone releases.

> I assume this isn't the case, but without a very clear idea of what
> the actual goals of mozilla.org are (as opposed to the rather nebulous
> statements on the website), it's hard to tell if this is simply poor
> management or if it reflects the priorities of the organization.
>

Communication is a two way street. If anyone is confused about how the
goals and objectives of the project relate to specific work they are
doing for either a large scale project, or even individual day-to-day
"which bug should I work on?" questions I would encourage them to flag
down, drivers, staff, or maybe even post to an appropriate newsgroup
for peer feedback. I'm involved in these kind of discussions 30-40
hours a week, and the same could be said for Asa, Brendan and others on
drivers and staff. These discussions influence the decisions that are
made.

One of the tools we used effectively in the past to help roll up key
technical initiatives in the past was the branch landing tool.
http://webtools.mozilla.org/planning/branches.cgi I would encourage
people to start using this tool again.

drivers, can and will, use posting to the branch landing tool, e-mail
updates and questions with pointers to tracking bugs or tasks to help
improve planning and communicate plans earlier and with more clarity to
all interested parties. The criticism about the tardiness of the 1.7
stable branch message is fair and I take full responsibility for it. I
hope it has not, or will not, cause significant problems for any group
or individual, and that the entire project can move forward to try and
make the 1.7 branch the best that it can be.

Thanks

Chris Hofmann

> james
>
> [1] http://www.mozillazine.org/talkback.html?article=4544#3

James Graham

unread,
Apr 5, 2004, 11:51:03 AM4/5/04
to

The problem is not the decision to make 1.7 stable per-se, it's the fact
that the decision was made so late and the fact that no allowance was
made for the puported goals of mozilla.org other than 'create a good
browser'.

> I'm not sure how you define "substandard code", and I'm definitely
> unclear about how that relates to the freezing of APIs. Perhaps you
> could clarify.

I was basing that on what bz said in the mozillazine thread I previously
mentioned. It appears that there was work people wanted to get in before
the next stable branch but which was not completed in the 1.7 cycle
because it was not announced that it would be the next stable branch
until recently.

> When we freeze API's we generally stamp them as frozen, or we make some
> final round of modifications and freeze them. When we do this we
> effectively make a contract with the embeddors that they can count on
> the interface not changing.
> Groups that are embedding mozilla currently use a combination of frozen
> APIs and unfrozen APIs. Arbitrary changes to APIs (a bad thing and to
> be avoided), or changes that help lead toward the freezing of APIs
> (general considered a good thing) both imply some cost to embeddors has
> they attempt to migrate or upgrade to a new long lived stable branch.
> We definitely want to continue along the road to reducing this cost to
> embeddors and reach frozen API nirvana at some point. 1.7 won't be that
> point, and it is unlikely that 1.8 would be that point either.

As far as I can tell, the goal of having being able to create an entire
embedding product from frozen APIs is very distant. I certianly don't
think that 1.8 would have acheived that. However that doesn't mean that
there can't be levels of instability. For example, if one is planning a
major improvement to some API, it might be good to get that in before a
stable branch so minimising the difficulty of maintaining a stable
release and a trunk-based release of a product. If one has several
similar APIs which are being modified to some new way of working, it
might be nice to finish those changes before a stable branch so that
developers don't have to spend a lot of time learning differences
between the APIs that will vanish with the next milestone.

>> Obviously this probably isn't the only thing that Boris had in mind
>> but it's an interesting example because, had decisions been made
>> proactivley before 1.6 branched in January there would have been no
>> conflict of interests.
>
>
> Its possible that more progress might have been made to freeze a few
> more API's, possibility at the cost of a few fewer crash bug or
> compatibility bug fixes.

Possibly, but more likely, at the expense of a few non-critical feature
requests or other enhancements. In any case, crash bugs can be fixed
after beta, major pieces of code cannot.

My central point is, if the organisation had communicated to developers
that 1.7 was going to be stable and that several embeddors were planning
to release of 1.7, they could have prioritized work as they saw fit.
Instead, it looks like the decision was made with regard only to the
needs of the embeddors and without consideration for the people working
on the core. I assume that isn't actually the case but it's not clear.

> I'm not sure if I agree with the statement
> that earlier and better clarity in the communication about 1.7 being a
> candidate would have removed all conflicts of interest. There will
> always be conflicts of interest, trade offs, and balance to be made on a
> project of this size and scope.

Sure :) But better communication from drivers about the criteria on
which decisions are made (the goals of the project) and about the
decisions themselves can reduce those tradeoffs dramatically since
people know what to expect and can work around problem areas.

> The decision was made as the result of looking at all the data that we
> could gather and digest, and with looking at what we thought was
> feasible to accomplish in the next 6 weeks.

But why only 6 weeks? It must have been clear for a long time that
either 1.7 or 1.8 would be stable. In light of the fact that there are ~
3.5 seamonkey milestones per year, I would expect the next stable branch
(released in summer 2005) to be 1.10 or 1.11, based on past history. I
believe that Camino and Firefox were making plans at the end of January
to release from 1.7. Given that these plans were clearly a large factor
in the eventual decision, it seems reasonable that it could have been
made before 1.6 branched for release.

> drivers, can and will, use posting to the branch landing tool, e-mail
> updates and questions with pointers to tracking bugs or tasks to help
> improve planning and communicate plans earlier and with more clarity to
> all interested parties. The criticism about the tardiness of the 1.7
> stable branch message is fair and I take full responsibility for it. I
> hope it has not, or will not, cause significant problems for any group
> or individual, and that the entire project can move forward to try and
> make the 1.7 branch the best that it can be.

Obviously, I want people to try and make 1.7, and all the subsequent
work on the project as good as it can be. Of course, this relates
somewhat to people having a clear idea what is percieved as being 'good'.

Chris Hofmann

unread,
Apr 5, 2004, 3:58:57 PM4/5/04
to
James Graham wrote:

> Chris Hofmann wrote:
>
>>
[snip]

>
> The problem is not the decision to make 1.7 stable per-se, it's the
> fact that the decision was made so late and the fact that no allowance
> was made for the puported goals of mozilla.org other than 'create a
> good browser'.
>

Again, I apologize for not working to get this message out earlier.

>> I'm not sure how you define "substandard code", and I'm definitely
>> unclear about how that relates to the freezing of APIs. Perhaps you
>> could clarify.
>
>
> I was basing that on what bz said in the mozillazine thread I
> previously mentioned. It appears that there was work people wanted to
> get in before the next stable branch but which was not completed in
> the 1.7 cycle because it was not announced that it would be the next
> stable branch until recently.
>

It may or may not have been appropriate on this case, but drivers always
has, and always will, encourage engineers to send mail to discuss areas
of work that are on the verge of not making making an alpha or beta
cycle for consideration in landing very early after a tree closure.
This is a case by case evaluation and we often take things late in the
development cycle that can significantly improve the milestone release,
and still offer a good deal of comfort that we can shake out any
problems associated with landings at the end of the development cycle.
I hope that all people working on the project understand this and
continue to use this to get help in landing important stuff at the end
of cycles.

[snip]

>
> But why only 6 weeks? It must have been clear for a long time that
> either 1.7 or 1.8 would be stable. In light of the fact that there are
> ~ 3.5 seamonkey milestones per year, I would expect the next stable
> branch (released in summer 2005) to be 1.10 or 1.11, based on past
> history.

Again I apologize. There are no good excuses here. Only poor ones
about trying to get too many things done on too many fronts, and
dropping the ball on a very important task.

I should say that we have a need to to at least one major release per
year we we try to align most of the organizations building on top of and
distributing mozilla to work together to make it significantly better
and more tested than others, if that has not been said before or is not
well understood. So much good work goes on in the course of the year
that should get those improvements to the widest distribution possible.
For example 1.7 has 20-30% page loading performance improvement over
1.4, and footprint requirements also have great improvements. The list
of improvements is long when you look at the things that have been
accomplished over the last year. We need to get all the major Linux
distros and others to move up to 1.7 and start getting the improvement
in the hands of their users.

Mozilla 1.0 Shipped in June 2002 and Mozilla 1.4 Shipped in June 2003 so
if your looking at past history June is a good month for trying to meet
the needs of distributors...

[snip]

James Graham

unread,
Apr 5, 2004, 6:05:43 PM4/5/04
to
Chris Hofmann wrote:
> Again I apologize. There are no good excuses here. Only poor ones
> about trying to get too many things done on too many fronts, and
> dropping the ball on a very important task.

Chris, thanks for taking the time to respond, it's very much
appreciated. I certainly have very high hopes for the products being
released off the 1.7 branch :)

L. David Baron

unread,
Apr 5, 2004, 7:38:58 PM4/5/04
to
On Saturday 2004-04-03 19:28 -0600, Boris Zbarsky wrote:
> As the subject says, what are the goals of Mozilla.org?

I think an interesting question to ask before that is: where should
mozilla.org's goals come from? I think the source of goals should be
from mozilla.org's contributors (of all types), since at the most basic
level mozilla.org is an organization that allows people to collaborate
on projects that they could not do themselves. This implies a few
things:

a. Its good we're having this discussion.

b. Some of these goals, or their requirements, or their requirements'
requirements (etc.) may in turn require paying attention to the
goals (and their requirements) of people who aren't contributors.
The main example of this is that contributors may want their work to
be used by as many people as possible, either for its own sake, or
to help fulfill some other goal they have (such as helping to keep
the web based on open standards). This implies that we should pay
attention to the goals of distributors of our software and of
potential contributors.

Thinking of this in terms of goals and requirements probably isn't the
best idea, since it treats goals and requirements as binary when they
aren't. But given that this discussion is framed in terms of goals
rather than utility, and I've already written most of this message
before realizing that it's the wrong framework, I'll stick with that
framework until the last paragraph.

> I see several possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.
>
> These are not mutually exclusive, of course. Which of these are actual
> goals (as opposed to accidental byproducts), and what are their relative
> priorities?

Here's another question: should mozilla.org be in the business of
defining its goals? Perhaps, instead, it should (A) provide a forum for
people to state their case for various goals, and (B) try to mediate
when the goals come into conflict. However, as a practical matter, many
of the goals *do* conflict, so (B) probably requires that mozilla.org
actually define its goals. And the relative priorities of the goals
certainly conflict. So probably mozilla.org does need to define its
goals.

An example might be useful here. My main goal is to keep the Web
developing towards a universal system for access to information, which I
think requires that it be based on open standards. Thus I care about
our support for standards and I care about making Mozilla usable on the
Web. Doing this often has much smaller bugward-compatibility
requirements than maintaining a technology platform on which
applications can be written. I think it would be good for the web (for
reasons I won't go into here) to develop the XUL box model into
something that is usable as a web standard. If I were to work on this,
mozilla.org's current rules *might* require that I maintain more
backwards-compatibility than is necessary to keep our current
applications running, or that I fix up mozilla.org applications that are
in our tree that I don't care about. Should I be required by
mozilla.org to care about things like this that I don't care about
personally, or should the people who do care about it be required to fix
it (or provide a backwards-compatibility layer) if I break XUL
backwards-compatibility? And how should mozilla.org decide whether I
should be required to do so?


To try to answer a small part of your original question: I already said
that my main goal is to keep the Web developing towards a universal
system for access to information, which I think requires that it be
based on open standards. Thus I care about what you called (4), and I
care about anything else that leads to the product of (4) being used
more widely on the Web, which I think leads to (variants of?) (1), (2),
and (3) being requirements.

But that's speaking for myself only, and I'd be surprised if more than a
few other contributors agreed with me.

(It's also worth noting that I've avoided complicating this discussion
with issues of my goals vs. my employer's goals. I don't think that
makes the underlying issues any more complicated, it just makes
describing them more complicated. And when I refer to my goals above,
I'm talking about my personal goals, not the goals I have because
they're my employer's goals.)


Then there's the issue of what requirements would help meet that goal.
Or, more clearly stated, what would increase my utility as defined by
that statement. Lately, I've been having trouble finding good answers
to that question, since I've been having trouble thinking of attainable
goals that I believe could have a noticeable change in the expected
utility.

-David

--
L. David Baron <URL: http://dbaron.org/ >

Ben Goodger

unread,
Apr 5, 2004, 11:49:11 PM4/5/04
to Boris Zbarsky
Boris Zbarsky wrote:

> I suppose the thing on my mind is that the project seems to lack clear
> goals and clear direction and that project management decisions are
> consistently made in an ad-hoc, reactive manner ("oh, no, X finally
> happened, must do Y") instead of being made in a proactive manner
> ("should do Y so that when X happens (as we know it must) we are ready
> for it").

I would tend to agree. In some ways it's easy for my project since I
have a fairly clearly defined sub-roadmap that estimates timelines and
general zones of work between now and July/August or so this year. But
in the wider sense I (and others) are curious about where the platform
is going. There's been much talk about "Mozilla 2.0" in the past year
and what it must do to effectively deal with some of the new API
challenges that are emerging. There's been very low level talk about a
number of specific changes to functionality that exists presently
without a view of medium-long range goals, but not a great deal (at
least that I've heard, and I've asked many of the sources) of higher
level stuff outlining what the important projects are that need to be
accomplished before we can have a "2.0". By higher level I don't mean
executive summaries - I mean identified projects and project plans.

It might seem like I'd only be interested in 1, 2 and 3 because of my
role, and while those are certainly primary interests of mine, 5 and the
first 6 are also interesting, but specifically 5. It's something I've
given a great deal of thought to in the past, and a place where I
believe there may be lucrative opportunities in the future. There are
many challenges that still need to be overcome before Mozilla technology
can compete at the same level as other platforms, and an understanding
of what people think "2.0" means is central to that, in my mind.

I hate to sound like a project manager, but I think that's what's needed
here.

1) Mozilla will (at least for the short-mid-term future, as far as I can
tell) be about creating a web browser
2) ... and about a mail solution (we have to keep the lights on).
3) If we want a platform for building apps (and 4 may be a subset of 6),
and that effort is one of the targets of a 2.0, we need to do some
things - identify what it means to be a next generation platform (that
means not targeting GTK/GNOME today, Windows 2000 or XP SDKs as they are
today, but what they're doing next), divvy that task up into sections
and get resources allocated, estimates - work plans. There's been so
much talk about this lately that I feel my head is going to explode. So
much talk, so much hand waving, so few plans.

-Ben

Brendan Eich

unread,
Apr 6, 2004, 1:43:50 AM4/6/04
to Boris Zbarsky
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.


(I'm going to refer to this second item 6 as (7) below.)


> These are not mutually exclusive, of course. Which of these are actual
> goals (as opposed to accidental byproducts), and what are their relative
> priorities?
>
> Inquiring minds want to know,


Thanks for writing -- you're asking exactly the right questions. Some
of what I write below follows from the slides I presented at Developer
Day (http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/).

I liked dbaron's followup where he brought up "utility", something from
the Dismal Science that hints at the true nature of our problem
(scarcity, subjective value). Goals and requirements sound all
scientific, or bureaucratic. Life isn't that simple, but people often
would rather it were; Armies are great simplifiers, in this sense.

Mozilla is not the Army. That's the good news. The bad news is that we
have Redmond's army ants arrayed against us. We need strong leadership
*and* external allies, if we are to preserve much of the utility
(however subjectively valued) of open standards.

Mozilla can't be a laissez-faire anarchy where staff just resolves
conflicts, because we face not only built-in conflicts, but what's more,
competition from aggressive monopolies and near-monopolies. Although
Mozilla code will be around for many years, it may become increasingly
irrelevant without two things:

A. Browser user agent market share.

B. *Useful, efficiently implementable, easily authored* open standards
co-evolved with killer applications, such that those standards compete
with counterparts in the proprietary systems (Windows Longhorn,
Macromedia Flex, etc.).

If we do only "the browser thing" (1-3 from your list of goals), we are
likely to be irrelevant in approximately five years. Not unused, but
trailing-edge; not built upon as a platform, not invested in even as a
hedge. Yet (1-3) are necessary, even if not sufficient.

Note that (2) and (3) may imply, for certain enterprises and reprobate
sites, supporting the IE DOM, Active X plugins, and other things we'd
rather not support. If we don't support some of these things, we may
not in fact succeed in competing with IE enough to get sufficient (A).

Why will we likely be irrelevant without more than a good web browser?
The answer is involved; bear with me.

First, Longhorn formats such as XAML will leak onto the web, satisfying
your goals (5-6). We can predict this with high confidence based on the
IE4 experience. In 1997, IE4 shipped a better browser, with
non-standard CSS bugs, DOM quirks, and DHTML features, and of course
things like Active X. By 2000, when IE was crossing the 50% market
share barrier, sites were (intentionally or not) restricting
interoperation to IE clients only.

Another Windows predictor: Windows XP took ~2.5 years to pass 40%
according to Google zeitgeist.

Second, Linux is poised to rise just by being cheaper. "Total Cost of
Ownership" compared to Windows is hard to assess currently, with many
variables, confounders, and hidden costs on both sides. Some experts
claim Windows has lower TCO right now. But assume Linux improves and
wins. This seems a fairly safe prediction, as predictions go --
especially in other parts of the world.

The problem I foresee is that Linux may very well not ship a default
Mozilla browser, relegating Gecko to the category of web-content engine,
soon to be "legacy" web content engine. In this light, we might make
(4) an anti-goal. Given trends in at least the GNOME world, the likely
result of the default-browser decision favoring a GNOME browser is that
GNOME/Linux desktops and apps evolve to compete with Windows Longhorn by
solving roughly the same problems in different ways (Mono or no Mono).

The long-term result would be not only a lack of cross-platform apps --
there would be a lack of new cross-platform contents and protocols
needed to countervail XAML and other Longhorn formats, protocols, and
languages. We can see the beginning of this fragmentation, although not
along OS lines so much as proprietary client lines, with Flex from
Macromedia, Laszlo's XML-based language, and similar children of XUL
from the "rich internet application" platform players.

If Miguel and company clone XAML and Avalon (the harder part to clone),
perhaps in three years Linux will be able to match most of what we can
see coming in Longhorn in the way of open-standards-threatening content.
But that content will still be relatively or completely closed, under
the control of Microsoft, subject to revision at its discretion. Not a
pretty picture, even if Mono *eventually* helps apply de-facto or even
de-jure standardization pressure.

What seems worse, though, is the likelihood that XML-based content types
might proliferate and speciate along platform lines: some for Linux,
others for Windows. Without cross-platform browsers implementing the
same standards everywhere, including the new, non-legacy, ones, the
likelihood of interoperation bugs and outright incompatible/non-portable
formats grows.

In all this, I'm discounting the Mac. It's an important and influential
niche, one that Mozilla values, but not one likely to grow enough to
make a difference compared to Linux and Windows. If the OS and
especially the multimedia apps were to be ported to PCs and opened up to
developers on other platforms, maybe -- but those steps would undercut a
lot of Apple's profitability, its platform's strengths, and its appeal
(yes, including its snob appeal).

Here's an alternative that I'm working hard to promote:

I. Build cross-platform apps from the ground up, using Gecko, native
theme-based rendering, and good desktop/OS integration.

II. Promote these apps, starting now -- think Mozilla-the-suite,
Firefox, Thunderbird, Open Office -- on Windows, especially in
enterprises that wish to avoid lock-in, virus hazards, and high license
fees.

III. Let those enterprises migrate to Linux if it makes sense, or defer
the hefty Longhorn upgrade tax by sticking with downrev Windows for as
many years as makes sense.

IV. At the same time, starting now and working closely with other open
source hackers, build a new, unified desktop/web application platform
from pieces of Mozilla and GNOME code, starting now. Share code and
effort; avoid big rewrites. Use standards where possible, including the
parts of XUL that are being specified now. This new platform might even
deserve the "Mozilla 2.0" title.

This new platform must include an advanced rendering layer with hardware
acceleration, fancy effects, animation, video, etc. We should use what
works now, with as much cross-platform leverage (OpenGL), filling in
gaps on some platforms, and again (always) avoid long-pole scheduling
dependencies where the entire subsystem must be rewritten.

Another characteristic of this new platform: high-level programming
language independence, with a good choice of "managed code" runtimes
(Java, Mono C#, JS2, ...) for type-safe buffer-overrun-free programming.
We must not keep losing fingers and toes to C and C++; that approach
is a money loser compared to .NET.

A crucial features of this new platform: the GUI toolkit must be able to
blend in among native apps, at least on Windows and Linux, ideally on
Mac too. There should be a well-specified XML syntax and semantics for
creating user interfaces (XUL) and graphics (SVG or something like it,
but unified), and for composing tags from DOM trees (XBL). There must
be a low-cost migration path from XUL today to this future language.

I've been busy laying groundwork, building bridges between different
open source projects. It's still too early to say exactly how things
will turn out. I don't want to make promises that I can't keep, and a
lot of planets have to align still. But there is interest among other
key projects' leaders. I think a number of smart folks see the need for
alliance against the hegemon.

This platform play would address (5-6) by marrying, as much as allying,
GNOME, Mozilla, and perhaps Mono -- bringing cross-platform code and
development to the Linux side, and native next-generation GNOME look and
feel to Mozilla. It would build something we've been unable to build in
a compelling or complete way by ourselves: a development platform for
arbitrary third party web and desktop apps.

The time frame for this plan is now, with working code by 2nd half of
this year. Otherwise we're sliding into next year, in danger of being
too late to gain mindshare before Longhorn's inevitability wins the day
for XAML, etc. So, if this is to succeed, we have major concurrent
development challenges ahead.

I'll answer any questions I can here, and I encourage all comments. If
something in the analysis above rings false, please say what and why. If
you're following up just one point, feel free to change the subject to
start a sub-thread.

/be

Axel Hecht

unread,
Apr 6, 2004, 8:32:09 AM4/6/04
to
Brendan Eich wrote:

<...>

I'd like to note that there is a pretty nice talk by Tim O'Reilly about
"paradigm shift". He basically said that single-computer-apps wont win a
thing in the future and that control over the wire will determine market
share. He used the term "commodity software" quite a lot, mostly talking
about LAMP on the server side. But IMHO, Mozilla is an important part of
commodity software in this scheme as well. And Tim didn't oppose to
that. Not sure if he would have dared, he just broke his one arm ;-).


>
> Here's an alternative that I'm working hard to promote:
>
> I. Build cross-platform apps from the ground up, using Gecko, native
> theme-based rendering, and good desktop/OS integration.

How far are we done here? 20% or 80%?

> II. Promote these apps, starting now -- think Mozilla-the-suite,
> Firefox, Thunderbird, Open Office -- on Windows, especially in
> enterprises that wish to avoid lock-in, virus hazards, and high license
> fees.
>
> III. Let those enterprises migrate to Linux if it makes sense, or defer
> the hefty Longhorn upgrade tax by sticking with downrev Windows for as
> many years as makes sense.
>
> IV. At the same time, starting now and working closely with other open
> source hackers, build a new, unified desktop/web application platform
> from pieces of Mozilla and GNOME code, starting now. Share code and
> effort; avoid big rewrites. Use standards where possible, including the
> parts of XUL that are being specified now. This new platform might even
> deserve the "Mozilla 2.0" title.
>
> This new platform must include an advanced rendering layer with hardware
> acceleration, fancy effects, animation, video, etc. We should use what
> works now, with as much cross-platform leverage (OpenGL), filling in
> gaps on some platforms, and again (always) avoid long-pole scheduling
> dependencies where the entire subsystem must be rewritten.

How much manpower do we have for cross-platform-widget code these days?

> Another characteristic of this new platform: high-level programming
> language independence, with a good choice of "managed code" runtimes
> (Java, Mono C#, JS2, ...) for type-safe buffer-overrun-free programming.
> We must not keep losing fingers and toes to C and C++; that approach is
> a money loser compared to .NET.
>
> A crucial features of this new platform: the GUI toolkit must be able to
> blend in among native apps, at least on Windows and Linux, ideally on
> Mac too. There should be a well-specified XML syntax and semantics for
> creating user interfaces (XUL) and graphics (SVG or something like it,
> but unified), and for composing tags from DOM trees (XBL). There must
> be a low-cost migration path from XUL today to this future language.

On the aspect of XBL, that needs a security model. And maybe other
things, as Alex Fritze felt forced to invent xtf,
http://www.croczilla.com/xtf

Changing the toolkit will open the fundamental point that dbaron
mentioned in his previous post. Who's doing the work.
(/me lays back and waits for glazou's rant.)

> I've been busy laying groundwork, building bridges between different
> open source projects. It's still too early to say exactly how things
> will turn out. I don't want to make promises that I can't keep, and a
> lot of planets have to align still. But there is interest among other
> key projects' leaders. I think a number of smart folks see the need for
> alliance against the hegemon.
>
> This platform play would address (5-6) by marrying, as much as allying,
> GNOME, Mozilla, and perhaps Mono -- bringing cross-platform code and
> development to the Linux side, and native next-generation GNOME look and
> feel to Mozilla. It would build something we've been unable to build in
> a compelling or complete way by ourselves: a development platform for
> arbitrary third party web and desktop apps.
>
> The time frame for this plan is now, with working code by 2nd half of
> this year. Otherwise we're sliding into next year, in danger of being
> too late to gain mindshare before Longhorn's inevitability wins the day
> for XAML, etc. So, if this is to succeed, we have major concurrent
> development challenges ahead.

That timeframe seems, say, very optimistic. "Timeframe now" in general
is a quarter too late, which made Boris start this thread.
OK, a month late for those working full time. But for contributors and
esp for modules without any full time staff, I think a quarter is closer.

> I'll answer any questions I can here, and I encourage all comments. If
> something in the analysis above rings false, please say what and why. If
> you're following up just one point, feel free to change the subject to
> start a sub-thread.
>
> /be

On a general note:
This post is pretty much worth two or three postings to
http://weblogs.mozillazine.org/roadmap/. And it's good to see at least
some of the vision of one of those doing the decisions in the end.
But let's keep in mind that a good direction with noone there to go
might do more harm than good. I see very good reasons for some aspects
of the Mozilla project being managed top-to-bottom, but as this thread
indicates, sometimes the bottom wonders who at the bottom is supposed to
implement the decisions.

On the edge on all of this, don't forget that some folks try to make a
living off the Mozilla platform. Their business plans rise and fall with
the decisions made here (and not here).

Axel

KaiRo - Robert Kaiser

unread,
Apr 6, 2004, 1:55:12 PM4/6/04
to
> build a new, unified desktop/web application platform
> from pieces of Mozilla and GNOME code, starting now.

I still think that it's a shame that Mozilla project is ignoring KDE
(and the other way round). Konqueror/KHTML seem not to be reason enough
for me to be that ignorant. This looks to me as it may lead to a massive
split with some Linux distributors and a big community user, as many of
them strongly support KDE.
OTOH, we need to focus on working on something, and we can't let
ourselves get split up into working on too many different things. And as
GNOME people have no good web browser but Gecko-based products, it's the
logical thing to do. If we really want an alliance of OSS projects to
win, we should not ignore that half of the Linux desktops (or more) are
not on GNOME but KDE, and we only can achieve good support of the OSS
communities by integrating with that as well, IMO.
We may not build everything with KDE in a "unified platform" - but we
should be able integrate much, much more. We're losing market on Linux
if we don't, I fear.

Robert Kaiser

Asa Dotzler

unread,
Apr 6, 2004, 2:01:05 PM4/6/04
to
James Graham wrote:

> believe that Camino and Firefox were making plans at the end of January
> to release from 1.7. Given that these plans were clearly a large factor
> in the eventual decision, it seems reasonable that it could have been
> made before 1.6 branched for release.

1.6 branched _in December_. If Firefox and Camino (and other projects)
were just beginning to converge on 1.7 at the _end of January_, how
could any decision have been made before 1.6 branched in December? In
addition to all of our other work, we're supposed to have invented time
travel, too?

--Asa

Brendan Eich

unread,
Apr 6, 2004, 2:20:39 PM4/6/04
to Axel Hecht
Axel Hecht wrote:
> Brendan Eich wrote:
>
> <...>
>
> I'd like to note that there is a pretty nice talk by Tim O'Reilly about
> "paradigm shift". He basically said that single-computer-apps wont win a
> thing in the future and that control over the wire will determine market
> share. He used the term "commodity software" quite a lot, mostly talking
> about LAMP on the server side.


This was at OSCON last summer, right? I was there, but I think that
keynote echoed things Tim had said elsewhere. Maybe you meant a
different talk, say http://tim.oreilly.com/p2p/FOSDEM.pdf?


> But IMHO, Mozilla is an important part of
> commodity software in this scheme as well. And Tim didn't oppose to
> that. Not sure if he would have dared, he just broke his one arm ;-).


http://primates.ximian.com/~miguel/tmp/two-stacks.png


Still, Mozilla is not a platform first -- it has been, intentionally, a
platform second, in order to build certain apps first.

I'm suggesting that we must keep building killer apps, but also partner
with other open source projects, in order to build a more coherent
platform that can withstand what's coming in Longhorn. And better yet,
be the base for new apps that we and others build, to do the kind of
collaborative networking, shared browsing, and pervasive computing that
Tim talks about.


>> Here's an alternative that I'm working hard to promote:
>>
>> I. Build cross-platform apps from the ground up, using Gecko, native
>> theme-based rendering, and good desktop/OS integration.
>
>
> How far are we done here? 20% or 80%?


For item II, below, we are at least 80% -- we can promote Firefox to
enterprises when it reaches 1.0, which will be some time this summer, if
all goes as planned. The Mozilla suite is already used by enterprises;
the "1.0" for both it and the platform it was built on was 2 years ago.
Thunderbird is right behind Firefox.

Implied but not stated in my original post was the idea that by building
a new platform with GNOME and others, with a clear migration path from
today's Mozilla platform, we could then bring up Firefox and Thunderbird
on the new platform, next year.


> How much manpower do we have for cross-platform-widget code these days?


More than a few paid developers in the Mozilla and GNOME worlds, if the
alliance can be pulled off. Many more volunteers from both communities.
The manpower problem is eased, not made worse, by alliance with other
projects.


> On the aspect of XBL, that needs a security model. And maybe other
> things, as Alex Fritze felt forced to invent xtf,
> http://www.croczilla.com/xtf


It seems to me (Alex, please jump in here) that XTF addresses different
requirements than XBL. I like XTF, though (but its name hurts my hands,
especially when I've been typing Xft lately ;-). I'd like to hear some
comments from content and layout folks (bz, dbaron, jst) on whether they
think it would be advisable to land the branch soon and support XTF by
default.


> Changing the toolkit will open the fundamental point that dbaron
> mentioned in his previous post. Who's doing the work.
> (/me lays back and waits for glazou's rant.)


More than just us in our Mozilla bunker; that's the idea, anyway.


> That timeframe seems, say, very optimistic. "Timeframe now" in general
> is a quarter too late, which made Boris start this thread.


Sorry, can't be helped. Better now than later. The problem is that we
haven't yet joined forces at an operational level with GNOME hackers.
To do that requires more negotiation on details with project leadership.


> On a general note:
> This post is pretty much worth two or three postings to
> http://weblogs.mozillazine.org/roadmap/.


Good idea, I'll update that. I'm not used to blogging, but posting to
newsgroups isn't that far from blogging.


> And it's good to see at least
> some of the vision of one of those doing the decisions in the end.
> But let's keep in mind that a good direction with noone there to go
> might do more harm than good. I see very good reasons for some aspects
> of the Mozilla project being managed top-to-bottom, but as this thread
> indicates, sometimes the bottom wonders who at the bottom is supposed to
> implement the decisions.


The 1.7-as-stable-year-long-release-branch decision should have been
announced earlier, but I don't think I could have said much about the
GNOME/Mozilla alliance earlier without lying. Even now, I'm not sure
how things will play out, but I'm convinced that to be a complete and
compelling platform, we need more than what we ourselves can do.
Specifically, we need the blessings of "native-ness" on Linux, as well
as "managed code" runtime support and programming language neutrality
(or good plurality), and killer hardware accelerated graphics.

I'm glad you pointed out http://www.croczilla.com/xtf, which I'd glanced
at the other week while looking at jssh. I think Mozilla needs the kind
of high-leverage hacking shown there. Hacking useful new things on top
of Mozilla-the-platform should not be that hard. It's getting easier if
you know the right fulcrums to use.

We do need to hide details where the implementation will have to change,
and where we plan to do incremental rearchitecture (reflow, line
breaking, etc. in layout, e.g.). We need a bit more symmetry and
completeness in the code, and a lot more documentation (DevMo, see the
threads at news://news.mozilla.org/netscape.public.mozilla.documentation
and stay tuned for an update).


> On the edge on all of this, don't forget that some folks try to make a
> living off the Mozilla platform. Their business plans rise and fall with
> the decisions made here (and not here).


That reminds me: whatever future toolkit with XML syntax comes from the
alliance being forged with GNOME and other projects, and also from the
standardization efforts in the w3c, Mozilla will keep compatibility with
XUL 1.0 and XBL 1.0, possibly unbundled so minimal "2.0" apps don't have
to carry the weight if they don't need it.

The only sure way to keep compatibility is to leave the old code as
untouched as possible. So the new platform work will have to be done
beside the current gfx, widget, and xul widget layers, by implementing
existing interfaces, introducing new ones used only conditionally, etc.

More on the operational details and tasks in a bit.

/be

us...@domain.invalid

unread,
Apr 6, 2004, 2:39:33 PM4/6/04
to
KaiRo - Robert Kaiser wrote:

I use KDE all the time. If Mozilla didn't actually WORK in KDE I'd have
to do something about it.

As far as Qt integration goes, there is no barrier to someone building
gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
integration into Mozilla. No-one has volunteered to do it, and no
companies seem interested in doing it. So it hasn't been done.

Rob

Laurens Holst

unread,
Apr 6, 2004, 3:29:48 PM4/6/04
to
Wonderful text. I'm looking forward to this, really. I voiced some of my
opinions on issues like this a few messages ago, and this sounds like
the ideal solution ^_^.

Furthermore, I read this article yesterday:
http://ometer.com/desktop-language.html

You probably already know it, but for those who don't, it forms a nice
background to this and the discussion and concern apparantly (and
rightfully) forming in the opensource community about the possibility of
starting to lag behind on modern technologies (in particular: OO
programming languages with garbage collection and JIT, etc).

That article sounds more in favour of Java than Mono, and I find that
somewhat of a shame as I really dislike developing in Java. Let's just
say I always have to fight to get things working, while in the contrary
.NET (/ Mono) has been a breeze :). However, that is mostly an API
problem, I think. XUL is a big improvement over what both environments
have to offer, UI-wise. For the Visual Studio addicts, an UI designer
tool would make XUL even more accessible to people.

Let's hope this proposed platform will offer lots of easy-to-use
functions in a wide range, and provide the nessecary shorthands when
they come in handy for actual development purposes. .NET does a good job
at this, and I hope this platform you are suggesting will do an even
better job, and then *truly* cross-platform :). Oh, and let's not forget
to introduce revolutionary new technologies, instead of following in
M$'s wake. Or at least it seems a little like that right now :), panic
all around because of fear of falling behind (and not unrightly so).

Anyways, I'm no active developer in this area (I'd rather stick to my
small personal projects :)), but I'm looking forward to what is going to
happen the next few years. Interesting times :).

L. David Baron

unread,
Apr 6, 2004, 3:56:52 PM4/6/04
to
On Tuesday 2004-04-06 14:39 -0400, us...@domain.invalid wrote:
> As far as Qt integration goes, there is no barrier to someone building
> gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
> integration into Mozilla. No-one has volunteered to do it, and no
> companies seem interested in doing it. So it hasn't been done.

The first two have been done. However, the code wasn't maintained, so
it was removed from the tree.

Brendan Eich

unread,
Apr 6, 2004, 6:25:20 PM4/6/04
to Axel Hecht
Axel Hecht wrote:
> Brendan Eich wrote:
>
>> Here's an alternative that I'm working hard to promote:
>>
>> I. Build cross-platform apps from the ground up, using Gecko, native
>> theme-based rendering, and good desktop/OS integration.
>
>
> How far are we done here? 20% or 80%?


The longest pole for the 1.0 apps is the "good desktop/OS integration",
particularly GNOME integration and GTK theme-based rendering. The bug
tracking this work is http://bugzilla.mozilla.org/show_bug.cgi?id=233462.

For most of the work items, we can buy by the yard, so to speak, up till
near the last freeze date for Firefox 1.0, without adding too much risk.

Please jump in and offer to help on the unfixed dependencies of this
bug. bryner and p_ch could surely use the help.

/be

Robert O'Callahan

unread,
Apr 6, 2004, 8:48:28 PM4/6/04
to
L. David Baron wrote:
> On Tuesday 2004-04-06 14:39 -0400, us...@domain.invalid wrote:
>
>>As far as Qt integration goes, there is no barrier to someone building
>>gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
>>integration into Mozilla. No-one has volunteered to do it, and no
>>companies seem interested in doing it. So it hasn't been done.
>
>
> The first two have been done. However, the code wasn't maintained, so
> it was removed from the tree.

Yeah, well I wasn't about to bring that up :-). It was never done *well*.

Rob

Dennis McCunney

unread,
Apr 7, 2004, 12:21:12 AM4/7/04
to
Brendan Eich wrote:

> I'll answer any questions I can here, and I encourage all comments. If
> something in the analysis above rings false, please say what and why. If
> you're following up just one point, feel free to change the subject to
> start a sub-thread.

Brendan, thanks for the analysis and reply.

Allow me to toss in a few thoughts of my own, because I've been thinking
about the issue as well.

Ultimately, this is about *marketing*.

The legendary management consultant Peter F. Drucker once said "The job
of business is to *create* a market". To do so, you need to understand
who the customer is, and what the customer needs. In many cases,
success will be a result of filling a need the customer didn't realise
she had until your particular widget was there to do whatever it does.

A lot of Open Source development I see reminds me of the late, lamented
Digital Equipment Corporation, run by engineers, producing cool
technology with what products might be made using the technology as an
afterthought. DEC isn't with us any more, and there are reasons for
that. Another horrible example might be Xerox Corp., with a habit of
creating great technology that someone *else* made into a killer
product. Without Xerox PARC, the Star workstation, and Smalltalk, we
wouldn't have the Mac *or* Windows, with mice and bit-mapped GUIs, but
Xerox never made a commercial success of the developments they
pioneered, and while Xerox is still with us, it has problems.

A lot of open source development is done by hackers working on cool code
without any real concept of who will *use* what they write.

The first question I would ask is "What is Mozilla?"

The answer *used* to be "Netscape's code name for the rewrite of
Netscape Communicator to produce a product that could compete with
Internet Explorer". That's not true any more. Netscape formally
divested itself of Mozilla.

I've seen well-reasoned arguments elsewhere that Netscape was barking
mad to toss out the existing Navigator code base and go for a ground-up
rewrite. Among other things, it took three years for the first fruits
of that labor to get out the door, whereas refactoring and enhancing the
existing code might have been done a lot sooner.

Also, to be able to create the browser they wanted, the Mozilla
developers first had to create a new set of tools and technologies they
could use to accomplish what they wanted. They did so, and the results
have been stunning.

I would call that set of tools and technologies Mozilla, and the Mozilla
browser simply one product that was created with it.

If I were marketing Mozilla, I wouldn't push the browser as the end
product. I'd push what I used to *create* the browser, and use the
browser as a real world example of what Mozilla can be used to create.

The second question I would ask is "Who is the customer?"

Back when Mozilla was still a Netscape funded effort to create the next
generation browser, that question was easy: the customer was Netscape,
and Netscape's vision of what *thier* customers wanted shaped the
requirements for the product.

Microsoft succeeded because there was a clear vision of what they were
building and who would use it. While there were doubtless internal
debates in Redmond about *how* to accomplish certain goals, they had
goals, based upon thier conception of who thier customers were, and what
thier customers would *pay* for.

Who are Mozilla's customers? Mozilla used to repeatedly say that the
actual Mozilla releases were for testing and development purposes, and
not intended for use by end-users. The assumption was that if you were
an end-user, you probably wanted the Netscape browser built on top of
the Mozilla code base.

Netscape is no longer the driver here, and more and more end-users *are*
using Seamonkey (or Firefox/Thunderbird), so Mozilla *is* now an
end-user product. But I don't think the Mozilla planning or development
process has truly grasped that yet. How many critical bugs are ignored,
or useful features unimplemented, because they aren't important or sexy
enough to the developers who would have to do it, and the developers
aren't focused on the needs of the end-users?

I'd split Mozilla.org's mission into two parts.

One would focus on polishing and refining the browser and other
components, because these are the real world examples of what can be
done with Mozilla technology, and it's in Mozilla's interest for as many
people as possible to be using them. The first group's customer would
be the end users.

The second part would focus on developing and extending the tools and
technologies used to created the browser. The second group's customers
would be other developers, looking for a better way to create
applications for end users.

I'd be a customer for both, but I'd have different needs.

As an end user, I use Mozilla as my production browser. I need it to be
fast and stable, and I need it to be easily extensible to handle tasks
related to it's primary mission. That mission, for me, is information
retrieval and storage. So I want the code base to settle, and I want to
be able to do things like install an extension, expect it to work in
either Mozilla or Firefox, and be able to disable or uninstall it if needed.

As a developer, I am looking for Mozilla based tools I can use to
develop applications for end-users. I'm a Unix SysAdmin for a living.
I support a number of non-technical users who access my servers to run
production applications. They don't know anything about the servers
they access, or about Unix, and they don't want to and shouldn't have
to. One of the things I've been thinking about is GUI front-ends on PCs
connecting the the production application on the back end, and giving
the users something more intuitive than a shell command prompt to work
with. CSS, XUL, and Javascript strike me as a perfect way to do that.

If I had a lot of money to fund a development effort, I'd pay someone to
write a GUI, drag-and-drop application builder that would generate CSS,
XUL and Javascript to create front-ends that would talk to server
applications on the back end, and free folks like me to define the
communications with the back end app and the interface between it and
the GUI.

Mozilla can solve a number of my problems, but only if the folks
creating Mozilla understand what my problems are. Multiply me by
(potentially) millions, and you define the challenge Mozilla faces.

> /be
______
Dennis

Daniel Glazman

unread,
Apr 7, 2004, 4:02:32 AM4/7/04
to
Boris Zbarsky wrote:

> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.

> 4) Create a platform for delivering apps over the network (not quite


> the same as a web browser, but close).

> 5) Create an embeddable rendering engine to enable creation of web
> browsers.
> 6) Create a technology platform on top of which applications (not just


> web browsers) can be written.

> 7) Something else I'm missing.

(the above items renumbered since your original numbering was bad)

Part of (7) is certainly "Create a platform for rich content editing".
This covers in-browser-editing (formerly known as Midas) and content
editors like Composer, Nvu, XML editors, XUL editors, ...
I am speaking for my own chapel only here, of course. That's why I
say "part of 7".

(2bis) is certainly "Create a mail user agent that can successfully
compete with OE". (3bis) is "Successfully compete with OE".

Please note that 2bis and 3bis could be MUCH EASIER to achieve
than 2 and 3... A lot of companies and governmental orgs are dropping OE
in favor of Mozilla because of security. Email is much more a
concern for sysadmins than the browser.

From my perspective, your items above are far too browser-centric.
Each time we have thought in a browser-centric way, we have introduced
improvements in the code that were bad for other apps.

The browser is the main application of the Mozilla platform, that's
for sure. But if we keep only that one in mind, we'll fail delivering
a platform to other applications' builders.

Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
We've not even started. Maybe MozFound should contract with Nigel
McFarlane and write with him the official Mozilla Technologies Embedding
Guide, sold as a book. I am very serious here.

Just my 2 eurocents.

</Daniel>

Axel Hecht

unread,
Apr 7, 2004, 4:13:29 AM4/7/04
to
Brendan Eich wrote:

> Axel Hecht wrote:
>
>> Brendan Eich wrote:
>>
>> <...>
>>
>> I'd like to note that there is a pretty nice talk by Tim O'Reilly
>> about "paradigm shift". He basically said that single-computer-apps
>> wont win a thing in the future and that control over the wire will
>> determine market share. He used the term "commodity software" quite a
>> lot, mostly talking about LAMP on the server side.
>
>
>
> This was at OSCON last summer, right? I was there, but I think that
> keynote echoed things Tim had said elsewhere. Maybe you meant a
> different talk, say http://tim.oreilly.com/p2p/FOSDEM.pdf?

I was listening to the talk at the FOSDEM.


>
>
> > But IMHO, Mozilla is an important part of
>
>> commodity software in this scheme as well. And Tim didn't oppose to
>> that. Not sure if he would have dared, he just broke his one arm ;-).
>
>
>
> http://primates.ximian.com/~miguel/tmp/two-stacks.png
>
>
> Still, Mozilla is not a platform first -- it has been, intentionally, a
> platform second, in order to build certain apps first.
>
> I'm suggesting that we must keep building killer apps, but also partner
> with other open source projects, in order to build a more coherent
> platform that can withstand what's coming in Longhorn. And better yet,
> be the base for new apps that we and others build, to do the kind of
> collaborative networking, shared browsing, and pervasive computing that
> Tim talks about.

What I was wondering for a bit, how much money do his friends like
amazon et al spend on getting their UI working in incompatible browsers?
If it'd be significant, we could get an ally or two over there.

Axel

Daniel Glazman

unread,
Apr 7, 2004, 4:10:09 AM4/7/04
to
Daniel Glazman wrote:

> Last point: ...

Sorry for spam, I forgot a _major_ point that Boris did not list:

"Successfully enter the mobile devices market with Minimo"

This item is _major_ for two reasons:

1. there is a place for Mozilla there
2. we can compete with Opera there
3. that's certainly for MozFound a good way of getting funds...
4. it forces us to think in terms of reduced footprint and perf
improvements, and that's good for the desktop apps too

</Daniel>

Axel Hecht

unread,
Apr 7, 2004, 4:15:38 AM4/7/04
to
us...@domain.invalid wrote:

Without any knowledge on how we hook up the toolkit, could we make that
pluggable? I bet the question cannot be "Gnome or KDE", but how to do
both with one installation.

Axel

Axel Hecht

unread,
Apr 7, 2004, 4:43:23 AM4/7/04
to
Daniel Glazman wrote:

<...>

> Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
> We've not even started. Maybe MozFound should contract with Nigel
> McFarlane and write with him the official Mozilla Technologies Embedding
> Guide, sold as a book. I am very serious here.

Well, we have started. Fantasi and Nigel head the devmo-drivers, and
though there is no content yet, we do have a start.

Of course, this is no paper work, at all. Not sure if any of the stuff
we're doing is reusable on paper. And I myself wouldn't focus on it to
start with, just because online documentation is a higher priority. And
online and paper docs just work completely different.

Axel

Benjamin D. Smedberg

unread,
Apr 7, 2004, 7:58:08 AM4/7/04
to
Daniel Glazman wrote:
> Part of (7) is certainly "Create a platform for rich content editing".
> This covers in-browser-editing (formerly known as Midas) and content
> editors like Composer, Nvu, XML editors, XUL editors, ...

Here here! In order for any reasonable "mozilla the platform"
application to succeed, we need to remember two functions that the
browser uses only sparingly: editing and printing. If we end up with a
great platform that can't do either of these, in the end we lose.

--BDS

fantasai

unread,
Apr 7, 2004, 9:10:29 AM4/7/04
to
Axel Hecht wrote:
>
> Well, we have started. Fantasi and Nigel head the devmo-drivers, and
> though there is no content yet, we do have a start.

Actually, Myk's doing most of the work, setting up infrastructure.

~fantasai

KaiRo - Robert Kaiser

unread,
Apr 7, 2004, 9:27:02 AM4/7/04
to
>> As far as Qt integration goes, there is no barrier to someone building
>> gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
>> integration into Mozilla. No-one has volunteered to do it, and no
>> companies seem interested in doing it. So it hasn't been done.
>>
>> Rob
>
> Without any knowledge on how we hook up the toolkit, could we make that
> pluggable? I bet the question cannot be "Gnome or KDE", but how to do
> both with one installation.

There was talk about that once, and it seems that it may be doable, but
as Qt support died, the question grew irrelevant.

I know there are people who'd like to help with doing a new Qt port
(actually there's no real use in reviving the old work, it seems, it has
to be redone completely, perhaps taking some ideas from the old work).
From time to time, talk arises about that in the still-existent
n.p.m.qt newsgroup, but as noone comes up to lead the work (should
ideally understand our framework and know Qt as well), it always dies again.
As with many things, we'd need a project leader (module owner) there,
then the project could take off easily on a branch/mini-branch.
I offered to be checking in work of people without CVS access on that
branch, and doing test builds from time to time.

Robert Kaiser

Heikki Toivonen

unread,
Apr 7, 2004, 2:26:19 PM4/7/04
to
Boris Zbarsky wrote:
> 6) Something else I'm missing.

Besides the mobile platform that was mentioned by Glazman, I feel we'd
really need more tools. Or maybe just one too, the killer XUL GUI builder.

We already have several very succesfull tools. The most well-known are
the webtools (Bugzilla at the front), but DOM Inspector and the JS
Debugger are pretty good.

On the GUI builder front, we have some external projects that seem to be
starved of resources. Microsoft has traditionally been very good a
providing good tools, and I feel our lack of a great, well-known GUI
builder is holding us back. Imagine a Visual Basic - or even Visual C++
- developer of 5 years hearing all this rant about the greatness of XUL
and the Mozilla platform deciding to give it a go, only to find that he
would need to hand edit cryptic XML files to get a simple dialog app
with a couple of buttons running!

--
Heikki Toivonen

Bogdan Stroe

unread,
Apr 7, 2004, 2:40:24 PM4/7/04
to
Heikki Toivonen wrote:

There is a proposal to integrate a Mozilla XUL builder into Eclipse IDE.
See http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/

Bogdan

Brendan Eich

unread,
Apr 7, 2004, 5:17:07 PM4/7/04
to Axel Hecht
Axel Hecht wrote:

>> I'm suggesting that we must keep building killer apps, but also
>> partner with other open source projects, in order to build a more
>> coherent platform that can withstand what's coming in Longhorn. And
>> better yet, be the base for new apps that we and others build, to do
>> the kind of collaborative networking, shared browsing, and pervasive
>> computing that Tim talks about.
>
>
> What I was wondering for a bit, how much money do his friends like
> amazon et al spend on getting their UI working in incompatible browsers?
> If it'd be significant, we could get an ally or two over there.


That browser compatibility problem won't go away any time soon, though.
IE is stagnant and it will be used for many years to come. We don't
know whether and how the Longhorn browser engine has been fixed, or not,
to match w3c specs -- I would guess "not".

So even if Firefox had big distribution deals, sites such as Amazon
would need to sweat browser compatibility for a long time yet.

/be

Brendan Eich

unread,
Apr 7, 2004, 5:12:40 PM4/7/04
to Daniel Glazman
Daniel Glazman wrote:

> Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
> We've not even started. Maybe MozFound should contract with Nigel
> McFarlane and write with him the official Mozilla Technologies Embedding
> Guide, sold as a book. I am very serious here.


You haven't been reading n.p.m.documentation, probably -- Nigel is
involved, he's one of devmo-...@mozilla.org.

/be

Nigel McFarlane

unread,
Apr 7, 2004, 8:39:28 PM4/7/04
to

> Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
> We've not even started. Maybe MozFound should contract with Nigel
> McFarlane and write with him the official Mozilla Technologies Embedding
> Guide, sold as a book. I am very serious here.

I'm open to all such things, but the MF & I have plenty of mutual
work at the moment. Nothing suit me better than writing on Mozilla,
unless it's arguing with Bugzilla denizens.

Calling all lurking Mozilla embedders: drop me an email if this
missing doco is hurting you; there's always a way forward.

regards, Nigel.

Nigel McFarlane

unread,
Apr 7, 2004, 10:00:25 PM4/7/04
to

I've read a lot of this thread. I don't really
care what Mozilla.org's stated goals are. I'm more
interested in what futures are practical and possible,
and what we say about ourselves to others.

Some points from me:

A. Popularity is worth nothing.

In all this discussion I only see Popularity as an
implied end-goal. Popularity by itself is a hollow value.
What, if anything, are we trying to do other than look
good in the mirror? To be in it for popularity
alone is no better than being in it for money alone.

This thread is no place for a political argument,
I merely point out that by itself, popularity is not
enough. If there are to be goals (an open question)
thay should be framed in terms of a better ideal, and
popularity relegated to the status of a tool or a tactic.
I have no beef with popularity as a tactic.

For Mozilla's Web offering we have this spirit in
place, at least in one form, when we talk about
preserving access to the Web for all people through
support for public standards.

We don't have a similar spirit in the broader context
of mozilla-the-technology. We need one.

"Mozilla: enabling free application software".

B. Mozilla lives in an Information Vacuum

DevMo will in part address this, but I should point it
out for those who've missed it. Mozilla as a technology
is highly disconnected from both the broader grass-roots
technology community, and from the product marketting
environment. This, more than anything, (as some other
posters here have complained) is limitting and slowing
the development of this technology.

At the marketing level, current brand management goes
no further than to market Mozilla as a point solution:
email and Web. This is a two-edge sword: we need to express
what mozilla products are, but this expression also
dumbs down and distracts from the fine technology underneath.

We need a "Mozilla Inside" plan, and we need to stop
having the problems that Macromedia had with their poorly
named Shockwave and Flash offerings.

Firefox: a great Web browser. Mozilla Inside.

Because of this lack, mozilla-the-technology labours badly
under questions such as "what is it?" and "what are the
goals of Mozilla.org?". Hence this thread.

At the grass-roots technology level, we are an island.
It is no coincidence that xulplanet uses an island metaphor
for its website. We need to get down and dirty with
all the other open and closed source programming communities,
from Perl and C++ to visual basic. This is a DevMo goal as
far as I'm concerned.

C. No one needs another complex OO framework

We have Java. We have Mono. We have C++. Any attempt
to make Mozilla another complex OO framework suitable for
high-level programmers is a waste of time.

It makes far more sense for Mozilla to aim at beginner
and intermediate programmers, who currently have no
FOSS offerings except the wierd syntax of Tcl, the
hackery of Perl and ports of Visual Basic. JavaScript has
a far cleaner syntax than any of these. Anyone who thinks
C# is stolen purely from Java is crazy. It's also stolen
from JS.

Mozilla-the-technology brings apparent simplicity
to programmers via HTML, JS, CSS, XML and simple uses of
XPCOM. That simplicity should be preserved.

Our highly talented contributors with extensive grasp of
OO, delegation and frames as programming constructs
have done a grwat job of boiling some of that down for the
vast majority of ordinary programmers.

In my view that is a core value we should preserve at all
cost. Lots of programers just can't do Java, even after
they're trained, and they are an audience for us.

D. What you've got is what you are.

Despite the constraint of C., our talented contributors
are producing a very sophisticated information engine.
It's been tuned, refactored, optimised, trimmed and bundled
to the finest detail. We should be justly proud of its
complexity and power, and shouldn't stop it.

I see in Brendan's post that he advocates a classic
"conflate two or more ideas to grow something new" strategy.
That's well and good, but we also have core values.

I propose that the answer to the question: "What is Mozilla?"
is this:

Within Open Source, Mozilla is the application kernel.

The linux kernel is deeply informed by hardware. Mozilla-the-
technology is deeply informed by data: XML, datacomms, display,
storage and objects. These are all application-level issues that
live on top of OS services. We should be proud to be in the
applicaiton space.

Mozilla-the-technology is big enough and ugly enough,and optimised
enough and detailed enough to call itself the application kernel.

E. But you can be more.

Brendan's ideas of conflating open source tools make sense,
but here's a note of caution. It is a huge task to develop
application domain-specific expertise. I have spent years in
the Telco event management field, and just grasping the
requirements of that single niche is the work of a lifetime.

To take on a domain beyond web and email/messaging at this
stage is suicide. We must stay focussed on tools, not
application domains.

Bringing together point E (tools), C (simplicity) and
Brendan's points, the challenge I see is for the
Gtk/Mozilla tools to leap way ahead of existing tools.

I recently read this:

"People have an expectation that replacing [xxx] with a commercial GUI
that has a GUI builder will save a lot of effort. However, GUI
programming effort usually consists of spending about 5 percent of the
time using the visually appealing drag-and-drop GUI builder. The other
95 percent of the time is still spent coding the underlying display
logic. Therefore, replacing UIX may not realize as much benefit as desired."

Clearly Longhorn is no improvement on this. But Mozilla's
new offerings and future direction could be.

regards, Nigel.

Doug Turner

unread,
Apr 8, 2004, 12:54:38 AM4/8/04
to Daniel Glazman

I am sure that I can not comment on the all of goals of mozilla,
but as for Minimo... Minimo is one of the most important fronts that
the Mozilla.org has. (okay, well maybe I a bit bias.)

Last I read, Linux currently makes up about 3% of the desktop and the
same for the consumer mobile markets. The linux usage or adoption rate
is increase much faster in the mobile market. More people are seeing
linux for devices as the obvious solution. Major manufacturers are
shipping linux on consumer devices such as the Sharp Zaurus. Linux
replacement OS's are reaching the point that non-geeks can use then
productively.

Many browsers in this space are limited that simple dhtml pages file to
layout. Others are huge memory consumers making them impossible to run
over the simplest page cycles. Minimo beat these browsers hands down.

Most of the goals of Minimo were shared by Mozilla. The majority of our
initial work was footprint and modularization. I think a goal of
Mozilla should be to foster continued work to make Mozilla smaller in
both disk footprint and memory usage. We have made allot of progress!
Mozilla owners should have a goal of minimizing footprint and making the
product as modular as possible so that we can remove optional component
for 'lite' projects such as Minimo.

With that said, Minimo needs more than that... We face some problems
that most of the traditional Mozilla user dont have. One of the obvious
problems is that most web pages and our client ui is designed for at
least 640x480. We need to think of better ways to make browsing such a
site not only do-able, but enjoyable. Glazman has done some excellent
work in the content area and has release a SSR extension for Mozilla,
kudos!.

Products like firefox have a chance on some of the high end mobile
device if its UI could notice that the resolution is too small and so
something smart. Right now, running the suite or the ng clients run
fine on many ARM devices but they are simply unstable since much of the
app ui isnt viewable.

Random needs|goals of Minimo in no particular order:

* Minimo needs to be running on QT. I have gotten many request for a QT
version of Minimo. If you know how to fix this port and have the time,
lets talk.

* Minimo needs UI love. We need some minimalistic eye candy.

* Minimo needs people to help identify code that can be removed if we
don't want it. For example, maybe you know about some code that we have
to handle some obscure or not frequently used feature. Tell me about it.

* Minimo needs some UI GTK help. If you have some time to do some gtk
hacking, please drop me a note. I have a few small tasks that I would
love to hand off.

Regards,
Doug Turner

Matthew Thomas

unread,
Apr 8, 2004, 2:03:42 AM4/8/04
to
Brendan Eich wrote:
>...
> The problem I foresee is that Linux may very well not ship a default
> Mozilla browser, relegating Gecko to the category of web-content
> engine, soon to be "legacy" web content engine.

(Disclaimer: I was one of those consulted on whether Galeon or Mozilla
should be GNOME's default Web browser. Epiphany vs. Firefox 1.0 would be
another interesting contest.)

>...
> The long-term result would be not only a lack of cross-platform apps
> -- there would be a lack of new cross-platform contents and protocols
> needed to countervail XAML and other Longhorn formats, protocols, and
> languages.

Throughout this you seem to be assuming that any alternative to XAML
needs to be cross-platform. But from what I have read, XAML is not
cross-platform; it is intended to produce applications that will make
sense on Microsoft Windows. Even if those applications can be run on
other platforms, they will be ugly and inconsistent on those other platforms.

In competing with XAML, it may be that you think cross-platform-ness is
part of the solution. I hope you also consider that it may be part of
the problem. Trying to work on multiple platforms may mean working
poorly on all of them.

>...


> Here's an alternative that I'm working hard to promote:
>
> I. Build cross-platform apps from the ground up, using Gecko, native
> theme-based rendering, and good desktop/OS integration.

In general, the more cross-platform a graphical application is, the less
desktop/OS integration it will have. (Prominent examples include Mozilla
1.x on eve