The roads I take...

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 blog post on extensibility of Safari, Chrome, and Firefox - and it hits a very important point.

Chrome is winning an interesting share of users, Safari wants to do the same, Firefox recently goes out of its way for improvements that make it more alike to the "cool child in the block" that Chrome currently represents. Now, many of the improvements the teams are making are worth to be made by themselves, with our without having competition in that field - I'm not sure all of them are, but that's a topic for other discussions.

What's important is that we look into what makes a difference between Chrome, Safari and Firefox. Now, as I recently posted, the mission is the main philosophical difference. On the side of the product, there is a real difference as well though - even if we'd match Firefox to look, feel and function almost or completely like Chrome (which I'm sure the team are not really targetting, even if they're going a lot of the way in that direction), that would persist - and if it wouldn't, I'd not feel like it would still be right to be called a Mozilla product.

And that difference, the one thing that sets our technology apart from any competition, is the Mozilla platform.

The core of that platform goes back to a decision of a few probably visionary Netscape engineers back in 1998 who found out that the new web renderer they designed for "Netscape 5" in the newly founded Mozilla project was so fast in rendering basic web pages and even form elements that they decided it would make sense to use it even for rendering the browser UI with that renderer - using the same code and definitions on all supported platforms. As HTML didn't have support for all a UI needs and the HTML box model was made for scientific documents and not on-screen design, they created XUL as the markup language the web renderer (Gecko) would use for that UI - but the key was that it was extensible in many ways with very web-like technologies that were - and are - quite easy to learn and use (and IMHO, much of it is even easier than HTML itself, as e.g. <input> has strange syntax there).

The extensibility of that platform and making UI work with web-like technologies made it a no-brainer to support additional modules that could be installed, later called "extensions", nowdays a part of the refined "add-ons" system. As the UI itself is built with the same technologies, that also means those extensions or add-ons can do anything the UI can do or that the application can do - I just recently converted what I previously ran as a full-blown application into a Firefox (and SeaMonkey) add-on (KaiRo.at Mandelbrot), for example.

With the tremendous success of Firefox over the last years, a rather large add-ons ecosystem has formed around exactly that platform that allows any extension the same flexibility as the application itself - and even though generic packaging and installing isn't very well-supported, whole applications are powered by the Mozilla platform or based on Mozilla technologies.

And that is the real strength of Mozilla technology-wise. We have a very powerful platform that allows building extensions to our applications or whole products by themselves (using XULRunner), and all those use "web" or very "web-like" (but IMHO to some part even cleaner) technologies and work on all platform that platform can be compiled on, recently that even can include mobile devices.

The real technology difference of Firefox, Thunderbird, and SeaMonkey to any competition is that extensible and powerful platform. If we want to "win" over any competitor, this is one thing we really need to focus on, this is the ace we need to play. Other might try to match us there, but we have put 10 years of the work of great minds into developing that strength, others won't match that easily.

So, let's put this difference to work. Our mission for a better and open Internet and this great platform technology ought to be a game-changer. We need to build on those to succeed. But we can do it. So let's get to work, and let's tell people about it.

As AllPeers, Mark Finkle and Songbird have all posted their wishlists for XULRunner's future, I think it's a good idea to throw mine in, in the light of possible Mozpad acitivities on such items.
Not that this is my personal view as a SeaMonkey and L10n contributor and no common view of the SeaMonkey project or the Mozilla L10n Project (MLP), though I'd guess that some of those items would be on the wishlists of multiple community members in those projects.

• Killing app-specific differences in toolkit:
  Toolkit and other core code still contains app-specific ifdefs in many cases, which block moving the applications to XULRunner. There should be no need for MOZ_PHOENIX, MOZ_THUNDERBIRD, MOZ_SUITE and friends in that code. We came across such problems in printUtils recently, and I'm sure there are still enough others. Efforts like generalizing openURL() are good steps, but actually long overdue.
• More robustness in mozStorage:
  When the topic of moving any code to mozStorage from RDF or Mork backends in SeaMonkey or MailNews comes up, people keep telling me there are so many warnings around how easily things can go wrong with mozStorage/SQLite when it comes to other apps wanting to access our data or even multiple threads accessing the database (see How to corrupt your database). If we want to make mozStorage the general backend for databases in XULRunner, we need to find way so that that developers don't back out because of such fears before even trying to use it.
