Evolving software forges: An experience report from Apache Allura

Abstract

The open‐source phenomenon has reached unimaginable proportions to a point in which it is virtually impossible to find large applications that do not rely on open‐source as well. However, such proportions may turn into a risk if the organizational and socio‐technical aspects (e.g., the contribution and release schemes) behind open‐source communities are not explicitly supported by open‐source forges by‐design. In an effort to make such aspects explicit and supported by‐design in open‐source forges, we conducted empirical software engineering as follows: (a) Through online industrial surveying, we elicited organizational and social aspects relevant in open‐source communities; (b) through action research, we extended a widely known open‐source support system and top‐level Apache project Allura; (c) through ethnography, we studied the Allura community, and learning from its social and organizational structure, (d) we elicited a metrics framework that support more explicit organizational and socio‐technical design principles around open‐source communities. This article is an experience report on these results and the lessons we learned in obtaining them. We found that the extensions provided to Apache Allura formed the basis for community awareness by design, providing valuable and usable community characteristics. Ultimately, however, the extensions we provided to Apache Allura were deactivated by its core developers because of performance overheads. Our results and lessons learned allow us to provide recommendations for designing forges, like Github. Architecting a forge is a participatory process that requires active engagement, hence remarking the need for mechanisms enabling it. At the same time, we conclude that a more active support for the governance is required to avoid the failure of the forge.

Improving the detection of community smells through socio‐technical and sentiment analysis

“…Community smells are defined as a set of social-organizational circumstances that occur within the software development community, having a negative effect on the relations health within the development community, which may cause social debt over time. 17,22,23,39 A number of community smells have been defined in the literature. We refer to the following community smell types as theoretical lens to explore open source community health: 17,22 • OSE: The OSE smell is manifested in OSS project when too high decoupling between developers, isolated subgroups, and lack of communication and collaboration between community developers occur.…”

“…Regardless the impact of such smells on the OSS projects and community health, they are organizational patterns that can help us understand the health of a community. Despite the effort of current works to characterize, identify, and define community smells' patterns, there is a lack of knowledge on how to define and calibrate a set of detection rules to match the symptoms of a community smell with the actual characteristics of a software project 6,7,22–24 . To address these issues, we introduced an automated approach based on genetic programming (GP) to learn from the symptoms of real‐world instances of community smells 25 .…”

“…Community smells are defined as a set of social‐organizational circumstances that occur within the software development community, having a negative effect on the relations health within the development community, which may cause social debt over time 17,22,23,39 . A number of community smells have been defined in the literature.…”

“…Therefore, such symptoms make the detection of community smells even harder and error-prone. 6,7,[22][23][24] For instance, some of the common smells are organizational silo effect (OSE) 7,17 and the solution defiance (SD) 7,17 and are typically associated in the form of lack of communication and lack of cooperation due to the independent subgroups through the development team.…”

“…Despite the effort of current works to characterize, identify, and define community smells' patterns, there is a lack of knowledge on how to define and calibrate a set of detection rules to match the symptoms of a community smell with the actual characteristics of a software project. 6,7,[22][23][24] To address these issues, we introduced an automated approach based on genetic programming (GP) to learn from the symptoms of real-world instances of community smells. 25 However, the proposed approach is mainly based on commit changes to identify developers working on the same files, and we consider two important factors:…”