Looking into the dynamics of Open Source communities and questioning if there is indeed such a thing as devcentricity. Looking for evidence for or against. Looking for anything that can describe relationships and workflow between a diverse group of stakeholders with differing skills.
https://halshs.archives-ouvertes.fr/file/index/docid/860579/filename/IJHSC-Barcellinietal.pdf
Major OSS projects are highly hierarchical and meritocratic communities (Gacek and Arief, 2004; Mahendran, 2002). Five different statuses are generally distinguished in these projects, according to the distinctive rights and power of the participants. Some participants can modify the source code and participate directly in the design process and in decisions regarding the software:
– the project leader (generally the creator of the project such as Guido Van Rossum for Python, or Linus Torvalds for Linux);
– the core team or administrators, who have to maintain the code base, the documentation;
-the developers or contributors who participate in the evolution of the OSS and maintain some of its parts.
Others participants are called users. In an OSS context, users may be highly skilled in computer science, and thus far from the classical notion of “end-users”.
– They are called active users if they participate in mailing-list discussions as informants for newcomers, by reporting or correcting bugs with patches, and by proposing new modules. These active users in a particular OSS project may be developers in another project
– Other users are called passive users as they only use the software or lurk on the discussion and documentation spaces of the project (Preece et al., 2004).
It is possible to evolve between these statuses by acquiring and proving one’s technical skills and ability to engage and maintain online discussions: that is to say that roles emerge and are actively constructed within the community
(Ducheneaut, 2005; Mahendran, 2002).
and
The literature on OSS clearly identifies that active users take part in the evaluation phase of design (bug reporting and patching, e.g. Ripoche and Sansonnet, 2006) and that the project leader, administrators and developers participate in the design process itself, i.e. generating and evaluating solutions and taking decisions (Barcellini et al., 2005).
and
Open issues are still to characterize the role of users regarding the design process itself and the role of all the active participants (project leader, administrators, developers and active users) during the elicitation of the needs and requirements phase. Despite the idealistic picture that users may intervene freely in the process, we will question whether users who are neither administrators nor developers in the core Python community can really have an impact on the design choices and decisions.
and
The coding of activities is inspired by previous studies on collaborative software design activities (d’Astous et al., 2004; Détienne et al., 2004; Olson et al., 1992; Stempfle and Badke-Schaub, 2002) and by the coding scheme developed in our previous paper (Barcellini et al., 2005), which we have extended.
and
We found that users mostly tend to participate in the user-oriented list, python-list. Here, they provide references mostly on usage and personal experience, computer science, and code and examples. They also tend to provide more personal experience and end-user references than others in python-list. Even if the users’ contribution seems important in order to specify usage needs, their participation remains local to the user-oriented community and does not guarantee that these needs will be taken into account in the actual design.
and
We found that cross-participants perform an emerging role of boundary spanners, which guarantees that usage is linked to design and that the boundary between the user community and the developer community is crossed.
and
According to our results, OSS design does not seem to be participatory in the strict sense of the definition, i.e. user involvement in “design” activities. Even if users of OSS may potentially be involved in all the phases of the OSS design process (elicitation of needs and requirements, design and implementation), we found that their participation remains mostly local to the user community in the PEP process we analysed. We found that the design-use mediation is supported rather by a number of key participants who act as boundary spanners and who are not necessarily users themselves: two of them were users but the three others were administrators and developers
