How well can open source transcend cultural and language barriers?

A few days ago I posted to the ironbee-devel list about the experimental nginx module for Ironbee.  It cannot be incorporated into Ironbee’s normal build/test processes in the manner of the Apache HTTPD and Traffic Server modules, because nginx doesn’t support loadable modules, so the libraries have to be installed so they can be linked when the nginx module is built.  This, along with a much more limited API, is presumably one of the design decisions the nginx team made when they focussed firmly on performance over extensibility.

In response to my post, someone drew my attention to an nginx fork called tengine.  The key point of tengine is that it addresses precisely the issue of loadable modules.  And not just that: it supports input filters, opening up the possibility of overcoming another shortcoming of the nginx module – the need to read and buffer an entire request body before scanning it.  Interesting.

I’ve now downloaded tengine, and tried building the nginx-ironbee module for it.  It appears to be fully API-compatible, and the only source change needed arose from their only having forked nginx 1.2.6 (the stable version), whereas I had developed the ironbee module using nginx 1.3.x.  All I need to add is a preprocessor directive to detect nginx version and work around the missing API, and the two are (or appear to be) fully interchangeable (well, until I take advantage of input filtering to improve it further).  This is seriously useful!

Tengine has been a collaborative open source effort for two years now (that’s almost as long as TrafficServer), yet this is the first I’d heard of it!  Perhaps one reason for that is that Tengine is made-in-China.  Just as TrafficServer originated from a single major site (Yahoo) before being open-sourced, so Tengine originates with Taobao and a Chinese developer community.  They have English-language resources including a decent-enough website.  But as a developer I want the mailinglist: there is an English-language list, but just looking at archive sizes tells me all the traffic takes place on the corresponding chinese-language list.

How much of a barrier is language?  I’ve written about that before, and now it’s my turn to find myself the wrong side of a language barrier.  Actually that applies to nginx too: the Russian-born web server has a core community whose language I don’t speak.  Developing the  nginx-ironbee module gave me an opportunity to test a barrier from the outside, and I’m happy to report I got some helpful responses and productive technical discussion on nginx’s English-language developer list.  A welcoming community and no language barrier to what I was doing.

Like other major open source projects, nginx has achieved a critical mass of interest that makes it not merely possible but inevitable that it crosses language barriers.  Not all nginx’s Russian core team participate in English-language lists (nor should they!), but all it takes is one or two insiders with fluent English as points of contact to bridge the divide.  I’ve no idea if I’ll get a good experience on tengine’s english-language list, but I expect I’ll find out now that I’ve heard of tengine and find it meets a need.

Corollary: there is still a language barrier.  Of course!  With Apache I started out developing applications (some of them modules) before making the transition to the core developer team.  With nginx or tengine I know I can’t make that transition – at least not fully.  And because I know that, I’m unlikely to let my work take me in that direction.  The same kind of consideration may or may not have led the tengine team to fork rather try and work directly with nginx.

Posted on February 22, 2013, in ironbee, open source, programming. Bookmark the permalink. 4 Comments.

  1. A further look at tengine shows it may still fall short. Only a limited class of modules can be dynamically loaded. So I may have to engage with the Chinese folks to discuss why, and whether what they’ve done can easily be extended to work for me.

  2. Hi, I’m a developer of Tengine, if you have any problem about tengine or your IronBee, you can contact us. We are also interested in your IronBee module. We are looking for new and useful WAF module.

    WordPress is blocked by GFW. Bad luck.

  3. Thanks, Weibin! I think it fair to say my experiences with both tengine and nginx have been very good. For the purposes of Ironbee they’re definitely interchangable.

    One thought for tengine. Your modular build is not quite enough to integrate easily with Ironbee’s build, in that it lacks separate compile and link stages. That means we can’t build the module until after “make install” for ironbee installs our libraries. Something more like Apache HTTPD’s “apxs” tool would be great!

    p.s. Your comment appeared twice, so I deleted the second one.

  1. Pingback: ApacheCon@home | niq's soapbox

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: