Modules move home

When I first released some Apache modules, I was not yet part of the core development team.  I released modules based at my own site, for whomsoever was interested.  More recently, most new modules I’ve developed have gone straight into the core distribution from apache.org.  I’ve discussed the issue of in or out in this blog before, and this post could be considered a case in point.

One of those earlier modules, mod_proxy_html, turned out to be the solution to a big latent need, and rapidly became my most popular single module.  Since first release in 2003 it’s seen a number of significant improvements, including one for which I had direct sponsorship.  More recently, the advanced internationalisation support that had developed over the years was separated out into a new module mod_xml2enc, so that the same code could be shared with other markup-processing modules without having to duplicate it and maintain multiple copies.

These modules were released as open-source, but without the infrastructure for substantial collaborative development.  At first there wasn’t even a change control repository, though that was introduced fairly early.  There was no bugs database, no general developer forum.  Anyone wanting to participate had the choice of mailing me (which various people have done – sometimes with valuable contributions) or ignoring me and forking their own project (as in mod_proxy_content).

That’s imperfect.  In ideological terms it falls short of an open development model: someone wanting to make more than a minor contribution would have to work with me taking a lead role (hire me?  dream on) or fork.     A bug report or enhancement request would usually but not necessarily get my attention, and if it related to a scenario I couldn’t reproduce, that could present difficulties.  Whoops!  Bottom line: it’s a fine model for a one-man project and somewhat workable as it grows, but lacks infrastructure support for the community that drives major open projects like Apache’s successes.

Announcement

I can now announce that I’ve donated mod_xml2enc and mod_proxy_html to Apache.  They will feature as standard in webserver releases from the forthcoming 2.4.0.

This gives them a platform to grow and flourish, even if I take a back seat – as inevitably happens from time to time when interest has passed a certain point.  It also has some further implications for developers and users:

1. Both modules are now relicensed under the Apache License.  They continue to exist under the GPL (or, in the case of mod_xml2enc, dual-licensed) at webthing, so third-party developers and distributors have a choice.
2. However, there is no guarantee, nor even expectation, that the two versions will remain in step.  It is likely now that the version at apache will be the more up-to-date in future.  That’s where it’ll get the tender loving care of a broad developer community.  My own further work may happen in both places, but is more certain to happen at Apache than WebThing (unless in the unlikely event that a paying Client dictates otherwise).

Libxml2 Dependency

This may be of particular interest to packagers.  Most obviously it relieves them of the need to distribute mod_proxy_html as a separate package, but with one proviso.  If these modules are packaged in a standard Apache/HTTPD distribution then libxml2 becomes a dependency of that.

Not a big deal for anything-mainstream (though in the distant past it was considered a reason not to accept mod_proxy_html into the core product), but it invites another change.  If you switch from expat to libxml2 for APR’s parser (as described here) you can eliminate expat, and standardise on libxml2 for all markup parsing needs.  One might consider this a good move in any case, as libxml2 is not just more powerful, but also has the more active development community of the two.  The downside then is that you’ve introduced a bigger dependency for any APR users who have no use for HTTPD or libxml2.

That leaves the expat-based module mod_xmlns somewhat orphaned.  I’ll probably get around to switching that one to use libxml2: it’s pretty-much a drop-in replacement.  Or maybe I’ll drop it altogether in favour of Joachim Zobel’s mod_xml2, which was (I understand) originally inspired by mod_xmlns but offers an alternative and probably superior platform for XML applications.