The roads I take...

A few people in the Mozilla community have known the project for many years already, newer "family members" might not have experienced the pre-Firefox days at all, others are just entering or visiting this steadily growing crowd of people as testers or bug reporters - or "just" interested users.
Some of those might read my name as a "SeaMonkey Council member", i.e. one of the five people steering the SeaMonkey project, working on keeping the integrated suite alive (that has its own long history, reaching back to when Netscape still dominated the Web market).

So, how does one grow from a student and web user to one of the SeaMonkey project leaders? For me, it was mostly a matter of stumblin' in - or actually seeing that "something needs to be done" - and trying to help make it happen.

Just for some background, my father entered the computer sales business early on, bought a PC quite early on, back in the 80s (a then quite modern 8086 with 12 MHz, 640K RAM, CGA monochrome display and a 20 MB harddisk) and so I learned working with PCs quite early while going to school (ah, those DOS days... and programming with GWBASIC ). Following that, we probably were among the first people who had Internet in a private household around here - and, of course, Web and Netscape were almost synonyms in those days.

So, as an always-proud Netscape user, hating how Microsoft used their Monopoly to drive the market leader off the browser market, I started wondering in 1999 if my favorite browser producer is working anything new and stumbled over mozilla.org, trying their Mozilla M5 milestone build (made available for download under something called "the Seamonkey project"). Somehow even that early stage felt promising and cleaner in design (esp. when it came down to website rendering) than Communicator 4 to me, but clearly it was very experimental. My first post to a Mozilla newsgroup already clearly tells what I felt about the Gecko-based product: "I am convinced the final release will be the best existing browser software by far." - along with some bugs I encountered Following the advice of some Netscape employee, I filed my first bugs in Bugzilla for those issues.

I decided to remember that project and check back later for newer milestones - as a beginner physics/chemistry student, long-time DOS/Windows user and (Visual)Basic developer I didn't feel I could help in any other way than testing that new technology. Starting with M7, I tried to use this product for browsing more and more and after some time I got interested what this XUL technology is that is said to build up Mozilla's user interface. Back then, all chrome files were unpacked plain files in the app directory and I quickly discovered that that was just something like the HTML I knew from creating web pages (I still had to learn what XML really was), being styled with CSS (which I really did know) and with strings in some simple-looking plain text format (not knowing XML, I didn't know those DTD entity definitions either). Intrigued but not yet convinced by all that stuff being simple text files, I decided to try out if they really make up what I'm seeing, replacing some colors in CSS with some Star -Trek-style colors, and replacing a few English strings with German variants - and then I was really impressed: It just did work!
While I decided that Star Trek styling was nice for playing around personally (later my LCARStrek theme based on that), the translated strings could potentially be useful to others, and so I posted a message to n.p.m.l10n in December, telling that I'd like to help with the German localization of Mozilla. As Tao Cheng from Netscape, the L10n head at that time, replied "If you have no objection, I'll put you as the German translation contributor." (note him saying "the" contributor), I realized I had just more or less taken over the responsibility of creating a full localization. I tried to live up to that and on December 31 I managed to release M12 as the first "fully" (as in: as far as possible) localized German Mozilla version.
In late January of 2000, I opened up a website (The SeaMonkey German website still has old news and downloads that I ported to the new site to archive them) and since then, practically every release of the suite has been made available in German language by me. Ah, and in September I got to know some people of our community personally for the first time when we had the first Mozilla Europe Developer Meeting near Frankfurt, Germany (organized by someone by the name of Axel Hecht, BTW).

For a some time, I contributed to the project as the main German localizer, and reported bugs here and there. In April 2002, I got a mozilla.org CVS account, originally for getting German L10n into CVS (it should take years to actually have a working model for locales in CVS and then even a different repository - seaMonkey is even still on the road to that currently). This was some kind of milestone for me personally, as I began to do some small fixes for problems in the L10n area, like some locale switching fixes, followed by the per-release localeVersion updates until I finally automated that. And suddenly I had become a code contributor (still proud it was me who made about:plugins localizable and themeable back then, which is code that can even be seen in Firefox), and I started using that CVS account for those few, mostly minor, code fixes.

In the summer of 2004, after the demise of Netscape in 2003 and the only contributor who had write access to the FTP staging server and the mozilla.org web pages being AWOL, the L10n community realized more than before that a new lead is needed: For one thing, localized builds had to go up onto mozilla.org servers again, and we needed someone to improve communications of localizers with Mozilla Foundation. As I saw someone had to make that happen, I brought forward a proposal for a new Mozilla Localization Project (MLP) staff team and tried to collect people who wanted to help there. When we got such a new team together, those people asked me to take the position as official MLP project lead - and in this I ended up as being the main L10n contact in talks and teleconferences about Firefox 1.0 release planning, even though I didn't localize Firefox myself (a different German localizer was working on that while I continued to do the suite part). The current MoCo L10n lead, Axel Hecht, also did care a lot about L10n issues there - even though he was no active Mozilla localizer himself. When Axel rose into that position, my being the MLP lead got less important, but other challenges were already waiting for me (BTW, despite trying to step down as MLP lead later on, nobody volunteered to take over, so I'm more or less still in this position).

