During the Firefox Summit, there was a lot of healthy discussion regarding the immediate future of addons.mozilla.org (AMO). We came up with a solid plan and timeline for top-priority items. The general idea is:

• Split public and admin pages into two separate appliations.
• Re-use core libraries, store them in a separate place in CVS.
• After the rewritten public site is re-launched in January, start development on admin CRUD pages and inremental rewrite of all developer tools.
• Profit! (just kidding)

The topics covered in the AMO breakout session ranged from standing problems, project overview, and additional resources needed to improve progress. I think it was a valuable discussion. Mostly I was happy that people recognized the importance of AMO. I left the room with a much better feeling about the future of the project (and also the knowledge that I need to work on my public speaking skills).

That said, I’d like to talk about why AMO is actually so important, because I don’t think everyone truly understands how vital it is to Firefox and Thunderbird, and consequently the entire Mozilla Foundation and Corporation.

It comes down to feature coverage, really. Most projects can hit 70-80% of the core feature requests. Firefox or Thunderbird don’t differ from this norm — Mozilla as an organization can only get so much done until they have to make the decision on where to draw the line for the next release. At some point project managers have to say, “Ok, these features are the most important and they will be what we focus on. These other ones will be slated for the next release, or whenever we get to it.”

And it’s not something unique to Mozilla — it happens everyday in projects across the world. The key, though, is managing what happens to the other 20-30% of the features. You might want to read a Wired article passed to me by Scott Kveton called The Long Tail — it explains the concept in more detail.

Successful projects today realize the value in developing for the developer — empowering the community to improve the application on their own. And I think that so far we have hit the tip of the iceberg in terms of getting a return on the ingenuity and open-mindedness of the general community.

We are already seeing a trend in more popular projects like Flickr or Google Maps where these services kick ass and deliver some awesome features just out-of-the-box, but what makes these apps _really_ special is their APIs. It’s also what makes Firefox and Thunderbird so special.

Coming down the pipe we are starting to see uses of these APIs that are mind blowing. With Katrina we saw an interesting use of the Google Maps API to report area status updates in Louisiana. On AMO we have seen some awesome extensions that have actually been integrated into 1.5 because they were so, “Duh, we should have done that from the beginning”.

For Mozilla, AMO is the playground for the determined user to do their thing and get exactly what they want to get out of their web browser or email client. It covers the extra 20-30% and best of all it benefits the product, the community, and the world (yeah, melodramatic, I know) by improving an already sound base of features.

Over the past year I’ve developed an appreciation for the importance of AMO. I’ve learned about its challenges, all the players involved, and hopefully we’ve come up with a solid plan for 2006. I’d like to see us provide a better tool for the community to develop, submit and distrubute great ideas. With that in place, Firefox and Thunderbird will continue to have a community-centric family of extensions that sets them apart from all competitors.

Oooh. Shiny.

Firefox 1.5 was released along with many changes to back-end services many people outside the developer community aren’t aware of. So instead of blogging about changes in this release I thought I’d take some time to stop and take a look at what went on with web services that support it.

Addons

Safe to say, without the great work of the Mozilla sysadmin team the release wouldn’t have gone very well. polvi and justdave worked very hard throughout the release to make sure everything stayed afloat — and I think we all owe them a debt of gratitude for their excellent work.

Seeing the overwhelming traffic to addons.mozilla.org (AMO) was pretty cool — until it started to bring down the application. 🙂 But not to worry, Dave and Alex were able to add more LVS nodes to the mix and the site is running well at this point.

On the marketing side of things, Rebron and Beltzner managed to work out the new look for AMO. They did a great job organizing content geared towards the correct audience, and I think the new look and content really hits the spot as far as addressing our main userbase — non-technical users who want to get things done!

We did manage, however, to hit MozDev pretty hard (just overall, not just from AMO). Thanks to shaver for helping us fix the search-engine page and relieve some of the pressure on MozDev.

AUS

On the AUS side of things, Chase has continued his dominance over the impossible by pushing out the new builds using the now cumbersome Bouncer 1.0 interface (one-at-a-time — more on this later) while managing to fix AUS problems caused by the disk issue on stage in the last week of November. I think we all owe Chase a bottle of port, or maybe at least a Guinness and a pat on the back.

Bouncer

Bouncer handled things pretty well during the release. So well, in fact, that Netcraft wrote an article on its performance. I thought that was pretty cool.

That said, Bouncer still needs a lot of love. Lars and I finally hashed out some of the blockers for Bouncer 2.0 and we should be able to help Chase out by providing the upload utility for adding multiple builds via a sum file. It’ll save him a lot of time before releases.

We also plan on releasing Bouncer (finally) to the public and opening it up for improvements. A community site is also in the works, once we have time to do it (weekend project!).

One of the cooler things I saw was Lars writing a conversion script to sync up the Bouncer 2.0 dev database with the Bouncer 1.0 production database in about 20 minutes. Lars, you’re a madman.

So… anyway…

It was an eventful week. The release was a success, and I was reminded of a few things that makes it all worth it:

• A focused community can accomplish so much in a short period of time
• Firefox is huge
• There are so many more opportunities to make things even better

So thanks to everyone who played a part in this release. It was once again a tremendous experience.

The whole is greater than the sum of its lesser parts.

This year, working on projects like Bouncer, AMO and AUS have been great experiences. They have opened doors for me and have helped me grow as a programmer and person. I am grateful for Firefox and the great people surrounding it — developers, testers, sysadmins, users. This coming year will hold more challenges and hopefully a lot more triumphs for all of us. Here’s to a bright future. 🙂

One person can accomplish a lot in a year. Multiply that by hundreds of millions and now you’ve got something really special.

