What are the goals of Mozilla.org?
Andrew Schultz
> [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
> 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
> [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.
>
> 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
Benjamin D. Smedberg
> [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
> 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
>
> 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
> 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
> 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
>
>
> 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
> 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
> 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
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
> 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
[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
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 (­) 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
>
>>> 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
Mooquackwooftweetmeow
http://bugzilla.mozilla.org/show_bug.cgi?id=233851
-- Greg “The Twaddle” Nicholson
Boris Zbarsky
> 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
>>>> 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.
>
> 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
> 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
> 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
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
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
> 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
> 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
> 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
> 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
> [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
<...>
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
> 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
> 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
> 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
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
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
> 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
> Brendan Eich wrote:
>
>>
>> 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
> 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
> 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
> 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
> 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