|The User-Developer Convergence: Innovation and Software Systems Development in the Apache Project|
|Prev||Chapter 6. Method||Next|
The interpretative research tradition is based within phenomenology and hermeneutics. The most fundamental principle of hermeneutics is the hermeneutic circle. It is a meta-principle upon which all hermeneutic principles stem from. The circle can be summarized as:
The whole context of a phenomena can't be understood by simply adding up the fragments making up the phenomena. The phenomena must be understood as a result if the fragments and the whole.
Thus the movement of understanding is constantly from the whole to the part and back to the whole. Our task is to extend in concentric circles the unity of the understood meaning. The harmony of all the details with the whole is the criterion of the correct understanding. The failure to achieve this harmony means that understanding has failed [GADAMER1976](Gadamer 1976, p. 117 ).
My study of the new-httpd mailing list iterates between separate fragments and the context. The fragments are most commonly single e-mails, but can also be discussion threads that together form a larger whole. The whole is in these situations the entire mailing list archives. At other times I regard the single thread a number of e-mails belong to as a whole. The aim of this approach is to achieve an understanding of the Apache project by "iterating between considering the interdependent meaning of parts and the whole they form" [MEYERS1999](Klein and Meyers 1999, p. 72). Despite this, I am not entirely true to the hermeneutic approach.
In addition to iterating between fragments and the context by reading the new-httpd mailing list archives, I also chose the statistic approach in an initial effort to break the hermeneutic circle. The amount of source material made available by the mailing list archives seemed unsurmountable, and initial attempts at simply reading the archives had given few results. The use of statistics is to be understood as an attempt at organizing a complex and unorganized mass of e-mails. But it is also a failure in a part on the application of a pure hermeneutic approach to the source material.
The basic tenet of phenomenology is that all we can ever know are phenomena, as there is no such thing as a thing in itself. Once the phenomena is understood correctly, we know all there is to know [GALLIERS1992](Galliers 1992). In practical terms this means that in order to fully understand the phenomena, the entire context must be grasped. I try to provide a sufficient context for the Apache case study. Chapter 5 is the direct historical background for the Apache project. The historic backdrop for the case is the history of hacking as briefly laid out in chapter 4. As most participants in the Apache project have an academic background within computing. Some of the participants have even worked as professional software engineers. Software engineering, as laid out in chapter 2, therefore plays a role in the context of the project. Despite this, the entire context by which to understand the project is not provided. There are avenues left unexplored. I have not, for instance, tried tracking any of the other related on-line fora like news and IRC where the Apache hackers participate in discussions about Web and Apache.
Interpretative research acknowledges that even the subjects under study are active interpreters. Interpretative theory "suggests that the facts are produced as part and parcel of the social interaction of the researchers with the participants"[MEYERS1999](Klein and Meyers 1999, p. 74). I have of practical reasons chosen to solely work with the new-httpd mailing list archives. Apart from two interviews with Stig Bakken, I have had no direct interaction with the hackers in general nor any active Apache hackers. By doing so I leave out the subject under study as an active interpreter. This is unfortunate from an interpretative point of view. Only half the story is told. The Apache hackers' interpretations of the events is never heard. When I have chosen to work in seclusion, it is at the danger of missing out on important interpretations by those actually involved. There is no dynamics between my interpretation and the Apache hackers', and I have therefore had no correction of my own interpretations. This makes my interpretations more vulnerable than they would otherwise have been if I had included the Apache hackers as active interpreters.