The roads I take...

As I mentioned here recently, the Mozilla Add-Ons site ("AMO") is currently being switched to a completely rewritten, new version (v3) nicknamed "Remora". And yes, it had been rolled back after a few hours of operation due to load problems. And it might even go back and forth between versions a few times until Remora is completely up to the task of taking over that high-traffic site. At the time that I'm writing this, the new version is online once again, we'll see if it stays that way or will turn back for more improvements again.

That said, the webdev folks are pretty responsive and fixing lots of bugs that are reported in that new version. For example, the wrong section descriptions I mentioned last time are fixed now. The list of bugs fixed since Remora went live the first time is also worth a read there. Today I discovered though that the "Recommended Add-Ons" listed on the SeaMonkey Add-Ons page are often not compatible with SeaMonkey actually. I guess the fix will also be done fast - filing a clearly described bug is once again the way of choice to get attention to such minor flaws.

The biggest point of discussions around Remora is the Sandbox feature though. Oh, yes, it is a feature, not an easter egg - despite the time of year of its release
The idea of the Sandbox is actually that users can - with lots of warnings - access add-ons that are not yet approved for public use, test them and comment on them and therefore help reviewers with approving new Add-Ons before they go public. There's even a description of the sandbox feature and a policy for public vs. sandboxed add-ons available on the new AMO site. There's still the problem that the sandbox is hard to find (this is being worked on in the "easter egg" bug I linked here) - and the issue that many add-ons that previously were public have suddenly been degraded to the sandbox. Mike Shaver tried to bring some clarity into that: "we chose a threshold to start with to seed the public site". I guess this was a threshold by user comments, ratings and/or download numbers, and that probably works fine for a good number of Firefox add-ons, and they expected all others just get nominated for going public by their authors anyways. Just that the authors weren't directly informed (don't you have all their mail addresses anyways?) before this went public, so they didn't know. And then there are add-ons like dictionaries, which are usually shown on a page that doesn't link comments or ratings and won't get much of those, and which are probably only interesting for smaller local communities (like my Swiss German dictionary) and won't rank high in downloads. Additionally, there are add-ons for less widespread apps (SeaMonkey and Sunbird), which were badly visible before on the old AMO site, and therefore have less comments, ratings, and downloads - and they the download numbers won't ever be nearly as high as those of Firefox-compatible add-ons, just because of the difference in user numbers of Firefox and the other applications.
All that has probably led to widespread sandboxing of certain types of add-ons and confusion among authors, but I'm sure that situation will improve with time and communication.
Additionally, I think that, with the proper "unapproved, testing-only stuff" warnings and with asking people for commenting on the add-on as well as rating it, the sandbox can be made visible much easier - but again, let's see where the "easter egg" bug leads to in this matter.

The SeaMonkey project plans to only link AMO as the source for add-ons (e.g. on our main web page) in the future, first we need to be sure it works reasonably and we have enough available add-ons. My LCARStrek theme somehow already slipped from sandbox to public without me requesting it or me being notified, so we now have the first SeaMonkey theme listed, but I'm sure there are more themes and other add-ons out there. Please, SeaMonkey add-on authors, submit your work to Remora, and ask for it be shown on public pages!
We now have this good system, which is supporting our software well (and will also work fine with the Add-Ons Manager and its auto-update feature in future SeaMonkey versions), so let's use it!

Update (2007-03-27 03:00 CEST):
1) Mike Shaver has restored all pre-existing add-ons to public, only new extension will go through the new sandbox process.
2) Remora seems to stay alive as the new AMO now after some performance fixes.

The new addons.mozilla.org (AMO) version (v3, codenamed "Remora") finally is was online today, and it's it was quite promising. Unfortunately I still see some minor flaws with it - and one more serious issue. (And it has been temporary rolled back to the old version - for performance issues, as I was told on IRC. You can view it on the AMO preview site in the meantime.)

First, the positive sides: It really looks good, polished, professional and friendly at the same time. Then, it has sections for 4 applications, adding SeaMonkey and Sunbird to the previously supported Firefox and Thunderbird. And yes, I'm very happy to see that new SeaMonkey Add-Ons section there. Even more, AMO is now fully localized, available in 10 languages as far as I see, and I'm sure more will be added in the future. From a localizer's point of view, this is really great. Good work, web development team!
AMO has also gained a few features, such as localizable add-on descriptions, flags for pre-releases of add-ons, publicly viewable source, and similar stuff, it even can display add-ons of specific types that are compatible with a specific application - you don't see lots of Firefox-specific stuff on SeaMonkey pages now. And then, there's a sandbox (can be activated by registered users), where add-ons can be accessed that are not approved and made public yet.

