Distributed Representations and Collective Agreement

Les Gasser, Gabriel Ripoche, Bob Sandusky, Bill Turner, and Jean-Paul Sansonnet

1/01/2005
(Original Publish Date: 2000)

Free/Open Source Software (F/OSS) communities develop large-scale software using complex distributed, collaborative processes. F/OSS is an arena in which "public proofs" based on limited evidence, variable social capital, and questionable expertise are routinely made: developers unknown to one another try proving that a design strategy is good or that a specific repair will be reliable; politicians, managers, and advocates debate the merits of open versus closed software strategies and acquisition policies, and so on. Many of these debates (certainly those within the developer communities) are founded on concrete artifacts (such as software codes) and representations (such as problem reports, screenshots, and execution traces) whose accumulation, use, and interpretation are distributed across space and time. These distributed objects are used as direct representations of facts, as supporting evidence, and as discourse media in public debates. Yet because they extend across space and time, they are fundamentally mysterious in these roles. For example, we find serious limitations in many common assumptions about how software codes, experience reports, and problem interpretations work as representations for supporting problem-solving and argumentation. Similarly, we only have limited accounts of how they support practices of software use. In one instance we have examined closely, problem reports archived longitudinally in large distributed issue-management repositories don't behave as faithful reflections of user experiences and source code conditions, and participants can't use them directly and unambiguously to support specific positions or design decisions. Instead, in practice these reports appear as massive, contentious assemblages of information constantly stressed by ongoing reorganization and reinterpretation. In many cases, recorded comments conflict, readers can't interpret comments, problems are reported more than once in different ways, and it is often difficult to correlate or link reports and with underlying manifestations. Empirical observations like these reveal many interesting issues of representation and practice. In this paper we unpack several kinds of representations and practices common in F/OSS communities, linking them to the problems of 1) creating consensus, 2) building social capital, and 3) taking definitive actions such as committing to specific software coding solutions or allocating developer resources.