Finally, in early 2005, the future of my beloved Mozilla suite became more and more uncertain and when bz asked MoFo for clarity on that, I also undersigned his open letter to staff and experienced the suite "Big Bang" first hand. When the transition plan laid out a way for the future of the suite as a volunteer project, I once again figured a project leading group is needed, and tried to figure out people willing to help in that team. After extensive discussions, mostly on IRC, Neil, biesi, IanN, CTho and me agreed to form that steering committee, which we later named the "SeaMonkey Council".
Once again, in a repeating pattern, my strong will to make something happen and putting my contribution where my mouth is made me stumble into being a leading contributor in the respective area.

In this role as a SeaMonkey Council member, I'm mainly concentrating on the organizational matters of the project, while the other members are more focused on doing actual development, along with our broader community of SeaMonkey contributors. Next to that, I'm trying to contribute some code myself, still work with the L10n community and, of course, keep the German localization of the suite alive and kicking.

It's been a great ride so far, I'm still eager to get stuff done, and I hope to continue the story of how I got here with some great future success stories of the SeaMonkey project!

As you probably have heard already, Google is repeating its Summer of Code ("GSoC") program the third time this year, funding 600 projects in the open-source area with up to $ 5000 (up to $ 4500 for the student and $ 500 for the project they are doing their work for).
This year that program includes 10 Mozilla projects, among which even one project aimed specifically at SeaMonkey con be found!

The title of this project is "Make SeaMonkey Not Suck As A News Reader", done by Markus Hossner, and mentored by our SeaMonkey Mail & Newsgroups owner Karsten Düsterloh (also known as Mnyromyr). I asked both Markus and Karsten 3 questions, read what they have to say about this GSoC project:

First, some questions to Karsten Düsterloh, GSoC project mentor and SeaMonkey MailNews owner:

[KaiRo] 1. You created the idea of this project. What exactly "sucks" in SeaMonkey's news reader currently (many people tell us it's pretty usable, actually) - and what improvements do you expect we get from this GSoC project?

[Karsten] First of all, the project idea's title is stolen from a bug report in Bugzilla: "Bug 176238 – Make Mozilla not suck as a newsreader", a very old meta bug referencing several other bugs which make using (Mozilla back then and SeaMonkey and Thunderbird even now) as a newsreader not the experience folks are accustomed to from the Mozilla browsers or other newsreaders.
While most of the "major suckage" is gone by now, there are still some advanced features missing, even when compared to our Netscape 4.x ancestors. Clickable references or reordering the folder pane are requested very frequently.
Markus has a very good Mozilla background to get things running in this area, since he's the author of the MessageID Finder extension (almost a must for serious newsreading with Mozilla applications), so I think we will see quite some progress.

[KaiRo] 2. How much do you think Mozilla projects profit from each other's GSoC projects? That is, how can/will Thunderbird and Firefox projects help SeaMonkey, and the other way round?

[Karsten] The ties between the SeaMonkey MailNews and Thunderbird backends are rather strong, so here's a very good chance that any SoC project for one will help the other, too. (Roaming support for TB may be an exception, since we already have that in SeaMonkey.) In general, projects touching the common codebase are usually good for any project, eg. JPEG2000 support. Some of the Mozilla projects are rather application-specific and thus non-sharable, like the Firefox micosummary stuff.

[KaiRo] 3. What other improvements of the Mail and Newsgroups component of SeaMonkey are planned for the next few months or would badly need help, perhaps from new contributors?

[Karsten] Lots.
We still have lots of "parity bugs" asking for features known in Netscape 4.x or other mail and news clients, like score files or "real" message templates. Thunderbird has some features we would like see in SM as well, like back/forward in the mail reading history or folder views. There are some structural backend fixes pending, like unified header usage in view/forwarding/printing or blackboxing the mail storage.
Sometimes I feel its just a gift that everything is running so well even without that...

And then, let's see what Markus Hossner, the student working on this project, has to tell us:


[KaiRo] 1. Please introduce yourself: Who is this guy who wants to improve SeaMonkey's news client, what involvement did you previously have with the Mozilla and SeaMonkey projects/communities?

[Markus] I'm a German Student of Computer Science at the University of Karlsruhe (TH). For 3 years now I'm maintaining an addon for the Mail/News client of SeaMonkey and Thunderbird: The MessageID-Finder. An addon to deal with messageids and references.

[KaiRo] 2. What are your concrete goals you would like to achieve with this GSoC project?

