The roads I take...

When reading those recent posts about better riding on the "Firefox" brand instead of "Mozilla" for telling what technology our apps share in return to the IMHO great "Powered by Mozilla" logo/initiative, I really start to wonder if the worlds we all are living in are really that different.

While Matthew tells us he 'must say "you know, the guys who make Firefox" about ten times a day', this interestingly happens very rarely to me. When I'm talking to people about what I'm doing, most haven't heard about SeaMonkey, but when I ask "do you know Mozilla then?" most people I talk to say "Oh, Mozilla Firefox!" - they clearly connect those two. Some even know the old Mozilla suite, esp. those that are a bit into web stuff.

And then, who are we targeting with a "Powered by Mozilla" logo on a website or product package? The normal user doesn't care about those fancy logos, they might just note "a lot of colored logos" on the package or website, only those that are at least a bit tech-savvy care about what those logos really tell. And I'm pretty sure those have at least noticed that it's "Mozilla Firefox" and know at least both brands.

Let's make sure that Firefox as well as our products does carry the "Powered by Mozilla" logo, and I'm pretty sure it works out well for those who really care about those logos. Only those who know that it's cool technology do actually care about this, and those should be pointed to the technology, not some random major app that is built with it.
Unless we're really living in different worlds - one can never know

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

The SeaMonkey confvars.sh did only set MOZ_XUL_APP=1 for a very short time, as I just removed it again

As a matter of fact, after my checkin for bug 383112 that I just did, the configure script makes all applications built from mozilla.org trunk default to MOZ_XUL_APP=1, so they don't need to explicitely set this variable any more - just Camino does unset it (until that last user of xpfe gets converted).

Actually, we might near a world where this variable isn't needed at all any more, as everyone uses the same toolkit anyways. But for now, configure turns it on for everybody - once Camino doesn't have to unset it, we might be able to just kill all its appearances from the code step by step.

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.