35 KiB
35 KiB
| 1 | Key | Item Type | Publication Year | Author | Title | DOI | Change characteristics (blue) | Actors (purple) | Environmental characteristics (green) | Methods details (orange) | Misc. (red) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | LB5MEY9S | journalArticle | 2017 | Norskov, Sladjana; Kesting, Peter; Ulhoi, John Parm | Deliberate change without hierarchical influence? The case of collaborative OSS communities | 10.1108/IJOA-08-2016-1050 | |||||
| 3 | KUWLMFWM | journalArticle | 2017 | Santos, Carlos Denner D60os | Changes in free and open source software licenses: managerial interventions and variations on project attractiveness | 10.1186/s13174-017-0062-3 | procedural --- license changes. managerial interventions in the nature of the license selected for the project; loosening the license makes the project more attractive, restricting it makes it less attractive; but asymmetric impacts though, there are more specific gradations of usefulness when moving between licenses than listed above | contributors to OSS projects --- ostensibly maintainers who are able to write to the license and switch the listed license. the project uses the framing of “managers” of OSS projects but it’s entirely backwards and should be disregarded. | environment of attractiveness, as defined through lookups, selections and stated intent to download. as parts of this, project user base, attractiveness through use and downloads make up the environment. | Quantitative --- mining OSS projects on source forge that have had interventions/changes to their license selection then comparing against download and popularity data | Mapping org studeis brain uncritically onto FOSS projects leads to failures within the empirical study; Just not very good, really grandiose in its claims; not sure how they’re going to isolate managerial intervention within the structure of OSS projects which,… rather famously do not have managers |
| 4 | SJEI288C | conferencePaper | 2024 | Franke, Lucas; Liang, Huayu; Farzanehpour, Sahar; Brantly, Aaron; Davis, James C.; Brown, Chris | An Exploratory Mixed-methods Study on General Data Protection Regulation (GDPR) Compliance in Open-Source Software | 10.1145/3674805.3686692 | technical and organizational/procedural: broad compliance with GDPR; increased development work and attention devoted to compliance with GDPR features and PRs -- increases to the technical management of data --- organizational: slowed down development timelines immensely --- organization: GDPR compliance requires and overhaul of --- consultation with legal team is a change in and of itself ; one that decreased productivity; technical because the technical aspects of the code were the things regulated by GDPR | OSS project developers --- some of whom had submitted GDPR compliance Prs | geopolitical legal regulation --- data privacy and rights regulation --- EU --- from a technical level, this is a non-functional requirement ---internal evaluation of change success within environment: consultation with legal counsel --- self-assessment --- “most of the resources on the internet are wrong” | Mixed-methods: pilot interview study with three developers; survey with 56 developers; mined Prs from GitHub, some sampling for survey done from activity data mined from GitHub ; grounded thematic coding methods for analysis of free responses/qualitative themes | developers not happy about compliance --- frustration of internal productivity in order to comply with the standard--- unhappiness also with the standard itself, not just what the compliance does to the project |
| 5 | U7U4YLVB | journalArticle | 2023 | Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Haiyi | "Nip it in the Bud": Moderation Strategies in Open Source Software Projects and the Role of Bots | 10.1145/3610092 | |||||
| 6 | M6PP5MPQ | conferencePaper | 2011 | Jensen, Chris; Scacchi, Walt | License Update and Migration Processes in Open Source Software Projects | https://doi.org/10.1007/978-3-642-24418-6_12 | |||||
| 7 | ENQ5AACF | journalArticle | 2022 | Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, Dirk | Managing Episodic Volunteers in Free/Libre/Open Source Software Communities | 10.1109/TSE.2020.2985093 | |||||
| 8 | RN5Y3TN5 | conferencePaper | 2020 | Wessel, Mairieli; Serebrenik, Alexander; Wiese, Igor; Steinmacher, Igor; Gerosa, Marco A. | What to Expect from Code Review Bots on GitHub? A Survey with OSS Maintainers | 10.1145/3422392.3422459 | organizational/procedural - adoption of code review bot; rationale: this code review bot will enhance feedback to developers contributing code; reducing maintainers effort when evaluating different parts of the code | OSS maintainers of projects that had adopted code review bots | external/peripheral contributions from the fork of the project --- those waiting for code review --- self-assessment: internal metrics of amorphous normative goals such as reducing time to close on Prs; maintainers hoped to automate things as the number of contributions increased | qualitative survey: 27 maintainers re: the adoption of code review bots within the project. maintainers for projects who had adopted at least one code review bot. using the GHTorrent data set and who had contributed on either side of bot adoption --- card sorting thematic analysis of the survey responses --- discussion and consensus regarding the themes | a lot of internal rationalization when addressing different factors of being more ‘productive’ or lessening small labor within the project--- added noise and downside results from the adoption of the bots |
| 9 | HS8AQN5V | journalArticle | 2010 | Sojer, Manuel; Henkel, Joachim | Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments | 10.17705/1jais.00248 | |||||
| 10 | GGZV58MQ | journalArticle | 2021 | Klug, Daniel; Bogart, Christopher; Herbsleb, James D. | "They Can Only Ever Guide": How an Open Source Software Community Uses Roadmaps to Coordinate Effort | 10.1145/3449232 | procedural --- Use of project roadmaps --- ecosystem/project (porous distinction between the two) grows larger, with different stakeholders and goals --- to organize this (identifying consensus around project goals) roadmaps are used to structure things -- articulated work for the core members of the project ; team members followed the guide far more than other contributors -- goal of the roadmap is to make the trajectory more visible for external parties; 5.1.4; the roadmap is critical for helping communicate work to external parties, to help users plan, | maybe the change is especially relevant for core team members --- for them the roadmap structures their priorities and aims; OSS contributors to the Rust project, either core (contributing to blog posts or team members) or more peripheral (have committed to the compiler project) | infrastructural OSS ecosystem, the Rust programming language ecosystem. --- the road-mapping architecture occurs across the ecosystem, encapsulating different repositories within the Rust project | mixed methods single case study and email interviews --- selection of a \`revelatory case’ for Rust and its roadmap evolution ; collected multimodal data across settings and then followed up with Rust contributors to try to contextualize finidngs/observations;sampled for email interview from the core develoeprs identified through data mining (2018 road map); always ends up with qual coding/analysis for the text data --- more rigorously inductive than computational approaches | there’s a difference in the roadmap’s presentation/ostensible utility and its utility in practice --- while it seems lo be a top-down directive, in fact it is a reflection of bottom-up interest and labor promises; litany of rationales and motivations for the creation of the roadmap, environmental pressures and inputs are only one part of that. so many internal reasons, change is not often articulated in terms of the external pressures, instead the self-organization of tings is useful for structuring the different feature developments; adaptive change (roadmap) does not occur in a vacuum, it needs to be cultivated and supported through the other documents like READMEs or GOVERNANCE documents; the roadmapping architecture enc |
| 11 | JL6YZE5S | journalArticle | 2023 | Hu, Jin; Hu, Daning; Yang, Xuan; Chau, Michael | The impacts of lockdown on open source software contributions during the COVID-19 pandemic | 10.1016/j.respol.2023.104885 | procedural (LoD at individual contributor) --- contributions devoted to OSS projectss -- the rationale between increases or decreases in contribution activity was adaptation to fear and time availability surrounding Covid-19 and the lockdown in China | OSS contributors in Wuhan and Xian -- GitHub location within the regions selected; contributions are broad contributions to any project, not project-specific ;validation set looking at OSS developers in specific states in the US | geopolitical; Covid-19 pandemic- initiated lockdowns in China and the united states. Lockdown (environmental) characteristics are directly informed by the regime’s approach to Covid mitigation and management. | mixed-methods; repository mining supplemented with survey study; primarily looking at commits s contributions; using difference-in-difference models to try to model the absence of F2F interactions, as such interactions are important motivators for contributors; survey study sampled from developers impacted by the two lockdowns that were studied-- specifically, sampled from the developers in the results from the mining | interesting sampling notes regarding prevalence of things in different geographies – using geographic proximity to establish matched pairs/similarity in the different cases; environmental factors were seemingly deterministic in the shape of the adaptations; not actually at the project-level, instead looking at contributions devoted to OSS projects, but the unit of analysis if the developer (maybe a note on the frailty of constraining the unit of analysis to project or individual level and the flexibility required to move between those in a thoughtful way) |
| 12 | XPC3Y8HH | journalArticle | 2020 | Butler, Simon; Gamalielsson, Jonas; Lundell, Bjorn; Brax, Christoffer; Mattsson, Anders; Gustaysson, Tomas; Feist, Jonas; Lonroth, Erik | Maintaining interoperability in open source software: A case study of the Apache PDFBox project | 10.1016/j.jss.2019.110452 | technical - actions to maintain interoperability --- decisions fall into four types: improve to match de facto reference implementation; degrade to match the de facto reference implementation; improve to match standard; scope of implementation | OSS contributors,maintainers and community of the ASF’s PDFBox --- the nature of the work varies for each of these contributor archetypes, many of the higher-level discussions surrounding different technical changes recess into the Apache way of organizing OSS work --- core developers take a front-and-center role in managing different types of changes with different rationales | two environments at play here; the putative standard of interoperability an the de-facto reference implementation of Adobe Acrobat. what technical changes are being made in the service of PDFBox’s interoperability ride in parallel across these rails --- throughout, the core developers are balancing internal demands and contexts on their adaptive changes | qualitative case study of PDFBox development over two years --- purposeful sampling for standards and collaboration-based OSS project | using a competing implementation as the synecdoche of the environmental standard (see more in the notes) |
| 13 | 4V42NWTT | journalArticle | 2016 | Adams, Bram; Kavanagh, Ryan; Hassan, Ahmed E.; German, Daniel M. | An empirical study of integration activities in distributions of open source software | 10.1007/s10664-015-9371-y | |||||
| 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 | |||||
| 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 |
| 21 | ZGK4HR76 | journalArticle | 2015 | Vendome, Christopher; Linares-Vasquez, Mario; Bavota, Gabriele; Di Penta, Massimiliano; German, Daniel M.; Poshyvanyk, Denys | ICSME - When and why developers adopt and change software licenses | 10.1109/icsm.2015.7332449 | Procedural – license changes within OSS projects --- the change event is the real adaptation action; rationale for commercial reuse is also a motivating factor | OSS maintainers (Java, on GitHub) who change the license --- oftentimes this is a copyright holder or primary core contirbutor of the project | nebulous environment of commercial reuse, ‘community’, and user base --- there’s also discussion around the role that changes to the broader dependency network play in the structure of the project and changes to the license | Mixed-methods; mining 16k java open source projects and their commits and then supplemented with survey study of 138 developers; sample of developers surveyed are from the trace data of the mined project actions --- specifically looking to identify projects that had shifted over time with regard to licensing | many of the intitial decisions and adaptations were motivated from a range of intrinsic and extrinsic motivations |
| 22 | PSZSSAS3 | journalArticle | 2017 | Ding, Hui; Ma, Wanwangying; Chen, Lin; Zhou, Yuming; Xu, Baowen | APSEC - An Empirical Study on Downstream Workarounds for Cross-Project Bugs | 10.1109/apsec.2017.38 | Technical – downstream workarounds from errors and bugs and undesirable method behavior introduced by upstream dependencies -- common workaround per prior literature -- workarounds fall into four common patterns: using a different method, wrapping the current method in a conditional per input, augmenting input to match method, augmenting method output to match downstream | OSS project developers of downstream scientific python libraries on GitHub | packaging ecosystems, Scientific python dependency ecosystem on GitHub | mixed-methods; though statistical methods were used in evaluating hypotheses or finding differences in the workarounds; manual methods were used for cross-project bugs with workarounds in the first place as well as some characterization of the bugs | the short-term adaptations are meaningfully different than the long-term fixes across the environment there’s a lot of similarity in the kinds of cross-project bugs that run into this problem/adaptation --- often when the downstream project encounters an emergent case that is untested by the upstream repository |
| 23 | V3F8FYG5 | journalArticle | 2018 | Meloca, Rômulo; Pinto, Gustavo; Baiser, Leonardo; Mattos, Marco; Polato, Ivanilton; Wiese, Igor; German, Daniel M. | Understanding the usage, impact, and adoption of non-OSI approved licenses | 10.1145/3196398.3196427 | Organizational / procedural-- adoption of non OSI approved licenses or change to OSI-approved license --- the majority of the changes in either direction were from the adoption or deletion of a license (which happened to be OSI compliant) --- RQ3 provides naivete or lack of care for reasoning for moves into non-approved licenses | OSS package publishers --- some of whom have published packages with non-OSI approved licenses | governing body --- OSI is an open source regulator, vets the software license to make sure that it’s either open source or not --Also looking at compliance within three well-known open source libraries: NPM, RubyGems and CRAN; these enviroments are kinda nested within the focal environment, compliance in terms of sync with dependencies --- check of ‘success’ or anything: majority of the time, surveyed developers are not checking whether the different licenses they select are conforming, or adhering to anything | Mixed-methods: mining packages from the three different package manager environments -- pulled down a bunch of package data from the different ecosystems and looked through their license change over specified versions: a survey with the publishers of the package. sampled from NPM. open responses were qualitatively coded by pairs of researchers | not happy with the way that the different segments of the project are conflated with each other --- what use is the response of developers who use specific non-compliant licenses when the majority of non-compliance evolution is deletion or lack of license? --- different sets of populations between different methods sections of the research --- “developers might not fully understand the effect of the adaptive action that they’re taking” --- contributors ‘dont care; about the licenses they use |
| 24 | 6AQY86BW | journalArticle | 2022 | Businge, John; Openja, Moses; Nadi, Sarah; Berger, Thorsten | Reuse and maintenance practices among divergent forks in three software ecosystems | 10.1007/s10664-021-10078-2 | |||||
| 25 | YJREPLGY | journalArticle | 2023 | Venturini, Daniel; Cogo, Filipe Roseiro; Polato, Ivanilton; Gerosa, Marco A.; Wiese, Igor Scaliante | I Depended on You and You Broke Me: An Empirical Study of Manifesting Breaking Changes in Client Packages | 10.1145/3576037 | Technical – rectification of breaking changes introduced to client packages in npm by provider packages; in general, the provider fixes the breaking change in a subsequent minor or patch release --- so the adaptive action is to kind of… wait and request that the thing is changed. ( on average, in 7 days)--- when the client does adapt to address the breaking change --- sometime clients downgrade to get out of the breaking change | OSS maintainers/contributors to the downstream repository whose functionality is broken because of the upstream dependency change | dependency ecosystems/package management systems, specifically -- the proliferation of breaking changes across the dependency ecosystem ; the dependency network is the environment but the breaking change is the antecedent cause specifically, the project looks at changes and adaptation within the npm packaging ecosystem --- npm is the primary package manager for JavaScript, with more than 1 million packages | mixed-methods; repository mining and statistical modeling of build changes in the npm ecosystem and then qualitative validation of breaking changes and the client packages’ adaptation to them. | “Client packages recovered manifesting breaking changes in 39.1% of cases, including clients and transitive providers.” ([Venturini, 2023, p. 20] This actually seems almost impossibly low, what do you mean it recovers in 39.1% of cases? Shouldn't it be recovering in like... all cases? ++ primarily looking at the environmental antecedent as the objects of study rather than the adaptation as the objects of study |
| 26 | QIVH9LJG | journalArticle | 2017 | Abdalkareem, Rabe; Nourry, Olivier; Wehaibi, ; Mujahid, Suhaib; Shihab, Emad | Why do developers use trivial packages? an empirical case study on npm | 10.1145/3106237.3106267 | 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; professional JS developers; many long-tenured | package management systems: npm – node.js; change adheres project to well-tested and implemented environment; there are a lot of trivial packages; 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; survey free-response answers were analyzed with qualitative coding – grounded theory methods | internal motivations for productiivty: many also stated that reuse was bad: developers aware that the change may represent existential risk for themselves; in adapting may also introduce more threats |
| 27 | TFDYF5UM | journalArticle | 2011 | Capiluppi, Andrea; Stol, Klaas-Jan; Boldyreff, Cornelia | Software Reuse in Open Source: A Case Study | 10.4018/jossp.2011070102 | |||||
| 28 | XDY5INZ6 | conferencePaper | 2018 | Lotter, Adriaan; Licorish, Sherlock A.; Savarimuthu, Bastin Tony Roy; Meldrum, Sarah | Code Reuse in Stack Overflow and Popular Open Source Java Projects | 10.1109/ASWEC.2018.00027 | technical -- code reuse from Stack Overflow within popular Java OSS projects-- rationale is copying from stackoverflow or other popular projects, which inherently increases technical fit with the environment --- disregarding within project copying, that is almost a meaningless metric copying between projects is larger (in size of code segment that’s copied over) and may be more prevalent? | OSS project developers for popular/well-regarded projects -- I guess this action is also at the developer/contributor level. | The most popular Java OSS projects on SourceForge and GitHub --- in 2017, which projects had the highest weekly popularity and contained requisite Java code or, alternatively, the projects that had the highest popularity on SourceForge; Also looking at all Java StackOverflow comments from 2014-2017. pulling out the code snippets from these answers | quantitative repo mining from Stack Overflow and most popular Java projects --- focusing on weekly and all-time popularity for GitHub and SourceForge metrics --- used near-OTS code reuse identification software changing parameters for a few things ; reliant on syntax and token similarity, not AST for analysis | paper finger wags about code reuse the whole time, discussing how it’s not a good practice. Adaptive change can lead to adherence to substandard environmental norms. Seems like code reuse from Stack Overflow isn’t even that prevalent? Not a very good paper honestly; never discusses when the code was reused within or in which direction --- it’s cross sectional data!! How can you even make an argument surrounding copying, which is a time-dependent action! |
| 29 | MBVCDT66 | journalArticle | 2023 | He, Runzhi; He, Hao; Zhang, Yuxia; Zhou, Minghui | Automating Dependency Updates in Practice: An Exploratory Study on GitHub Dependabot | 10.1109/TSE.2023.3278129 | organizational/procedural -- adoption of dependabot--- stated rationale: managing project dependencies --- specifically, keeping project dependencies up to date --- | OSS developers for projects that have adopted dependabot --- specifically, developers who are likely to be familiar with dependabot and its workings | GitHub ---- specifically the projects on GitHub but often, the platform itself structures the environment that projects operate in --- also dependency networks, the reasoning why dependabot is used is for projects to align better with the dependencies that they’re reliant on | mixed-methods, EDA and a developer survey --- from a sample of 1823 projects, mining the PRs made by Dependabot with a survey of the projects’ developers (n131)--- sampled for the survey from the projects that were identified in the mining scenario -- a lot of researcher selection in finding maintainers who are likely to be familiar with it | a lot of analysis on whether or not adopting dependabot works, like whether the thing that people are doing to adapt is… actually working… even though dependabot is not that useful for automatic updates, many developers believe that it is useful for notifying updates |
| 30 | DGV2UJNM | conferencePaper | 2020 | Zhou, Shurui; Vasilescu, Bogdan; Kästner, Christian | How has forking changed in the last 20 years? a study of hard forks on GitHub | 10.1145/3377811.3380412 | technical and procedural --- the changing of a fork from social to hard in GitHub;the forks often start social, but then move to hard once obstacles to contributing upstream were found, whether that be unresponsive maintainers or rejected pull requests | GitHub repo owners of hard-forked OSS projects are the ones who effect the adaptive change ; though the quantitative sample looks at 15,306 hard forks on GitHub (initiated/shepherded by the owners of those hard forks), the interview sample looks at 15 owners of forked libraries --- these are long-tenured OSS contributors | forking networks on GitHub, the environmental characteristics are unresponsive upstream projects or barriers to contributing to the upstream project; the hard fork is downstream of the construction of the upstream project as external to the social fork | mixed-methods; mining and classifying hard-forked projects and then interviewing the owners of those repositories/maintainers of upstream; heuristic classifier to find hard forks, qualitative card sorting to characterize them; qualitative interviews to gain perspective -- interview sample created from identifying hard forked projects and authors | hard forks are, generally, a rare phenomenon across GitHub -- though the scale of GitHub means that the total number of these forks is actually pretty large; another verification of respondent claims: “we see little evidence of actual synchronization or merging across forks in the repositories:” ([Zhou et al., 2020, p. 453 |
| 31 | QLSEMWTQ | journalArticle | 2017 | Vendome, Christopher; Bavota, Gabriele; Penta, Massimiliano Di; Linares-Vásquez, Mario; German, Daniel; Poshyvanyk, Denys | License usage and changes: a large-scale study on gitHub | 10.1007/s10664-016-9438-4 | |||||
| 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 |