@inbook {1617,
	title = {Flow Research SXP Agile Methodology for FOSS Projects},
	booktitle = {Open Source Software: Mobile Open Source Technologies},
	series = {IFIP Advances in Information and Communication Technology},
	volume = {427},
	year = {2014},
	pages = {195-198},
	publisher = {Springer Berlin Heidelberg},
	organization = {Springer Berlin Heidelberg},
	abstract = {

This paper aims to explain a procedure that takes into account the different research processes carried out in developing an open-source, allowing control and management. This study is the SXP methodology applied in this type of project was carried out, allowing the validity of the basis of this research.
},
	keywords = {methodology SXP, open-source, production, research, Software},
	isbn = {978-3-642-55127-7},
	doi = {10.1007/978-3-642-55128-4_28},
	url = {http://dx.doi.org/10.1007/978-3-642-55128-4_28},
	author = {Pe{\~n}alver Romero, GladysMarsi and Leyva Samada, LisandraIsabel and Abad, AbelMeneses},
	editor = {Corral, Luis and Sillitti, Alberto and Succi, Giancarlo and Vlasenko, Jelena and Wasserman, AnthonyI.}
}
@proceedings {1522,
	title = {Boa: A Language and Infrastructure for Analyzing Ultra-Large-Scale Software Repositories},
	year = {2013},
	month = {05/2013},
	pages = {422-431},
	abstract = {In today{\textquoteright}s software-centric world, ultra-large-scale software repositories, e.g. SourceForge (350,000+ projects), GitHub (250,000+ projects), and Google Code (250,000+ projects) are the new library of Alexandria. They contain an enormous corpus of software and information about software. Scientists and engineers alike are interested in analyzing this wealth of information both for curiosity as well as for testing important hypotheses. However, systematic extraction of relevant data from these repositories and analysis of such data for testing hypotheses is hard, and best left for mining software repository (MSR) experts! The goal of Boa, a domain-specific language and infrastructure described here, is to ease testing MSR-related hypotheses. We have implemented Boa and provide a web-based interface to Boa{\textquoteright}s infrastructure. Our evaluation demonstrates that Boa substantially reduces programming efforts, thus lowering the barrier to entry. We also see drastic improvements in scalability. Last but not least, reproducing an experiment conducted using Boa is just a matter of re-running small Boa programs provided by previous researchers.},
	keywords = {ease of use, forge, github, google code, lower barrier to entry, mining, repository, reproducible, scalable, Software, sourceforge},
	author = {Dyer, Robert and Nguyen, Hoan Anh and Rajan, Hridesh and Nguyen, Tien N.}
}
@proceedings {1271,
	title = {Towards a Unified Definition of Open Source Quality},
	year = {2011},
	note = {"In order to answer the research question, how is quality defined in the FLOSS literature, we performed a literature review."

"we searched Google Scholar for journal articles and conference papers containing the terms {\textquotedblleft}open source{\textquotedblright} and {\textquotedblleft}quality{\textquotedblright}"

"This process left us with 24 papers, to which we then added 16 from the quality and defect-fixing categories in [34] that met the above stated criteria.
This left us with 40 papers that defined quality and performed some form of empirical validation of that definition."

"there is little consensus in the FLOSS literature when it comes to defining quality."

defect resolution versus modularity: "Defect resolution rates (amount of defects resolved, speed of resolution) are the best way to measure a community{\textquoteright}s commitment to quality, because they recognize that FLOSS is not a static product, but ever evolving. These rates should be calculated per release, and not cumulatively, because the cycle of FLOSS evolution is the release. Researchers should be careful to only include defects and not new feature requests, duplicates, or poorly reported bugs into their calculations.
Modularity is being touted as the main driver of FLOSS quality success, but it needs to be further defined and studied in order to understand how it works."},
	month = {10/2011},
	pages = {17-33},
	publisher = {Springer},
	abstract = {Software quality needs to be specified and evaluated in order to determine the success of a development project, but this is a challenge with Free/Libre Open Source Software (FLOSS) because of its permanently emergent state. This has not deterred the growth of the assumption that FLOSS is higher quality than traditionally developed software, despite of mixed research results. With this literature review, we found the reason for these mixed results is that that quality is being defined, measured, and evaluated differently. We report the most popular definitions, such as software structure measures, process measures, such as defect fixing, and maturity assessment models. The way researchers have built their samples has also contributed to the mixed results with different project properties being considered and ignored. Because FLOSS projects are evolving, their quality is too, and it must be measured using metrics that take into account its community{\textquoteright}s commitment to quality rather than just its software structure. Challenges exist in defining what constitutes a defect or bug, and the role of modularity in affecting FLOSS quality.},
	keywords = {literature review, measurement, open source, quality, Software},
	author = {Ruiz, Claudia and Robinson, William}
}
@article {flosswp77,
	title = {Guarding the Commons: How Community Managed Software Projects Protect Their Work},
	journal = {Research Policy},
	volume = {32},
	year = {2003},
	note = {"Data was collected from three primary sources: 1) observation at project and user group meetings, technical presentations and conferences; 2) informant interviews; and 3) project data archived on the Internet that detailed project interactions and structural developments."

"Project data was collected from online archives and included documents such as: mission statements, charters, bylaws, meeting minutes, and mailing list archives."},
	month = {February},
	pages = {1179-1198},
	edition = {7},
	abstract = {Theorists often speculate why open source and free software project contributors give their work away. Although contributors make their work publicly available, they do not forfeit their rights to it. Community managed software projects protect their work by using several legal and normative tactics, which should not be conflated with a disregard for or neglect of intellectual property rights. These tactics allow a project?s intellectual property to be publicly and freely available and yet, governable. Exploration of this seemingly contradictory state may provide new insight into governance models for the management of digital intellectual property.},
	keywords = {Common Pool Resources, email, email archives, intellectual property, mailing list, open source, Public Goods, Software, Survey},
	attachments = {https://flosshub.org/sites/flosshub.org/files/rp-omahony.pdf},
	author = {Siobhan O{\textquoteright}Mahony}
}
