« July 26, 2003 | Main | July 29, 2003 »
July 28, 2003
Digitally Signed Photos on US Passports
This article in New Scientist discusses a plan by the US Passport Service to issue with "smart" passports carrying a digitally signed photograph by late 2004. The new passports will include a smart card that will hold a digitally signed image. Of course, a lot of people are concerned about the potential for abuse. I've never shared those concerns. I think the advantages significantly outweigh the potential problems. Utah went through a period of civic dialogue (meaning people went non-linear) a few years ago when Scott Howell introduced legislation to make the driver's license into a smart card. I thought it would be a great place to keep a digital signature, along with other information. The black helicopter crowd was out in force decrying the loss of civil liberties. The legislation was defeated. Of course, the new driver's licenses have a 2D bard code on them that holds just as much information, its just read-only.
06:45 PM | Recommend This | Print This
OSS in Government
Tom Adelstein continues his series on open source software (OSS) use in state and local government today with fourth article that talks about how the procurement process affects OSS. Tom makes some excellent points that jive with my experience. But, there are several insidious dynamics related to OSS that I don't think Tom quite captures.
First, RFPs are not written in a vacuum. RFP authors write it after studying whatever resources are available to them, including vendor web sites, sales material, and, interestingly enough, the salespeople themselves. There's an old saying in Government that if you want to win an RFP, you'd better help write it. OSS doesn't typically have sales people working on its behalf and the collateral material available to help an RFP writer is virtually non-existent.
Even more problematic is that RFP are not usually about just hardware or software, they're about solutions to particular problems, including hardware, software, supports, etc. Most government's don't write much software, they outsource that and the vendor supplies a system to meet a particular need. So, KPMG or Deliotte and Touche submit an RFP for a total solution. Here's the problem: these vendors get a percentage of the software and hardware sales in the RFP. As Tom points out in his article, most RFPs are judged on a lot of criteria other than cost, so is KPMG going to recommend Linux or Solaris? You know the answer.
Overcoming these systematic disadvantages for OSS requires that the RFP writer and the organization that he or she works for has a predisposition to use OSS. The use of OSS where ever possible could be one of the criteria in the RFP, for example. The more likely scenario, however, is that an unfunded project gets started using OSS and grows into a funded project where the OSS foundations forms a bias in favor of OSS for the larger project.
In Utah, we added OSS products to the "approved" software list as a way of just letting people know OSS was OK. Government managers who favor OSS software will need to take such steps to drive OSS usage in their agencies.