The roads I take...

Just before flying off to California and in the middle of packing, I could make yet another addition to the SeaMonkey 2.1 feature list:

SeaMonkey now supports OpenSearch through toolkit's search service!



We're late into this compared to Firefox, but this is one of the last, maybe even actually the last, item we needed to pick of from "the toolkit". The good thing is that now, all the search plugins that work for Firefox and possibly other browsers also do work for SeaMonkey. The bad news is that the special feature we had, the scraping of search results into the sidebar, is gone now and we don't have a clear idea if it would even be possible to get it back.

Also, we don't have a search bar available yet (it's planned to have it as an optional item through toolbar customization), the sidebar does some of its job for now, but even things like detecting site-specific engines or search suggestions are not available there yet.
The current state is a first step to get this feature in at all for SeaMonkey 2.1 Beta 1, now further steps can be taken to refine and improve it for the second beta and the final release.

I have mentioned it previously, and now it's coming up really fast: My personal browser start page says I have "2 days, 17 hours, 36 minutes" left until take-off to a trip that will lead me to the San Francisco Bay Area, Silicon Valley and the Mozilla headquarters.

I hope to be working next week (October 4th through 8th) from the Mozilla headquarters and having a number of meetings with different people working from there, on a mission to improve communication and cooperation between different parts of Mozilla and the SeaMonkey project.

If you are around in that area or at Mozilla, please contact me via email or on IRC and I hope we can arrange meeting up - after all, talking to people involved with Mozilla is what I'm there for.

Of course, being out of my usual environment, I'll try to have some fun next to the work engagements, and so I already have tickets for a Friday night Country Music concert (Rascal Flatts, Kellie Pickler, and Chris Young) and a Sunday night football game (Eagles @ 49ers) - and I'll probably take most of the second week I'm there to drive around (I have a rental car for the whole stay) and do some sightseeing and relaxation, though I haven't planned details yet.

In any case, I'll spend most of this Friday (Oct 1) at airports and on planes to get there, and most of Oct 17/18 traveling back the same way.
I should be around on and off on IRC the first week of those two, but probably not or very rarely the week after - still I should be back in Vienna with some time left before the core SeaMonkey community will convene here.

Oh, and I hope to get even better photos than on previous trips due to having an (older, but still quite decent) DSLR with me in addition to the good-quality pocket cam I usually took all my pics with.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 38/2010 (September 20 - 26, 2010):

• Build Machines and System:
  After our Windows builds had been broken with yet another problem of us not building libxul, Mark Banner bit the bullet and made SeaMonkey and Thunderbird build on libxul by default and on all our build machines. I then worked on cleaning out old builds and making packaging fit with that change.
  Based on that work, I worked on enabling Plugin Crash Detection (Out of process plugins) for SeaMonkey and succeeded. But then, we found out that universal builds were broken due to PPC not enabling that feature, it had build problems, for which I had to do several iterations of patches until it was fixed.
  Those switches also came out with linking a debug libxul needing a real lot of RAM, esp. on Linux, and so we needed to request increasing memory on build machines, which was mostly done, but brought up other problems, like the Parallels host not being able to support that much RAM on VMs and one build machine being down now as a result. Due to that, we had hiccups in the whole system, as even the build master runs on that host, and some some Mac minis are missing right now after reboots and we need Mozilla IT to manually tackle them. I hope everything turns out alright in the end, but it's another sign of how fragile our build machine pools are at the moment. I'm working on improvements, though, but need to convince the heads of Mozilla to help us there.
• Data Manager:
  Ian did his reviews on Data Manager, we filed some more followup bugs, and I fixed up some things in the code, but in the end, this feature that IMHO makes SeaMonkey stand out somewhat could land and is a part of SeaMonkey now!
• OpenSearch:
  OpenSearch support got reviews from Karsten after I did another iteration of the patch. Now I'm waiting on super-review before being able to land that as well, which I hope can still be done before this week's string freeze for SeaMonkey 2.1b1, so localizers will adapt to this now for the first beta instead of their work getting broken later on.
• Personas:
  My patch for making sidebar look good with Personas got reviews and could land, so browser windows should look good with lightweight themes in the upcoming beta.
