The Web as the Platform and The Kilimanjaro Event

[Damon Sicore]

All,

Today, Mozilla contributors are building the Web as the Platform experience that incorporates all of the Mozilla project's efforts: Firefox for the desktop, Firefox for Android, Persona for a browser ID, the upcoming HTML5 Web App Mozilla Marketplace, and now the Boot to Gecko (B2G) effort to produce the first true Web phone. To deliver on the promise of the Web as the Platform, we need to improve coordination across these projects. Our first milestone in that work is something we're calling the Kilimanjaro Event.

The Kilimanjaro Event is the point in time (not a release) when we realize a tightly integrated set of products that enables users to use the ID of their choice to find and install Web apps from HTML5 App marketplaces--including one created by Mozilla--and have those apps and appropriate data synchronized amongst devices. It is important to point out that the Kilimanjaro Event is not a single release. It is an incremental effort where we deliver a series of releases and features to each of our products that result in and enable an end-to-end user experience across these efforts.

Engineering has re-inspected our methods and processes in order to improve quality of features and releases, to up the sense of urgency to deliver new features, to instill greater accountability for on-time patches, and to improve the processes we use to ship products at the project level. Today, the release trains run on time, and the desktop product is on a rhythm--shipping features and fixes on schedule. The train model is here to stay. Yet it can be improved. Our goal with the train model is to deliver significant improvements to users and developers with each release on a regular cadence; however, we find ourselves often catching the next and the next train, acting without urgency. To counter these issues we need to utilize some of the most successful techniques we created for pre-train releases. We must augment the train model.

In the past we used blocking bugs (bugs which would keep us from shipping a release if not fixed) to guide contributors to work on the bugs which, when fixed, enabled Firefox to ship. We used distributed triage with component owners doing most of the driving early in the release cycle and through the middle of the release. Eventually, during the endgame, a few release drivers led daily triage to drive releases to ship.

To augment the train model and enable us to realize this moment of integration, we are re-introducing the concept of blockers. We're adding a flag to Bugzilla, to all relevant components (including Marketing and any other group the Kilimanjaro Event depends on), to enable anyone to nominate bugs or features that block the realization of the Kilimanjaro Event. We will re-introduce distributed triage by component owners as a driving mechanism for this event. Every team will be accountable for their blockers--even those teams and individuals who have never had blockers before. As we near the endgame, we will increase frequency of triage and drive hard. This is the same technique we used for pre-train releases. Blockers will not block trains. Trains still run on time. Blockers will ride trains. Once all blockers are fixed, we will have realized the Kilimanjaro Event: We have an elegant and simple experience for HTML5 Web apps in Firefox on multiple devices that puts the user in control of their apps and identity.

The next steps are simple:

A) We will immediately add Kilimanjaro blocking mechanisms to Bugzilla and communicate how to use them.

B) The Product Team will coordinate with contributors the identification of features and fixes (in the form of bugs in Bugzilla) that will seed the lists of Kilimanjaro blocker bugs.

C) Weekly Kilimanjaro Event triage meetings will be established to quickly process nominations for blockers and, as soon as it is possible, immediately enable distributed triage by component owners.

D) We will use the Tuesday and Wednesday engineering and product meetings and the dev-planning public mailing lists to coordinate everything.

I, personally, am extremely excited about this effort. Our releases are the most exciting events I've ever experienced in my professional career, and we're going to see that same excitement this time. Plus, I'm looking forward to another great round of stickers, t-shirts and fun events celebrating what we do so well: Ship fantastic, positive, world-changing software.

All my best,

Damon

[Anthony Hughes]

Great post, Damon. I think this strategy makes a lot of sense. I'm
excited to see how Kilimanjaro takes shape and to contribute to this
effort from a QA standpoint.

--
Anthony Hughes
Quality Engineer, Mozilla

[Chris More]

Hi Damon.

