Andy Oram

Notes from the Politics of Open Source conference

by @praxagora  | +Andy Oram  | Comment10 May 2010

Small conferences are often the best, especially when there's a high concentration of really well-educated and personally committed people sharing a room for two days. That's what I found at the Politics of Open Source conference at the University of Massachusetts Amherst on Friday. (I could attend only the second day.)

Gov 2.0 Expo 2010The conference was the brainchild of the Journal of Information Technology & Politics, which will publish articles based on conference talks in an upcoming issue. The editors have agreed to release the papers under an open license, and drafts are up on the web now -- for instance, the draft of my paper Promoting Open Source Software in Government: The Challenges of Motivation and Follow-Through.

Along with celebrity keynoters -- Eric Von Hippel and Clay Johnson -- the presenters as well as the attendees could boast a lot of real-world experience, a lot of serious academic achievement, and occasionally even a combination of the two.

They covered a lot in two days, too. A conference organizer summarized the main themes as:

  • The politics of open source software and content. Topics included the movement's openness to women and the international impacts of open source.
  • How open source influences other domains: political activism, peer production such as Wikipedia (there is still no touchstone for the peer production movement to compare with Wikipedia), and the kinds of customer-driven innovation described by Von Hippel throughout his work.
  • Government policies in relation to open source. This was the category embracing my talk, and I'll spend the rest of the blog on these issues.

My main goal was to expose the daunting challenges in getting open source software into government. Prospects have improved with supple, low-barrier initiatives such as Apps for Democracy and Apps for America, but the gargantuan machinery of most government agencies creaks along with scarcely a trace of light from the free software movement.

But people used to "configure/make/make install" or other everyday uses of free software shouldn't cluck our tongues and mutter about the backwardness of bureaucrats. There are real barriers to change, barriers that even a manager sincerely devoted to change can't remove with a wave of the hand.

For uncertain administrators looking for a smooth installation and maintenance process, proprietary products make life easy in ways that vendors do for few free software projects. (I owe some of the following observations to Joe Reddix, founder of the Reddix Group.) Proprietary vendors sit with a manager to carry out a sale. They often send a technician to install the software. If they don't actually do the installation themselves, they provide a convenient installation package.

And as managers love to say, the proprietary vendor offers one throat to choke when something goes wrong. I find it hard to imagine a nastier metaphor for a relationship between client and vendor, but Reddix tells me many IT managers form personal relationships with staff from software vendors, making it even harder psychologically to consider switching.

How many free software projects offer these amenities? A few major projects such as GNU/Linux and Apache are backed by prominent firms, and desktops offer have convenient packaging and automatic updates, but most IT managers want to update software at times of their own choosing, and the wealth of smaller projects that could meet government needs force the users to get their hands dirty.

Naturally, free software has plenty of its own rewards to make up for the lack of fancy packaging. Users can get support from developers and fellow users, and can determine the future of the software through discussion and code contributions. But IT and agency managers need to experience these benefits to love them. And they have an uphill battle persuading their department superiors as well as their staff that the new way of life is worth the change.

My paper lays out prerequisites for a successful conversion to open source software:

  • A strategic commitment to open source -- perhaps even an explicit political set of goals involving open source.
  • Managers who have lived with open source and appreciate its strengths and weaknesses. An ideological preference for open source, while valuable, is no replacement for experience.
  • A set of rational, formal reasons for moving to open source, which provide an intellectual bulwark for the strategic commitment. Cost savings are often one of the reasons, but are sometimes surprisingly hard to prove and are rarely enough to motivate a migration to open source.
  • Practical need often triggers change, and an investigation into the state of a government's software may begin for some reason totally unrelated to open source but end with the decision to migrate to open source.
  • Buy-in at the start from funders or other high-level leadership who can otherwise squash a migration.
  • Thick skin and grit, to stand up to the pressures to abandon the migration that will issue from staff, partners, and proprietary vendors.

Two other speakers presented intense research -- involving questionnaires, visits, and historical background -- on open source migration: Mark Cassell (PDF) and Aaron Shaw (PDF). Their research bears out my points, I think. Mark added several more points based on his research in three German cities:

  • Change should be done incrementally, but with a comprehensive, long-term plan to make sure departments keep progressing.
  • Winning over staff at low levels is just as important as winning over management. Bringing union representatives into decision-making and project promotion can help accomplish this goal.
  • Centralized control removes barriers among local departments and helps the migration go faster.

The third point may seem surprising -- given how much good press decentralization is getting -- but it makes sense when you consider that local experts often like to preserve the status quo because it fits comfortably with their expertise. Harsh as it sounds, progress often requires breaking the power of local elites. Furthermore, there's a practical reason for centralization: software integration. The software used by one department often has to exchange data with another, so development has to be coordinated.

Shaw also had some unique points to make. He investigated in Brazil how free software satisfied some goals of Workers Party activists who came into government with Lula, at the same time as it was being pushed by IBM, a major vendor in Brazil, and was coveted by the administrators of the state banks for practical reasons. Rising to key points of influence in government, a loosely coordinated set of free software advocates put migration on the agenda and empowered departments to make the shift, especially among the banks.

The draft I've written will accumulate more detail and get beefed up with the insights I get from Cassell, Shaw, and anyone on the ground doing these migrations whom I can get in touch with.