Andy Oram at O’Reilly Radar: “Reasons for government agencies to adopt free and open source software have been aired repeatedly, including my article mentioned earlier. A few justifications include:
- Access
- Document formats must allow citizens to read and submit documents without purchasing expensive tools.
- Participation
- Free software allows outside developers to comment and contribute.
- Public ownership
- Whatever tools are developed or purchased by the government should belong to the public, as long as no security issues are involved.
- Archiving
- Proprietary formats can be abandoned by their vendors after only two or three years.
- Transparency
- Free software allows the public to trust that the tools are accurate and have no security flaws.
- Competition
- The government has an interest in avoiding lock-in and ensuring that software can be maintained or replaced.
- Cost
- In the long run, an agency can save a lot of money by investing in programming or system administration skills, or hiring a firm to maintain the free software.
Obviously, though, government agencies haven’t gotten the memo. I’m not just talking metaphorically; there have been plenty of memos urging the use of open source, ranging from the US Department of Defense to laws passed in a number of countries.
And a lot of progress has taken place. Munich, famously, has switched its desktops to GNU/Linux and OpenOffice.org — but the process took 13 years. Elsewhere in Europe, Spain has been making strides, and the UK promises to switch. In Latin America, Brazil has made the most progress. Many countries that could benefit greatly from using free software — and have even made commitments to do so — are held back by a lack of IT staff with the expertise to do so.
Key barriers include:
- Procurement processes
- General consensus among knowledgeable software programmers holds that age-old rules for procurement shouldn’t be tossed out, but could be tweaked to admit bids from more small businesses that want to avoid the bureaucracy of registering with the government and answering Requests for Proposals (RFPs).
- Habits of passivity
- Government managers are well aware of how little they understand the software development process — in fact, if you ask them what they would need to adopt more open source software, they rarely come up with useful answers. They prefer to hand all development and maintenance to an outside firm, which takes full advantage of this to isolate agencies from one another and lock in expensive rates.
- Lack of knowledgeable IT staff
- The government managers have reason to keep hands off free software. One LibrePlanet audience member reported that he installed a good deal of free software at his agency, but that when he left, they could not find knowledgeable IT hires to take over. Bit by bit, the free software was replaced with proprietary products known to the new staff.
- Political pressure
- The urge to support proprietary companies doesn’t just come from their sales people or lobbyists. Buying software, like other products, is seen by politicians as a way of ensuring that jobs remain in their communities.
- Lack of information
- Free software is rarely backed by a marketing and sales organization, and even if managers have the initiative to go look for the software, they don’t know how to evaluate its maturity and readiness.
Thoroughgoing change in the area of software requires managers to have a certain consciousness at a higher level: they need to assert control over their missions and adopt agile workflows. That will inevitably spawn a desire for more control over the software that carries out these missions. A posting by Matthew Burton of the Consumer Financial Protection Bureau shows that radical redirections like this are possible.
In the meantime, here are some ideas that the panelists and audience came up with:
- Tweaking procurement
- If projects can be kept cheap — as Code for America does using grants and other stratagems — they don’t have to navigate the procurement process. Hackathons and challenges can also produce results — but they have a number of limitations, particularly the difficulty developers have in understanding the requirements of the people they want to serve. Some agencies can also bypass procurement by forming partnerships with community groups who produce the software. Finally, a possibly useful model is to take a cut of income from a project instead of charging the government for it.
- Education
- Managers have heard of open source software by now — great progress from just a few years ago — and are curious about it. On the production side, we need to help them see the benefits of releasing code, and how to monitor their software vendors to make sure the code is really usable. On the consumption side, we need to teach them maturity models and connect them to strong development projects.
- Sharing
- Most governments have familiar tasks that can be met by the same software base, but end up paying to reinvent (or just reinstall) the wheel. Code for America started a peer network to encourage managers to talk to one another about solutions. The Brazilian government has started a Public Software Portal. The European Union has an open source database and the US federal government has posted a list of government software released as open source.”