• Places:
  When I landed places bookmarks, I unintentionally gave us a broken Move Bookmarks dialog. I finally found out what was wrong and fixed that.
• German Community:
  I added a few more people to Planet Mozilla (de), I hope more will join this in the upcoming times.
• Various Discussions:
  JavaScript speed and my Mandelbrot demo, SeaMonkey Development Meeting, visit to Bay Area and Mozilla HQ, resolving gcc 4.5 issues, Firefox add-on bar, doorhangers, 2.1b1 freeze and adding another beta, Mozilla web task force and domain name strategy, etc.

A lot of great things are happening right now that should make SeaMonkey 2.1 Beta 1 a really compelling milestone for testing what's upcoming for our next stable release - and that one will be surely be the best application suite we ever delivered, as it should be.
Next week I'll be on a mission to improve cooperation with Mozilla Corporation and visit / work from their headquarters in Mountain View, and I also hope to be able to start creation of our Beta 1 builds from there, which we should still release before most of our major contributor meet face to face here in Vienna.

Interesting times we're living in, indeed!

After fast JavaScript and Plugin Crash Protection, here's another major improvement that just came to SeaMonkey 2.1 code and will be in the upcoming Beta - and this time, it's a SeaMonkey-specific invention:

Data Manager



I have reported about the add-on and on the features before, but now this idea I started working on four months ago has made one more step and is included by default in SeaMonkey, starting with manual builds from today as well as tomorrow's nightly builds.

Right now, you find it in the Tools menu or by entering "about:data" in the location bar and it's a pure addition to the other managers of the same data for the moment, until it can do everything those can do and we can remove them. There's a lot of work to do until then and the bug report has a long list of dependencies for those work items - help is appreciated there!

Once again, SeaMonkey 2.1 Beta 1 in early October will be the first version we'll ship to a wider audience for testing this feature.

Some of you might have heard of "Plugin Crash Protection" or "Out Of Process Plugins", a feature that made its Mozilla debut in Firefox 3.6.4 and runs browser plugins like Flash and Java in their own processes outside the browser process so that in case of a crash they don't take the whole browser with them.

Since today's nightly builds, this is available in SeaMonkey 2.1 as well. This means that you'll find "plugin-container" processes running when you're using the SeaMonkey browser, those are the processes in which the actual plugins run in. Also, it means that a crash in Flash code will not take down your browser or even mail component of SeaMonkey any more!

We'll make this feature, just like the faster JavaScript and the Data Manager, available for more wide-spread testing in early October in our first beta.

Happy browsing with SeaMonkey 2.1!

In the last days, I did some JavaScript performance tests on different SeaMonkey versions on my machine, just to find out where we are heading for SeaMonkey 2.1 in comparison to what we shipped in the past:



I ran 3 tests there: my personal Mandelbrot demo 1.0 with default settings (blue), the pretty common SunSpider benchmark (red), and the new Kraken benchmark (yellow). Note that the scale of Kraken results is different to the scale of the other two.

(Update/Note: I was told that my Mandelbrot demo uses JavaScript 1.7 and HTML5 features that Mozilla 1.8 supported but other browsers still don't, so there's a more cross-browser Mandelbrot demo 2.0 now - that one performs even a tad better on Mozilla trunk than the results here.)

The builds I tested were current pre-2.1 trunk builds, which already have the first stage of the new JaegerMonkey JavaScript engine, 2.0 branch builds without and with the venkman JavaScript Debugger add-on enabled (without JSD means that TraceMonkey can fully work, as activating venkman makes JSD put JavaScript into a non-tracing debug mode) - and finally, the 1.1.19 release build.

Unfortunately, I can't get data for Kraken on 1.1.19, as after a very very long time of running (given the "slow JavaScript" warning is deactivated), it errors out with not finding any JSON support. Comparing to the other tests, it suffices to say that SeaMonkey 1.1.x, coming from the Mozilla 1.8 tree, is very slow - but then, that's the baseline we started from.

