Effort estimation of FLOSS projects: A study of the Linux kernel

This is the post-print version of the Article. The official published version can be accessed from the link below - Copyright @ 2011 SpringerEmpirical research on Free/Libre/Open Source Software (FLOSS) has shown that developers tend to cluster around two main roles: “core” contributors differ from “peripheral” developers in terms of a larger number of responsibilities and a higher productivity pattern. A further, cross-cutting characterization of developers could be achieved by associating developers with “time slots”, and different patterns of activity and effort could be associated to such slots. Such analysis, if replicated, could be used not only to compare different FLOSS communities, and to evaluate their stability and maturity, but also to determine within projects, how the effort is distributed in a given period, and to estimate future needs with respect to key points in the software life-cycle (e.g., major releases). This study analyses the activity patterns within the Linux kernel project, at first focusing on the overall distribution of effort and activity within weeks and days; then, dividing each day into three 8-hour time slots, and focusing on effort and activity around major releases. Such analyses have the objective of evaluating effort, productivity and types of activity globally and around major releases. They enable a comparison of these releases and patterns of effort and activities with traditional software products and processes, and in turn, the identification of company-driven projects (i.e., working mainly during office hours) among FLOSS endeavors. The results of this research show that, overall, the effort within the Linux kernel community is constant (albeit at different levels) throughout the week, signalling the need of updated estimation models, different from those used in traditional 9am–5pm, Monday to Friday commercial companies. It also becomes evident that the activity before a release is vastly different from after a release, and that the changes show an increase in code complexity in specific time slots (notably in the late night hours), which will later require additional maintenance efforts

Structural Complexity and Decay in FLOSS Systems: An Inter-Repository Study

Past software engineering literature has firmly established that software architectures and the associated code decay over time. Architectural decay is, potentially, a major issue in Free/Libre/Open Source Software (FLOSS) projects, since developers sporadically joining FLOSS projects do not always have a clear understanding of the underlying architecture, and may break the overall conceptual structure by several small changes to the code base. This paper investigates whether the structure of a FLOSS system and its decay can also be influenced by the repository in which it is retained: specifically, two FLOSS repositories are studied to understand whether the complexity of the software structure in the sampled projects is comparable, or one repository hosts more complex systems than the other. It is also studied whether the effort to counteract this complexity is dependent on the repository, and the governance it gives to the hosted projects. The results of the paper are two-fold: on one side, it is shown that the repository hosting larger and more active projects presents more complex structures. On the other side, these larger and more complex systems benefit from more anti-regressive work to reduce this complexity

A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Designing for e-Social Action An Application Taxonomy

In this paper, we present a taxonomy for understanding designs and designing of Information & Communication Technologies (ICT) in the field of ‘Social Action’. We use the term ‘Social Action’ to refer to activities of individuals and organisations in civil society, which are oriented towards social (rather than primarily economic) goals. We then apply the term e-Social Action to refer to the application of ICT in these activities. This definition incorporates a wide range of initiatives, varying from: trade-unions logging safety inspections on ships, Age Concern York organising volunteers to place on-line supermarket orders on behalf of housebound elderly people; the International Red Cross using logistics software to deliver emergency aid; and Martus.org providing technology to enable victims of human-rights abuse to report their experience whilst protecting their anonymity and thus avoiding reprisals. To study designing in this broad space, it is necessary to understand key dimensions of the settings where designing takes place. The aim of this paper is to examine how information and communication technologies in social action can be understood, classified and distinguished, to allow for more refined explorations of designing in this space. Keywords: e-SocialAction, Taxonomy, design and society</p

Advancing Economic Research on the Free and Open Source Software Mode of Production

Early contributions to the academic literature on free/libre and open source software (F/LOSS) movements have been directed primarily at identifying the motivations that account for the sustained and often intensive involvement of many people in this non-contractual and unremunerated productive activity. This issue has been particularly prominent in economists’ contributions to the literature, and it reflects a view that widespread voluntary participation in the creation of economically valuable goods that is to be distributed without charge constitutes a significant behavioral anomaly. Undoubtedly, the motivations of F/LOSS developers deserve to be studied more intensively, but not because their behaviors are unique, or historically unprecedented. In this essay we argue that other aspects of the “open source” phenomenon are just as intriguing, if not more so, and possibly are also more consequential topics for economic analysis. We describe the re-focusing and re-direction of empirical and theoretical research in an integrated international project (based at Stanford University/SIEPR) that aims at better understanding a set of less widely discussed topics: the modes of organization, governance and performance of F/LOSS development -- viewed as a collective distributed mode of production.. We discuss of the significance of tackling those questions in order to assess the potentialities of the “open source way of working” as a paradigm for a broader class of knowledge and information- goods production, and conclude with proposals for the trajectory of future research along that line.

Using antipatterns to improve the quality of FLOSS development

Antipatterns have been mostly reported in closed source software environments. With the advent of Free/Libre Open Source Software (FLOSS), researchers have started analysing popular FLOSS projects, seeking vitality indicators and success patterns.  However, an impressively high percentage of FLOSS projects are unsuccessful.  Moreover, even in the successful cases of FLOSS there can be found tracks of failed attempts, dead-ends, forks, abandonments etc.  FLOSS antipatterns can help developers to improve their code and improve the communication and collaboration within the FLOSS community.  In this paper, we present some example of FLOSS antipatterns and discuss the benefits that they bring to various FLOSS user roles.  Furthermore, we present ontology-based technology and software tools that can be used to assist FLOSS developers and community users to identify, document, share antipatterns and use these mechanisms to assist FLOSS projects conform to specified requirements.  Finally, we propose a framework for the quantitative identification of the antipatterns to use as quality indicators in the certification of FLOSS products

Community-Based Production of Open Source Software: What Do We Know About the Developers Who Participate?

This paper seeks to close an empirical gap regarding the motivations, personal attributes and behavioral patterns among free/libre and open source (FLOSS) developers, especially those involved in community-based production, and its findings on the existing literature and the future directions for research. Respondents to an extensive web-survey’s (FLOSS-US 2003) questions about their reasons for work on FLOSS are classified according to their distinct “motivational profiles” by hierarchical cluster analysis. Over half of them also are matched to projects of known membership sizes, revealing that although some members from each of the clusters are present in the small, medium and large ranges of the distribution of project sizes, the mixing fractions for the large and the very small project ranges are statistically different. Among developers who changed projects, there is a discernable flow from the bottom toward the very small towards to large projects, some of which is motivated by individuals seeking to improve their programming skills. It is found that the profile of early motivation, along with other individual attributes, significantly affects individual developers’ selections of projects from different regions of the size range.Open source software, FLOSS project, community-based peer production, population heterogeneity, micro-motives, motivational profiles, web-cast surveys, hierarchical cluster analysis