Notes from the Politics of Open Source conference

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.

tags: , , ,