SeaMonkey 2.0.x - even with venkman on and JSD knocking tracing off - is 90% or more faster than 1.1.x in those tests we can run in the older version. Suffice to say that Mozilla's JS team has made tremendous improvements between the 1.8 and 1.9.1 branches of the platform. One might think it's hard to go even further after such a jump, and indeed it has become much harder - but things could still get better. First, turning the debugger off and tracing on wins 19% in SunSpider, 13% for Mandelbrot and 2% for Kraken (the latter either doesn't have a lot of tight loops, which is what tracing help most with, or we are bad at tracing them in this version). At this level, SeaMonkey 2.0 looks already nice - but that's still 1-2 years old code, and development continued.

The current pre-2.1 builds of SeaMonkey bring another 61% win on Mandelbrot, 66% on SunSpider and 72% on Kraken - over 2.0 with full tracing! While the basic Mandelbrot set image took over 25 seconds to calculate and display on 1.1 and significantly over a second on 2.0, we're under half a second now for pre-2.1 code. And, as I already mentioned, JaegerMonkey work isn't even finished yet, there's a few more things to come there.

Of course, the question is if what those tests run is what Web sites and applications really need - we know a few things in SunSpider are non-realistic workloads. Kraken tries to look into CPU-intense workloads that could be useful for actual web applications, esp. if they want to to things like image and audio processing. My Mandelbrot set demo may look far-fetched, but then, I can surely see websites or even more web games dynamically generating fractal-based shades and textures based on variable parameters, and there you might have very similar code.

For those people who want the hard facts, here's the numbers for my graph with all details:

• Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre SeaMonkey/2.1b1pre
• Mandelbrot: 483.0ms +/- 1.4% (0.481, 0.492, 0.474, 0.487, 0.481)
• SunSpider: 477.4ms +/- 1.1%
• Kraken: 11151.6ms +/- 0.5%

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.13pre) Gecko/20100913 Lightning/1.0b2pre SeaMonkey/2.0.9pre

Mandelbrot: 1421.8ms +/- 5.0% (1.336, 1.401, 1.497, 1.383, 1.492)

SunSpider: 1738.0ms +/- 2.6%

Kraken: 40428.1ms +/- 1.6%

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.13pre) Gecko/20100913 Lightning/1.0b2pre SeaMonkey/2.0.9pre (venkman disabled)

Mandelbrot: 1237.6ms +/- 3.3% (1.220, 1.216, 1.301, 1.197, 1.254)

SunSpider: 1402.2ms +/- 3.6%

Kraken: 39558.9ms +/- 1.5%

Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19

Mandelbrot: 25214.2ms +/- 1.0% (25.176, 24.907, 25.180, 25.216, 25.592)

SunSpider: 17501.2ms +/- 1.2%

Kraken: Runs slowly for a while, but does break for not finding JSON handling.

All in all, the Mozilla JavaScript team is really enabling a lot of new possibilities here, as now we can do things client-side we needed to do server-side up to now, and that makes completely new dynamics possible. And SeaMonkey fully features those improvements made by the Mozilla community.

Nach einem Abend mit interessanten Gesprächen, gewässertem Pils - äh, Kölsch - und sehr gutem Essen ging's relativ früh zurück ins Hotel und ab ins Bett, schließlich wollten wir um 9 in der Früh fit und bereit zu weiteren Diskussionen im Tagungsraum sein.

Dort ging's ans Eingemachte - nach Vorträgen und Präsentationen am Vortrag war dies der Tag der Arbeiten und Entscheidungen. Vorerst war mal zu klären, was wir mit der Domain mozilla.de machen wollten, alle waren sich einig, der die aktuelle Weiterleitung auf die deutsche mozilla-europe-Seite nicht ideal ist, sondern eher die Community-Seiten aller Produkte verlinkt werden sollten. Und auch sonst drehte sich alles darum, wie wir wohl die Community in bessere Kooperation bringen könnten. Deshalb wurde auch beschlossen, die Newsgroup mozilla.dev.l10n.de nicht nur bestehen zu lassen, sondern auch wieder mehr zu nutzen. Schließlich erarbeiteten wir in Gruppen und später wieder in der gesamten Runde unsere Top-5 Ziele für die nächsten 6 Monate. Alles in allem eine sehr fruchtbare Diskussion, die das Treffen gut abrundete - ich hoffe, wir können diese Ziele auch erreichen.

