tl;dr The IRS built an app for the iPhone. They built it using tools and libraries that hadn't internally been approved by the IRS. The team in charge of the app could have requested a waiver to use non-approved software, but decided not to because of time constraints. This was detected during a security audit. The audit was performed because this was the first time the IRS developed an iPhone app and they wanted to make sure it had been built securely.
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.
Bravo.. If you read between the lines they basically ignored outdated/inappropriate processes/bueracracy to provide a service to the end user. And by not adhering to those rules they indeed saved taxpayer dollars. Glad they pushed through and delivered... All they gotta do now is circle back and get the waivers. The epitome of a broken/meaningless process. Quite typical, unfortunately, in our gov....
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 unwritten implications of this are that open-source code must be subject to more scrutiny before use, and that the regulations regarding software development are too dated to be strictly followed.
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).
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.