I have a few questions for further clarification. Once we reach the
metaphorical "summit" of Kilimanjaro and the event has ended, is that
the end of Kilimanjaro? Once all the products are aligned as described
above, will we need to continue to repeat the Kilimanjaro or will only
the Kilimanjaro event be redeployed when there is a new "summit" to
reach (i.e. more product alignment)?

Will there still be projects at Mozilla that don't in some way align
with a Kilimanjaro event?

Is the Kilimanjaro event similar to the arewefastyet.com,
arewemobileyet.com, and areweprettyyet.com initiatives, but at a
higher level and more comprehensive?

Thanks,
Chris

[Wes Garland]

On 3 April 2012 18:18, Anthony Hughes <ahu...@mozilla.com> wrote:

> Great post, Damon. I think this strategy makes a lot of sense. I'm excited
> to see how Kilimanjaro takes shape and to contribute to this effort from a
> QA standpoint.
>

This *IS* very exciting. My team is currently building products, both for
"intranet" and public consumption, which leverage the HTML, CSS, JavaScript
stack. No Flash, No Java, No plugins, No Native "Apps".

Our server-side code runs on top of Mozilla's SpiderMonkey JavaScript
engine (via Apache and our FOSS platform, GPSEE). We officially support
only the latest version of any browser (we are on board with the fast
release train! ... but might need to graft in IE9 support shortly).

We are heavily invested in non-desktop browsers also, meaning we
specifically target GoogleTV Chrome, iOS Safari, Blackberry PlayBook Webkit
along with our desktop support. Android Firefox is on our short list to
add to our test suite -- we used to test Mac OS Fennec before the Native UI
initiative.

Many of our key application components rely on CSS3 features, and we are
starting to use new HTML5 features as they stabilize and become available.
In fact, yesterday, we did our first "live trial" of photo booth software
which uses webcams via WebRTC -- we are using Chrome Canary (like Firefox
Aurora) builds for this at the moment, but we are confident that WebRTC
technology will make it into the marketplace at large... and hopefully
Firefox Mobile. :)

This post was great, now I have a name for the convergence of events that I
have been describing in the board room (although my POV is more web-wide).
The Kilimanjaro Event is the moment I have been talking about for a long
time, now I can finally give it name. As Mozilla achieves this milestone, I
am confident that it will have a profound ripple effect throughout the web
as a whole, propelling the web forward, just as Phoenix/Firebird/Firefox
did and continues to do.

Climb on!

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Robert Kaiser]

Damon Sicore schrieb:

> The Kilimanjaro Event is the point in time (not a release) when we realize a tightly integrated set of products that enables users to use the ID of their choice to find and install Web apps from HTML5 App marketplaces--including one created by Mozilla--and have those apps and appropriate data synchronized amongst devices.

I'm absolutely excited that this spans an arch over the multiple efforts
going on at Mozilla, from traditional desktop and mobile browsers via
services like Sync, Persona and Marketplace to the whole disruptive web
device experience with B2G.
And whoever came up with "the web is the platform" as the marketing
message on MWC has to be congratulated, as this is exactly the message
we need to communicate, and it is what Mozilla was always about (at
least since the disruptive decision to build Mozilla UI on web-like
technologies such as XUL, CSS, JS, etc.) and what we need to push
forward on this again. Thanks for that!
And yes, the time has come where we can from web-like technologies to
*actual* web technologies in many areas, which is exciting by itself,
and makes all that even more awesome - and a great success for our mission!

Together we can move mountains! :)

Robert Kaiser

[Asa Dotzler]

On 4/3/2012 4:50 PM, Chris More wrote:
> Hi Damon.
>
> I have a few questions for further clarification. Once we reach the
> metaphorical "summit" of Kilimanjaro and the event has ended, is that
> the end of Kilimanjaro? Once all the products are aligned as described
> above, will we need to continue to repeat the Kilimanjaro or will only
> the Kilimanjaro event be redeployed when there is a new "summit" to
> reach (i.e. more product alignment)?