Schlussendlich ließen wir die Veranstaltung ausklingen, in dem wir gemeinsam warteten, bis die jeweiligen Transportmittel abfuhren, zuerst in einem Cafe am Domplatz, später an div. anderen Orten rund um den Dom - Rothaut und ich waren so ziemlich die letzte, die Köln wieder verließen, denke ich.

Zurück in Wien war ich zwar kräftig müde, aber konnte auf ein Wochenende zurück blicken, an dem ich viel gelernt habe, von neuen Gesichtern über Accessibility-Technologien bis zu den gemeinsam erarbeiteten Plänen für die deutsche Mozilla-Community. Eine Veranstaltung, die sich wirklich deutlich gelohnt hat!

Um 5 musste ich heute schon außer Haus, etwas früh für mich, der Arbeit bis 3 in der Nacht durchaus gewohnt ist - aber wichtiges stand am Programm - vorerst mal ein Flug von Wien nach Köln, um rechtzeitig zum Treffen der deutschsprachigen Community in der Rheinstadt zu sein.

Ich hatte das Privileg, unsere "Rothaut" auf dieser Reise zu begleiten, gemeinsam mit Thomas (Lendo) stellten wir Österreicher damit ein Sechstel der anwesenden Mozilla-Community-Mitglieder - ein respektabler Anteil in dieser Gruppe von hauptsächlich Übersetzern und Community-Betreuern der verschiedenen Aspekte des Mozilla-Projektes.

Wir fanden uns am Vormittag in der Lobby des Hotel Cristall wieder, das als Tagungsort fungieren sollte. Nach kleinem Umherirren rund um den riesigen Dom und damit verbundener Nahrungsaufnahme begann dann zurück in diesem Hotel unser eigentliches Erlebnis, wobei nach einigen technischen Wirren ich den Reigen der Vorträge mit SeaMonkey eröffnen durfte, und denke ich deutlich genug machen konnte, wie wichtig der deutsche Sprachraum für unser Projekt ist, und dass SeaMonkey 2.1 jedenfalls am aktuellen Stand ist.

Die Kollegen von den anderen Projekten haben jeweils die Situation ihres Teiles dargestellt, wobei ganz klar wurde, dass es doch gute Möglichkeiten geben müsste, zwischen verschiedenen Teilen enger zu kooperieren, um uns alle zu stärken. Besonders interessant fand ich Rothaut's Präsentation der Accessibility-Technologien - ich hatte schließlich noch nie einen Screen-Reader und eine Braillezeile in Aktion gesehen, und es war echt spannend, einen kleinen Einblick zu bekommen, wie Software und das Internet für jemand aussieht, der/die keinen Bildschirm verwenden kann.

Einige Neuheiten konnte ich sonst auch noch aufschnappen, wie die Existenz von auf deutsch übersetzen MDN-Seiten oder dass die deutsche Firefox-Version 10% der gesamten Benutzer-Anteile ausmacht, aber auch altbekanntes wie die fast zum "Running Gag" advancierende "Ressourcenknappheit".

Mittlerweile sind wir im Zielspurt des heutigen Nachmittags in einer Diskussion der Probleme bei den Mozilla-Übersetzungen, besonders im Bereich von div. Webseiten, angelangt, bevor wir uns zum Einchecken für die Übernachtung und dann zum Abendessen und gemütlichen Tagesausklang begeben.

Der Informationspart heute war sehr ergiebig, und ich hoffe, dass sich das in Einzelgesprächen heute noch fortsetzt - und morgen geht es dann zu den produktiven Diskussionen!

In previous years, when we had a public security or grave stability problem in a "stable" release and needed to go into fast-pace mode to get update out as fast as possible to fix that, we called that a "firedrill". Still, that name is not very accurate, as it's a real problem case, not just a drill for one.

So, recently, Mozilla land adopted the name "chemspill" for those - needing to clean up after spilling chemicals represent the actual case better for sure.

But then, after recent events, I realized that for maritime life-forms like Sea-Monkeys, it's really more fitting to call it an "oilspill" in our project. Thank goodness, we didn't need that expression for quite some time after I came up with it - until now.

With SeaMonkey 2.0.7, we saw a sudden rise of a previously-rare crash signature in our topcrasher statistics, along with comments from users that it was on launch after updating that this happened, and the affected users were not able to run SeaMonkey at all any more in this version. Now, that's unacceptable, of course, so we stopped issuing updates from 2.0.6 on the release channel and went into investigating the problem.

