There’s a nice post from David Eaves today on the need for a “MuniForge” — a repository for open source municipal software. Without getting too into the details, I wanted to point out one line that really struck a chord with me, discussing the conundrum that governments find themselves in when procuring proprietary software:
…most solutions are proprietary and so lock a city into the solution in perpetuity. This not only holds the city hostage to the supplier, it eliminates future competition and worse, should the provider go out of business, it saddles the city with an unsupported system which will be painful and expensive to upgrade out of.
Talking to many government IT folks recently, I’ve heard this story over and over again. The notion of a city being “held hostage” by a software vendor is a bit abstract, and is probably hard for people outside the business to grasp, but it’s a real and important problem. To make it more concrete, and to continue to make the case for open source and open data, we should focus on telling these stories.
So, what’s your proprietary government software horror story?
I’m the lead developer of an Open Source Computer-Aided-Dispatch application, Tickets by name, and targeted to those shops/agencies that cd use a decent dispatch management solution and have no suitable budget.
It’s a web-based application, (PHP/MySQL,will work with any current browser, and the server component will run under Apache and IIS – probably others. To the best of our knowledge, it’s the only free, open source CAD application under active development.
While the geo-component isn’t yet open source – we currently use GMaps – our plans include a transition to OSM and OpenLayers.
It’s on SourceForge at http://openises.sourceforge.net/
It was recently discussed in an EMS trade publication at http://emsresponder.com/features/article.jsp?id=11988&siteSection=7
Your next question may well be re the number of installations, and the reliable answer is that we don’t really know, since it’s freely downloadable.
Arnie Shore
Annapolis, MD
I work for a large regional government organization and I must say we truly do work in handcuffs. The adoption of FOSS has been significantly hampered in local government by a combination of factors. Surprisingly, it is not so much IT department policies as purchasing policies that have caused this. Software purchases are subject to the “Request for Proposal” (RFP) policy which is designed to keep bids for purchases fair and competitive. RFPs do not address utilizing free alternatives.
Another factor is “vendor lock in”. This occurs when a vendor has such an enormous share of a market that, when it is time to acquire the software or renew software licenses, alternatives are not sincerely considered and are all too often easily dismissed. Vendor lock in also occurs when an organization has so much invested with a particular software vendor that migrating to a new system, even if it were free, is beyond their means and resources.
Then there is the “fear factor”. This is, in part, caused by software vendor “propaganda” about “issues” with FOSS ranging from security to reliability. This has so permeated many local government IT departments that they do not realize that there are just as many failures associated with proprietary software; they are just better hidden by the vendors. Another component of this “fear factor” is something I call the “blame game”. IT departments want a vendor they can blame if something goes wrong AND local government employees deeply fear the consequences of failure since elected officials are known to use the “blame game” on employees who have the guts to try new ideas. Not all new ideas work 100% of the time.
The organization I work for spends way too much of it’s time monitoring and policing software licenses and, thanks to RFP policies and vendor lock in, does not consider FOSS alternatives. Don’t “rock the boat”. Just sign that software license renewal and send those software vendors our budget and hard earned tax dollars. It’s how we have always done these things…
Recently one of the “big two” software giants performed a “contract audit” on us and found that, due to a poorly worded, decade old contract, they felt we owed them over $1,000,000 in (totally unexpected) licensing fees. These fees were paid and we continue using their software…because, like the man with failed kidneys and not enough money, the dialysis machine is a cheaper alternative than a kidney transplant.
And it’s not only licensing that is hurting local government, the ludicrous maintenance fees some vendors charge (upwards of 20% per year!) are sapping local government IT budgets.
The university community saw this coming some years ago and formed the Kuali (www.kuali.org) organization to develop higher education administrative systems. Their member list reads like a who’s who of the biggest universities in the country. Their financial system and student administration software is being implemented across the country offering their adopters big savings and a say in their destiny.
Local government would be wise to organize a similar organization. “Muni-forge” just isn’t going to hack it. If a significant federal redevelopment (or other) grant could be used to boot strap such an organization, local governments, not feeling that they were “going it alone” would flock to join it and, in the process, save the tax payers big bucks while having a say in their destiny.
In the meantime, I urge you to keep up the pressure for change in this area as it is long overdue.
In order for FOSS to take off in local government, the following changes need to occur:
The first is an attitude change. FOSS solutions need to be treated fairly and sincere choices made. Personally, I would say that FOSS needs to be given preferential treatment since it can save budget and tax payer dollars. FOSS, however, does not address everything. There are some complicated or specialized applications for which no FOSS solution exists. But where a FOSS solution exists, it should be given a fair and unbiased evaluation. This is the basis for a “Sincere Choice” policy which all government organizations should adopt..
Local government needs to become “software agnostic”. IT departments need to change their motto from “We are a shop.” to “We are a standards based shop.”. Less attention needs to be given to what I call vendor added “bells and whistles” which are often extra features and functions that are much like frosting on donuts. The concentration needs to be on “Does the software do the job?” not on who the software vendor is or what kind of whiz bang extra features does it do. Adoption of open “standards based” software needs to be a focus so as to avoid the trap of “proprietary standards” that inhibit systems from communicating with one another and facilitate “vendor lock in”. Microsoft Word documents and Excel spreadsheets are prime examples of this. Try opening an old Word document or Excel spreadsheet that was created using Windows 3.
The “blame game” needs to stop. Vendor support for mission critical software is vital whether it is FOSS or proprietary but often “community support” for non-critical FOSS applications is quite adequate. The IT department needs to learn to utilize “community support” (through wikis and the like) and also become involved in and support those FOSS projects on which it depends. Fear of failure should not inhibit innovation.
FOSS Alternative Review (FOSSAR) policies should be instated. Local governments need to establish a policy that FOSS solutions are investigated well before new software is acquired and well before existing software licenses are renewed. This is because with FOSS “no salesman will call”. It is up to the IT department in conjunction with the the departments who use it, to investigate, install, test and evaluate appropriate FOSS solutions and then make a sincere choice as to whether the FOSS solution is acceptable. As I stated above, FOSS does not address everything. There are many complicated or specialized applications for which no FOSS solution exists. But where a FOSS solution exists, it should be given a fair and unbiased evaluation and, because of it’s nature, be exempt from the RFP process. However, if appropriate FOSS solutions are not discovered or are deemed unacceptable after being sincerely evaluated, the RFP is in order. RFPs for consulting or vendor support of
mission critical FOSS are certainly appropriate.
Formation of Citizens Open Source Advisory Boards (COSAB) chaired by a citizens knowledgeable in FOSS, elected local government officials and members of local government IT departments. These boards would exist to facilitate the adoption of the FOSSAR policy and assist the IT department with initial and on-going FOSS adoption issues.
These times of “no money” are the perfect time for FOSS adoption by local government to start. Let’s stop wasting tax payer money and start working together to forge a new and better destiny for local government IT systems.
Unfortunately, for now I must remain anonymous as my job depends on doing what I am told with the proprietary tools that I am given.