Sunday, 22 November 2009

Offset your Bad Code footprint today

Twisting the much-abused concept of "offsetting" carbon dioxide emissions (your "carbon footprint") by buying "carbon credits", now you can "offset" your footprint of badly-written software by buying Bad Code Offsets.

Donations go to the widely-used open source projects jQuery, PostgreSQL, and the Apache Software Foundation.

Nice idea, but that last one is enough to trigger my rant mode:

Perhaps this will help Apache Commons to actually finish and maintain a project for once!

Apache may have, according to their home page, "a desire to create high quality software that leads the way in its field", and be "celebrating a decade of open source leadership", but the part I have experience with - the Commons java libraries - are, despite being very widely used, hardly a shining beacon of what open source can achieve in terms of Good Code!

Over the last few years I have spent a lot of time with several of these, using them in a large java project in my day job. This has proven a very time-consuming and frustrating experience. Without exception, I have found them to be incomplete, buggy and poorly written, and often essentially orphaned, with no releases in several years despite numerous reported critical bugs. I have had to build custom versions of four of them to fix basic failures - typically things that have already been reported with submitted patches, and often things severe enough to break my production installations. Fixes contributed back to the projects generally just sit in the issue tracker, unreleased! Why even bother contributing?

Bad open source code which is free, I can tolerate, if it admits its limitations and its completely unsupported status. After all, I can (and do) fix it myself, given the permissive license.

Bad open source code which makes a lot of noise about community, claims to strive for high quality and to lead its field, provides an issue tracker and release plan, yet doesn't release contributed critical bugfixes even after several years - this I have much less tolerance for.

More than most projects, I blame the Apache Foundation and its process for this. As Paul Graham points out, process (especially ease of releasing, and hence frequency) has a lot to do with software quality and currency. Apache places a big emphasis on their community consensus process, committees, the process of gaining project committer status etc, so they should be blamed when that process fails dismally and still hasn't released known, already-implemented fixes after several years.

via Coding Horror

No comments:

Post a Comment