It turned out that we had both a problem on our side with cleanup after updates as well as a platform problem that affected Firefox and Thunderbird as well, and it looks like both together were even worse for us. We found fixes for both now and decided to take a fix for font face in HTML email signatures along for the ride on creating a fast update that has nothing but those changes in comparison to the 2.0.7 release.

We now have candidate builds of this SeaMonkey 2.0.8 version up for testing and will ship it to the public between today and Friday of this week if everything looks as good as expected with it.

So, after all, we have our first "oilspill" release situation on our hands and I hope we are dealing with it in a satisfactory way. I just wish that real oil spills would be as easy to deal with as those in our software.

Die Frage nach Geschwindigkeitsverbesserungen bei SeaMonkey kam kürzlich auf, und nachdem ein großer Teil der JavaScript-Verbesserungen für die nächste Version dieses Wochenende in Entwicklerversionen eingespielt wurden, hab ich heute mal die populäre SunSpider-Benchmark mit verschiedenen SeaMonkey-Versionen laufen lassen.

Der letzte aus der 1.x-Serie, SeaMonkey 1.1.19, der vor einem Monaten die Wartung dieser Versionen beendete, brauchte auf meiner Maschine 17501ms für diese Tests - das also war unsere Startlinie in Erneuerungen.

Eine aktuelle SeaMonkey 2.0.x-Version kommt auf der gleichen Maschine auf 1738ms mit aktiviertem JavaScript-Debugger (Standardeinstellung) bzw. 1402ms, wenn dieser deaktiviert wird. Dass das Deaktivieren des Debuggers unter 2.0 einen Vorteil bringt, liegt daran, dass dort bei seiner Aktivierung die TraceMonkey-Beschleunigung ausgeschaltet wird - trotzdem ist auch ohne dieser eine gewaltige Verbesserung gegenüber 1.x feststellbar, braucht der Test doch nur mehr 1/10 der vorherigen Zeit.

Aber in der heutigen Welt kann das nicht genug sein, und für weitere Verbesserungen hat SeaMonkey 2.0 bloß eine neue Startlinie gesetzt - die Mozilla-Gemeinde ruht nicht und arbeitet intensiv weiter.

Die heutige SeaMonkey-2.1-Vorversion integriert die neuen Arbeiten an "JaegerMonkey" für noch schnellere JavaScript-Ausführung und landet nun bei 477ms für diesen Test auf meiner Maschine, nochmal auf 1/3 gegenüber 2.0 reduziert!

Dabei muss man bemerken, dass die Arbeiten an JaegerMonkey noch lange nicht fertig sind, einige Dinge können hier noch signifikant verbessert werden, und Mozilla's JavaScript-Engine-Entwickler arbeiten bereits kräftig daran. Ich denke, SeaMonkey bewegt sich (wie Firefox) in die richtige Richtung.

Anfangs war es bloß eine Idee, aber jetzt ist es Wirklichkeit:

Ein "Planet" von gesammelten Blog-Meldungen aus dem deutschsprachuigen Teil der Mozilla-Community ist hier!

Zu finden ist dieser unter planet.mozilla.de - und eine Menge an zusätzlichen Leuten sollte noch hinzu kommen, die jetzige Gruppe ist nur ein erster Anfang.

Alle, die in der Mozilla-Community aktiv sind und ihr eigenes Blog führen, in dem man Posts sowohl in deutscher Sprache findet, als auch über die Arbeit im Mozilla-Bereich, möchte ich bitten, einen Bug anzulegen und ich werde den Feed hinzufügen (wir bevorzugen Atom mit vollem Beitrag im Feed).

Es gelten übrigens die gleichen Regeln wie für den allgemeinen "Planet Mozilla": Es ist eure Sache, welchen Feed ihr uns angebt (so lange die Meldungen in deutscher Sprache sind), aber wir würden gerne die gesamte Persönlichkeit der Individuen in unserer Community zeigen, also braucht ihr euch nicht auf Meldungen beschränken, die einzig und alleine Mozilla zum Thema haben - wir freuen uns darüber, dass das Leben der Leute in dieser Gemeinschaft viele Facetten hat und sich nicht nur um ein einziges Thema dreht!

