@proceedings {1927,
	title = {Managing Hidden Dependencies in OO Software: a Study Based on Open Source Projects},
	year = {2016},
	month = {11/2016},
	abstract = {Dependency-based software change impact analysis is the domain concerned with estimating sets of artifacts impacted by a change to a related artifact. Research has shown that analysing the various class dependency types independently will not reveal a complete estimate of impact sets. Therefore, dependency types are combined to improve the precision of estimated when compared to impact sets. Software classes can be linked in different ways; for instance semantically, if their meaning is somewhat related or, structurally, if one class depends on the services of other classes. {\textquoteright}Hidden{\textquoteright} dependencies arise when two classes, linked structurally, do not share the same semantic namespace or when semantically dependent classes do not share a structural link. With the goal of revealing hidden dependencies during change impact analysis, we empirically investigated the interplay between structural and semantic class dependencies in object-oriented software systems. Results show that (i) semantic and structural links are significantly associated, (ii) the strengths of those links does not play a significant role and, (iii) a significant number of dependencies are hidden. We propose refactoring techniques to deal with hidden dependencies, based on existing design patterns. Our approach has the potential for reducing refactoring and testing effort.},
	author = {Nemitari Ajienka and Capiluppi, Andrea and Counsell, Steve}
}
@conference {Robles:2014:EDE:2597073.2597107,
	title = {Estimating Development Effort in Free/Open Source Software Projects by Mining Software Repositories: A Case Study of OpenStack},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {222{\textendash}231},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {Because of the distributed and collaborative nature of free / open source software (FOSS) projects, the development effort invested in a project is usually unknown, even after the software has been released. However, this information is becoming of major interest, especially ---but not only--- because of the growth in the number of companies for which FOSS has become relevant for their business strategy. In this paper we present a novel approach to estimate effort by considering data from source code management repositories. We apply our model to the OpenStack project, a FOSS project with more than 1,000 authors, in which several tens of companies cooperate. Based on data from its repositories and together with the input from a survey answered by more than 100 developers, we show that the model offers a simple, but sound way of obtaining software development estimations with bounded margins of error.
},
	keywords = {effort estimation, free software, mining software repositories, open source, openstack},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597107},
	url = {http://doi.acm.org/10.1145/2597073.2597107},
	attachments = {https://flosshub.org/sites/flosshub.org/files/robles_0.pdf},
	author = {Gregorio Robles and Gonz{\'a}lez-Barahona, Jes{\'u}s M. and Cervig{\'o}n, Carlos and Capiluppi, Andrea and Izquierdo-Cort{\'a}zar, Daniel}
}
@proceedings {roblesestimating,
	title = {Estimating Development Effort in Free/Open Source Software Projects by Mining Software Repositories: A Case Study of OpenStack},
	year = {2014},
	month = {05/2014},
	abstract = {Because of the distributed and collaborative nature of free/open source software (FOSS) projects, the development effort invested in a project is usually unknown, even after the software has been released. However, this information is becoming of major interest, especially - but not only- because of the growth in the number of companies for which FOSS has become relevant for their business strategy. In this paper we present a novel approach to estimate effort by considering data from source code management repositories. We apply our model to the OpenStack project, a FOSS
project with more than 1,000 authors, in which several tens of companies cooperate. Based on data from its repositories and together with the input from a survey answered by more than 100 developers, we show that the model offers a simple, but sound way of obtaining software development estimations
with bounded margins of error.},
	keywords = {effort estimation, openstack},
	url = {http://gsyc.urjc.es/~grex/repro/2014-msr-effort/msr14-robles-estimating-effort.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr14-robles-estimating-effort.pdf},
	author = {Gregorio Robles and Gonz{\'a}lez-Barahona, Jesus M and Cervig{\'o}n, Carlos and Capiluppi, Andrea}
}
@conference {Romo:2014:FGD:2641580.2641592,
	title = {Filling the Gaps of Development Logs and Bug Issue Data},
	booktitle = {Proceedings of The International Symposium on Open Collaboration},
	series = {OpenSym {\textquoteright}14},
	year = {2014},
	pages = {8:1{\textendash}8:4},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {It has been suggested that the data from bug repositories is not always in sync or complete compared to the logs detailing the actions of developers on source code.

In this paper, we trace two sources of information relative to software bugs: the change logs of the actions of developers and the issues reported as bugs. The aim is to identify and quantify the discrepancies between the two sources in recording and storing the developer logs relative to bugs.

Focussing on the databases produced by two mining software repository tools, CVSAnalY and Bicho, we use part of the SZZ algorithm to identify bugs and to compare how the "defects-fixing changes" are recorded in the two databases. We use a working example to show how to do so.

The results indicate that there is a significant amount of information, not in sync when tracing bugs in the two databases. We, therefore, propose an automatic approach to re-align the two databases, so that the collected information is mirrored and in sync.},
	keywords = {Bug traceability, bug-fixing commits},
	isbn = {978-1-4503-3016-9},
	doi = {10.1145/2641580.2641592},
	url = {http://doi.acm.org/10.1145/2641580.2641592},
	author = {Romo, Bilyaminu Auwal and Capiluppi, Andrea and Hall, Tracy}
}
@book {1531,
	title = {Is It All Lost? A Study of Inactive Open Source Projects},
	series = {IFIP Advances in Information and Communication Technology Open Source Software: Quality Verification },
	volume = {404},
	year = {2013},
	pages = {61 - 79},
	publisher = {Springer Berlin Heidelberg},
	organization = {Springer Berlin Heidelberg},
	address = {Berlin, Heidelberg},
	abstract = {
Open Source Software (OSS) proponents suggest that when developers lose interest in their project, their last duty is to {\textquotedblleft}hand it off to a competent successor.{\textquotedblright} However, the mechanisms of such a hand-off are not clear, or widely known among OSS developers. As a result, many OSS projects, after a certain long period of evolution, stop evolving, in fact becoming {\textquotedblleft}inactive{\textquotedblright} or {\textquotedblleft}abandoned{\textquotedblright} projects. This paper presents an analysis of the population of projects contained within one of the largest OSS repositories available (SourceForge.net), in order to describe how projects abandoned by their developers can be identified, and to discuss the attributes and characteristics of these inactive projects. In particular, the paper attempts to differentiate projects that experienced maintainability issues from those that are inactive for other reasons, in order to be able to correlate common characteristics to the {\textquotedblleft}failure{\textquotedblright} of these projects.
},
	keywords = {sourceforge},
	isbn = {978-3-642-38928-3},
	issn = {1868-422X},
	doi = {10.1007/978-3-642-38928-3_5},
	url = {http://staff.lero.ie/stol/files/2013/03/2013-Is-It-All-Lost-A-Study-of-Inactive-Open-Source-Projects.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/2013-Is-It-All-Lost-A-Study-of-Inactive-Open-Source-Projects.pdf},
	author = {Khondu, Jymit and Capiluppi, Andrea and Stol, Klaas},
	editor = {Petrinja, Etiel and Succi, Giancarlo and Ioini, Nabil and Sillitti, Alberto}
}
@proceedings {1450,
	title = {Exploring the Role of Commercial Stakeholders in Open Source Software Evolution},
	volume = {378},
	year = {2012},
	month = {09/2012},
	pages = {178-200},
	publisher = {IFIP AICT},
	abstract = {It has been lately established that a major success or failure factor of an OSS project is whether or not it involves a commercial company, or more extremely, when a project is managed by a commercial software corporation. As documented recently, the success of the Eclipse project can be largely attributed to IBM{\textquoteright}s project management, since the upper part of the developer hierarchy is dominated by its staff. This paper reports on the study of the evolution of three different Open Source (OSS) projects {\textemdash} the Eclipse and jEdit IDEs and the Moodle e-learning system {\textemdash} looking at whether they have benefited from the contribution of commercial companies. With the involvement of commercial companies, it is found that OSS projects achieve sustained productivity, increasing amounts of output produced and intake of new developers. It is also found that individual and commercial contributions show similar stages: developer intake, learning effect, sustained contributions and, finally, abandonment of the project. This preliminary evidence suggests that a major success factor for OSS is the involvement of a commercial company, or more radically, when project management is in hands of a commercial entity.},
	author = {Capiluppi, Andrea and Stol, Klaas-Jan and Boldyreff, Cornelia}
}
@article {1484,
	title = {Similarities, challenges and opportunities of Wikipedia content and open source projects},
	journal = {Journal of Software: Evolution and Process},
	year = {2012},
	note = {The Sourceforge repository was chosen as the largest and most representative OSS repository. In order to extract a sample from it, the flossmole.org database [20] was downloaded, containing the basic information of all the Sourceforge projects. The latest available dump of such data, at the time of the extraction (April 2009) contained 126,142 projects. From this database, three filters were applied: one based on the given status of the projects; one classifying the activity of the project, and imposed by the SourceForge site ({\textquotedblleft}active{\textquotedblright} and {\textquotedblleft}inactive{\textquotedblright}); and one relative to the specific topic (or application domain) that each project is developed for.},
	month = {08/2012},
	pages = {n/a - n/a},
	abstract = {Several years of research and evidence have demonstrated that open source software portals often contain a large amount of software projects that simply do not evolve, developed by relatively small communities, struggling to attract a sustained number of contributors. These portals have started to increasingly act as a storage for abandoned projects, and researchers and practitioners should try and point out how to take advantage of such content. Similarly, other online content portals (like Wikipedia) could be harvested for valuable content. In this paper we argue that, even with differences in the requested expertise, many projects reliant on content and contributions by users undergo a similar evolution, and follow similar patterns: when a project fails to attract contributors, it appears to be not evolving, or abandoned. Far from a negative finding, even those projects could provide valuable content that should be harvested and identified based on common characteristics: by using the attributes of {\textquoteleft}usefulness{\textquoteright} and {\textquoteleft}modularity{\textquoteright} we isolate valuable content in both Wikipedia pages and open source software projects. },
	keywords = {flossmole},
	doi = {10.1002/smr.1570},
	url = {https://www.researchgate.net/publication/259684110_Similarities_challenges_and_opportunities_of_Wikipedia_content_and_open_source_projects},
	attachments = {https://flosshub.org/sites/flosshub.org/files/jsep2012.pdf},
	author = {Capiluppi, Andrea}
}
@article {1324,
	title = {Are Developers Fixing Their Own Bugs?},
	journal = {International Journal of Open Source Software and Processes},
	volume = {3},
	year = {2011},
	note = {"The analysis is focused at the level of lines of code and it uses the information stored in the source code management system"},
	pages = {23 - 42},
	abstract = {The process of fixing software bugs plays a key role in the maintenance activities of a software project. Ideally, code ownership and responsibility should be enforced among developers working on the same artifacts, so that those introducing buggy code could also contribute to its fix. However, especially in FLOSS projects, this mechanism is not clearly understood: in particular, it is not known whether those contributors fixing a bug are the same introducing and seeding it in the first place. This paper analyzes the comm-central FLOSS project, which hosts part of the Thunderbird, SeaMonkey, Lightning extensions and Sunbird projects from the Mozilla community. The analysis is focused at the level of lines of code and it uses the information stored in the source code management system. The results of this study show that in 80\% of the cases, the bug-fixing activity involves source code modified by at most two developers. It also emerges that the developers fixing the bug are only responsible for 3.5\% of the previous modifications to the lines affected; this implies that the other developers making changes to those lines could have made that fix. In most of the cases the bug fixing process in comm-central is not carried out by the same developers than those who seeded the buggy code.},
	keywords = {bug fixing, developers, loc, scm},
	issn = {1942-3934},
	doi = {10.4018/jossp.2011040102},
	author = {Izquierdo-Cortazar, Daniel and Capiluppi, Andrea and Jesus M. Gonzalez-Barahona}
}
@article {1418,
	title = {Effort estimation of FLOSS projects: a study of the Linux kernel},
	journal = {Empirical Software Engineering},
	year = {2011},
	pages = {1-29},
	abstract = {Empirical research on Free/Libre/Open Source Software (FLOSS) has shown that developers tend to cluster around two main roles: {\textquotedblleft}core{\textquotedblright} contributors differ from {\textquotedblleft}peripheral{\textquotedblright} 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 {\textquotedblleft}time slots{\textquotedblright}, 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{\textendash}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.},
	keywords = {complexity, effort estimation, Effort models, mining software repositories, open source software},
	issn = {1573-7616},
	doi = {10.1007/s10664-011-9191-7},
	url = {http://www.springerlink.com/content/612r616k8t52m867/fulltext.html},
	author = {Capiluppi, Andrea and Izquierdo-Cort{\'a}zar, Daniel}
}
@proceedings {1280,
	title = {Successful Reuse of Software Components: A Report from the Open Source Perspective},
	year = {2011},
	month = {10/2011},
	pages = {159-176},
	publisher = {Springer},
	abstract = {A promising way of software reuse is Component-Based Software Development (CBSD). There is an increasing number of OSS products available that can be freely used in product development. However, OSS communities themselves have not yet taken full advantage of the {\textquotedblleft}reuse mechanism{\textquotedblright}. Many OSS projects duplicate effort and code, even when sharing the same application domain and topic. One successful counter-example is the FFMpeg multimedia project, since several of its components are widely and consistently reused into other OSS projects. This paper documents the history of the libavcodec library of components from the FFMpeg project, which at present is reused in more than 140 OSS projects. Most of the recipients use it as a black-box component, although a number of OSS projects keep a copy of it in their repositories, and modify it as such. In both cases, we argue that libavcodec is a successful example of reusable OSS library of components.},
	keywords = {component-based software development, OSS components, Software reuse},
	author = {Capiluppi, Andrea and Boldyreff, Cornelia and Stol, Klaas-Jan}
}
@conference {1220,
	title = {Second International Workshop on Building Sustainable Open Source Communities (OSCOMM 2010)},
	booktitle = {Second International Workshop on Building Sustainable Open Source Communities (OSCOMM 2010)},
	year = {2010},
	abstract = {The Second International Workshop on Building Sustainable Open Source Communities (OSCOMM 2010) aims at building a commu- nity of researchers and practitioners to share experiences and discuss chal- lenges involved in building and maintaining open source communities. De- tailed	information	regarding	the	workshop	is	available	at http://tutopen.cs.tut.fi/oscomm10/.},
	keywords = {oscomm, oscomm2010, oss2010, workshop},
	attachments = {https://flosshub.org/sites/flosshub.org/files/osscomm000.pdf},
	author = {Hammouda, Imed and Aaltonen, Timo and Capiluppi, Andrea}
}
@article {1237,
	title = {Bridging the Gap between Agile and Free Software Approaches},
	journal = {International Journal of Open Source Software and Processes},
	volume = {1},
	year = {2009},
	month = {31/2009},
	pages = {58 - 71},
	abstract = {Agile sprints are short events where a small team collocates in order to work on particular aspects of the overall project for a short period of time. Sprinting is a process that has been observed also in Free Software projects: these two paradigms, sharing common principles and values have shown several commonalities of practice. This article evaluates the impact of sprinting on a Free Software project through the analysis of code repository logs: sprints from two Free Software projects (Plone and KDE PIM) are assessed and two hypotheses are formulated: do sprints increase productivity? Are Free Software projects more productive after sprints compared with before? The primary contribution of this article is to show how sprinting creates a large increase in productivity both during the event, and immediately after the event itself: this argues for more in-depth studies focussing on the nature of sprinting.},
	keywords = {agile, kde, lines of code, loc, plone, productivity, scm, scrum, sprints, subversion},
	issn = {1942-3934},
	doi = {10.4018/jossp.2009010104},
	author = {Paul J. Adams and Capiluppi, Andrea}
}
@conference {571,
	title = {Domain Drivers in the Modularization of FLOSS Systems},
	booktitle = {OSS2009: Open Source Ecosystems: Diverse Communities Interacting (IFIP 2.13)},
	series = {IFIP Advances in Information and Communication Technology },
	volume = {299/2009},
	year = {2009},
	month = {2009///},
	pages = {3 - 19},
	publisher = {Springer},
	organization = {Springer},
	chapter = {3},
	abstract = {The classification of software systems into types has been achieved in the past by observing both their specifications and behavioral patterns: the SPE classification, for instance, and its further supplements and refinements, has identified the S-type (i.e., fully specified), the P-type (i.e., specified but dependent on the context) and the E-type (i.e., addressing evolving problems) among the software systems. In order to detect types, and establish similarities, among Free/Libre/Open Source Software (FLOSS) systems, this paper considers three modular characteristics (functions, files and folders) and their evolution: how they are evolving with size, if they are constant across systems, and whether recurring evolutionary patterns are observed. Using these various-grained characteristics,a set of models for the evolution of modularization are extracted from evolving systems, and then used to extract similarities and types from a wide sample of FLOSS projects. This paper provides three contributions: first, it shows that several models are needed to encompass the variety of modularization patterns; second, it provides three types of models (uni-variate, bi-variate and tri-variate) for the evolution of modularization, with significant goodness-of-fit{\textquoteright}s. Finally, it shows that two of these patterns alone can interpolate the modular characteristics of the vast majority of a random choice of FLOSS projects.
},
	issn = {978-3-642-02031-5},
	doi = {http://dx.doi.org/10.1007/978-3-642-02032-2_3},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Domain\%20Drivers\%20in\%20the\%20Modularization.pdf},
	author = {Capiluppi, Andrea}
}
@conference {600,
	title = {First International Workshop on Building Sustainable Open Source Communities (OSCOMM 2009)},
	booktitle = {OSS2009: Open Source Ecosystems: Diverse Communities Interacting (IFIP 2.13)},
	series = {IFIP Advances in Information and Communication Technology },
	volume = {299/2009},
	year = {2009},
	month = {2009///},
	pages = {353 - 354},
	publisher = {Springer},
	organization = {Springer},
	chapter = {32},
	abstract = {The First International Workshop on Building Sustainable Open Source Communities aims at building a community of researchers and practitioners to share experiences and discuss challenges involved in building and maintaining open source communities.
},
	issn = {978-3-642-02031-5},
	doi = {http://dx.doi.org/10.1007/978-3-642-02032-2_32},
	attachments = {https://flosshub.org/sites/flosshub.org/files/First\%20International\%20Workshop.pdf},
	author = {Hammouda, Imed and Aaltonen, Timo and Capiluppi, Andrea}
}
@article {Beecher2009739,
	title = {Identifying exogenous drivers and evolutionary stages in FLOSS projects},
	journal = {Journal of Systems and Software},
	volume = {82},
	number = {5},
	year = {2009},
	pages = {739 - 750},
	abstract = {The success of a Free/Libre/Open Source Software (FLOSS) project has been evaluated in the past through the number of commits made to its configuration management system, number of developers and number of users. Most studies, based on a popular FLOSS repository (SourceForge), have concluded that the vast majority of projects are failures. This study{\textquoteright}s empirical results confirm and expand conclusions from an earlier and more limited work. Not only do projects from different repositories display different process and product characteristics, but a more general pattern can be observed. Projects may be considered as early inceptors in highly visible repositories, or as established projects within desktop-wide projects, or finally as structured parts of FLOSS distributions. These three possibilities are formalized into a framework of transitions between repositories. The framework developed here provides a wider context in which results from FLOSS repository mining can be more effectively presented. Researchers can draw different conclusions based on the overall characteristics studied about an Open Source software project{\textquoteright}s potential for success, depending on the repository that they mine. These results also provide guidance to OSS developers when choosing where to host their project and how to distribute it to maximize its evolutionary success.},
	keywords = {developers, forge, forges, repositories, repository, scm, software repositories, sourceforge, success, users},
	issn = {0164-1212},
	doi = {DOI: 10.1016/j.jss.2008.10.026},
	url = {http://www.sciencedirect.com/science/article/B6V0N-4TVTJFS-1/2/e32ecee1bcb54bd4a5dff6d5e3daca8d},
	author = {Karl Beecher and Capiluppi, Andrea and Boldyreff, Cornelia}
}
@article {Capiluppi200989,
	title = {Quality Factors and Coding Standards - a Comparison Between Open Source Forges},
	journal = {Electronic Notes in Theoretical Computer Science},
	volume = {233},
	year = {2009},
	note = {Proceedings of the International Workshop on Software Quality and Maintainability (SQM 2008)},
	pages = {89 - 103},
	abstract = {Enforcing adherence to standards in software development in order to produce high quality software artefacts has long been recognised as best practice in traditional software engineering. In a distributed heterogeneous development environment such those found within the Open Source paradigm, coding standards are informally shared and adhered to by communities of loosely coupled developers. Following these standards could potentially lead to higher quality software. This paper reports on the empirical analysis of two major forges where OSS projects are hosted. The first one, the KDE forge, provides a set of guidelines and coding standards in the form of a coding style that developers may conform to when producing the code source artefacts. The second studied forge, SourceForge, imposes no formal coding standards on developers. A sample of projects from these two forges has been analysed to detect whether the SourceForge sample, where no coding standards are reinforced, has a lower quality than the sample from KDE. Results from this analysis form a complex picture; visually, all the selected metrics show a clear divide between the two forges, but from the statistical standpoint, clear distinctions cannot be drawn amongst these quality related measures in the two forge samples.},
	keywords = {artefacts, artifacts, coding standards, coding style, complexity, forge, forges, kde, metrics, quality, source code, sourceforge},
	issn = {1571-0661},
	doi = {DOI: 10.1016/j.entcs.2009.02.063},
	url = {http://www.sciencedirect.com/science/article/B75H1-4VXDKRV-7/2/abcc2be2c4c3998e4bc9b53473ca2d81},
	author = {Capiluppi, Andrea and Boldyreff, Cornelia and Karl Beecher and Paul J. Adams}
}
@conference {592,
	title = {Reassessing Brooks{\textquoteright} Law for the Free Software Community},
	booktitle = {OSS2009: Open Source Ecosystems: Diverse Communities Interacting (IFIP 2.13)},
	series = {IFIP Advances in Information and Communication Technology },
	volume = {299/2009},
	year = {2009},
	month = {2009///},
	pages = {274 - 283},
	publisher = {Springer},
	organization = {Springer},
	chapter = {24},
	abstract = {Proponents of Free Software have argued that some of the most established software engineering principles do not fully apply when considered in an open, distributed approach. Among these principles, {\textquotedblleft}Brooks{\textquoteright} Law{\textquotedblright} has been questioned in the Free Software context: large teams of developers, contrary to the law, will not need an increasingly growing number of communication channels. As advocates claim, this is due to the internal haracteristics of the Free Software process: the high modularity of the code helps developers to work on comparted sections, without the need to coordinate with all other contriutors.
This paper examines Brooks{\textquoteright} Law in a Free Software context, and it studies the interaction of contributors to a large Free Software project, KDE. The network of interactions is analyzed and a summary term, the {\textquotedblleft}compaction{\textquotedblright}, is dynamically evaluated to test how the coordination mechanism evolves over time in the project. This paper argues that the claim of advocates holds true, but with limitations: in the KDE project, the few initial developers needed a significant amount of communication. The growth of KDE brought the need to break the number of overall communication channels to a significant extent. Finally, an established amount of 300 developers currently needs the same amount of communication as when the developers were only 10. We interpret this result by arguing that Brooks{\textquoteright} Law holds true among the core developers of any large Free Software project.
},
	issn = {978-3-642-02031-5},
	doi = {http://dx.doi.org/10.1007/978-3-642-02032-2_24},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Reassessing\%20Brook\%27s\%20Law.pdf},
	author = {Capiluppi, Andrea and Adams, Paul}
}
@conference {573,
	title = {Software Engineering in Practice: Design and Architectures of FLOSS Systems},
	booktitle = {OSS2009: Open Source Ecosystems: Diverse Communities Interacting (IFIP 2.13)},
	series = {IFIP Advances in Information and Communication Technology },
	volume = {299/2009},
	year = {2009},
	month = {2009///},
	pages = {34 - 46},
	publisher = {Springer},
	organization = {Springer},
	chapter = {5},
	abstract = {Free/Libre/Open Source Software (FLOSS) practitioners and developers are typically also users of their own systems: as a result, traditional software engineering (SE) processes (e.g., the requirements and design phases), take less time to articulate and negotiate among FLOSS developers. Design and requirements are kept more as informal knowledge, rather than formally described and assessed. This paper attempts to recover the SE concepts of software design and architectures from three FLOSS case studies, sharing the same application domain (i.e., Instant Messaging). Its first objective is to determine whether a common architecture emerges from the three systems, which can be used as shared knowledge for future applications. The second objective is to determine whether these architectures evolve or decay during the evolution of these systems. The results of this study are encouraging: albeit no explicit effort was done by FLOSS developers to define a high-level view of the architecture, a common shared architecture could be distilled for the Instant Messaging application domain. It was also found that, for two of the three systems, the architecture becomes better organised, and the components better specified, as long as the system evolves in time.
},
	issn = {978-3-642-02031-5},
	doi = {http://dx.doi.org/10.1007/978-3-642-02032-2_5},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Software\%20Engineering\%20in\%20Practice.pdf},
	author = {Capiluppi, Andrea and Knowles, Thomas}
}
@conference {598,
	title = {Undergraduate Research Opportunities in OSS},
	booktitle = {OSS2009: Open Source Ecosystems: Diverse Communities Interacting (IFIP 2.13)},
	series = {IFIP Advances in Information and Communication Technology },
	volume = {299/2009},
	year = {2009},
	month = {2009///},
	pages = {340 - 350},
	publisher = {Springer},
	organization = {Springer},
	chapter = {30},
	abstract = {Using Open Source Software (OSS) in undergraduate teaching in universities is now commonplace. Students use OSS applications and systems in their courses on programming, operating systems, DBMS, web development to name but a few. Studying OSS projects from both a product and a process view also forms part of the software engineering curriculum at various universities. Many students have taken part in OSS projects as well as developers. At the University of Lincoln, under the Undergraduate Research Opportunities Scheme (UROS), undergraduate student researchers have the chance to work over the summer embedded within an existing research centre on a UROS project. Here two such projects within the Centre for Research in Open Source Software (CROSS) are described: Collaborative Development for the XO Laptop (CODEX) and Software Modularity in Open Source Software (SoMOSS). The CODEX project focused on creating resources to support students undertaking software application development for the XO laptop, and the SoMOSS project focused on architectural studies of OSS instant messaging software. Both projects achieved successful research outcomes; more importantly, both student researchers benefited directly from the encouragement and concrete assistance that they received through interaction with the wider OSS research community. Both projects are ongoing and present further research opportunities for students.
},
	issn = {978-3-642-02031-5},
	doi = {http://dx.doi.org/10.1007/978-3-642-02032-2_30},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Undergraduate\%20Research\%20Opportunities.pdf},
	author = {Boldyreff, Cornelia and Capiluppi, Andrea and Knowles, Thomas and Munro, James}
}
@conference {557,
	title = {Detecting Agility of Open Source Projects Through Developer Engagement},
	booktitle = {OSS2008: Open Source Development, Communities and Quality (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing},
	volume = {275/2008},
	year = {2008},
	month = {2008///},
	pages = {333 - 341},
	publisher = {Springer},
	organization = {Springer},
	chapter = {30},
	abstract = {The principles behind the agile development methods and common practise within the Open Source community are vastly different. In recent years there has been a rise of interest in these, in order to detect and inform on areas of compatible shared practises. This paper argues that it is possible to quantify the level of agility displayed by Open Source projects. An indicator of agility, the Mean Developer Engagement (MDE) metric is introduced and tested through the analysis of public project data. Projects sampled from two repositories (KDE and SourceForge) are studied and a hypothesis is formulated: projects from the two samples display a similar level of MDE. This paper provides two main contributions: first, the MDE metric is shown to vary significantly between the KDE and SourceForge projects. Second, by combining MDE with a project{\textquoteright}s lifespan, it is also shown that SourceForge projects have insufficient uptake of new developers resulting in more active, shorter, initial activity, and in a quicker {\textquotedblleft}burning out{\textquotedblright} of the projects.
},
	issn = {978-0-387-09683-4},
	doi = {http://dx.doi.org/10.1007/978-0-387-09684-1_30},
	attachments = {https://flosshub.org/sites/flosshub.org/files/Detecting\%20Agility\%20of\%20Open\%20Source\%20Projects.pdf},
	author = {Adams, Paul and Capiluppi, Andrea and de Groot, Adriaan}
}
@conference {671,
	title = {From the Cathedral to the Bazaar: An Empirical Study of the Lifecycle of Volunteer Community Projects},
	booktitle = {OSS2007: Open Source Development, Adoption and Innovation (IFIP 2.13)},
	series = {IFIP International Federation for Information Processing },
	volume = {234/2007},
	year = {2007},
	month = {2007///},
	pages = {31 - 44},
	publisher = {Springer},
	organization = {Springer},
	chapter = {3},
	abstract = {Some free software and open source projects have been extremely successful in the past. The success of a project is often related to the number of developers it can attract: a larger community of developers (the {\textquoteleft}bazaar{\textquoteright}) identifies and corrects more software defects and adds more features via a peer-review process. In this paper two free software projects (Wine and Arla) are empirically explored in order to characterize their software lifecycle, development processes and communities. Both the projects show a phase where the number of active developers and the actual work performed on the system is constant, or does not grow: we argued that this phase corresponds to the one termed {\textquoteleft}cathedral{\textquoteright} in the literature. One of the two projects (Wine) shows also a second phase: a sudden growing amount of developers corresponds to a similar growing output produced: we termed this as the {\textquoteleft}bazaar{\textquoteright} phase, and we also argued that this phase was not achieved for the other system. A further analysis revealed that the transition between {\textquoteleft}cathedral{\textquoteright} and {\textquoteleft}bazaar{\textquoteright} was a phase by itself in Wine, achieved by creating a growing amount of new modules, which attracted new developers.
},
	issn = {978-0-387-72485-0},
	doi = {http://dx.doi.org/10.1007/978-0-387-72486-7_3},
	attachments = {https://flosshub.org/sites/flosshub.org/files/From\%20the\%20Cathedral.pdf},
	author = {Capiluppi, Andrea and Martin Michlmayr}
}
@conference {DBLP:conf/csmr/CapiluppiLM03,
	title = {Characteristics of Open Source Projects},
	booktitle = {7th European Conference on Software Maintenance and Reengineering (CSMR{\textquoteright}03)},
	year = {2003},
	note = {"We analyze a sample of around 400 projects from a popular OS project repository. "
no pdf to confirm what projects these are or what the repository is.[ms]},
	pages = {317-},
	abstract = {Most empirical studies about Open Source (OS)projects or products are vertical and usually deal with the flagship, successful projects. There is a substantial lack of horizontal studies to shed light on the whole population of projects, including failures. This paper presents a horizontal study aimed at characterizing OS projects. We analyze a sample of around 400 projects from a popular OS project repository. Each project is characterized by a number of attributes. We analyze these attributes statically and over time. The main results show that few projects are capable of attracting a meaningful community of developers. The majority of projects is made by few (in many cases one) person with a very slow pace of evolution.},
	keywords = {evolution, project success, repository},
	author = {Capiluppi, Andrea and Patricia Lago and Maurizio Morisio}
}
@article {1099,
	title = {Evidences in the evolution of OS projects through Changelog Analyses},
	journal = {Proceedings of the 3rd ICSE Workshop on Open Source},
	year = {2003},
	note = {"In this study we concentrate on a very large sample (406 projects) selected randomly from an OS portal[20]" (freshmeat)

"We define three clusters of projects: {\textquoteright}large{\textquoteright} projects as long as they are based on more than 1000KB(40KLOC)..."},
	pages = {19-24},
	abstract = {Most empirical studies about Open Source (OS) projects or products are vertical and usually deal with the flagship, successful projects. There is a substantial lack of horizontal studies to shed light on the whole population of projects, including failures. This paper presents a horizontal study aimed at characterizing OS projects. We analyze a sample of around 400 projects from a popular OS project repository. Each project is characterized by a number of attributes. We analyze these attributes statically and over time. The main results show that few projects are capable of attracting a meaningful community of developers. The majority of projects is made by few (in many cases one) person with a very slow pace of evolution. We then try to observe how many projects count on a substantial number of developers, and analyze those projects more deeply. The goal is to achieve a better insight in the dynamics of open source development. The initial results of this analysis, especially growth in code size and tendency to stability in modularity, seem to be in line with traditional close source development.},
	keywords = {classification, freshmeat, loc, modularity, repository, size, sloc, source code},
	url = {http://hdl.handle.net/10552/1037},
	attachments = {https://flosshub.org/sites/flosshub.org/files/capiluppi2003.pdf},
	author = {Capiluppi, Andrea}
}
@conference {1153,
	title = {Characterizing the OSS process},
	booktitle = {Proceedings of the 2nd ICSE Workshop on Open Source},
	year = {2002},
	note = {"We have considered two well-known Open Source portals (FreshMeat [1] and SourceForge [2] )."
"Using pseudo-random sampling we have selected a sample of 400 projects (mostly from FreshMeat). Each project is described by several variables (programming language, type of license, size of source code, type of documentation available and others). By indirect means (analysis of the Changelog file, or CVS) it is also possible to compute the number of people working on the project, and the number of external contributors. From FreshMeat we get both a vitality index, that considers the number of releases per time period, and a popularity index, which is a first measure of the interest of users to the project (project URL hits, mixed with subscriptions to it)."},
	abstract = {The Open Source model of software development has gained the attention of both the business, the practitioners{\textquoteright} and the research communities. The Open Source process has been described by the seminal paper by Eric Raymond [4] and [5]. However, sound empirical studies are still very limited [3], [6].
Our goal is to investigate the OS process by empirical means, to analyze, characterize it, and possibly model it with quantitative models. It should be noted that the Open Source process provides open process and product data, and therefore is a rare opportunity for empirical research.
Our initial research focus is on the characterization of the process, starting from the evolution of OS projects. In traditional projects, a significant number of releases in a short time is usually considered an instability factor [7] and [8], while in the OSS community, it is an evidence of vitality, shows the commitment of the authors and the power of attraction of other programmers [9]. Is it possible to characterize the vitality of projects? And, can vitality be traced to some other characteristics of a project?},
	keywords = {bugs, change log, classification, cvs, downloads, freshmeat, metadata, patches, popularity, project success, release history, sourceforge, vitality},
	attachments = {https://flosshub.org/sites/flosshub.org/files/CapiluppiLagoMorisio.pdf},
	author = {Capiluppi, Andrea and Patricia Lago and Maurizio Morisio}
}
