Been a busy couple days in Selenium-land. On Tuesday I pushed a new version of Selenium-IDE (see the official announcement) and yesterday Sauce Labs pushed Sauce IDE. I’ve not been coy about my relationship with Sauce Labs and don’t want this to be a generic fluff post, but I think Sauce IDE will eventually be the model for building a commercial product around Selenium-IDE. And the reason for this is/will be packaging.

Firefox extensions are, at their core, just a zip file with an extension Firefox knows what to do with and have a minimum common set of configuration files (install.rdf, chrome.manifest and such). One of those configurations in the Se-IDE and Se-IDE plugins is to set the em:type to 2 which tells Firefox that it is an extension (rather than a theme or whatnot).

The ‘classic’ way for a businesses to commercialize an open source project is to essentially fork it and start along their own, potentially divergent path. One of the goals of starting to develop an API for Se-IDE was to explicitly avoid all this splintering.

The Firefox system for extension is extremely helpful in this regard. There are very few things a commercial entity cannot do to Se-IDE through overlays. This means they don’t need to fork. I fully anticipate that situation where extra helper methods, or even some refactoring will be necessary to succeed long term, but in general, companies don’t need to change the code Se-IDE code. They just write an extension.

There is still a bit of a delivery problem though. My model for the plugin idea for Se-IDE has been the relationship between Firebug and YSlow. When you go to the YSlow page it says to install Firebug, then install YSlow. This is fine for the alpha geek demographic, but is less than appealing from a corporate perspective. What you want is a single installer.

The folks at Firefox thought of that too! Enter the multi-item installer.

What this lets you do is package multiple .xpi files in a single .xpi file. Which means, in a commercialized Se-IDE perspective, you can ship the version of Se-IDE unmodified as well as your modifications as an extension in a single file. Here is the install.rdf of a multi-item xpi banged out to package Firebug with a couple plugins as a make-sure-it-works experiment.

<rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#"><description about="urn:mozilla:install-manifest"><type>32</type><id>firebug@goucher.ca</id><name>Firebug Multi-installer</name><version>0.0.1</version><creator>Adam Goucher</creator><description>Proof is in the pudding</description><targetapplication><description><id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</id><minversion>2.0</minversion><maxversion>3.6.*</maxversion></description></targetapplication></description></rdf>

Now, Sauce IDE isn’t quite there yet, but that is the endgame. Right now, it is about 60% there; Se-IDE was forked, but the modifications were made in a plugin-esque manner so they could be separated once it was all working. It’s working now, so the splitting will commence shortly meaning the fork will be retired and an official Se-IDE xpi will be bundled as part of the multi xpi.

Plugins are where a lot of future development of Se-IDE will be focused. Heck, some existing functionality might be extracted into an extension to clean up the code / core. Plugins are only half the story though when it comes to commercial entities adopting Se-IDE as the automation platform they build upon. They need simple distributions to appeal to the mass market. Thankfully, there are ways to solve that problem.

So let’s start getting those commercial distributions of Se-IDE going!