IRS criticized for releasing app using open source and Objective C
treasury.gov
treasury.gov
The project wasn't criticized for using open source software or Objective C. They were criticized for using non-approved software and for not getting a waiver to use the non-approved software.
Of course there are lots of examples where rules or regulations weren't followed and bad things happened: BP oil spill, Enron and many other accounting fiascos, endless number of stories on HN about software being developed with basic security flaws, numerous stories regarding lost laptops with unencrypted private information and so on.
Each time this happens you can't count to ten before the Google bot indexes another GB of punditry arguing for more regulations.
If it were easy to know when bureaucratic controls or official regulations were appropriate and when they were superfluous the world would be a simpler place.
I'm not sure what general princple applies here other than KISS. Reducing complexity is probably a good rule of thumb for any endeavor. Complex rules and meta-rules create their own second, third, or n-th order problems.
The first implication is probably the more disturbing, since proprietary code is just as likely to have security flaws, and the only advantage it has is a clear way to shift the blame off the government. While the audit only complained about the use of unapproved open-source libraries, the IRS promises to be better about getting all libraries reviewed and approved in the future.
The second implication, regarding OMB Circular A-130, last revised in 2000, is probably quite true. The IRS's responses repeatedly express a desire to adhere to the intent of that document, but they seem to feel that following it strictly would interfere with the use of modern technologies and development methods (here, agile).
I kid, I kid