> One of these days I'd like to volunteer (with a large enough group of peers) to build a system like this for the government free-of-charge. I can't imagine th

> One of these days I'd like to volunteer (with a large enough group of peers) to build a system like this for the government free-of-charge. I can't imagine that a hundred good developers working part-time couldn't get this system migrated in a reasonable amount of time. Unless you and those hundred developers had previously formed a company that was building software for the government, you wouldn't even be considerable, as a matter of law. The federal government has a list of regulations they're subject to, specifically documented in the "FAR" (Federal Acquisition Regulations). One of the first requirements is that they cannot source work from a vendor who has not done work for the government before, and that they must be able to be recommended by the agencies for whom the work was done. In the industry, these are referred to as "quals" (short for qualifications), and it means, specifically, that you have done this kind of work for a previous agency and done well enough that the receiving agency would recommend you. The only way to "get" quals if you don't already have them, is to sub-contract with a qualified agency, like SAIC, CACI, Boeing, etc, and get similar work so that you can gain enough qual to do the work yourself as a prime contractor. Generally, by the time you've done this, you'll realize that no, you and a hundred good developers are not enough to deliver a project of any size to a reasonably sized government agency, at least, not by yourself. For a project that would require 10-100 developers, you'll need at least two architects, a contracts attorney, a strong project management team, and a team of experienced writers in order to even put together the proposal response enough that would make it winnable. Sunlight Foundation tried to do this same thing, and ended up with a contract that wasn't even considerable by the agency. I cannot stress enough how difficult a contract proposal is to write, and how much work and effort is involved, and without a really good proposal, you literally could not even give your work away for free, even if you ignore that 90+ percent of government contracts are indeed "wired" for an existing vendor to win them. To even write a decent contract, you'll have to have a really intimate knowledge of how that agency is already doing things, which means hiring some people from within the agency for consulting before you can even begin to write a proposal. On top of that, your architects will spend all day in meetings trying to explain away stupid things to competitors like how creating a new table in an existing database will not subject the agency to more risk of hacking, how switching from SOAP to JSON will not make systems more vulnerable, etc., etc., to an audience consisting of competitors who want you to fail, managers who want you to fail, end users who want you to fail, and other folks who are paid to disbelieve you. Moreover, you'll be limited to doing all of your development on Sun Solaris (or AIX, or whatever) using Oracle Database, communicating messages via SOAP, etc., etc., and you won't be allowed to introduce Ruby, or Scala, or ZeroMQ, or whatever new-fangled tools you are used to using except those that already exist within the environment. Reading this back to myself, it seems awfully pessimistic. It probably is, but that wasn't my intent. But, there are reasons that government projects cost what they cost, and while definitely plenty of it is wasteful, that waste isn't in there by design, but is in fact a product of a system designed to not generate the very waste it creates.