Kilimanjaro is an alignment event across several of our offerings
(products and services). The current thinking is to have regular
alignment events like K9O happening every 4-6 months, which may or may
not be named after mountains :-)

> Will there still be projects at Mozilla that don't in some way align
> with a Kilimanjaro event?

Absolutely. Windows 8 Metro work, for example, does not align with K9O.
It's still critically important. Not all products and services will need
to align in each of our alignment events.

> Is the Kilimanjaro event similar to the arewefastyet.com,
> arewemobileyet.com, and areweprettyyet.com initiatives, but at a
> higher level and more comprehensive?

Those are ongoing projects. Kilimanjaro will culminate in an event or
announcement when the in-scope products and services reach sufficient
quality, capability, and alignment.

- A

[Damon Sicore]

On Apr 3, 2012, at 4:50 PM, Chris More wrote:

> Hi Damon.
>
> I have a few questions for further clarification. Once we reach the
> metaphorical "summit" of Kilimanjaro and the event has ended, is that
> the end of Kilimanjaro? Once all the products are aligned as described
> above, will we need to continue to repeat the Kilimanjaro or will only
> the Kilimanjaro event be redeployed when there is a new "summit" to
> reach (i.e. more product alignment)?

I believe there will be more events with a different names as we will continue need to align multiple projects, converge, and also provide tools needed to provide focus and urgency on bugs that are important to overall efforts.

>
> Will there still be projects at Mozilla that don't in some way align
> with a Kilimanjaro event?

Absolutely. There are many of those types of projects today, and Kilimanjaro in no way should prohibit such projects. In fact, augmenting the train model with major milestone blockers should enable us to shepherd projects into major milestones (Kilimanjaro and beyond) by providing overall coordination, thereby informing those projects of the overall state should their integration need to be timed so as to not destabilize overall efforts or, even better, explicitly improve key functionality to help a major milestone event.

>
> Is the Kilimanjaro event similar to the arewefastyet.com,
> arewemobileyet.com, and areweprettyyet.com initiatives, but at a
> higher level and more comprehensive?

Yes. arewefastyet.com provides a direction: Make this line in the graph go down. Same thing is true with Kilimanjaro: Drive this blocker bug list to zero. It is higher level in that multiple projects will have blockers for a common event.

Excellent questions. :)

Sincerely,

Damon

>
> Thanks,
> Chris
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

[da...@sicore.com]

Thanks, Wes. Your expression of excitement is much appreciated. It's encouraging to me and, I believe, others to know this effort is striking a chord in our project.

Sincerest regards,

Damon

[rolf....@gmail.com]

Am Dienstag, 3. April 2012 23:53:38 UTC+2 schrieb Damon Sicore:
> All,
>
> ... Firefox for the desktop, Firefox for Android, Persona for a browser ID, the upcoming HTML5 Web App Mozilla Marketplace, and now the Boot to Gecko (B2G) effort to produce the first true Web phone. ....
>

Great Posting, great Project.
However, I consider Palm / HP webOS soon to be Open webOS the first true Web phone. The first (smart) phone, build on Web Standards.

Just my 5 cents. ;-)

Greetings from a true and loyal webOS and Mozilla user.
Rolf

[Robert Kaiser]

rolf....@gmail.com schrieb:

> However, I consider Palm / HP webOS soon to be Open webOS the first true Web phone. The first (smart) phone, build on Web Standards.

webOS includes a lot of stuff in its "HTML" that are not standards and
not in an effort to become cross-vendor web standards, AFAIK, so if
that's true, I wouldn't consider it "web" really, despite the marketing
and name.

Robert Kaiser

[Johnathan Nightingale]

Other web-ish smartphone OSes are not strictly off topic for this thread/forum, but we're getting close to platformwarz. Eyes on the prize, please!

J

---
Johnathan Nightingale
Sr. Director of Firefox Engineering
@johnath