@article {Kazuhiro Yamashita2016,
	title = {Magnet or Sticky? Measuring Project Characteristics from the Perspective of Developer Attraction and Retention},
	journal = {Journal of Information Processing},
	volume = {24},
	number = {2},
	year = {2016},
	pages = {339-348},
	abstract = {Open Source Software (OSS) is vital to both end users and enterprises. As OSS systems are becoming a type of infrastructure, long-term OSS projects are desired. For the survival of OSS projects, the projects need to not only retain existing developers, but also attract new developers to grow. To better understand how projects retain and attract contributors, our preliminary study aimed to measure the personnel attraction and retention of OSS projects using a pair of population migration metrics, called Magnet (personnel attraction) and Sticky (retention) metrics. Because the preliminary study analyzed only 90 projects and the 90 projects are not representative of GitHub, this paper extend the preliminary study to better understand the generalizability of the results by analyzing 16, 552 projects of GitHub. Furthermore, we also add a pilot study to investigate the typical duration between releases to find more appropriate release duration. The study results show that (1) approximately 23\% of developers remain in the same projects that the developers contribute to, (2) the larger projects are likely to attract and retain more developers, (3) 53\% of terminal projects eventually decay to a state of fewer than ten developers and (4) 55\% of attractive projects remain in an attractive category.
},
	keywords = {github, retention},
	doi = {10.2197/ipsjjip.24.339},
	url = {https://www.jstage.jst.go.jp/article/ipsjjip/24/2/24_339/_article},
	author = {Yamashita, Kazuhiro and Kamei, Yasutaka and McIntosh, Shane and Hassan, Ahmed E. and Ubayashi, Naoyasu}
}
@proceedings {1769,
	title = {Investigating Code Review Practices in Defective Files: An Empirical Study of the Qt System},
	year = {2015},
	month = {05/2015},
	publisher = {IEEE},
	abstract = {Software code review is a well-established software
quality practice. Recently, Modern Code Review (MCR) has been
widely adopted in both open source and proprietary projects.
To evaluate the impact that characteristics of MCR practices
have on software quality, this paper comparatively studies MCR
practices in defective and clean source code files. We investigate
defective files along two perspectives: 1) files that will eventually
have defects (i.e., future-defective files) and 2) files that have
historically been defective (i.e., risky files). Through an empirical
study of 11,736 reviews of changes to 24,486 files from the Qt
open source project, we find that both future-defective files and
risky files tend to be reviewed less rigorously than their clean
counterparts. We also find that the concerns addressed during
the code reviews of both defective and clean files tend to enhance
evolvability, i.e., ease future maintenance (like documentation),
rather than focus on functional issues (like incorrect program
logic). Our findings suggest that although functionality concerns
are rarely addressed during code review, the rigor of the
reviewing process that is applied to a source code file throughout
a development cycle shares a link with its defect proneness.},
	keywords = {code review, software quality},
	url = {http://sail.cs.queensu.ca/publications/pubs/msr2015-thongtanunam.pdf},
	attachments = {https://flosshub.org/sites/flosshub.org/files/msr2015-thongtanunam.pdf},
	author = {Patanamon Thongtanunam and McIntosh, Shane and Hassan, Ahmed E. and Hajimu Iida}
}
@conference {Yamashita:2014:MSO:2597073.2597116,
	title = {Magnet or Sticky? An OSS Project-by-project Typology},
	booktitle = {Proceedings of the 11th Working Conference on Mining Software Repositories},
	series = {MSR 2014},
	year = {2014},
	pages = {344{\textendash}347},
	publisher = {ACM},
	organization = {ACM},
	address = {New York, NY, USA},
	abstract = {For Open Source Software (OSS) projects, retaining existing contributors and attracting new ones is a major concern. In this paper, we expand and adapt a pair of population migration metrics to analyze migration trends in a collection of open source projects. Namely, we study: (1) project stickiness, i.e., its tendency to retain existing contributors and (2) project magnetism, i.e., its tendency to attract new contributors. Using quadrant plots, we classify projects as attractive (highly magnetic and sticky), stagnant (highly sticky, weakly magnetic), fluctuating (highly magnetic, weakly sticky), or terminal (weakly magnetic and sticky). Through analysis of the MSR challenge dataset, we find that: (1) quadrant plots can effectively identify at-risk projects, (2) stickiness is often motivated by professional activity and (3) transitions among quadrants as a project ages often coincides with interesting events in the evolution history of a project.
},
	keywords = {Developer migration, Magnet, mining challenge, msr challenge, open source, Sticky},
	isbn = {978-1-4503-2863-0},
	doi = {10.1145/2597073.2597116},
	url = {http://doi.acm.org/10.1145/2597073.2597116},
	attachments = {https://flosshub.org/sites/flosshub.org/files/yamashita.pdf},
	author = {Yamashita, Kazuhiro and McIntosh, Shane and Kamei, Yasutaka and Ubayashi, Naoyasu}
}
@article {1399,
	title = {The evolution of Java build systems},
	journal = {Empirical Software Engineering},
	volume = {17},
	year = {2012},
	month = {8/2012},
	pages = {578 - 608},
	abstract = {Build systems are responsible for transforming static source code artifacts into executable software. While build systems play such a crucial role in software development and maintenance, they have been largely ignored by software evolution researchers. However, a firm understanding of build system aging processes is needed in order to allow project managers to allocate personnel and resources to build system maintenance tasks effectively, and reduce the build maintenance overhead on regular development activities. In this paper, we study the evolution of build systems based on two popular Java build languages (i.e., ANT and Maven) from two perspectives: (1) a static perspective, where we examine the complexity of build system specifications using software metrics adopted from the source code domain; and (2) a dynamic perspective, where the complexity and coverage of representative build runs are measured. Case studies of the build systems of six open source build projects with a combined history of 172 releases show that build system and source code size are highly correlated, with source code restructurings often requiring build system restructurings. Furthermore, we find that Java build systems evolve dynamically in terms of duration and recursive depth of the directory hierarchy. },
	keywords = {ant, build, maven, scm, source code analysis},
	issn = {1573-7616},
	doi = {10.1007/s10664-011-9169-5},
	author = {McIntosh, Shane and Adams, Bram and Hassan, Ahmed E.}
}
@conference {951,
	title = {The evolution of ANT build systems},
	booktitle = {2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010)},
	year = {2010},
	pages = {42 - 51},
	publisher = {IEEE},
	organization = {IEEE},
	address = {Cape Town, South Africa},
	abstract = {Build systems are responsible for transforming static source code artifacts into executable software. While build systems play such a crucial role in software development and maintenance, they have been largely ignored by software evolution researchers. With a firm understanding of build system aging processes, project managers could allocate personnel and resources to build system maintenance tasks more effectively, reducing the build maintenance overhead on regular development activities. In this paper, we study the evolution of ANT build systems from two perspectives: (1) a static perspective, where we examine the build system specifications using software metrics adopted from the source code domain; and (2) a dynamic perspective where representative sample build runs are conducted and their output logs are analyzed. Case studies of four open source ANT build systems with a combined history of 152 releases show that not only do ANT build systems evolve, but also that they need to react in an agile manner to changes in the source code.},
	keywords = {ant, argouml, build, eclipse, jboss, maintenance, metrics, source code, tomcat},
	isbn = {978-1-4244-6802-7},
	doi = {10.1109/MSR.2010.5463341},
	attachments = {https://flosshub.org/sites/flosshub.org/files/42msr2010_mcintosh.pdf},
	author = {McIntosh, Shane and Adams, Bram and Hassan, Ahmed E.}
}