• Template Query Processor for mozStorage (bug 321172):
  SeaMonkey has a lot of UI that is based on RDF templates. If we should be moving to mozStorage as a backend for much of our data, it would be very helpful to be able to be able to build UI as easily as for RDF, which needs templates to work with mozStorage.
• Pipe-based IPC (bug 68702):
  Invoking external processes and controlling them via stdin/stdout or even named pipes is something that many more XULRunner apps will want in the future. I mostly care for having a good way to integrate EnigMail/OpenPGP into SeaMonkey by default, which needs to call gpg through such a mechanism, but I'm sure there are many other needs for this.
• OpenSync support (bug 303963):
  While the linked bug report is about MailNews and most of the work for this is probably app-specific, it might be a good idea to provide hooks on the platform side to hook into this open, cross-platform data synchronization framework, so it's easy for Mozilla/XULRunner-based apps to use it and provide synchronization with a wide variety of devices and applications.
• Profile management improvements:
  Profile roaming seems to be something that gets requested again and again, but does not work well. The mostly working framework we have for that in SeaMonkey 1.x is broken with toolkit profiles on trunk (bug 378647) and there's no code for doing this with toolkit profiles. I also would love to have profile language selection back if multiple languages are installed for the application (also an xpfe feature not supported by toolkit). Accessing one profile from multiple instances/processes (bug 135137) would probably be nice but is hard to get right.
• L20n (wiki page):
  The localization framework used for Mozilla applications up till now has its merits but also its share of problems. Based on what we know about current localization frameworks, which all have their own big problems, Axel Hecht, the L10n lead of MoCo, has figured out a next-generation L10n framework which he calls "L20n". We really need such an improved framework with one single file format for everything and enough flexibility for complicated languages (those are out there and currently not supported well in any software).
• Language switching in EM (bug 377881):
  Being able to easily install a language pack and switch to using it is good for L10n testers but sometimes also for normal users, esp. in multi-language families and countries. We should not clutter the interface for those users who don't need this, though. To achieve that, we can leave the current way of language handling in Extension Manager, just with small tweaks so that language switching is handled the same way as theme switching.
• Tray icon support (bug 325353):
  The main reason why the so-called "Quicklaunch" feature on Windows has remained popular with our users in the SeaMonkey 1.x product line is that they have a tray icon with a context menu that provides fast access to open browser and mail windows. Additionally, it kept mail libraries loaded and provided information about new mail arriving - and it allowed to close all SeaMonkey windows and still have fast access to the browser, mail and get this mail notification. It would really be nice if we could still provide that functionality with toolkit-based versions of SeaMonkey, but we'd need tray icon support in toolkit for that.
• Splash screen support (bug 329742):
  This might sound like a small thing, but having a splash screen gets branding across, which is why I believe many corporate users of XULRunner will want this, and on laptop machines with slow harddisks, even Firefox takes long to launch, with currently no visual feedback at all to the user that anything is happening.
• KDE integration (bug 140751):
  As a KDE user, like probably half or more of the Linux population, I'd really wish we could integrate more with KDE. We currently are able to fetch file type icons (moz-icon) from GNOME, and system settings also from there, but it doesn't help much when GNOME isn't configured much because I never use it. We've grown to use themes from KDE quite well in default themes, as KDE makes GTK inherit its settings and we inherit them from there, which works interestingly well. It might be worth to investigate how we can pick up other things through such channels, like e.g. default apps for certain MIME types.

I think I have touched my main wishes here, others might still come up to my mind later, but I hope they're only smaller wishes

Our Planet lately has been full of XULRunner talk.
And this is good, as it clearly tells that there's wide support of that technology, and things are moving on in that area. While we unfortunately have not yet reached a point where we can magically deploy a common, shared runtime and this vision will not get a reality in the Gecko 1.9 timeframe, the XULRunner platform is growing, and lots of work is being put into it, by MoCo and lots of outside volunteers. This is a cool, open, cross-platform base to builds applications upon, it will get way better even in the Gecko 1.9 cycle, and it will continue to improve in the future. I'm sure of that.

