Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

September 19 2011

Promoting Open Source Software in Government: The Challenges of Motivation and Follow-Through

The Journal of Information Technology & Politics has just published a special issue on open source software. My article "Promoting Open Source Software in Government: The Challenges of Motivation and Follow-Through" appears in this issue, and the publisher has given me permission to put a prepublication draft online.

The main subject of the article is the battle between the Open Document Format (ODF) and Microsoft's Office standard, OOXML, which might sound like a quaint echo of a by-gone era but is still a critical issue in open government. But during the time my article developed, I saw new trends in government procurement--such as the Apps for Democracy challenge and the site--and incorporated some of the potential they represent into the piece.

Working with the publisher Taylor & Francis was enriching. The prepublication draft I gave them ranged far and wide among topics, and although these topics pleased the peer reviewers, my style did not. They demanded a much more rigorous accounting of theses and their justification. In response to their critique, I shortened the article a lot and oriented it around the four main criteria for successful adoption of open source by government agencies:

  1. An external trigger, such as a deadline for upgrading existing software

  2. An emphasis on strategic goals, rather than a naive focus on cost

  3. A principled commitment to open source among managers and IT staff responsible for making the transition, accompanied by the technical sophistication and creativity to implement an open source strategy

  4. High-level support at the policy-making level, such as the legislature or city council

Whenever I tell colleagues about the special issue on open source, they ask whether it's available under a Creative Commons license, or at least online for free download. This was also the first issue I raised with the editor as soon as my article was accepted, and he raised it with the publisher, but they decided to stick to their usual licensing policies. Allowing authors to put up a prepublication draft is adroit marketing, but also represents a pretty open policy as academic journals go.

On the one hand, I see the decision to leave the articles under a conventional license as organizational inertia, and a form of inertia I can sympathize with. It's hard to make an exception to one's business model and legal process for a single issue of a journal. Moreover, working as I do for a publisher, I feel strongly that each publisher should make the licensing and distribution choices that it feels is right for it.

But reflecting on the academic review process I had just undergone, I realized that the licensing choice reflected the significant difference between my attitude toward the topic and the attitude taken by academics who run journals. I have been "embedded" in free software communities for years and see my writing as an emerging distillation of what they have taught me. To people like me who promote open information, making our papers open is a logical expression of the values we're promoting in writing the papers.

But the academic approach is much more stand-offish. An anthropologist doesn't feel that he needs to invoke tribal spirits before writing about the tribe's rituals to invoke spirits, nor does a political scientist feel it necessary to organize a worker's revolution in order to write about Marxism. And having outsiders critique practices is valuable. I value the process that improved my paper.

But something special happens when an academic produces insights from the midst of a community or a movement. It's like illuminating a light emitting diode instead of just "shining light on a subject." I recently finished the book by Henry Jenkins, Fans, Bloggers, and Gamers: Media Consumers in a Digital Age, which hammers on this issue. As with his better-known book Convergence Culture, Jenkins is convinced that research about popular culture is uniquely informed by participating in fan communities. These communities don't waste much attention on licenses and copyrights. They aren't merely fawning enthusiasts, either--they critique the culture roughly and demandingly. I wonder what other disciplines could take from Jenkins.

May 10 2010

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

  • 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 href="">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

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 href="">Apps for Democracy and href="">Apps for
America, but the gargantuan machinery of most government agencies
creaks along with scarcely a trace of light from the free software

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 href="">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

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

  • 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

  • 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

Two other speakers presented intense research -- involving
questionnaires, visits, and historical background -- on open source
migration: href="">Mark
Cassell (PDF) and href="">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.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!