And that's where the serious problem happened: Many add-ons that were public previously on AMO are now in the sandbox only and not shown to anyone - unless he's a registered user, has checked to see the sandbox in user prefs and actively clicks on the sandbox link he then gets to see. So, one thing is, it's really hard to get there. One reason for this may also be that once you're logged in, you have to realize that clicking on you mail address at the right top of the page is the link to "Edit user prefs". Another reason it that the sandbox is, as I said, pretty well hidden.
The biggest issue with that sandbox is not that it's hard to find though, but that many previously public add-ons are now hidden in there, including 3/4 of all dictionaries and all SeaMonkey themes! I don't understand why those add-ons, that already had been reviewed and approved for the old AMO site, are suddenly hidden in this sandbox and treated like they are insecure and not approved. (This includes my Swiss dictionary and both my SeaMonkey themes, BTW.)

There are some other flaws as well, but all of those are minor: The "Themes" and "Extensions" sections for SeaMonkey wrongly mention Firefox; once you're logged in, the site feels quite slow; the SeaMonkey themes section is missing almost all categories (only "Misc" is shown, but not all themes available [in the sandbox] have that category set); if you click a link to a listing that results in no add-ons to display (e.g. popular SeaMonkey themes) you get a page without any site decoration, only a "No add-ons in this category!" message that looks unprofessional. This may be just a page that forwards you to a normal one after a few seconds, but as empty as it is it looks strange.

I hope those issues, esp. the hiding of many previously public add-ons, will be fixed soon, as that new system really looks promising!

Now that the USPTO lists both our trademarks (for the word "SeaMonkey" and our logo) with a current status of "Application has been published for opposition", I started to think of more ways to spread the word about our software and do some SeaMonkey marketing. And you might have seen some results of those thoughts already...

Before mentioning details about that, some short remarks about the trademarks: Even with that status, and about 6 months after the Mozilla Foundation filed the trademark applications, those marks are not officially registered yet but that should happen unless there's some opposition to that. IIRC, even some "Star Trek" figure once said that bureaucracy is a constant in this universe - and as one can easily see here, it also takes time. A lot of time, given the fast life of the software industry.
Due to our request, the Mozilla Foundation (MoFo) currently is exploring doing trademark filings for SeaMonkey in Europe and Japan as well. Thanks to Frank Hecker and Gervase Markham from MoFo for helping us so much in this regard.
Also, I want to ensure that those trademarks do not mean that anything in our source base will not be covered by the MPL/GPL/LGPL tri-license in the future. MoFo people share our opinion on trademark and copyright being two different things and so we can publish trademarked imagery and names under the tri-license (which only covers copyright).
We're currently in the process of finishing up a trademark policy for using our marks, very much modeled after the ubuntu one.

That leads me to a first real point about SeaMonkey marketing. Once we have that policy up at our project page, we want to put up a good collection of logos and buttons for people to use to link to our project. As trivial as it sounds, this is probably one of our main marketing initiatives - SeaMonkey is a community project, so we need to do community marketing mainly: Our community is not only what makes it possible to keep the project alive, our community is also who needs to spread the word about SeaMonkey.
We need YOU to tell other people about SeaMonkey!

What the SeaMonkey Council can and will do, is to support community members who spread the word with some materials - which need to be made up by other community members though, so we can put them up on our pages, the wiki, or wherever they make sense. If you feel something's missing for community marketing, tell us in m.d.a.seamonkey or even better, create that missing piece yourself and tell us in that newsgroup, so we may be able to put it up somewhere for a greater public and/or improve your creation.

Another way to support people in spreading the word is a SeaMonkey shop with T-shirts, maybe mugs, maybe even other stuff. I'm working on getting such a shop in the next weeks. It will probably be at CafePress, as we can offer more than just T-shirts there and their int'l shipping costs for single T-shirts are better than spreadshirt's. We'll try to not produce income for SeaMonkey with the shop but get that marketing material out to you as cheap as possible - we wouldn't know whom to give any money we earn to anyways, we care much more about having many people to spread the word.