Ich hoffe, wir lesen uns am deutschsprachingen Planet Mozilla!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 35/2010 (August 30 - September 5, 2010):

• Build Machines:
  I fixed the missing L10n nightlies by applying a trick the Firefox build engineers team told me about - all locales that build right now should have nightlies out for all platforms again.
  When I noticed that two machines were missing, I filed a bug and IT promptly got them back to work for us - thanks for that!
• Automated tests:
  While a few other people in our team are churning along to reduce our test failures, I only helped marginally with this effort this week - but when one fix landed and didn't have the wanted effect, I investigated that a bit, wrote a test specifically for the new issue we're seeing and found out what the actual problem there is - we're still discussing a solution.
  I did create a patch to only build Web Console for Firefox, which should make our test failures there go away - if it gets accepted.
• Places:
  I did one more patch for cleaning up the places library, reverting theming for some parts to ease getting it reviewed.
  The fast bookmarking button got some more review comments and finally got as far as being OKed for the Classic theme, so I updated it for mac and Modern as well. The star button nit backport got review, I requested approval to land.
  The Mac problem of bookmarks being broken when no windows are open is solved after some more teamwork between Stefan and me.
• Doorhanger notifications:
  While the main patch is still waiting for review, I updated the followup on add-on installation notifications following some more Firefox work. I also filed a bug for "Learn more" on geolocation notifications, but I won't work on it while the rest is still in limbo.
• UA string:
  I did a patch for the somewhat controversial change of including a Firefox token by default in our UA string, after I realized the fight for this has been lost. There will be a UI pref in the advanced panels, and some don't believe this fight is over and want to prolong needless fighting, but I think this change needs to be done and the discussion ended if we don't want to continue losing users over this.
• Data Manager:
  From what I can see, the updates to the Data Manager patch and the review comments seem to get very close to final with respect to Neil's super-review. Now all I'm waiting for is the official marking of that and Ian's actual review.
• Site-specific zoom:
  I updated the patch for remembering zoom per site after I found out how to mitigate errors I had earlier and requested reviews now, but that might just be stalled for using a controversial event right now, which Neil just doesn't like to see at all in our code.
• OpenSearch:
  One thing that comes up time and again when users try to use it unsuccessfully and ask in our channels is OpenSearch support. This has been stalling for a long time basically just because we now have crufty, badly documented binary code around for search and a sidebar of which we don't know usage but which is crafted around a model that is far away from OpenSearch and not even fitting the current code.
  After we have decided some weeks ago that we'll set no priority on the sidebar working, I finally bit the bullet and tried to get our code to work with toolkit's OpenSearch module and so far, it has been easier than I thought - even though we are still missing a few things in my current WIP patch. I also did a very rough WIP for an optional search bar, but that needs a lot more work and isn't as high a priority as the main OpenSearch patch.
• Various Discussions:
  SeaMonkey Development Meeting, SeaMonkey build machines, visit to Bay Area and Mozilla HQ, building with libxul and/or "fatlibxul", organizational future for SeaMonkey, etc.

Esp. in the first half of this week I've been under a lot of strain, and generally I'm badly overworked and having too many things I think I need to take care of, resulting in symptoms that are very much pointing in the direction of an oncoming burn-out. At the same time, I'm trying to organize or help organize a few things that in the short term cause me some additional stress for planning, but should relief a lot of stress and frustration in the end. I hope that all will help my sanity somewhat (in the mean time - sorry when I might overreact at times) and help the SeaMonkey project to improve significantly in the future.

A major belief among a large part of the Mozilla community appears to be that 5-10 years in the future, the desktop or local applications will be extinct, and all we'll be working with will be "web apps".

Now, as with many other things, I don't think this extreme will be the common case (or else we should stop caring about Windows, Mac OS or any other "fat" operating system and all jump fully on ChromeOS) - but I'm sure that "web apps" will play a very much larger role, and I agree that almost everyone will at least use some of those.

