Install the Prototype

Jetpack Prototype Experiment Report

The Jetpack Prototype project was announced on May 20, 2009 with an introductory blog post, video, and the initial version of the prototype extension. It was retired after eight major iterations in March 2010.

For Labs experiments, a prototype is the phase of a project where we rapidly iterate on design and architecture before making a determination on potentially "rebooting" and incubating further toward a production release.

Goals

The main goal of the prototype was to lower the barrier of entry to Firefox extension development, improving the usability of the developer experience for both experienced web developers and more casual "cut-and-paste" coders--individuals who don't self-identify as coders but are still able to do basic things with JavaScript by copying and pasting snippets of code and modifying them as necessary.

The prototype was also intended to serve as a facade to the Mozilla platform, thereby decoupling extensions made with it from a constantly-evolving platform.

The prototype also aimed to improve the user experience by making it easier to install and uninstall extensions, and it planned to reduce the risk of using extensions by limiting the privileges they could obtain on users' computers.

Techniques and Prototype

An overview of the prototype can be seen at the Introduction to Jetpack screencast and in the Introducing Jetpack, Call for Participation blog post.

Atul wrote about the security issues facing Jetpack shortly after the release of the prototype in his July 2009 blog post entitled Jetpack: Summer 2009 State of Security, Part 1. Later, in January of the following year, he published the roadmap for security in his blog post Evolving Firefox Extensions.

Findings

—What Went Right—

Usability

The prototype's usability was quite impressive, and received excellent feedback: developers liked how easy it was to get started writing an extension. End-users and developers alike liked the ability to install and uninstall extensions without having to restart their browser.

Many aspects of the developer ergonomics directly influenced the design of Raindrop's developer experience.

In this sense, Jetpack validated the hypothesis that both extension development and the end-user experience can and should be easier.

Web Technologies Are Good

Using well-known, well-supported Web technologies like HTML and CSS lowered the barrier to entry for extension development, since many already knew it, and extensive documentation, support, and tooling already existed for it. For instance, users could consult MDC or w3schools for help with HTML and CSS, while they could also use Firebug to introspect and debug their code.

Jetpack Enhancement Proposals (JEPs)

JEPs were the primary means by which the Jetpack platform was extended, based on Python's own PEP system. This turned out to be an excellent pattern that fostered a community of contributors at the level of API design. It also documented the history of API design nicely.

Quick to Release

The initial Jetpack prototype only took a couple of weeks to make, which was an excellent use of resources in comparison to the value of the feedback we received from the launch.

Integrating with Existing Tools Is Good

The initial Jetpack prototype integrated with Firebug, which instantly made debugging far easier than it had been in traditional Firefox extensions.

—What Went Wrong—

Scope Confusion

Since its inception, this project lacked a clear scope and had an ambiguous vision. The first release was focused on usability, while many stakeholders believed it should focus primarily on security. Still others believed that, as a Labs product, it should focus on generativity, giving developers access to things the Mozilla platform doesn't provide out-of-the-box, such as access to the system's web camera and microphone. These conflicting goals resulted in something of a second system effect, where the final product was expected to have everything, and resulted in a product that wasn't particularly good at any one thing.

There was also confusion regarding whether Jetpack technology should ultimately replace traditional XUL-based extensions: some stakeholders saw Jetpacks as complementary to traditional extensions, while others saw them as a replacement, which significantly affected perceptions of scope.

Quality Confusion

There was also significant confusion regarding whether the project was an experimental prototype or a production-ready incubation. This was in part caused by the project's ambiguous vision, but resulted in conflicting messaging that meant different things to different audiences. The belief held by some that the project was a prototype, for instance, resulted in no code review, while those who assumed the goal of the project was security consequently assumed it was a production-ready incubation. This confusion resulted in different stakeholders having entirely different conceptions of when the project might be integrated into Firefox.

Note that code review was instituted at one point because of this confusion, even though it had not been explicitly determined that the project was now being incubated (nor that the incubated version would use the prototype codebase, which of course it ultimately didn't).

Non-Systemic API Design

While the JEP system was successful at inviting participation and documenting the design of APIs, no one took the responsibility of ensuring that every JEP cohered to particular standards of API design. As a result, the slight differences between every Jetpack API made the platform as a whole feel disjoint and confusing.

Poor Documentation Infrastructure

The documentation system was designed as "yet another miracle": documentation was marked up in an undocumented microformat and intended to provide semantics that would allow for the dynamic inspection of documentation in Firebug. However, the developer of this system couldn't fully implement the system because he eventually had to focus full-time on security, so it languished. Once the JEP system was put in-place, the documentation for new APIs just pointed at the JEPs since no one knew how to write for the half-implemented solution. This resulted in a schism where half the platform's documentation was contained in one place, and half was in another.

Reliance on jQuery

There was significant disagreement over the built-in use of jQuery in the project. Feedback indicated it is actually quite confusing and unintuitive to people who know JavaScript but not jQuery.

Moving Integration Targets

As mentioned earlier, one of the best features of the prototype at launch time was its Firebug integration. However, changes to Firebug frequently broke Jetpack's integration with that extension, and Jetpack developers were unable to maintain the integration.

Little Dogfooding

There wasn't a lot of dogfooding of the Jetpack prototype by the development team after its initial launch, in part because it didn't offer any really compelling user experiences out-of-the-box.

Conclusion

The Jetpack prototype suffered from a number of goals involving scope and quality ambiguity.

Confusion regarding scope should be eliminated in the future by ensuring that every stakeholder signs off on the project's vision statement from the outset, a principle laid forth by the Software Project Survival Guide (McConnell 1997).

Confusion regarding quality should be made clearer as well, perhaps through better messaging and ensuring that all stakeholders are aware of the ways in which an experiment is different from an incubation.

Source Code Access

The source code for the Jetpack Prototypes discussed in this experiment report is available at http://hg.mozilla.org/labs/jetpack.

Incubation

The Jetpack Prototype was superseded by the Jetpack SDK on March 9, 2010.