We realize that many people just haven't heard about SeaMonkey. Many users who want an integrated suite might stick to Mozilla suite just because they either don't know about it being a dead project or - even more often - don't know that there's a vibrant project out there which gives them basically the same software, only with a different name and current updates.
This is why getting SeaMonkey onto the suite start page (see my recent blog post) makes sense. Most people who want a browser only have probably migrated to Firefox already, those who want the integrated suite might not know about SeaMonkey though.
We also are looking into getting some word about us out to the press, but as we are backed by MoFo, we need to coordinate such activities with them. This would be no big problem usually, but the suite start page topic has recently stirred some discussions internally there about to what extent they want to actively promote competing projects/products. I'm sure we'll find some solution that works for all sides though and improves choice and innovation on the Internet.

Our primary target audience consists of advanced and professional users and web developers though, and apparently there's a big enough group there who wants an integrated all-in-one solution. We won't reach those through mass marketing though, we mainly need peers in our community to tell them about SeaMonkey.

As I said before: You all need to actively spread the word. Yes, you as a community member are the core of SeaMonkey marketing. Please help us and tell people around you about our project and our great software!

Update (2007-04-04): I stumbled over the correct "Star Trek" cite wrt bureaucracy now: It's Dr. Leonard "Bones" McCoy who says "The bureaucratic mentality is the only constant in the universe" in the movie "Star Trek IV: The Voyage Home"

Again and again I stumble over people who seemingly don't understand how a bug reporting system is supposed to be used - usually that's Mozilla's Bugzilla in my case.

