NOT FIRED FOR BUYING LINUX? QUIRKS OF OPEN SOURCE ADOPTERS' WORLDVIEWS

INTRODUCTION

How do real people in real organisations decide whether to use free or Open Source software? Is it the money? Is it love of Linux? Or fear of getting fired? Or what? I've been looking into what people actually say, what lies beneath and what we can learn.

I shall start with some theory and context to set the scene. Then I shall talk about my methods and my data, before going into the things I have been discovering, and what sense we can make of them, before I round up and take questions and comments.

To start this paper, I need to declare that I am in fact a sociologist by background. As those of you who went to a British university, and probably others, will know, sociologists are people who like to call themselves social "scientists", whose theories either have no visible connection with reality or are just verbose common sense. They aspire to rather low paid jobs in Social Services departments or else they perpetuate the species by working as sociology lecturers.

Having worked with computers for a few short years, and recently completed some study of software engineering, rediscovering a love of programming, I find that some of the more interesting and intractable aspects of the software development process are its most human-oriented aspects. Examples are requirements engineering, user interface design, project management, and software quality. At a high level, the software development process itself is fundamentally a human process – which may be why its most bureaucratic forms are currently being outflanked by agile modes.

It is also refreshing to note that the stuff of software engineering – the code and the data we work so hard at – is at least as intangible as the stuff of sociology. It weighs nothing and is really an abstraction. It exists only insofar as we agree to its existence and its interpretation. The machines we use to hold and process it are creations of society and its organisations.

This, I hope, softens you up for a declaration of the philosophy or perspective from which I approach this study of the worldviews of free or Open Source software adopters. I start with the basic notion that reality is socially constructed. In this stance, all that we think of as real, is created and maintained by means of social processes, and the principal social process that dominates the existence of the world is discourse or conversation. I am describing an outlook that sociologists have used, for perhaps as many years as computers have existed, to illuminate the workings of society, of organisations and institutions, of groups of people, and even of one-to-one conversations as simple, apparently, as a phone call. 

Although I call this a philosophy, I will not detour into the metaphysics of whether there are "really" objects, molecules, particles or quanta. You will already be aware that the world of science and engineering is deeply attached to the basic positivist idea that there are objects that exist in a real world independent of the observer, give or take some difficulty in identifying them. I need to ask you to suspend that belief for a while, or at least to accept the idea that people in social interaction create reality, as a useful and interesting model. For now, treat positivism as a grantsmanship tactic.

Scholars have used this social construction outlook to study countless things: family structures, illness, institutions, police work, the decisions of juries, walking down the street, and why people talk about the weather. A German and international team led by Christiane Floyd in 1992 have looked at software development as reality construction. Some of the leading British scholars of software requirements engineering have taken this thinking further, using the term "technomethodology" as, roughly, the study of people's actual working practices around information and other technical systems, as opposed to the neat theory of the rational human being at work.

QUALITATIVE METHODS AND TOOLS

This set of beliefs about what is real and how human life works brings its own set of techniques for systematic study. We use qualitative, rather than quantitative methods. That is, rather than using surveys and statistical tools to develop or test theories and hypotheses, we use non-numerical techniques, and draw conclusions based on critical interpretation of texts. By texts, I mean found writings (published works, office memos, private e-mails, technical documents and so on), our own "field notes" of observations we make as on-site researchers in a chosen context, and printed transcripts of conversations recorded within the study location, and of semi-structured interviews that we use to probe more deeply into some interesting phenomenon.

The phrase "critical interpretation" might sound alarmingly close to literary criticism, or newspaper reviews of the night's entertainment. How do we rise above our own subjective opinions? How can we claim to be at all "scientific"? There are several answers to this. One is that we use peer review and teamwork, and carry out reality checks with our subjects, to check our provisional findings. Another is that we use introspection and reflection, as Java Beans do, to surface our assumptions and open up our methods to the outside observer. A third way is to use systematic methodology.

This methodology nowadays is assisted by software tools that give specialist support to the analysis of text in depth for the multiple meanings it contains. The jargon acronym is CAQDAS, meaning Computer Aided Qualitative Data Analysis Software. In the UK, the University of Surrey hosts a CAQDAS Networking Project. There are many software packages around now, mostly for Windows, some for the Macintosh and one or two for Unix/Linux/BSD. Some copylefted tools have recently appeared.

One such tool – the one I use – is Atlas.ti, developed by Thomas Muhr in Germany and implemented in ParcPlace Visual Smalltalk.  This is typical of qualitative analysis software. Its most basic function is to add labels, which we call codes, to text documents. The labels can attach to segments of any length, from one word or less to a whole document. We distinguish two kinds of labelling or coding: "in vivo" codes are labels derived from words or phrases actually found in the speaker's or writer's own material. "In vitro" codes are the researcher's own phrases or concepts, words not found in the original texts. For example, talking about operating systems, people talk about "crashing", and this could be an in-vivo code. We might also detect and label passages that exhibit "deviant values", but with no-one using the word deviant.This would be an in-vitro code. The ground-level task of qualitative analysis is to run and re-run through the data, loading it with these labels.

