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.