[Markus] The project's slogan is: "Make SeaMonkey Not Suck As A News Reader". The project aims to make SeaMonkey a much more useful news reader by adding needed features. Features like clickable references, clickable headers in general, a more usable subscribe dialog, the ability to reorder newsgroups in the folder pane, the ability to quote only selected text, to offer a better offline support for news reading and a correct implementation of the nntp/news protocols.

[KaiRo] 3. Could you imagine to continue to work on improvements for SeaMonkey after this summer project?

[Markus] For sure

We all hope that SeaMonkey will "suck less" through this project, as will probably even Thunderbird. On the other hand, I hope SeaMonkey can gain from other projects as well, maybe even last year's Firefox GSoC project for a better Page Info window.
It's always good to see that a company like Google is giving back something to the open source communities, which provide a collection of good software which is probably also used intensely inside Google itself.

Mozilla 2 is to be started soon, and as you might have read, there are thoughts of creating a new localization infrastructure for that future generation of Mozilla software. Currently this is named L20n, driven by MoCo's L10n lead Axel Hecht, and though it's in a draft stage, I can't await to use this technology.

When Axel talked about L20n at FOSDEM, I was hoping people would tell us how they love it - unfortunately time for the talk was over before he could get to the interesting part - examples. Discussions there in Brussels were pretty interesting though, as I can't remember objections to the need of this or the general approach, only some criticism of the lol file format semantics. Oh, yes, it looks like localizing will be much fun in the future, having L10n info in ".lol" (Localizable Object List) files
I actually think that the proposed syntax of those file is good, as it feel familiar to most developers but is different enough from other languages to realize you're not in JS, XML but in a lol file.

The good thing is that L20n is a format that is growing out of knowledge about problems in current L10n approaches, both of the Mozilla approach(es) and the gettext/PO approach. People who have worked with both on a developer and localizer side know they all have their problems. While Mozilla lacks language fallbacks and plural handling, gettext/PO lacks good VCS compatibility and needs long original strings in the source code, while both lack flexible support for declension and other grammatical specialities. L20n is an effort to learn from the strengths and weaknesses of those, and esp. from the problem of their users, to create an L10n toolkit that satisfies developers, localizers and users the same - also across programming language boundaries. Axel has contacted other L10n communities than the Mozilla one to get feedback and, from what I heard, has received positive feedback and wishes for collaboration.

As an active SeaMonkey localizer, I heard about this new approach soon, bing in the Mozilla L10n newsgroup, I was more or less there when it was born (or the ideas for it were gathered) and actively took part in those discussions.
I'm more eager to working with L20n from a developer's perspective than from a localizer's perspective though: While "my" language (German) doesn't differ from English that much that I regularly run into the big problem of current approaches, L20n could simplify the code I write as a developer a lot:

Let's take this "simple" snippet of PHP code and German .po file to print out a number of comments (simplified source of this blog):

blog.php:
if ($postCount < 1) { print(gettext('no comments')); }
elseif ($postCount == 1) { print(sprintf(gettext('%s comment'), $postCount)); }
else { print(sprintf(gettext('%s comments'), $postCount)); }

blog.po:
msgid "no comments"
msgstr "keine Kommentare"

#, php-format
msgid "%s comment"
msgstr "%s Kommentar"

#, php-format
msgid "%s comments"
msgstr "%s Kommentare"

Now let's look at how it might look (in principle, I could be using wrong function names here) with L20n:

blog.php:
print($l20n_context->getValue('comm_cnt', array('num'=>$postCount)));

blog.lol:
<plural0: (n) -> {n == 0 ? 0 : (n == 1 ? 1 : 2 ) }>
<comm_cnt[plural0(num)]: ["keine Kommentare", "${num}i Kommentar", "${num}i Kommentare"]>

Note that I'm not sure that $postCount would be passed as an array like this, but it would probably be similar to that - and I hope I got the "plural0" macro right.
There are multiple good things about that approach: First, the actual code is much shorter and easier to read (even more so if I don't have short strings but long sentences there). Second, there is no "original string" in the source, just an ID ("comm_cnt"), it actually doesn't matter which language I'm doing first, while writing the code, as L20n doesn't care. Third, while writing the code, I could just define the string as <comm_cnt[num]: "${n}i Kommentare"> to make things simple, and I could refine it to better values later (when the code is stable). Fourth, if some localizer comes along and tells me he need 5 different plural forms depending on the numbers, he can just do that in the lol file, I as a developer don't need to know or care. Fifth, the localization file is shorter. Sixth, I as a developer am actually writing a first localization along with the code, which a localizer can use as an example for his work. And there are probably more.
(And yes, I know, gettext probably knows plurals in some way, so those might be a bad example. It's one if the easiest to grasp for a developer who doesn't speak Finnish, Polish or other grammatically more complicated languages though.)

It would be so nice to simplify code and get all those long strings out of the source (which often require horizontal scrolling here) - and that's only speaking as a PHP dev doing two languages that don't need declensions or other specialties. It must be even more compelling for a localizer of some language like that who can finally give his users a linguistically correct user experience.