Framework for Governance in Open Source Communities
C. Lattemann; S. Stieglitz
Publisher: IEEE
Abstract: In recent years, the development of software in open source communities has attracted immense attention from research and practice. The idea of commercial quality, free software, and open source code accelerated the development of well-designed open source software such as Linux, Apache tools, or Perl. Intrinsic motivation, group identification processes, learning, and career concerns are the key drivers for a successful cooperation among the participants. These factors and most mechanisms of control, coordination, and monitoring forms of open source communities can hardly be explained by traditional organizational theories. In particular, the micro and macro structures of open source communities and their mode of operation are hardly compatible with the central assumption of the New Institutional Theory, like opportunistic behavior. The aim of this contribution is to identify factors that sustain the motivation of the community members over the entire life cycle of an open source project. Adequate coordination and controlling mechanisms for the governance in open source communities may be extracted.
Published in: Proceedings of the 38th Annual Hawaii International Conference on System Sciences
This paper broadly covers governance of OSS in terms of the why, the who and under what timelines and circumstances. The paper covers some descriptions of how certain user archetypes find meaning in contributing to OSS, how they likely identify themselves, their evolving roles through a life cycle of OSS projects and communities and some insight into critical aspects of contribution, engagement and project structure in order to be 'successful'. Success in this paper is early on established as cooperation of participants, sustainablility of the OSS (or comfortable/appropriate sunsetting of OSS) and 'increased organizational efficiency '. There is also a brief mention of Donaldson and Davis's Stewardship Approach research that the paper bolsters in the explorationa nd reenforcement of co-operative and mix of intrinsic and extrinsic goals in contributing to OSS.
This paper mentions 'well-designed' OSS in the context of 'successful' OSS that has existed with sustained user base for 10+ years. The software they describe as part of this is Linux, Apache and Perl as examples. This interpretation of 'well-designed' as 'has existed and been sustained for X period of time doesn't mean that the user needs and goals are met in a 'design function' fashion. There is an alternative reading that as this paper deal primarily with Governance that a 'well-designed' OSS project has been successful in some ways in their governance. However, this paper later goes on to say that user 'satisfaction' as a metric of retention in contributors/users. In this way we can link a concept of design, HCI, usability and other design disciplines as a part of how users/contributors are retained and thus remain a part of successful governed OSS projects.
'Well-designed' may mean in comparison to commercial/proprietary tools but also could mean in comparison to 'other' OSS tools non-successful OSS tools unamed in the paper.
There is a use of the term 'innovation' when this paper describes the characteristics of open source communities and how the 'software' can be created, modified and configured within the community. Specifically in describing 'for further development of the software are sequential, meaning innovation is based on preview development and does not making radical leaps.' OSS rarely make radical leaps in what can be described as commercial/proprietary innovation. In the commercial/proprietary world, innovation is how to keep ahead of the competition and assure you are a profit making company. Therefore the pressure for innovation is more critical. Within OSS there are competitors but their is less of a culture of competition and certainly less profiting where another organisation makes losses. Youc ould describe an aspiration of OSS software as a whole is that everyone uses an OSS to do a 'function' or 'task' but those people are free to choose from many OSS that could perform that task and there is still a cultural success of all people using OSS to perform a task. Innovation tends to happen in OSS more readily when there are significant technological advances and availabilities e.g. AI, ML, Big Data etc. and often new OSS projects that may or may not have been forked or comprise of other OSS may be created in response to established OSS taking longer to make 'radical leaps' in innovation. In the Humanitarian and Human Rights OSS space the need for innovation is driven largely by if the OSS is funded by funders or not and the ways in which those funders want or do not want an OSS to focus on technologies or aspects that could be considered 'innovative'. As we engage with the term 'innovation' more and more within the OSS space through the lenses of both design and Humanitarian and Human Rights we can see more and more evidence that innovation is understood culturally as technological 'leaps' much like the commercial and proprietary world views innovation. But in practice we find that operations, activities and methods of working in OSS and Humanitarian and Human Rights OSS spaces are innovative by virtue of largely being absent and under-funded e.g. User Research, Usability and Accessibility.
There is a section of the paper that describes the act of contribution to OSS as 'pure pleasure' engagement. In that people (Specifcally coders and programmers are referenced in this paper) contribute to OSS out of an uncomplex joy. I propose that this 'pleasure' element is likely filtered via multiple other feelings like a sense of responsibility, duty of care and a want to share your knowledge with the world and less about a purely pleasurable experience of contribution.
When the paper delves into some of the details about why the category of 'bug fixer' contributes what they contribute, there is an incentive intrinsically for 'better usage' from the perspective of the bug fixer. This raises the question of if the primary role of a bug fixer is to raise errors and flaw experienced by them as a user, and then to fix those flaws themselve in order to acheive better usage, who decides if that flaw or error is indeed a flaw or error or simply a difference in the bug fixers tastes in how they consider the OSS to optimally function. 'Furthermore, many bug fixers provide solutions to the problems they find.' Here is where we can see bug fixers not just submitting functional, running errors but also submitting preferences based on their own experience as a single user (scratching their own itch) and making a generalisation of all users that if they are using this OSS, they must experience that OSS in the same way that I (bug fixer) experiences it and therefore have the same or similar preferences to myself. This is where the absence of Design professionals skilled in user research gathering and synthesising.
An aspect of this paper speaks to the want for reputation gain from contributors as an extrinsic goal. In Humanitarian and Human Rights OSS I have experienced less indication of reputation gain desire and more of an intrinsic goal for knowing and feeling like they have contributed to 'something for good' even in small ways. Another motivation described in this paper is described as '...signaling knowledge to potential employers of profit-oriented companies. By working on open source projects, programmers have the opportunity to convey specific knowledge to people outside the project. This is true of the professional role/job of a developer/coder/programmer and is a reasonbly established aspect of how these job roles progress. In the design world this is largely absent. This is likely due to OSS not being within the regular sphere of knowledge of design organisations/companies and therefore using OSS contributions as knowledge signalling spaces is not yet socially re-enforceed.
In this paper, they only describe 3 different types of OSS contributor community members. At first it seems as though the third category of 'coordinators' could contain all other types of roles and functions not related to programming/coding (cover by the first two types of bug fixer and programmer). On further reading the role of 'coordinator' morphs into 'manager' and categorises a kind of OSS contributor that has taken on a role that is strategic and guiding in nature. This therefore leave no space in this particular paper for the deeper exploration of other kinds of contributor (Design, writing documentation, community engagement or events etc.) in OSS.
The paper references 'usability' in sentence 'classification of these three important member groups (bug fixer, programmer and co-ordinator) shows the heterogeneity found in open source communities of motivational aspects and reasons for participating. It is necessary to consider these characteristics when examining the usability of governance tools.' In this context I wonder if the author also meant the 'understandability' or the 'relevancy in proximity to meaning' of governance tools.
The exploration into the life cycles of OSS is of interest when we want to investigate when and how a designer can be best involved. As I read the life cycle sections, I reflected on where designers currently enter into OSS proejcts with contributions. This is most likely in the 'mature phase' where a project is already established and has some noteriety outside of the possible echo-chambers of the OSS cultures. Designers don't tend to engage in OSS projects in the introduction stage and less likely to interact in the growth stage. The decline or revival stages are likely when designers have long absconded of contribution or they have 'taken on' a more 'programmer' mindset or role, becoming inducted in to the OSS ranks as a programmer or programmer-like in their investment in OSS principles. Th introduction stage describes an ideationa dn exploration stage on the part of developers/programers where self-determined work/contributions are critical to the success of the stage. Here is where I thought of a tension in designer involvement in the intriduction stage. Design as a function seeks to inform work through evidence and user insight or exploration. Designers are less likely to be 'scratching their own itches' in OSS spaces and more likely to be of the mindset of 'offering expertise and insight to improve for the greater good' (intrinsic goal) and/or gain experience in order to practice skills and methods needed in a future workplace. If a designer comes into this 'programmer exploration phase where self-determination of work is highley critical' with a perspective and attitude whicch asks 'Why?' of the ideas and explorations the programmers have, then this risks limiting the self-determined need of the introduction stage. 'Programming. They feel a kind of self-realization while doing creative work and supporting a useful project.' It squeezes the creativity that programmer find in the stage and seeks to broaden the rationale with user insight. At this stage, design can, at worst stop the OSS project and at best slow down the progress and push the OSS project into a premature growth or maturity stage. It seems to me that design is best positioned to enter early in the growth stage or perhaps engage in observing, documenting and facilitating activities in the intriduction phase and then as the OSS proejct fully enters the growth stage designers can engage in early community growth conversations and then establish themselves as early specialisations in this growth stage and solidify those roles in the maturity stage where specific role and specialisations become more operationalised.
In the conclusion the authors explore the complexities of implementing governance 'A main problem in implementing governance tools is considering which objectives exist for different members. A missed opportunity could be that designers could better facilitate a consenses process for governance amoungst the disparate members of an OSS project community - though only if that designer has established social capital in the project already. This aspect of social control is covered in section 3.3 of the paper where I relfected that designers have very minimal or weak social capital in OSS spaces and therefore will struggle to exert any social goverance within an OSS project. This social governance model does tedn to rely on a like-sees-like nature of respect between comparable job roles or functions. Additionally a unique aspect of Humanitarian and Human Rights related OSS is that the 'beneficaries' of the OSS that do not participate in contribution processes are rarely involved or considered in governance processes and often relegated to the 'designed for' instead of the 'designed with' level of involvement in the development of Humanitarian and Human Rights OSS.
'