mgaughan/adaptation-slr
1
0
Fork 0
Code

22/34 papers done

Browse Source
This commit is contained in:
mgaughan 2025-07-21 10:12:25 -04:00
parent 2513e718f3
commit 154eadda62
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
070725_papers_master.csv
View File

@ -14,7 +14,7 @@ XPC3Y8HH,journalArticle,2020,"Butler, Simon; Gamalielsson, Jonas; Lundell, Bjorn
MVGUFG8P,conferencePaper,2016,"Crowston, Kevin; Shamshurin, Ivan",Core-Periphery Communication and the Success of Free/Libre Open Source Software Projects,10.1007/978-3-319-39225-7_4,,,,,
WE8VYWEX,journalArticle,2021,"Geiger, R. Stuart; Howard, Dorothy; Irani, Lilly",The Labor of Maintaining and Scaling Free and Open-Source Software Projects,10.1145/3449249,"organizational/procedural – projects have to reconstruct their processes and organization in order to comply with shifting expectations of scale. trust scaling requires new forms of code review… formalizing it while also trusting designated individuals to adhere to it --- this may seem like a technical process but in reality it’s organizational, as it expresses the direction of the project and the way of doing. ","OSS project maintainers, largely white, male from the global north, and young-ish, --- from a range of project types too","environment is infrastructural mapping of project for other organizations --- as projects scale…also GitHub as an environment that creates pressures around presentation and reputation. the ecosystem turns from interdependent to competitive as projects scale within it -- the project reshapes the environment --- maintainers have to directly manage this new environment and set of relationships --- sometimes, maintainers choose to consolidate like-projects within an ecosystem. Check of success: NA",qualitative interview study: semi-structured interviews with maintainers during 2019-2020. non-random sampling. tried to interview maintainers from a breadth of environments and projects; recruited from a breadth of settings. Interpretive grounded theory for qualitative analysis.,"adaptive change becomes an ‘overwhelming and never-ending chore’--- environmental demands from users are disrespectful, entitled, and demanding in terms of time and attention. Burn out because of ‘what was expected’ of maintainers as they scale out"
3F7CJATB,journalArticle,2022,"Yin, Likang; Chakraborti, Mahasweta; Yan, Yibo; Schweik, Charles; Frey, Seth; Filkov, Vladimir",Open Source Software Sustainability: Combining Institutional Analysis and Socio-Technical Networks,10.1145/3555129,"Procedural – discussion of governance in OSS projects ---- measured through identiification of Institutional Statements within Apache-incubator projects --- more functional-based discussions around IS statements precedes graduation from ASFI\*. more IS discussion in general precedes increased activity; more governance discussion from mentors (ASFI proxies) precedes engagement with the project. *However, without more robust description of the interpretation of the LDA topics, I have a bit of skepticism around this. There are other notes about evolution with regards to attracting contributors and setting up contributions, but that’s secondary to the adaptation discussion.","stakeholder agents for the OSS projects within ASFI (committers, contributors, mentors). Different than contributor or maintainer because the role of mentor is rather bespoke in this environment.","Apache Software Foundation incubator and graduation from the environment “Those having foundation support, like the ASF, may additionally be in the process of organizing the developers’ structured interactions under a second tier of governance prescriptions as required by the ASF Incubator.” ([Yin et al., 2022, p. 4]","quantitative ---- computationally modeling institutional norms and rules from OSS communications as well as socio-technical collaboration records; collecting data for both historical development activity such as commits and communications as well as project-level discussions regarding mailing list discussions creating a socio-technical network of collaboration for the different projects fine-tuning a BERT classifier to identify institutional statements with the ASF-specific language from different things; with this longitudinal data, they use Granger causality to identify “causal links” of different things. Limitations using granger causality when evaluating cause and effect; some discussed in RQ3 results","longstanding gripes about the generalizeability of ASF studies --- the isomorphic pressure is, I think, too big for any takeaway to be meaningfully transferred to other settings --- ;like this oper The ASFI can have mentors that represent the desires (re: fit) of the environment more broadly, directly adapting the focal project to the envrionment;s wants"
BFEMKQCR,journalArticle,2014,"Gamalielsson, Jonas; Lundell, Björn",Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?,https://doi.org/10.1016/j.jss.2013.11.1077,,,,,
BFEMKQCR,journalArticle,2014,"Gamalielsson, Jonas; Lundell, Björn",Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved?,https://doi.org/10.1016/j.jss.2013.11.1077,Procedural – creating hard fork of a prior project; making the prior project now an environmental factor in the construction of the new project. Ideologically motivated hard fork (at the time of forking) LO from OO. Adaptation in the construction of the hard fork means ideologically motivated restructuring of governance and licensing (further egalitatrian and copyleft) which is even different than the AOO proejct which also evolved from OO,"engaged contributors and maintainers of the LibreOffice project, a fork from the pre-existing OpenOffice project","OpenOffice derivative forks; OO was an open source productivity library that was bought by Sun and then sold to Oracle.; LO is an offshoot of the project by OO contributors who wanted to depart from the mainline software; AO is an offshoot that is the result of Oracle selling the OO project to Apache. In a way, cross-project competition in the same product space ","mixed-methods case study analysis of the OpenOffice project and its different derivative forks. first, quantitative analysis of the contribution patterns of the different projects and their forks; quantitative modeling spent a lot of time looking at passive evolution of projects rather than intentional adaptation. second, interview study talking to different active participants in the LO community --- qualitative analysis based in open coding/qual coding practices","Interesting notes about sustainable communities and what that might mean for the projects involved; contributor activity peaks during the fraught times within the project’s lifecycle, when there’s a lot of activity surrounding the hard fork from upstream"
FJSA37EW,journalArticle,2021,"Bogart, Chris; Kästner, Christian; Herbsleb, James; Thung, Ferdian",When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems,10.1145/3447245,,,,,
72F8GVAP,journalArticle,2025,"Jahanshahi, Mahmoud; Reid, David; Mockus, Audris",Beyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development,10.1145/3715907,,,,,
QEKG8ISF,journalArticle,2016,"Hilton, Michael; Tunnell, Timothy; Huang, Kai; Marinov, Darko; Dig, Danny","ASE - Usage, costs, and benefits of continuous integration in open-source projects",10.1145/2970276.2970358,"Procedural – adoption and change to CI systems within project builds --- though the rational for initial adoption are intrinsic to the project, the reasons for changing or evolving the CI yaml file are largely contingent on dependencies and reliability","OSS maintianers, specifically of popular projects on GitHub, many of whom have used CI workflows in their builds",OSS on GitHub --- no evaluation of whether CI changes ‘work’ for their environment though I guess adherence to the new dependency is the thing that would display that ,"mixed-methods: mining open source projects from GitHub while also surveying developers from popular projects.survey sampling is NOT from the mined authorship data, instead focusing on popular GitHub projects",he discussion of adaptive change is often framed within the broader setting of whether or not the change is popular/relevant -- i.e. 40% of projects are using CI systems
@ -32,4 +32,4 @@ QLSEMWTQ,journalArticle,2017,"Vendome, Christopher; Bavota, Gabriele; Penta, Mas
5E2EWRQN,journalArticle,2020,"Abdalkareem, Rabe; Oda, Vinicius; Mujahid, Suhaib; Shihab, Emad",On the impact of using trivial packages: an empirical case study on npm and PyPI,10.1007/s10664-019-09792-9,technical: code reuse: trivial package reuse: rationale – trivial packages provide well-implemented and tested code from the packaging ecosystem: enables adherence to the quality testing of the broader ecosystem,application developers: long-tenured JS and Python coders: largely professional but some independents,package managemeny systems: npm and PyPI: change adheres project to well-tested and implemented environment: no project evaluation of change ‘success’ wrt environment ,mixed methods: pilot survey – data mining – follow up survey – data mining to validate survey responses: sampling from prior methods step: skews to university ,internal motivations for productiivty: many also stated that reuse was bad: paper spends a lot of time defining trivial packages
P3MTJWXP,conferencePaper,2022,"Zhang, Xunhui; Wang, Tao; Yu, Yue; Zeng, Qiubing; Li, Zhixing; Wang, Huaimin","Who, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Github’s Sponsor Mechanism",10.1145/3491102.3501822,procedural/organizational: developer adoption and participation in the GitHub sponsors program --- rationale for adopting the sponsorship model: I should be rewarded or recognized for my OSS work ,"OSS developers, but not necessarily those with big commits or key contributions, the popular ones who work on big projects","GitHub --- and also broader society. the adoption of the feature is bound to the platform as the environment --- as such, the bounds of the project’s activity are restricted by GitHub as a platform --- to what extent is broader social environment (intrinsic desire for payment) also the environment here?",mixed-methods -- both data mining and survey; quantitative data mining of different sponsorship events within GitHub --- pulling a lot of data on the individual sponsorships and the sponsoring events --- statistic modeling (lmer) of maintainer/contributor balance etc.; Sampling from the data mining to identify the relevant population.; qualitative already with a questionnaire about the why and what questions.  -- survey looked up the expectations and rationales for using the sponsor feature ; two-stage survey,"again a validity check of the contributor rationales --- How effective is the sponsorship mechanism with carving out time for maintainers to work on things --- didn’t hold up!; configurable adaptations more throughout this, not the first paper that discusses this; environment (GitHub) is incredibly deterministic in establishing who adapts/adopts the feature --- instead of being an amorphous social pressure or anything like that --- it is a platform trying to get you to use their most recent feature; intersection of rationales for doing things sit at the intersection of intrinsic and extrinsic motivations"
DW9Q2W6V,conferencePaper,2022,"Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, Coen",Variant Forks - Motivations and Impediments,10.1109/SANER53432.2022.00105,"technical change rooted in procedural motivations ---- creating variant of existing project in order to redirect the technical aims of the work. The creation of the variant fork is switching the social fork from contributing back to mainline to being more of a hard fork. creating a ‘variant fork’ of a project on a social coding platform -- variant fork is the same as hard fork I think. --- technical maintenance, wanting to change something and running into issues contributing back to the project or wanting to redirect the features ;; addition of different types of things","OSS maintainers who support the variant fork, who walked away from the upstream mainline project in order to create a new repository and effort",the environment is the newly-constructed relationship between the fork project and its upstream mainline. The actions of the mainline thus become the rationale for moving the fork from social to variant. ,"Mixed-methods – largely a survey with 105 maintainers of social fork projects; 12 questions, 15 minutes long of surveying authors. then selected things Likert scales and free responses from the survey responses. But also Sampled for variant forks through heuristic-based mining of platforms like Libraries.io and GitHub. Then also collected popularity metrics for the forks and their variants --- leading to mixed-methods analysis, even though the quantitative side of it is weak… to say the least.",Interesting that the categories of technical and procedural run into issues when the motivations are based in the procedural gripes with technical maintenance
3Y9YKK5M,conferencePaper,2011,"Heinemann, Lars; Deissenboeck, Florian; Gleirscher, Mario; Hummel, Benjamin; Irlbeck, Maximilian",On the Extent and Nature of Software Reuse in Open Source Java Projects,,,,,,
3Y9YKK5M,conferencePaper,2011,"Heinemann, Lars; Deissenboeck, Florian; Gleirscher, Mario; Hummel, Benjamin; Irlbeck, Maximilian",On the Extent and Nature of Software Reuse in Open Source Java Projects,DOI: 10.1007/978-3-642-21347-2_16,Technical – software reuse in Java projects - the reuse itself motivates the project to fit closer with the environment (using the code from the environment in the project),Contributors to Java OSS projects in this data set,"20 of the most downloaded stable projects writte in Java on SourceForge. when using quantitative methods, reuse is only compared against 22 popular Java libraries --- when using manual inspection, it can be other things but contingent on personal evaluation",mixed-methods analysis of code reuse in 20 Java projects. First using computational comparison software to ID reuse and copied code. then using a different heuristic with manual inspection to also try to ID copied code. There was a slightly different byte-code level computational comparison used in the black-box identification.,"establishing how widely prevalent the code in the environment is --- e.g. 90% of projects in their data set reuse code from different projects similar to the other heinemann paper --- i thik that one was an extentions of this one “We selected 22 libraries which are commonly reused based on our experience with both own development projects and systems we analyzed during earlier studies.” ([Heinemann et al., 2011, p. 211](zotero://select/library/items/3Y9YKK5M)) ([pdf](zotero://open-pdf/library/items/KV55AS6A?page=5&annotation=SGBGKMI9)) how is this remotely comprehensive of the different libraries and environmental spaces that Java projects might pull from to reuse? I strongly dislike the methods of only selecting a specific subset of projects to test the reuse against --- given how constrained the empirical setting is, I’m skeptical of assigning too much weight to these results as representative or even indicative"

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
14 MVGUFG8P conferencePaper 2016 Crowston, Kevin; Shamshurin, Ivan Core-Periphery Communication and the Success of Free/Libre Open Source Software Projects 10.1007/978-3-319-39225-7_4
15 WE8VYWEX journalArticle 2021 Geiger, R. Stuart; Howard, Dorothy; Irani, Lilly The Labor of Maintaining and Scaling Free and Open-Source Software Projects 10.1145/3449249 organizational/procedural – projects have to reconstruct their processes and organization in order to comply with shifting expectations of scale. trust scaling requires new forms of code review… formalizing it while also trusting designated individuals to adhere to it --- this may seem like a technical process but in reality it’s organizational, as it expresses the direction of the project and the way of doing. OSS project maintainers, largely white, male from the global north, and young-ish, --- from a range of project types too environment is infrastructural mapping of project for other organizations --- as projects scale…also GitHub as an environment that creates pressures around presentation and reputation. the ecosystem turns from interdependent to competitive as projects scale within it -- the project reshapes the environment --- maintainers have to directly manage this new environment and set of relationships --- sometimes, maintainers choose to consolidate like-projects within an ecosystem. Check of success: NA qualitative interview study: semi-structured interviews with maintainers during 2019-2020. non-random sampling. tried to interview maintainers from a breadth of environments and projects; recruited from a breadth of settings. Interpretive grounded theory for qualitative analysis. adaptive change becomes an ‘overwhelming and never-ending chore’--- environmental demands from users are disrespectful, entitled, and demanding in terms of time and attention. Burn out because of ‘what was expected’ of maintainers as they scale out
16 3F7CJATB journalArticle 2022 Yin, Likang; Chakraborti, Mahasweta; Yan, Yibo; Schweik, Charles; Frey, Seth; Filkov, Vladimir Open Source Software Sustainability: Combining Institutional Analysis and Socio-Technical Networks 10.1145/3555129 Procedural – discussion of governance in OSS projects ---- measured through identiification of Institutional Statements within Apache-incubator projects --- more functional-based discussions around IS statements precedes graduation from ASFI\*. more IS discussion in general precedes increased activity; more governance discussion from mentors (ASFI proxies) precedes engagement with the project. *However, without more robust description of the interpretation of the LDA topics, I have a bit of skepticism around this. There are other notes about evolution with regards to attracting contributors and setting up contributions, but that’s secondary to the adaptation discussion. stakeholder agents for the OSS projects within ASFI (committers, contributors, mentors). Different than contributor or maintainer because the role of mentor is rather bespoke in this environment. Apache Software Foundation incubator and graduation from the environment “Those having foundation support, like the ASF, may additionally be in the process of organizing the developers’ structured interactions under a second tier of governance prescriptions as required by the ASF Incubator.” ([Yin et al., 2022, p. 4] quantitative ---- computationally modeling institutional norms and rules from OSS communications as well as socio-technical collaboration records; collecting data for both historical development activity such as commits and communications as well as project-level discussions regarding mailing list discussions creating a socio-technical network of collaboration for the different projects fine-tuning a BERT classifier to identify institutional statements with the ASF-specific language from different things; with this longitudinal data, they use Granger causality to identify “causal links” of different things. Limitations using granger causality when evaluating cause and effect; some discussed in RQ3 results longstanding gripes about the generalizeability of ASF studies --- the isomorphic pressure is, I think, too big for any takeaway to be meaningfully transferred to other settings --- ;like this oper The ASFI can have mentors that represent the desires (re: fit) of the environment more broadly, directly adapting the focal project to the envrionment;s wants
17 BFEMKQCR journalArticle 2014 Gamalielsson, Jonas; Lundell, Björn Sustainability of Open Source software communities beyond a fork: How and why has the LibreOffice project evolved? https://doi.org/10.1016/j.jss.2013.11.1077 Procedural – creating hard fork of a prior project; making the prior project now an environmental factor in the construction of the new project. Ideologically motivated hard fork (at the time of forking) LO from OO. Adaptation in the construction of the hard fork means ideologically motivated restructuring of governance and licensing (further egalitatrian and copyleft) which is even different than the AOO proejct which also evolved from OO engaged contributors and maintainers of the LibreOffice project, a fork from the pre-existing OpenOffice project OpenOffice derivative forks; OO was an open source productivity library that was bought by Sun and then sold to Oracle.; LO is an offshoot of the project by OO contributors who wanted to depart from the mainline software; AO is an offshoot that is the result of Oracle selling the OO project to Apache. In a way, cross-project competition in the same product space mixed-methods case study analysis of the OpenOffice project and its different derivative forks. first, quantitative analysis of the contribution patterns of the different projects and their forks; quantitative modeling spent a lot of time looking at passive evolution of projects rather than intentional adaptation. second, interview study talking to different active participants in the LO community --- qualitative analysis based in open coding/qual coding practices Interesting notes about sustainable communities and what that might mean for the projects involved; contributor activity peaks during the fraught times within the project’s lifecycle, when there’s a lot of activity surrounding the hard fork from upstream
18 FJSA37EW journalArticle 2021 Bogart, Chris; Kästner, Christian; Herbsleb, James; Thung, Ferdian When and How to Make Breaking Changes: Policies and Practices in 18 Open Source Software Ecosystems 10.1145/3447245
19 72F8GVAP journalArticle 2025 Jahanshahi, Mahmoud; Reid, David; Mockus, Audris Beyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development 10.1145/3715907
20 QEKG8ISF journalArticle 2016 Hilton, Michael; Tunnell, Timothy; Huang, Kai; Marinov, Darko; Dig, Danny ASE - Usage, costs, and benefits of continuous integration in open-source projects 10.1145/2970276.2970358 Procedural – adoption and change to CI systems within project builds --- though the rational for initial adoption are intrinsic to the project, the reasons for changing or evolving the CI yaml file are largely contingent on dependencies and reliability OSS maintianers, specifically of popular projects on GitHub, many of whom have used CI workflows in their builds OSS on GitHub --- no evaluation of whether CI changes ‘work’ for their environment though I guess adherence to the new dependency is the thing that would display that mixed-methods: mining open source projects from GitHub while also surveying developers from popular projects.survey sampling is NOT from the mined authorship data, instead focusing on popular GitHub projects he discussion of adaptive change is often framed within the broader setting of whether or not the change is popular/relevant -- i.e. 40% of projects are using CI systems
32 5E2EWRQN journalArticle 2020 Abdalkareem, Rabe; Oda, Vinicius; Mujahid, Suhaib; Shihab, Emad On the impact of using trivial packages: an empirical case study on npm and PyPI 10.1007/s10664-019-09792-9 technical: code reuse: trivial package reuse: rationale – trivial packages provide well-implemented and tested code from the packaging ecosystem: enables adherence to the quality testing of the broader ecosystem application developers: long-tenured JS and Python coders: largely professional but some independents package managemeny systems: npm and PyPI: change adheres project to well-tested and implemented environment: no project evaluation of change ‘success’ wrt environment mixed methods: pilot survey – data mining – follow up survey – data mining to validate survey responses: sampling from prior methods step: skews to university internal motivations for productiivty: many also stated that reuse was bad: paper spends a lot of time defining trivial packages
33 P3MTJWXP conferencePaper 2022 Zhang, Xunhui; Wang, Tao; Yu, Yue; Zeng, Qiubing; Li, Zhixing; Wang, Huaimin Who, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Github’s Sponsor Mechanism 10.1145/3491102.3501822 procedural/organizational: developer adoption and participation in the GitHub sponsors program --- rationale for adopting the sponsorship model: I should be rewarded or recognized for my OSS work OSS developers, but not necessarily those with big commits or key contributions, the popular ones who work on big projects GitHub --- and also broader society. the adoption of the feature is bound to the platform as the environment --- as such, the bounds of the project’s activity are restricted by GitHub as a platform --- to what extent is broader social environment (intrinsic desire for payment) also the environment here? mixed-methods -- both data mining and survey; quantitative data mining of different sponsorship events within GitHub --- pulling a lot of data on the individual sponsorships and the sponsoring events --- statistic modeling (lmer) of maintainer/contributor balance etc.; Sampling from the data mining to identify the relevant population.; qualitative already with a questionnaire about the why and what questions.  -- survey looked up the expectations and rationales for using the sponsor feature ; two-stage survey again a validity check of the contributor rationales --- How effective is the sponsorship mechanism with carving out time for maintainers to work on things --- didn’t hold up!; configurable adaptations more throughout this, not the first paper that discusses this; environment (GitHub) is incredibly deterministic in establishing who adapts/adopts the feature --- instead of being an amorphous social pressure or anything like that --- it is a platform trying to get you to use their most recent feature; intersection of rationales for doing things sit at the intersection of intrinsic and extrinsic motivations
34 DW9Q2W6V conferencePaper 2022 Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, Coen Variant Forks - Motivations and Impediments 10.1109/SANER53432.2022.00105 technical change rooted in procedural motivations ---- creating variant of existing project in order to redirect the technical aims of the work. The creation of the variant fork is switching the social fork from contributing back to mainline to being more of a hard fork. creating a ‘variant fork’ of a project on a social coding platform -- variant fork is the same as hard fork I think. --- technical maintenance, wanting to change something and running into issues contributing back to the project or wanting to redirect the features ;; addition of different types of things OSS maintainers who support the variant fork, who walked away from the upstream mainline project in order to create a new repository and effort the environment is the newly-constructed relationship between the fork project and its upstream mainline. The actions of the mainline thus become the rationale for moving the fork from social to variant. Mixed-methods – largely a survey with 105 maintainers of social fork projects; 12 questions, 15 minutes long of surveying authors. then selected things Likert scales and free responses from the survey responses. But also Sampled for variant forks through heuristic-based mining of platforms like Libraries.io and GitHub. Then also collected popularity metrics for the forks and their variants --- leading to mixed-methods analysis, even though the quantitative side of it is weak… to say the least. Interesting that the categories of technical and procedural run into issues when the motivations are based in the procedural gripes with technical maintenance
35 3Y9YKK5M conferencePaper 2011 Heinemann, Lars; Deissenboeck, Florian; Gleirscher, Mario; Hummel, Benjamin; Irlbeck, Maximilian On the Extent and Nature of Software Reuse in Open Source Java Projects DOI: 10.1007/978-3-642-21347-2_16 Technical – software reuse in Java projects - the reuse itself motivates the project to fit closer with the environment (using the code from the environment in the project) Contributors to Java OSS projects in this data set 20 of the most downloaded stable projects writte in Java on SourceForge. when using quantitative methods, reuse is only compared against 22 popular Java libraries --- when using manual inspection, it can be other things but contingent on personal evaluation mixed-methods analysis of code reuse in 20 Java projects. First using computational comparison software to ID reuse and copied code. then using a different heuristic with manual inspection to also try to ID copied code. There was a slightly different byte-code level computational comparison used in the black-box identification. establishing how widely prevalent the code in the environment is --- e.g. 90% of projects in their data set reuse code from different projects similar to the other heinemann paper --- i thik that one was an extentions of this one “We selected 22 libraries which are commonly reused based on our experience with both own development projects and systems we analyzed during earlier studies.” ([Heinemann et al., 2011, p. 211](zotero://select/library/items/3Y9YKK5M)) ([pdf](zotero://open-pdf/library/items/KV55AS6A?page=5&annotation=SGBGKMI9)) how is this remotely comprehensive of the different libraries and environmental spaces that Java projects might pull from to reuse? I strongly dislike the methods of only selecting a specific subset of projects to test the reuse against --- given how constrained the empirical setting is, I’m skeptical of assigning too much weight to these results as representative or even indicative