Those systems can work very well for reporting and working on bugs, and even though it could be improved (yes, all improvements I'd like are filed as bugs themselves), Bugzilla has grown into a really good such system over the years. To be honest, I've never professionally studied such technologies, and Bugzilla is the only one I know really well, but when you're working with it long enough and think about it, you begin to understand what this is all about.

One common mistake people are making is to go into a bug report that already has 50 or more comments and is pretty lengthy, and then they request some detail change in some part of the work that has already been done, reviewed and landed there. A recent comment in the "new SeaMonkey theme" bug doing exactly that is what leads me to write this blog entry. The correct solution to deal with such issues caused by a different bug (esp. if that one is a lengthy report already) is to file a new "followup" bug that covers exactly that one detailed issue you're seeing and mark this new bug dependent on the original one. Leaving a comment in the original bug can also help to get attention to the new issue, but that comment shouldn't be more than "I found a problem with X caused by this checkin, see bug XXXXXX" (Bugzilla is intelligent enough to link your mentioning of "bug XXXXXX" to the actual bug report).

Another common mistake is to add comments to the bug that don't add anything that wasn't already said there, esp. comments that just tell "I'm seeing this too" or "I want this fixed as well" or even "Adding myself to the CC list". "Me too" is only useful if you tell that you're seeing this on a configuration where it wasn't clear before that it is affected by the bug. If developers already know the cause for the problem or are convinced that this should be fixed, a "me too" comment just wastes their time - they need to read it and get no new information from that read, while they could use the same time to already actually work on a fix. You're probably distracting other people from work with such comments, keep that in mind.

I even believe that discussion of how some implementation should work in concept is usually wrong for a bug report. Bug reports should focus on explaining what exactly is the issue, finding out its root cause, and the actual fix (along with reviews of that fix). That's even true for feature requests. If the design of such a feature is unclear, this should be discussed in some place that allows to do this more in a real discussion style, allows easy editing of drafts, etc. Use a newsgroup, a wiki page, or both, or whatever fits this issue, link that from the bug, and come back to the bug when the discussion has settled on a specific approach.

So, actually, effective use of such a system comes down to:

• Care that there's one bug report per specific issue, avoid the need for multiple patches/fixes in a single bug report.
• If you want to track multiple or general issues, use a tracking bug for that (such a bug has multiple specific reports marked as dependencies and no specific work/fix/patch by itself)
• Only add comments that add further information that helps to resolve the bug
• Care that new people who look at the bug report can easily get informed of what the specific issue is and how far a fix has been progressed
• File followup bugs for any derived specific issues, such as regressions, improvements to already passed (reviewed/checked in) fixes (unless you're very sure of a logical one-line-fix or that a backout is the only chance to fix the derived issue)
• When filing new bugs, make sure that all information someone else (a developer) needs to fix this bug is there. If you're not sure what such a developer needs, describe the details of the problem you found (when/where/how it happened to you, what version of what software you were using for that, what you were doing in detail)
• If a developer tells you to file a followup or take the discussion somewhere else, just do it - even if you don't understand why this may be a good idea. If you request a fix done by someone else, it's usually a good idea to also follow his requests that ease him working/helping on a fix. It's usually a good idea to add a comment on the bug that says "requested followup is bug XXXX" or "I opened a thread for this discussion at http://foo/bar" or "The requested draft is on the wiki at http://foo/wiki/bar". Helping developers by following their requests can magically speed up fixing

I'm sure this set of common mistakes and guidelines is incomplete, but I think if you follow this advice, working with Bugzilla and other bug reporting systems will not only be more fun for everyone, but also will make fixes appear faster as developers can be more foused to specific working tasks.

OK, looks like what I did blog a few hours ago is obsolete now.

Asa Dotzler points out that the word of the Firefox marketing manager and a MoFo employee aren't worth as much as I'd like: "The upgrade path for the Mozilla Suite is Firefox. This was decided years ago and has not changed."
In this case, I'd rather leave those people with a scarily insecure Mozilla 1.x with their suite than to work on Firefox-only marketing.

It would have been nice to give those people a real choice. But it seems the time is not ready for giving them such a choice.

"The mission of the Mozilla project is to preserve choice and innovation on the Internet."
How bitter this can sound in a world where Mozilla doesn't even want to give people the choice between software created within the Mozilla family. I had a quite high opinion of Asa at times, but such statements don't fit with that. I may have to re-think this one.

The Mozilla suite is dead. OK, that might be old news for you. Using the outdated Mozilla suite is a security risk, as you already know. And with the alive-and-kicking SeaMonkey suite and Firefox browser there are quite good upgrade paths available, and you, of course, have followed one of those a long time ago.

Probably this is really true for you - but unfortunately there are a lot of people out there that have not upgraded to one of our current products yet and are still risking their security daily by using a hopelessly outdated browser. You want numbers? OK, here they are: www.seamonkey.at is the homepage of the German SeaMonkey and Mozilla suite localization - and happens to also contain the default start page of those localized suite versions. That domain had 3.2 million page views in February, originating from about 1.1 million different IP addresses (OK, each address is counted once per day, but I guess that doesn't matter much there). Of course, most of those hits come from people hitting their browser's default start page, 56% of all hits go to that page - so it's no surprise that the suites are leading stats for browsers there. The downside is which one is first - it's still the old, outdated, insecure Mozilla suite, scoring 65% of all hits (bots excluded) on that domain in February! SeaMonkey is "only" second with 29% of all hits, leaving 6% to the browsers that don't have their start page set to this domain - mainly Firefox (3.5%) and MSIE (1.4%), all other scoring far below 1% of all hits. That's surely no representative picture of the web, but it should be quite representative for relative adoption of Mozilla suite vs. SeaMonkey (in German-speaking countries - and I doubt other regions of the world would be much different).

For me, having 960,000 hits a month with SeaMonkey is a good start - but after more than a year of stable SeaMonkey releases and 10 months after the last Mozilla suite update, the amount of remaining Mozilla users is really scary - and looking at a version breakdown is even more so, as 1.7.13 only scores 10%, which means that over 50% of my site hits are even older Mozillas (while about 40% of the SeaMonkey users are using 1.1.x already).

So, clearly, something needs to be done to get Mozilla users to migrate to a newer browser. Someone has to kick their butt, so to say. And now, in bug 373065, we're trying to do something in that way for the default en-US version (and I'll go with a similar approach for German at about the same time). We'll be showing all those people a big warning on their start page that they're using outdated, insecure software. At the same time, we'll be pointing them to the recommended upgrade paths - and yes, Mozilla representatives also feel we should present SeaMonkey and Firefox as equal choices there. Yay! It really feels good that our project is recognized that way

I'm still waiting for some text improvements by Paul Kim from Firefox Marketing and an OK from Gerv from MoFo - but expect to see this warning hitting your start page soon. Oh wait, I forgot, you already upgraded, right?