This space is usually politics-free. Today I take a diversion from that course to make an argument about a political background from a technical perspective.

One of the best principles of software development is the idea of defensive code.  That we build code (and systems) that expect certain inputs, validate those inputs, process those inputs, and return the expected results.  When we get inputs that don't fit with the expections, our systems have to fail gracefully, limit the damage to other systems, and land in a stable state.

In many ways, a straight democratic process could work.  It's not hard to collect votes nationally, to provide some form of real-time reporting, and announce results in realtime.  The problem with this is the sheer number of vulnerable points.  It means that anyone can inject bad data into the system anywhere - Chicago, perhaps? - and cause changes in the system as a whole... aka changing the overall election results.

In steps the Electoral College...

In the past week, a few people have called me to task about referencing the dotProject vulnerability in the Project Importer Release and Risk Management Module update without giving details or even proof.  Since the release of the fix (dotProject 2.1.2), I finally feel that it is appropriate to discuss this in detail.

First of all, congrats to the dotProject team on the latest release.  Rolling a release is always a painful thing and coordinating the pieces it takes for a successful Open Source project - and more importantly - and solid community is difficult by all measures.