What we need though, is a stronger community around it - not that we lack people working on it or using it, or knowing its internals and deployment, we just can improve a lot in their communication. This helps "users" of the platform (those building apps based on it) in getting better info about how to achieve what they want to do, it helps people working on the platform in knowing what those "users" need to make working with it even easier - and it helps the platform itself by getting patches into it through this collaboration (hopefully also patches contributed back by the platform users).
Mozpad ("Mozilla Platform Adherents and Developers") is a good idea, and we build upon that idea to get such a community started. I hope though that we will leverage existing Mozilla community infrastructure as much as possible there so that it's as easy as possible for people already in the Mozilla communities to participate there.
Daniel Glazman insists in recent blog articles that we need a real name for this runtime, a logo, images "Built with Xulrunner", more visibility on the web sites, and articles in the press. I must admit that I'm with him on that - though I believe, despite I also have heard of other plans - that we should not pick any new name for that runtime/platform. The current, originally temporary, name of "XULRunner" describes exactly what it is - it runs XUL applications, it consists of everything building up the XUL platform - it basically markets the core technology of our platform, which is probably XUL. The majority of XULRunner builds around what is needed to provide XUL with everything it needs to works as expected, so that name serves very well to tell the message that "if you want to use XUL, you need XULRunner". And then, I think the package already got spread widely enough under that name that we should just stick to it, as changing it would probably trash all publicity it already has in developer communities (which are the target audience of this technology, right?). We really need a logo, and "built with XULRunner" images based on it, though. Maybe a good point for starting off the new community.

The SeaMonkey project got some really positive attribution in that recent platform/XULRunner discussion, by the way: John Lilly counts SeaMonkey among XULRunner/Mozilla-platform apps that are doing amazingly well, Mike Shaver is calling our project an excellent example of contributing to the platform, and talks of our success as a volunteer project: SeaMonkey is a great example of a group within the Mozilla community that has shown leadership and motivation in developing, supporting and marketing a piece of software that doesn’t have any Mozilla Foundation employees tasked directly to help it — though some Employees do indeed work primarily in the context of that product as a personal choice, and that’s a fine thing.
It's really good to hear people talk about SeaMonkey this way, it has been hard work to get here, and lots of people didn't believe we could ever get here when we started off this effort.

Oh, and we surely won't stop to work hard on getting even further along. As you might know, though we are using big pieces of the platform building up XULRunner, we still have major steps ahead to get a "real XULRunner app", the efforts for which we have code-named "suiterunner". The major step in that direction, killing xpfe in favor of toolkit should happen really soon now, and we will continue to adopt new technologies present in XULRunner, replacing old, often badly or non-maintained code in current SeaMonkey - without killing the feel of the suite our users have grown to love.
We will continue to be a good example of a XULRunner user, improving this where we can, as this helps both sides: SeaMonkey is a good testcase of an extensive, non-browser-only app building upon XUL technologies, which helps to improve XULRunner as a platform for such products, while we can get out a platform that serves our suite better.
Because of that, the SeaMonkey project will be proud and glad to be a member and supporter of a stronger XULRunner community, helping to make this Mozilla platform the best comparable product on the market.

A Japanese blogger called "Amigomr" seems to be picking interesting posts from the Mozilla blogoshpere and translating it to Japanese to give us a wider audience in Japan. This is awesome - and something that's probably only possible due to the web and maybe the "Web 2.0" phenomenon.
And now, this blogger asked me if he was allowed to also translate my posts - so if it's easier for you to read my earlier post about The Mozilla Platform, Firefox, and SeaMonkey in Japanese, here is the translated article!

I never thought I'd see my own blog posts in a language I am not nearly able to grasp. Again, thanks, that's just awesome.

The recent discussion of the Mozilla platform is really interesting to read. The arguments go from "we need to be more of a platform" to "needing platform tools is bad", and interestingly, I tend to agree with a real lot of those - as I guess will most active SeaMonkey and general Mozilla contributors.

Sounds strange? Actually, it's easy to explain:

For one thing, there's the Mozilla Manifesto, which, even though only taken into words this year, describes what we in the Mozilla development community have already been working for in recent years and we will continue to go with those principles. In a certain way, it's nothing more than the base Mozilla mission of "preserving choice and innovation on the Internet" which always had been there and will still guide us to the future. Because of those common principles, we have similar visions for the future of the Mozilla project, the browser and the web - those those vision vary in their details, of course. But still, there are strong similarities, so no wonder if we agree in principle in lot of topics on "the platform".

