Wednesday, February 11, 2009

Develop openly to benefit upfront from your project's community

One of the many advantages of performing free software development out in the open (releasing early and often) rather than behind closed doors (releasing "when its ready") is that you get the opportunity to immediately draw upon the rich set of skills and experience held by your project's community that might otherwise remain untapped.

For example, in March last year I created the initial implementation of a QR Code encoder for BWIPP. It wasn't complete since it lacked an important optimisation known as mask selection, but it worked so I put it out into the trunk of the project and tagged a release to the applause of many expectant users.

Then during April this new code was thoroughly tested by Jean-Fran├žois Barbeau of Objectif Lune, who incorporate BWIPP into their commercial offerings. Our many commercial integrators are valuable members of the community since, for the most part, they are very generous and provide exhaustive testing that results in new code becoming enterprise-class in very little time at all.

Eventually in November I added the missing mask selection code, although this was very inefficient and based on my best guess at the interpretation of ISO/IEC 18004:2006 section This section is very ambiguous, open to a large number of interpretations and more closely resembles something you might expect to find on a single slide from a PowerPoint presentation than a part of an internationally reviewed normative specification.

A disconcerting issue was that my implementation calculated a different optimal mask pattern to the (un-worked) example provided by the specification. However, all of the other Open Source implementations that I tried also disagreed with the provided example - and unfortunately they mostly differed from each other as well!

Actually, it does not really matter which mask is chosen from the point of view of the correctness of the QR Code symbol. The purpose is simply to pick the mask that reduces the number of occurrences of the undesirable features that increase the likelihood of a misread. However it's always nice to know that you are doing something right by producing the best possible output.

After pointing out this discrepancy on the project mailing list I was helpfully referred by an individual that assisted with the QR Code standardisation process to the editor of the ISO standard - and there really isn't anybody much more qualified to speak authoritatively about such subtle and detailed matters! So luckily in late December he confirmed that my initial implementation was indeed correct.

At this point we had a highly-inefficient, correct implementation. However in December, whilst my implementation was still being verified I received a welcome surprise. An expert on the PostScript language developed some highly-optimised code for the mask selection process which produced equivalent results to my own verified code in just a fraction of the runtime. The result was that we now had an implementation that was both efficient and correct.

So this was a clear example where the involvement of a community in terms of testing, influence, connections, authority and coding turned something that was "good enough" (and that I may have been content to leave as was) into something that was better than any other implementation that I have seen.

Well done guys!