This research deals with Open Source Software (OSS) Design, seen as a new form of work organization based on : a design process open to users voluntary participation; a continuous design process; an distribution of the design process into three activity spaces on the Internet (discussion, documentation et implementation spaces). In this context, our objective is to characterize organizational forms supporting artefact and community designs. The methodological contribution of this research deals with contextual analyses of formal design process employed in the Python project: the Python Enhancement Proposal (PEP). PEP processes are analyzed according a synchronic dimension (PEP-discussion focused) and a diachronic dimension (PEP evolution in the three interaction spaces). These analyses combine: structural analyses of design and use oriented mailing-lists. These analyses provide us with representations of online discussions dynamic (chronology, thematic coherence, participants positions); content analyses based on a coding schema of collaborative design activities (generation-evaluation of design solutions, clarification, coordination), knowledge sharing (use, coding, examples.) and activities related to interpersonal issues (thanking, acknowledgment of ones works); Documentation and implementation spaces traces analyses such as time of actions, and identification of participants involved in these spaces, comparing to the discussion space; Interviews helping us in clarifying awareness of the project (design and social), the boundaries of the user oriented and the design oriented communities, and in selecting our data. Regarding the artefact design organization, we outline that the design process is distributed through the three activity spaces and through time. There is a specialization of design and use oriented mailing-lists in terms of steps of the design process and activities. Elicitation of needs and valorization of the new functionality take place in the use-oriented mailing-list, refinements of the functionality specifications take place in the design-oriented mailing list, whereas proper specifications take place in parallel in the two mailing-lists. We make clear links between actions in the mailing-lists (discussion space) and actions in the two other spaces (documentation and implementation). For instance, ending of the specification step deals with the PEP document first production and the first version of code succeed to the refinement step. Online design discussions are focused and marked by quasisynchronic interactions, qualifying the asynchronicity of the design process. After all, collaborative activities distribution and pattern are similar to the ones revealed in other studies dealing with faceto-face design meeting. For instance, generation-evaluation and clarification are the most important collaborative design activities in online discussions we studied. Regarding the design community organization, we show that the Python design community is constituted by local design networks combining users from various application domains around a core group of developers. In this community, participation is based on effective roles performed by participants more than their statuses (users vs. developers). Cognitive roles (generation-evaluation, clarification) and epistemic roles (knowledge sharing) are performed by all participants, users included. However, specific profiles (roles combination) occur to appear. Project leader and champion (the one who propose the new functionality with a PEP) have an animator profile characterized by a coordination role, a central interactive role (interaction management) in discussions, and sometimes a socio-relational role (interpersonal relations). Boundary spanners profiles, mediating usage and design, appear to be key participants for the design process performance. Their interactive role is based on cross-participation between design and usage mailing-lists, and a central position in discussions. Their epistemic role is based on knowledge sharing about design application domains. They also support the champion in defending his proposition. These results may found specification of tools enhancing participation to OSS projects, going beyond various barriers (e.g. temporal cost to take part in a project) and supporting construction and preservation of project awareness (design process and social awareness).
