Roadmap Update: Mozilla Application Suite will be Sustained
Friday January 16th, 2004
Brendan Eich has updated the Mozilla Development Roadmap, adding a note that the Mozilla Foundation has no plans to retire the Mozilla Application Suite in the near future and will continue to release updates to the program, also known as SeaMonkey. This means that users of the Mozilla Application Suite will continue to benefit from changes made to core components such as the Gecko rendering engine and the Necko networking library. However, no major updates are planned for the frontend user interface, as the Foundation still wants to focus innovation in this area on the standalone applications, such as Mozilla Firebird and Mozilla Thunderbird. Sustaining the Mozilla Application Suite will benefit enterprises and other organisations that have standardised on Mozilla 1.x, as well as providing a smooth upgrade path for users of the discontinued Netscape browser and other derivatives of SeaMonkey.
Brendan Eich's newsgroup posting has more details about the Roadmap revision. A major Roadmap overhaul, outlining the path to Mozilla 2.0 and the future of the open Web, is planned for later this month.
This is good...
but, does this mean that if I submit a patch for a seamonkey frontend bug it won't be accepted?
Nope, patches will continues to be accepted. For example, I am considering making the sidebar in Seamonkey only show one sidebar tab a time, ala Galeon.
#3 Movement from the suite to seperate apps
by pkb351 <firstname.lastname@example.org>
Friday January 16th, 2004 7:50 PM
"The idea is to move from the over-integrated application suite to simpler toolkit applications, to remove more advanced functionality from the default configurations, but to provide robust tools for building your own browser by layering those extensions that you want to use on top of the base. In an attempt to avoid an explosion of unique builds that have to be supported by mozilla.org, we will likely ship with all of the popular extensions installed but disabled, so that they can be easily turned on by those who wish to use them, and uninstalled by those who don't."
One major reason I use the Seamonky suite over the Firebird/Thunderbird combo is preferences. Its been about 4 months since I test drove Firebird, but I found it lacked too many settings for preferences I wanted to set. You state in the roadmap that "we will likely ship with all of the popular extensions installed but disabled, so that they can be easily turned on by those who wish to use them, and uninstalled by those who don't." I highly agree with this model and strongly feel it should also apply to the preferences. There is a tendency to pare preferences to a minimum set and if a user desires/needs to set a preference not in this "bare bones" set to use about:config. The default setting for a preference does not work for all users every time. At one time the tab setting in Firebird was set to open a new tab each time a link was clicked on with no preference to change it to open the link in the same tab if so desired. This sucked since I am on broadband and links usually open quickly. Users do not need all the preference settings found in about:config, but they do need more settings beyond the bare bones preference panel being promoted. usability for a user often means being able to alter a default behavior in a program. Maybe there should be a heiarchy of preferences:
1. Most often used preferences (the default preference panel). 2. Less often (but still useful) used preferences (opened by clicking on a button located in the default preferences panel.)
#5 Re: Movement from the suite to seperate apps
Saturday January 17th, 2004 1:44 AM
> You state in the roadmap that "we will likely ship with all > of the popular extensions installed but disabled [...] > I highly agree with this model and strongly feel it should > also apply to the preferences.
Wasn't there a "prefs extension" planned?
It was suggested before that the suite was going to fade out. I felt a bit alone as believing the suite was "a good thing". Now I finally see a confirmation of what I supected based on people's comments, the suite will stay. I think the suite makes a perfect solution for someone using both the browser and mail client. Being integrated they open quickly if they one of them is already open. that alone makes a lot of sense to many usersand saves memery and resources (I tend to believe that, but it may not be true). Besides, the suite is really stable and full featured, FB and TB have a few better features, but lack a lot of basic stuff and are less polished being still beta.
#6 Good decision, nobody has to suffer disadvantages
Saturday January 17th, 2004 1:52 AM
Good for those who like the suite to get official releases -- and in no way bad for the bird lovers. Sometimes people from the outside complain why development does not focus on the standalone apps yet, but they don't know this: Most (by far) of the Mozilla Foundation paid work is going into the birds (eiter FB/TB UI or Gecko backend). Suite-specific work is almost exclusively done by volunteers who like the suite. The switch to the birds as the mozilla.org default most probably will not make them suddenly like the birds over the suite and certainly cannot force them to contribute patches to them instead of the suite. So this official switch will probably change development less than most people think.
"adding a note that the Mozilla Foundation has no plans to retire the Mozilla Application Suite in the near future and will continue to release updates to the program,"
Good news! :)
That is wonderful news!!! I know I'm happy to hear it!!! I'm still very happy using seamonkey here. So I'm glad to see that it's still going to be maintained. I had hoped that it would be... :)
Just nice to hear official words on what's happening with the future.
Thanks people. :D
They could always do an NT/9X type thing where the birds (Mozilla 2.0) are targetted to home users and the suite (Mozilla Pro?) is targetted at companies and the like. Of course both our products will work, not just one of them.
by alcatraz52 <email@example.com>
Saturday January 17th, 2004 11:23 AM
Now that's a great idea!
#10 Just perfect
Saturday January 17th, 2004 7:06 AM
Now we finally know where the suit stands and what's going to happen to the birds editions. I'm glad the suit lives. It's something I expected, but again, I'm glad to see this outcome written by Brendan/Hyatt.
Note: MultiZilla 2.0 will be a blast for the bird thing :-)
#11 only until the *birds can be combined
Saturday January 17th, 2004 7:39 AM
I think that the goal for 2.0 (perhaps) should be to be able to retire Seamonkey in favor of bird apps that can be added together to create the same thing based on the GRE. That is, the user can download Firebird and add Thunderbird functionality to that if they want, and then Sunbird, etc. Or, they can just download them all together and have the suite. The key will have to be only one GRE used for the whole shebang to avoid redendant Gecko code.
#12 Thunderbird add-on for Firebird
Saturday January 17th, 2004 7:39 AM
Does anyone know anything about the Thunderbird hooks in Firebird so that it can be both an addon and a stand alone? The picture (with the circles and squares) on the road map has said that it will be both, yet I haven't heard anything about how the integration process is going or if it's even possible yet.
Anyone know of any bugs that track this issue?
#28 Re: Thunderbird add-on for Firebird
Sunday January 18th, 2004 7:56 AM
I don't think anything has been done towards implementing that - I don't think it even got as far as having any bugs filed to track the work.
I think it was just an idea that was introduced with the roadmap, in order to compensate for getting rid of the suite. There's no reason it couldn't happen in the future, but I think the idea of the people employed by Mozilla doing it as a priority was dropped some time ago - the paragraph that was in the old roadmap doc about implementing it has been removed as part of this update.
The roadmap mentioned: "Gecko also suffered from over-reach. Not because too many integrated applications were built on top of it -- those helped shake out many design and implementation bugs -- but because it was naively quite "modular" without actually being easy to extend. At the same time, parts of Gecko are still baroque (<http://dbaron.org/log/2003-01#l20030109>) due to early design limitations and an accumulation of code to patch around core problems."
Dbarons blog goes into more of the details. I'm curious as to how much progress has been made on this front, i.e. architecural changes to simplify Gecko.
Quite a good bit. I suggest you search for bugs with "decomtaminate" in the summary (some fixed, some still open though a number of patches have landed to partially fix those issues).
#14 Firebird & Enterprise enviroments
Saturday January 17th, 2004 9:46 AM
I work in a huge IT shop (over 75,000 internal clients) and we actually have a couple of pilot applications using XUL & Mozilla Suite.
The problems that we have had with Firebird is the lack of polish and hassle to install desired extensions, and the lack of consistent preference menus as someone mentioned earlier. The extensions do not seem to have a "silent" or offline installation mode, which causes our software distribution people spend alot of time just prepping Firebird packages.
Our conclusion is that if you have fast computers available, use the suite.
#43 Re: Firebird & Enterprise enviroments
Tuesday January 20th, 2004 2:12 PM
I run a bigger IT shop (110,000+) and FireBird works just fine for us.
This is great news.
Onward, ever onward.
Sunbird, Thunderbird, Firebird, but no Composer standalone public release yet. The continuation of the suite will help ensure its viability.
This is bad news: this monolithic monstrosity will continue to sap resources. I think they should freeze it completely from a functionality point of view and just put it in to maintenance mode. The stand alone apps need more attention so that they can be brought up to the level of their equivalent in Sea Monkey.
I want a Mozilla Suite, but I don't want this crappy single process we have now. Every component needs to be in a separate process. In fact, things like Firebird should be able to run in multiple concurrent processes. Stand-alone apps are not synonymous with loss of integration, although reading the comments here and over the last few months, it's obvious a lot of people think this.
The current architecture is folly and troublesome - why should a buggy plugin in the browser bring down the mail client and wipe out the email I've been working on? Why should processing a large newsgroup make browsing impossible? It shouldn't. There are other tightly integrated product suites out there that work very well without the need of running in a single process. Furthermore, there is no reason why standard alone apps in the same suite should appear any different to a monolithic app from a UI perspective.
Mozilla Foundation's paid applications engineering team remains focused on the Aviary. I wouldn't worry too much about sapping resources. Much work continues on the Gecko core that all Mozilla apps share and that all benefit from. A look in the #mozilla IRC channel will show that many of the folks working on the Seamonkey front end have little interest in working on the Aviary front ends anyway.
So you read an article that says SeaMonkey will be put into maintenance mode (instead of just being abandoned outright). And then you turn around and demand that it be .... put into maintenance mode? I fail to see the logic.
BTW, I do realise that the road map indicates that the focus will be on the stand alone apps, I just see too much dithering and wasted effort. I use Mozilla 1.4.1 on my desktop, but prefer FB and TB on my laptop. I think they should make a final version of Sea Monkey and treat it as the stable replacement for the 1.4 line. And a clear statement that nothing more will be added.
Are you kidding? As it says in the roadmap, practically all of the organizations which support Mozilla support is because they use SeaMonkey, without an all-in-one, full of corporate features suite, thay will probably stop supporting it. Also, there's no reason for at least continue releasing upgrades to SeaMonkey, if the only basic thing to upgrade is Gecko, and it is the same along all Gecko apps... Apart of that, many old Mozilla users prefer the suite. And remember that the birds are still in beta...
> I think they should make a final version of Sea Monkey and treat it as the stable > replacement for the 1.4 line. And a clear statement that nothing more will be added.
So you want to prevent us Suite-lovers from checking in patches to make the Suite better?!? I will (at least in the near future) use the Suite, no matter what the birds do. And if I spend my spare time to make patches, I want to do the patches or the program I'm really using. Do you want prevent mefrom doing so? This will not make me inclined to improve Firebird.
Yes. If you don't like it, fork the tree. Maintain it yourself or with a group of like-minded people. If you want to share the results, organise your own servers and bandwidth too.
I want a Suite too. I want a better Suite. This means ditching the single process implementation in favour of a multi-process one. Mozilla Foundation's stated aim is to move the suite to the *birds. Thus the days of the single process implementation are already numbered. I want to hasten that and make the transition as soon as possible, for the final solution will be far better. Forcing a complete freeze on features on the monolithic implementation will either drive people away, or (the hopeful result) encourage them to place their efforts where the results will be more meaningful: bringing the multi-process implementation of the suite up to scratch more quickly.
You want to submit patches or new features, add them to the *birds instead of wasting your energy on the current implementation. Furthermore, by adding features to the current monolith, I would guess you increase the amount of work required to make the final transition and delay it further.
Don't you know that most of the differences between the suite and the aviary are in the UI?.. Many of "Mozilla's features" are included in Gecko, too, so a patch for a problem in seamonkey will often fix it too in firebird, thunderbird, or the equivalent component. Also, as you don't like the suite, many people like the suite and don't like the birds, but aren't out there talking "stop the birds", caus it'll be stupid. If the suite is mantained is because organizations want/like it and many people too, if the birds are maintained is because many end users like them. Two products for two targets. MARKETING. If you are thinking that a suite can be composed of birds: a company donesn't want nice UIs or happy prefs, they want to customize the program wo their needs and need corporate features. Although nearly all of the features are shared between the birds and the suite, the suite puts more attention on "strange" features, that are the ones organizations may use. Don't forget that the birds are still in beta stage, and that to build a suite of birds it's first necessary to use a unique GRE among all the bird-suite's apps.
How many times do I have to state this? I don't dislike the suite! I want a suite. What I do not like (intensely dislike infact) is the current implementation and architecture of the suite. There's no reason why a multi-process version of the suite can't meet any of the requirements you mention. In fact, I believe it will provide a better solution for everybody's needs. Trust me: I *know* that the *birds are a beta product, which is why I want a stop this BSing around with the current production implementation which is based on a broken architectural model. The current implementation is good enough that it can tread water for a while whilst we wait for the alternative to be bring up to par... assuming of course that it doesn't take as long as Mozilla 1.0 did.
That integrated suite of birds doesn't still exist, and if even the current versions using a common GRE won't be as inegrated as seamonkey. Also, there aren't plans to make the birds as "strange-features" full as seamonkey, and seamonkey is REALLY all-in-one, I mean that you start a single process once, and one it loaded, you don't want anymore. I know that it goes against reality :-P, but seamonkey 1.6 loads up faster that fbird 0.7+ in my machine :-D. And don't forget that many people are used to the UI, the feel, etc., of seamonkey, and like it how it is. They won't like the birds just because seamonkey isn't there anymore. And there's no reason to at least let people to continue developing seamonkey, and to continue upgrading the core (gecko), as it's the same in all mozilla apps.
> Yes. If you don't like it, fork the tree.
Already done. The Mozilla.org SeaMonkey tree and the Firebird tree _are_ forked.
>Yes. If you don't like it, fork the tree. Maintain it yourself or with a group of like-minded >people. If you want to share the results, organise your own servers and bandwidth too.
I don't like your attitude, boy. Such statements create a bad mood in the community. And nobody in his right mind would want that. Open Source is not only about free access to source code. It is also about tolerance and being open-minded about other views and ideas.
There is already a small rift between seamonkey people and bird-people. This rift needs to be closed not broadened.
I'm glad to hear this :) Although I use Thunderbird and Firebird most of the time, I do still use seaMonkey sometimes.
Well, it seems that Mozilla has been in the process of fragmenting itself since AOL decided to part ways with it. I agree with the concepts behind with the suite (like the integration, hate the look and feel and organization of prefs), and I agree with the concepts behind the standalone's (like the look and feel with reservations, but hate the lack of integration with other components), but is it really prudent to do work on both of them? Suppose you were to instead focus resources on integrating the standalones together so that they *are* separate programs, but seem to function seamlessly... wouldn't that be the best option for the "suite", as well as accomplish both objectives?
Just seems like they're fragmenting themselves into oblivion sometimes.
#29 Re: Fragmenting to Oblivion?
Sunday January 18th, 2004 8:11 AM
No, it probably wouldn't be prudent to work on moving forward with both the suite and the birds. But the Mozilla Foundation aren't doing that. The only work they are doing on the suite is to make sure it doesn't fall apart, and to facilitate the work of third parties using the suite. All new development will be (and has been since 1.4) focused on "the Aviary".
Dropping the suite completely would not result in any significant amount more resources going towards the birds.
Hopefully the new roadmap doc will make this point very clear...
"Suppose you were to instead focus resources on integrating the standalones together so that they *are* separate programs, but seem to function seamlessly"
You mean like IE, FrontPage and Outlook? Novel.
The suite has alienated so many potential users. The vast majority of internet users have little choice of what email client to use so bundling mail with the browser made no sense. Including composer made even less sense as it is used by a tiny fraction of users.
To sum it up, the suite makes the birds sweet, and the birds make the suite fly.
#30 If Mozilla lives, then FireBird needs a new name
Sunday January 18th, 2004 2:32 PM
Guess we'll have to find yet another name for FireBird, if Mozilla, the Suite lives on.
Since the Suite is called Seamonkey, why not "Seabird" for FireBird?
This is GREAT news. No, I do NOT use the suite. But many, many people do, and most of the developers.
I'm pro "mozilla 2.0 = *birds" but the idea of this could easily make many of the current gecko/suite devs loose interest in mozilla.
I think this is a VERY wise decision. First it keeps everyone happy, and Second I don't think it SPLITs resources like many do, those working on the *birds I would assume have lost interest with the suite, and those on the suite could care less for the *birds so all in all, keeping both parties happy I think is benifiting Mozilla and attraction more volunteers.
Just my 2 cents
I like it. i think that the integrated suite should stay. although i do use firebird since pre-0.4 (and mozilla since pre-1.0), i really think a suite that can download in one part, installed in one part, and generally maintained (user-wise) as one part is very important.
Why wouldn't a multi-process implementation based on the *birds be an "integrated suite"?
I wonder if there is going to be any kind of community process for the 2.0 stuff. Well, we had community rule for the birdsmap (a few folks wrote it, a lot more folks ignored it). But it'd be nice to have some kind of process in the middle between driver rule and troll spam. I was wondering if having some kind of forum with only module owners and peers having permission to post would help. That way, plans can be tested against the schedules of those implementing them in a gentler way while cutting off 90% of trolls and, say, 20% of heat. Just trying to be realistic here ;-).
Good idea. The only problem I see would be that such a group would probably focus *too much* on developer issues/features and not enough on stuff the end-users care about. But to counter that is hard. Probably bringing in some of the few QA people like Asa, Michael Lefevre, Matti and a few others could help. But I'm not sure on that. Any other suggestions?