In such a future, where the common case will be to use both web and local applications to some extent, probably also with a mixture of cloud and pocket data, it will matter a lot to have solid and well-thought-out ways of bridging their differences and working well with both - esp. for professional and advanced users, who spend a lot of time "in front of the screen" (whatever that will look like).

Also to keep in mind is that pure web applications in the currently done ways pose a problem for some people - I had an interesting conversation recently with a guy working in development aid for some African regions where he said there are entire communities of people that share a 256 KBit/sec Internet connection and things like Facebook or GMail cause nightmares for him.
That surely doesn't mean they should not exist, but those cases need thought, just like cases where you (intentionally or unintentionally) have no or a very bad network connection but might want to do work with your (mobile) computer (device). Not every place where people go in or around this world will have high-volume Internet access available for everyone all the time. We don't even have light all the time on this world, even though life on this planet heavily depends on it, and we have a transmitter right in our neighborhood (well, in terms of what we need there, 8 light-minutes are right next door).

Still, web applications allow the incredible stunt to have the same software on a free and open platform that runs on all kinds of devices with mostly quite permissive licensing. And they allow getting productive immediately, without long install procedures or continuous updating - as well as unprecedented collaboration and other features only the web can make possible.
On the other hand, they're currently one of the worst examples in cross-application consistency, easy adaptation to the personal look and feel preferences and integration with the people's work environments, leaving any current or past desktop environment looking like a champ in comparison.

To improve those situations, we of course need to have possibilities for web applications to cache code and data locally so they don't need to load everything a new all the time, they need ways to adopt to a common look and feel defined by those accessing them, ways to integrate with the work environments - and a richer toolkit of easy-to-use controls to match desktop applications. All those are being worked on by the teams of Mozilla and other browser vendors in committees working on improving HTML, CSS, ECMAScript and other web technologies as well as in implementations in our web runtimes ("rendering engines" is not the correct term any more, I guess).

What we also need, though, are smooth transitions between desktop and web applications - in both ways - and between local and cloud/remote data, both in terms of the user-facing side and in terms of writing applications. We need local and web applications that can work with local and cloud/remote data, we need technologies to write local application with (basically) the same set of technologies as we're writing web applications, and we need to be able to convert one to the other rather seamlessly.

The Mozilla platform already works very much with the a lot of the same set of technologies as the web, so we are in a good position in this area already, but we need to become even better by making the technologies even more similar (and there's a lot that future HTML can learn from XUL, too, even if XUL is being treated a lot like the ugly stepchild nowadays). A lot of awesome things can be done today, but I'm convinced that's nothing compared to what we'll be able to do tomorrow if we follow those paths we're already on to the most part.

And then, I'm quite convinced that there's a tremendous potential on an application that bridges web browsing, running web applications, and running local application code built around web/Internet communications. All those things should seamlessly integrate, work together, be able to exchange data where the user allows it, and give us the power of being productive, social, communicative, efficient, informed, and interconnected all at once. Right now, there's nothing as productive and efficient than fast, organized local application interfaces, and there's nothing as social and interconnected as some web applications. An integrated Internet application could build a bridge between them, bring that together and beat all the single offers out there, and there's none better situated in that particular race than SeaMonkey. We just need to grab the chance and bring it there.

Who is with me in that?

I just read this quote from my colleague, Firefox product manager Mike Beltzner:

I think that says a lot about our spirit in Mozilla about how we work on our products. Nobody pays us to produce products like Firefox, Thunderbird, or SeaMonkey - even if some of us might earn money for doing it, that comes through indirect paths, and not from those using our products. And we're nothing more than community members, just that we're playing a certain role in the community, but we're still parts of it, and we are just as much users as we might fulfill other positions. On the other hand, every user has a chance to work with us to improve the products - we're open for (constructive) feedback and help. We even give you access to the code, and accept patches very much - with the result that some features we ship in our products get developed completely by people not earning a cent for working on it, but being 100% volunteers. This is how open source / free software should work.
Still, we have a lot of dreams of where we want to go, and our teams are always too small to fulfill all those dreams at once, so that help is not just appreciated but very much needed. As Mike goes on:

Feedback is good and often helpful, but very often things only happen if someone steps up and takes matters into his own hands (a lesson I sometimes think I have learned too well).

We need you to help us to become even better. We need you to work with us, just like we are working with you.