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.

About these ads

Posted on October 28, 2011, in apache, free software, open source. Bookmark the permalink. 2 Comments.

  1. In the interest of fairness, I tried to contact you in December 2008 regarding mod_proxy_html and your plans for it, but never received a response. Since mod_proxy_content was needed for a client project, I didn’t have the luxury of delaying development to continue to engage you or work within your schedule. A fork was my only practical choice.

    It turned out that the CBBB delayed my ability to release the code at all for over two years, so I’m just happy that it’s out there in any form whatsoever.

    If someone is interested in merging the changes back into mod_proxy_html, I certainly have no problem with it.

  2. Steve, thanks for the comment. My post wasn’t meant as criticism of you: I had no knowledge of your circumstances and motives, and I respect your openness about the derivation and license, in a world where not all are so honest!

    I don’t recollect contact from you, so I guess I missed or misunderstood it. Anyway, whatever actually happened, I think it reinforces my point about the benefits of a bigger community and infrastructure: less risk of your contact falling through the cracks. If you’re still taking an interest, maybe you’d like to offer some of your work via the dev list at apache. Or maybe via bugzilla, where it could take the form of feature requests accompanied by patches (though still with the expectation that they get discussed on-list if substantial).

Follow

Get every new post delivered to your Inbox.

Join 34 other followers

%d bloggers like this: