From MozillaWiki
Jump to: navigation, search

Note This page hasn't changed substantially since December 2005. You probably want to read the Update pages for development plans.

< back to offsite schedule


Discussion about Topics to be covered are usability, functionality, security, scalability and marketing.

Why AMO is important

  • Incubator for new features
  • Provides tools for innovators in the community
  • Helps people get what they need faster (features added via addons instead of waiting for it to be a part of the core)
  • It's a major part of what makes Firefox unique and flexible
  • Great way to encourage integration with web services and address corporate interests
  • It helps us take advantage of the long tail.
    • Provides a way for the community to do the remaining 40% of the product.
    • Lets MoCo focus on the core 60% of Firefox that is most important.

Backdrop and State of AMO

  • Slapped together
  • Woah, wait a minute here...
  • Security audit
  • Re-release
  • It works
  • ...but it doesn't work as well as it should
  • Still needs to be rewritten because...
    • code should be reused, not done inline over-and-over
    • code should be easy to read, not impossible
    • future enhancements need to be easy, not impossible
    • the application core should be a lot more scalable

Recent Work

  • Maintenance script
  • New template and content
  • Versioning hell

What's Up With v2.0?

  • Public side is almost done but... a lot has happened since the summer and we should get our bearing.
    • Migration to PHP5
    • Adoption of a broader framework, dropping Smarty and PEAR?
    • Database redesign a necessity given other discussed changes
  • AMO 1.5?
    • Release current v2.0 code as a new public-facing version of AMO that is simplified and more reliable.
    • After this is released, refocus efforts on an improved rewrite/refactoring.

What's right?

  • Community is still strong
    • bugs being reported
    • people appreciating the new template
    • people working together on QA
  • Database layer is not a bottleneck (yet), system still running relatively well
  • No major security problems this year

What's wrong?

Since late 2004, the project has been in the hands of volunteers without a driving force behind the project. Some of the challenges we've faced are:

  • distributed volunteer base
  • lots of inexperienced programmers
  • lack of testing for submitted patches (leads to a -)
  • some developers want to use php5
  • not enough time to organize all incoming requests
  • not enough time to satisfy all requirements from all groups:
    • Sysadmins
    • Marketing
    • Product management
    • Add-on developer community
    • AMO site developer community
    • AMO users
    • Mozilla Security
    • Other parties

What do we need to change?

My conclusion (My == morgamic) is that the project suffers from a lack of organization that needs to be fixed by more involvement/investment on behalf of MoCo.

I would like to see the additional involvement (hiring/contracting/whatever) of some key players that have been lacking over the course of the last year:

  • A project manager to help relieve the pressure developers feel from all angles
  • A lead to set reasonable requirements and standards
  • A developer core, probably contractors, that is paid -- and held accountable for progress of a structured rewrite
  • A QA lead for assuring validity of submitted extensions and handling incoming support questions

Additional resources would help set aside much-needed development time and organization of the project that has served as a major obstacle to progress in the past year.

The bottom line is we tried to get everything done with a volunteer developer base, but that fell through because of lack of resources -- and we can't afford to keep things going the way they are.

What ended up happening is that all of the above responsibilities fell on morgamic for one reason or another, and one person (a volunteer) simply can't get all of this accomplished alone with only limited volunteer help as an asset.

What do we want to do?

  • Trust metrics - taking a different look at how we review add-ons.
  • Locale support - where is it? How do we take care of this?
  • Version nightmares - what versioning standard should we enforce / agree on?
  • Catering to our users - how can we improve the application to work for Mom and Dad? (input from Beltzner?)
  • Add-on signing - documentation, support hashes on AMO, other issues
  • What is a "supported application" - do we support Flock, Netscape, Nvu or just throw them into the category of "unsupported applications and/or unrecognized GUIDs"?
  • Compatibility lists - how do we handle the transition from one major release to the next? How do we say, "YES WE KNOW THIS WORKS WITH 1.5 (or 2.0)"?
  • support different apps by creating two installs

Open Discussion

  • Questions about existing application
  • Forum about future enhancements