Talking about software

So far the Apache developers' role has not been discussed. The Apache project bears resemblance with participatory design. Through their study of real-life projects, Waltz et. al. observes that for developers to understand users' needs software it is important they speak the same language "or, at least, dialects whose semantics are similar enough to facilitate communication and understanding" [WALZ1993](Curtis et al. 1993, p. 63). Unlike the unified process where requirements are captured through use-cases, no explicit requirements gathering takes place in the Apache project. Quite particular to the Apache project is the convergence between user and developer. Developers often play the role of users, like Robert Thau does when using the wish for having simply one configuration file as an argument for Skolnick's implementation of virtual hosting. In other discussions, like non-forking, Thau plays the role of systems expert again.

Unlike the unified process where formal iterations are employed to ensure periodic feedback and communication from users, the Apache project has a continuous communication between users and developers. The feedback is often immediate, but it is not always possible to tell whether the team members are playing the role of user or developer. Often they play both roles, and it isn't all that interesting to talk about the split between developer and user. Julian Orr draws up a triangular relationship between user, technician and machine [ORR1996](Orr 1996). The same triangular relationship can be seen between user, developer and software. It is by talking about the software that developer and user can reach a common understanding of what they are dealing with and the requirements for the software to be developed. It is also through talking about the software with the user once the software is running, that the developer will make an understanding of how the software fulfills its requirements and which are the shortcomings that have to be corrected.

If we look at how virtual hosting came about it is apparent that it is due to the convergence of roles. The need for virtual hosting arose as a user-land problem. However, since both Thau and Skolnick are developers they choose to implement the feature themselves. After having the functionality partially in place, can they start talking about the software and possible directions. But it isn't always necessary to even produce software. Knowledge stemming from use—Robert Thau speaks about the peakiness of Web server load—enriches the technical discussion surrounding virtual hosting. The convergence between user and developer lets user-land considerations effortlessly blend with technical discussion. The triadic relationship remains an important part of the Apache project's work-style.

At the same time as the users of the above example do share their explicit knowledge about their own requirements to virtual hosting and that a possible solution to the problem would stem from combining the users' operational experience with the developers' knowledge of the software and the underlying operating system, it can be argued that the ensuing discussion after Hartill has forwarded the message is in fact a new phase of socialization. "… experienced-based operational knowledge often triggers a new cycle of knowledge creation. … the users tacit operational knowledge about a product is often specialized, thereby initiating improvement of an existing product …" [NONAKA1995](Nonaka and Takeuchi 1995, p. 72). As it happens, the users' request is technically infeasible and as such does not initiate an improvement of the Web server. Backtracking a bit I will argue that the initial drive for virtual hosting does stem from the combination of experienced-based operational knowledge that has triggered a cycle of knowledge creation. By combining explicit knowledge from the ISP domain and the Web technology, Terbush and Skolnick have found the need of hosting virtual Web sites on one computer. Terbush's sharing of two models for handling this feature and Skolnick's actual realization of the feature are both socialization triggered by combination. This is somewhat at odds with the original model of knowledge creation where the process starts with socialization. I would argue, and I believe the virtual hosting vignette bears sufficient arguments to support my case, that innovation actually starts with combining knowledge from different domains.

In all of this, it may be easy to forget there is a technical aspect to the Apache project. The non-forking discussion is complex and filled with technical nuances. The participants post fragments, assuming knowledge of the issues by the other participants. Through the implementation of possible solutions and discussions, the team builds a joint understanding of the problems, caveats and pitfalls involved with implementing a non-forking server.