The Future of Mozilla XForms

I received a couple mails and comments lately about Mozilla XForms not being available for Firefox 5 (or on addons.mozilla.org for Firefox 4). I also have been thinking about the future direction the Mozilla XForms extension could and should take. This post tries to outline some of those thoughts.

Let's start with the facts. On the development side, I have been the only person doing coding work on XForms for almost a year now (with great support from Aaron, Alex and Olli, who did all the reviews). Unfortunately, I'm very limited on time and it has not been much work at all (at least by the results; the various platform changes required me to dig much deeper into platform code than I every thought I would, and it took me quite some time to get used those very different areas of code). This makes development extremely slow and puts the focus mainly on "keep the thing working" rather than implementing new features.

On the user's side, according to the feedback I get via mail and on the mailing list, and according to the download stats, there are still some users of the XForms extension. (The 0.8.8b1 XPI for Firefox 4 has around 300 downloads a month from my site.)

Finally, the environment side. The XForms extension is a binary component that uses many internal interfaces of the Mozilla platform. This makes it, as the past has shown, highly affected by platform changes. It has always been the case that some changes were required on every major platform release (formerly every .x release, e.g. 3.5, 3.6 etc., now every release, e.g. 5, 6, 7).

Since the 3.x-days, three things changed:

1. No more stable APIs. This has been outlined in [1] and implemented with Firefox 4 (Gecko 2.0). This means we cannot rely on any API to stay stable for more than one major release.
2. With the Rapid Release Process [2], the new development model since Firefox 5, a major release is released every 6 weeks and users are auto-updated to that release.
3. Extensions with binary components must be at least recompiled for the new major version, even if no changes to the codebase are necessary. [3]

These three points put together mean that not only a new XForms release every 6 weeks is necessary, but also that a growing number of fixes for platform changes is needed.

You probably see the problem now. One developer that's short on time has absolutely no chance to do a release every six weeks, and without that the Mozilla XForms extension becomes unusable every six weeks (as said before, users are auto-updated to the new major release).

So, what's the conclusion? With the current situation, I will not be able to keep up the speed. If no other developers pop up, I don't see a future for the Mozilla XForms extension. I personally will continue to use it in the project I'm working on (and that will stay on the platform Firefox 3.6 is based on probably), but I will not invest much time into the further development to make it compatible with the latest Firefox release.

Put the other way around, this means: if you are a user of the Mozilla XForms extension and need it to be supported on newer Firefox versions, you might consider joining the development (I will help where ever I can, and I am sure that Aaron, Alex and Olli do the same) or pay someone to do so.

As a final comment, I personally came to the conclusion that XForms as a browser plugin is dead. XForms as technology is still very much relevant, but not for all use cases thought of when initially standardizing XForms 1.0. One of them, replacing the "old" HTML4 forms, will probably never happen. HTML5 and its surrounding technologies make the browser much more powerful in a generic way. This makes it possible to provide a much greater user experience with server-side solutions than it was possible a couple years ago. The web and with it the browser market changed drastically over the last couple years, with more competitors and innovations happening at a much faster pace than ever before. By acknowledging this we can use the new opportunities the HTML5-Cloud-Buzzword-Web brings to provide an even better experience for the users of XForms -- unfortunately, the Mozilla XForms extension will not be part of that experience.

 

PS: There is much discussion going on in the community right now about add-on compatibility, including ideas like porting binary addons to js-ctypes or using the Addon SDK (JetPack). Both options are not really applicable to XForms, as it is probably unique in the way how deep it
integrates with the platform. Even if they were, a lot of engineering effort would be necessary to utilize those technologies. [4], [5]

[1] http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/18f49e75338e4ce0/f42915417230e621?pli=1
[2] https://wiki.mozilla.org/RapidRelease
[3] "We have and we will break add-on API compatibility with every release, certainly binary add-on compat. We will be adding major new features or doing serious re-architecuring with every release." -- Asa Dotzler at http://weblogs.mozillazine.org/gerv/archives/2011/07/firefox_version_numbers_cognitive_disson.html
[4] http://xulforge.com/blog/2011/07/version-numbers-add-on-breakage/
[5] http://adblockplus.org/blog/binary-xpcom-components-are-dead-js-ctypes-is-the-way-to-go
This is a cross-post from the mozilla.dev.tech.xforms news group, please follow up there for the further discussion.