As in software development, there follows a chain of tasks, which we follow with much iteration and backtracking. Given the coded texts, we start to group codes into structures and families. We start theory-building by constantly reviewing out texts and codes and structures. Atlas-ti and the best of the other tools provide a visual graphing  module, which we use to build semantic networks of ideas. Eventually we hope to reach "theoretical saturation" and arrive at some useful insights into the phenomena we have studied: some support for a theory we were testing, or some threrat to it, or some new hypothesis supported by our data. All the time, we can quickly refer back to the raw data. This is the heart of the well-known principle of Grounded Theory.

Because the whole project is stored in a file system, including texts, codes, memos and semantic patterns, and because we can apply version control and recording, the process can be defended as scientific, in the sense that it is quite transparent and can be audited or replicated. At the same time, it is essentially a creative human process. 

DATA SOURCES ON OPEN SOURCE SOFTWARE ADOPTION

To look at such a general topic, I needed a broad mix of data, in several respects. The type and location of the organisations to be studied, the job position and expertise of the spokesperson, and the context and medium or channel of communication for the text data under investigation are each quite varied. Thus we have British, overseas and international cases; private and public sector organisations, and sizes ranging from small to very large. The voices have come from Chief Information Officers, IT managers, system administrators, users, and journalists.  The material includes press releases, news stories, conference presentations - like this one, Web pages, news-group postings, e-mails, face-to-face and telephone interviews transcribed into text, and my own "field notes" and research memos. 

At one extreme, I made a case study of Nottingham City Council's adoption of SuSE Linux and their OpenMail Server. Here, I interviewed Richard, the "systems guy" who initiated the decision, captured press coverage and commentary, attended a presentation by the council's  IT director, and studied Richard's newsgroup postings. 

Another case where I got in close by working with newsgroup material was the adoption of Open Office by Chase Academy, an independent school in the Midlands.

Twenty or thirty case studies and think pieces from online news sources formed a large source of material. These have to be treated with care, since the media have a reputation for inaccuracy, and of course such stories have an "angle" and an eye on the readership and the advertisers or sponsors.  But qualitative research treats every text as a product of a political, economic,  cultural and personal context anyway. The whole truth is not out there waiting to be uncovered. Qualitative techniques use reflection and deconstruction to unwrap a text's layers of meaning and persuasion. A particularly interesting and unusual mini-series called "The Wrong Choice" has been appearing on Search Enterprise Linux.com, with titles like "Company Rejects Linux, Learns A Lesson." A case of writing what people want to read, perhaps?

The recent Linux For Business conference in London yielded a useful variety of live case studies. Organisations represented by speakers included the West Yorkshire Police, the insurance brokers Hill House Hammond, and the multinational business Unilever, which I believe is the only non-IT member of the Open Source Development Laboratory, Linus Torvalds' new employer. 

Another source I selected for this study is one of the less polished collections in the genre of case studies or success stories. Mandrakebizcases.com is 'an open forum to allow "Mandrakians" to share their experiences with Mandrake Linux products in "real-world" scenarios.' Its main asset is a sequence of well over 500 messages from users worldwide, talking briefly or at some length about their first-hand experiences. 

A final source, potentially, is you the listener. If you have ideas for authentic material on the decision-making process, or if you are interested in putting your own words into the mix, I will be glad to hear from you. 

THEMES, THREADS AND EXAMPLES

What follows next is a fairly free-form presentation of some of the findings of this study. I shall show how the social construction perspective opens up a very different picture from the rational-purposive business analysis image in which decision-makers do objective step-by-step analysis, focussing always on the financial bottom line. 

We see, for example, the importance of image and the presentation of self, in social life. We see power relations and struggles enacted in business decision-making. As a result, people can appear to have two different faces or voices – a "Janus effect". 

We see complex use of rhetoric and narrative. People construct stories, even fairy tales, that make sense of decisions they have taken. In fact, it seems that in many cases the exercise has consisted mainly in justifying and reinforcing a decision that was taken at or before the beginning of the apparent decision-making process. 

We see fascinating use of various levels of language, from ultra-technical peer-to-peer talk to patronising marketing fluff. And we become aware of the multiple voices, or intertextuality, within the most apparently coherent accounts.

Some distinctive threads emerge. There is, for instance, a dimension I describe as moving between the visceral through the practical to the rational. Here, the tone varies between remarkably romantic, almost erotic declarations of love or loathing for software, pragmatic talk with its sleeves rolled up, and quasi-scientific pronouncements of objective facts about these inherently volatile objects.

Another very significant dimension is the way speakers or writers tactically minimise or emphasize the newness of the Open Source solution, according to their complex relationship with their listeners and stakeholders. This is a "half full/half empty glass" effect, since there is as much of both novelty and routine in Linux or in the GPL as we choose to say there is. 

And we start to see the cultural underpinnings of technological and business decision-making – the values, the fears, the symbols, the statements of the "way we do things around here" that make the adoption decision a statement of who we and our organisations are, or wish to be, at least as much as a conscious thought process.