It felt like a normal Saturday in Corvallis. I woke up — sort of — got my caffeine injection, and hopped online. Just like last night, before me sits a small terminal running Vim. White on black, Line 1, “ReviewFest Agenda”.

I review. I edit. I rewrite.

Later that morning, Firefox-one was set loose upon the sky. Polvi and the OSULUG put together a pretty cool event along with the Oregon Space Grant Consortium. We talked, we laughed, the balloon was off, we blinked, and we left smiling.

I waddled over to the Penguin’s Nest to get ready. In time, the agenda was on the board, I had our TODO list, accounts were set up, and I waited.

Soon enough people trickled in, and suprisingly the room was filled with volunteers at 2pm. I introduced myself, talked about the history of addons.mozilla.org (AMO), my involvement, how the community contributes, etc. — basically how it’s kept itself running over the last year or so.

While I was speaking about the project, I started to realize how much of AMO depends on the community. The initial site developers, all of the reviewers, the enthusiastic addons developers and proud users of Mozilla products all contribute in many ways to this project. Saturday was no exception.

Around 15 OSU students donated 3+ hours of their Saturday afternoon to help the project, moving the queue from 157 pending addons to 67, and reducing pending comments from 330+ to about 80.

Much like the Firefox-one launch, the ReviewFest showed me how much a small group of people can accomplish in a small amount of time.

But it doesn’t just work out that way; you need a catalyst. Mozilla has served as a catalyst for community production — funding infrastructure, development, project management and marketing.

Polvi has been a great catalyst locally, organizing the Firefox-one project, the sidewalk chalk incedent, and he has been great at getting people involved and excited about Linux and open source.

In many ways, the OSU Open Source Lab (OSL) serves as a catalyst by providing hosting services and spreading the word about open source by sponsoring conferences like Goscon. It’s so fun to work at the OSL and be a part of it.

My point is that in some way, someone gets the ball rolling. They get people interested, pumped up, willing to participate. It helps people realize that, “hey, we can do this!”

And once you have the initial buy-in, things start to fall into place. Focused, excited volunteers can accomplish so much — it’s beautiful. Mozilla products benefit from thousands of contributors who test, code, discuss and reinvent on a daily basis. Their token of appreciation? A great product, an itch scratched, and sometimes a little thanks and recognition.

Speaking of which, I’d like to thank the OSULUG for helping set up the ReviewFest. More importantly, along the same lines, I’d like to thank the hundreds of volunteer reviewers who have been working hard to review and test AMO submissions. Together they work hard beind the seens, and are a main reason why addons.mozilla.org is still functional.

People Who Kick Ass
Reviews	Name
1117	Wolf
1062	Alan Starr
924	Mel Reyes
751	Chris Blore
300	Daniel Steinbrook
290	Mike Kroger
219	Pontus Freyhult
200	Ed Hume
191	Giorgio Maone
187	Georges-Etienne Legendre
176	Jed Brown
141	Scott Kveton
127	Jan Dittmer
123	Cameron
123	Gabe
116	Jon Stritar
113	Toronto
112	Aggro
99	Kevin Freitas
85	Sethnakht
84	Mark Bokil
78	Doug Bromley
75	Felix Ritter
72	Roman Mironenko
70	Aronnax
69	George Topouria
68	Darren B.
65	Jeremy Gillick
65	Captain Caveman
64	Arthur Wiebe
61	JaGx
60	Davide Ficano
60	Chris Thomas

So, if you’re still reading this, first I’d like to say – WOW, you must be bored! Also, I want you to know there is still a lot of work left to do (as always!). If you’d like to help review addons or help code for the site, drop into IRC (#umo@irc.mozilla.org) or see our wiki page and reviewer’s guide for more information.

Thanks again to everyone who has contributed to AMO over the last year. It’s been awesome to be a part of it.

I’ve got a good feeling this year will be better than the last.

Last week I took 3 days of vacation to make a trip down to the Mozilla office and work on a few projects. My trip went very well — it gave me time to focus and whiteboard things with Chase.

I spent the majority of my time working on AUS – which could stand for Automated Update Service or Application Update Service. I’m not entirely clear on which one it is, so let’s just say AUS. I was able to update the AUS Lite code to reflect our needs for branch updates.

In the previous version of AUS, branch testers would turn on their automatic update settings in Firefox or Thunderbird and then receive an update notification. The successive update would then upgrade their installation to the Aviary Trunk. Not good.

So the updated code now has awareness of the Version -> Branch relationship, which is a fancy way of saying that it knows which versions get what updates.

In the first run-through, AUS only knew about major updates for an entire product. This was to test the AUS client GUI in the beginning phases of the Deer Park feature, which is one of the major things that will be added to 1.5 applications (both Firefox and Thunderbird).

So now branch testers can stay on the branch, and everyone’s happy. Upcoming features for AUS would include a better build-system bootstrap, and a better way to generate XML output into static files (as opposed to being semi-dynamic). The upcoming feature list is relatively short, but it warranted some great discussion between Chase and I.

Needless to say, the future of Mozilla’s software update looks very bright indeed.

Other things I worked on:

• Automated test scripts for AUS to verify correct output for pre-planned test cases that are stored in an .ini file. This ensures that new builds pass a sanity check, and would be ran from a web-interface or command line.
• Bouncer updates, particularly with the user interface for the build system bootstrap via SUM file using Lars’ awesome loader.py script.
• Some brief discussions with Rafael about the future of addons.mozilla.org (AMO).

Overall, I got a lot accomplished in the two days at the Mozilla office. Thanks to Chase and Karen for setting up this trip.

Unlimited snacks and redbull can make for a very productive geek.