And then, "the platform" is multiple different things, actually. There is the Mozilla application architecture, or XULRunner as a platform to build internet software, usually based on XUL and cross-platform (though Camino doesn't follow that exact path and is still based on that platform). As the platform is "only" the backend for application, it probably receives equal or more work but less publicity than the applications built on top of it. Those applications, most notably Firefox, but also Thunderbird, SeaMonkey or Sunbird, due to the rich extension architecture built into them, are another platform though - it's awesome what interesting work gets done based on that extension platform. And then, the web itself is a platform nowadays, and it gets richer and richer. After all, that's what "Web 2.0" is all about. And our browsers are supporting that web platform through a lot of open standards we implement.

So, if we're talking about "the platform", we're probably taking about different levels of that tiered platform stack all at once. And surely we can improve all those - Gecko 1.9 and upcoming Mozilla2 work is directed at improving all those platforms and lots of work on them is happening as I'm writing this and you are reading this. So, Mozilla will be a better platform and we're all working on that, as we know we want that: a better application platform, a better extension platform, and a better entry door to the open web's platform (no, not a platform for the web, but a client for the web platform - the web will never be tied to us, it's much more the other way round). And yes, as shaver points out, you don't need tools to work with those platforms (I'm doing my work on all those platform levels with a simple text editor) - but of course, there can be tools to ease working with them. Still, using a tool means that you give some control of your work to that tool instead of having every single character of the document in your own hands. And you can keep that full control yourself when building on our platform(s).

The difference in those platforms is that we control both the application and extension platforms in the Mozilla community, we can keep them as open as we want/need to fulfill the Mozilla Manifesto we all believe in, and to preserve choice and innovation on the Internet.
The web as a platform is nothing we have direct control of - after all it's way bigger than our own community, it's actually what we build upon (without the web there would probably be no Mozilla project at all), we are only a part of the ecosystem. And there are other forces at work there, which don't follow the Mozilla Manifesto, some because they want to earn their money in other ways than us, some because they want to create web sites and apps that look cool and work for some group only without caring for a wider audience or free choice of clients. I'm sometimes shivering when I see how many "Web 2.0" services depend on the closed Adobe Flash system, for example - which needs specially crafted, potentially expensive, tools for creating content, and a viewer that is still not available for 64-bit systems or minority platforms such as BeOS, from what I know. There are also lots of sites out there that do browser detection and close out any browsers their creators didn't know, even if they'd work perfectly with their content, and so they are effectively closing out users and, yes, customers.

As Tristan points out, Firefox has helped a lot in making the web better, as a standards-compliant browser with 15% market share gives better reasons for people to create standards-compliant web content. And I'm with him that this market share still needs to increase (not by heavily competing with other standards-compliant browsers though, users of non-compliant clients need to be targeted primarily - and Firefox has the right concepts to serve as vastly improved replacement for IE). Unfortunately, web content creators haven't grown more intelligent with Firefox' rising market share though, and so they're still heavily using browser detection, often wrongly looking for "Firefox" in the UA string instead of realizing that Gecko is Gecko and so SeaMonkey, Minefield and other non-Firefox-branded Gecko browser users are often closed out unnecessarily.

And where does SeaMonkey fit into all that "platform" talk? Naturally, we fully support growth of all those platforms. Of course, as a consumer of the application platform, we want to see a good toolkit - and we're seeing our product as a good example and testcase for a non-browser-only app built on this platform, often raising problems there that wouldn't be seen by having only Firefox as a consumer. We are also trying to be a good extension platform, vastly improving this by moving to the new extension management infrastructure of toolkit with our next major release. And, of course, with a heavier orientation on power users, experts and web developers, we're standing united with Firefox in supporting an open web platform, hoping to fill a market niche that our trimmed-down browser-only brother may not reach that well with providing our integrated solution and providing more options directly in the default UI.

I think, in the big picture, that we are all big supporters of all those tiers of "the platform", even though I guess, most of us want their respective part of it to get the most attention. In the end, we all want all parts of it to thrive, and I also see that happen as we work on them together - now and in the future.