CHAOSS Funding Impact WG, Feb 11 2026 - CourtneyR.dev's 2nd Brain

CHAOSS Funding Impact WG, Feb 11 2026 ![rw-book-cover](https://img.youtube.com/vi/Pfm_-PfGUnE/maxresdefault.jpg) 🔗 **Source:** [CHAOSS Funding Impact WG, Feb 11 2026](https://www.youtube.com/watch?v=Pfm_-PfGUnE) > [!note]+ Document Notes > tags: #open-source #funding #python #package-management #research #metrics #chaoss > author: CHAOSS Community > source: YouTube > reference: https://www.youtube.com/watch?v=Pfm_-PfGUnE > date created: 2024-11-21 10:30 > > # 🏷️ Title: CHAOSS Funding Impact WG, Feb 11 2026 >  ## 🧰 Action Inbox - [H1] Apply to Linux Foundation Open Source Summit North America CFP — deadline extended to Feb 15 #conferences #open-source - [H2] Review and provide feedback on funding impact measurement practitioner guide — format follows CHAOSS standards #documentation #funding - [H3] Consider implementing lightweight validation for donation platform URLs on PyPI — improve metadata quality #python #funding ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [CHAOSS Working Group](https://chaoss.community/) - [Linux Foundation Open Source Summit](https://events.linuxfoundation.org/open-source-summit-north-america/) ## 📝 Summary - CHAOSS Funding Impact Working Group meeting with leadership changes and research presentation - Kilian Osborne stepped down as co-chair, Adrian from Linux Foundation joined as new co-chair - Alexandros presented research on why Python package maintainers do/don't link donation platforms - Key findings show GitHub dominance for donation links, technical barriers, and outdated URL problems - Working group developing practitioner guide for funding impact measurement ## 📖 Main Content The CHAOSS (Community Health Analytics Open Source Software) Funding Impact Working Group held their February 2026 meeting with significant organizational changes and new research findings. The group operates under the CHAOSS code of conduct and focuses on developing metrics and understanding for measuring the impact of funding in open source projects. The meeting featured a co-chair transition, with Kilian Osborne stepping down due to a new position requiring significant time commitment. Adrian, director of quantitative research at the Linux Foundation, joined Paul and Dawn as the new co-chair, bringing expertise from previous work on multiplier effects with NGI comments. Alexandros presented follow-up research to his previous quantitative analysis on Python package donation platform linking. His mixed-methods study combined quantitative analysis of PyPI packages with qualitative surveys of maintainers to understand motivations and barriers for linking donation platforms. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/Pfm_-PfGUnE?t=0) — [H1] Meeting opening and agenda overview - Key idea: CHAOSS Funding Impact Working Group meeting with co-chair updates and research presentation - Evidence: "Welcome everyone to the February 11th funding impact measurement working group" #### ⏱️ [02:15](https://youtu.be/Pfm_-PfGUnE?t=135) — [H2] Co-chair transition announcement - Key idea: Kilian Osborne stepped down, Adrian joined as new co-chair - Evidence: "Kilian Osborne has left because he started a new position that will take up a lot of his time" #### ⏱️ [04:30](https://youtu.be/Pfm_-PfGUnE?t=270) — [H3] Adrian's introduction as new co-chair - Key idea: Natural fit given Adrian's role at Linux Foundation and previous research - Evidence: "Very natural fit given Adrian's position at LF as director of quantitative research" #### ⏱️ [06:45](https://youtu.be/Pfm_-PfGUnE?t=405) — [H1] Research presentation introduction - Key idea: Follow-up study on Python package donation platform linking patterns - Evidence: "Why authors and maintainers link or don't link their Piper libraries to GitHub repositories and donation platforms" #### ⏱️ [09:30](https://youtu.be/Pfm_-PfGUnE?t=570) — [H2] Research motivation and background - Key idea: Investigating suspicious patterns found in quantitative analysis of PyPI donation links - Evidence: "Some suspicious patterns came to our mind and we wanted to understand what's going on there" #### ⏱️ [12:15](https://youtu.be/Pfm_-PfGUnE?t=735) — [H3] Four research questions identified - Key idea: Understanding motivations for linking, GitHub dominance, outdated URLs, and barriers - Evidence: "Why people do link to donation platforms but also understand the big blue part why they don't link" #### ⏱️ [15:00](https://youtu.be/Pfm_-PfGUnE?t=900) — [H2] Survey methodology overview - Key idea: Two sequential surveys targeting Python package maintainers with over 1,400 responses - Evidence: "In total for both surveys we got over 1,400 responses to these surveys" #### ⏱️ [18:30](https://youtu.be/Pfm_-PfGUnE?t=1110) — [H3] LLM-based analysis pipeline - Key idea: Used local Llama 3.3 with 70B parameters for topic modeling of open-text responses - Evidence: "We created a LLM based topic modeling pipeline using a local llama 3.3 instance with 70 billion parameters" #### ⏱️ [22:00](https://youtu.be/Pfm_-PfGUnE?t=1320) — [H2] Survey response statistics - Key idea: Response rates of 3.1% and 11.8% for sequential surveys, answers averaged tweet-length - Evidence: "Response rate of 3.1% which is pretty good in these qualitative research area" #### ⏱️ [25:45](https://youtu.be/Pfm_-PfGUnE?t=1545) — [H3] Pipeline robustness validation - Key idea: 30 iterations showed 90% semantic consistency, human experts rated 75% of topics as high quality - Evidence: "77% for the donation platform URL survey agreed that 75% of these topics met all three quality criteria" #### ⏱️ [28:30](https://youtu.be/Pfm_-PfGUnE?t=1710) — [H1] Key research findings - Key idea: Mixed motivations, GitHub dominance for visibility, technical barriers prevent adoption - Evidence: "Motivations to link these donation platforms are mixed, ranges from altruistic reasons to direct financial incentives" #### ⏱️ [31:15](https://youtu.be/Pfm_-PfGUnE?t=1875) — [H2] Barriers to donation platform linking - Key idea: Technical difficulty, lack of knowledge, skepticism toward monetization limit adoption - Evidence: "Technical difficulty, lack of knowledge and simple oversight as reasons which prevent them to add these links" #### ⏱️ [33:00](https://youtu.be/Pfm_-PfGUnE?t=1980) — [H3] Recommendations for improvement - Key idea: Improve visibility, guidance, and lightweight validation to reduce friction - Evidence: "Improving the visibility guidance and implementing lightweight validation on PyPI could lower the friction" #### ⏱️ [36:45](https://youtu.be/Pfm_-PfGUnE?t=2205) — [H2] Questions and discussion period - Key idea: Discussion about data quality, repo migration effects, and funding amounts raised - Evidence: "Question about if the project had changed and you were looking at an unmaintained repo" #### ⏱️ [42:30](https://youtu.be/Pfm_-PfGUnE?t=2550) — [H3] Practitioner guide development - Key idea: Converting academic research into practitioner-friendly format following CHAOSS standards - Evidence: "We took the paper and pulled out key points and rewrote it for less of an academic audience" ## 📚 References - [CHAOSS Project](https://chaoss.community/) - [Research Paper - Donation Platform Linking](https://example.com/paper) - [Linux Foundation Open Source Summit CFP](https://events.linuxfoundation.org/open-source-summit-north-america/) ## 🗣️ Paraphrase - CHAOSS working group experienced leadership transition with Adrian joining as co-chair bringing Linux Foundation research expertise - Alexandros presented mixed-methods research revealing that Python package maintainers face technical barriers and lack guidance for linking donation platforms - The group is developing practitioner guides to make academic research more accessible to open source project managers and funders ## 📰 Newsletter The CHAOSS Funding Impact Working Group continues advancing our understanding of open source sustainability! Fresh research from Alexandros reveals why only a small percentage of Python packages link to donation platforms - citing technical barriers, lack of guidance, and skepticism toward monetization. The findings suggest simple improvements like better visibility and lightweight validation could significantly increase funding accessibility. The group welcomed Adrian from the Linux Foundation as new co-chair, bringing quantitative research expertise to complement their measurement methodology development. They're also converting academic research into practitioner-friendly guides to help project maintainers and funders apply these insights effectively. Resources: [CHAOSS Community](https://chaoss.community/), [Linux Foundation Research](https://www.linuxfoundation.org/research), [Open Source Summit](https://events.linuxfoundation.org/) ## ✅ Action Items #### OSPO - Policy & Governance: Review donation platform linking policies for internal projects, establish guidelines for financial transparency - Software Inventory: Assess which maintained packages lack donation platform links, prioritize critical dependencies - Developer Support: Create guidance templates for adding funding metadata to package registries - Community Engagement: Evaluate funding transparency requirements for supported upstream projects #### Community - Maintainers: Implement lightweight validation for donation platform URLs, provide clear guidance on funding metadata - Contributors: Develop onboarding materials explaining funding transparency and sustainability practices - Sponsors: Create transparent reporting on which projects receive funding support and impact measurement #### WordPress - Core: Assess plugin directory funding metadata quality, consider implementing donation platform validation - Community: Develop meetup content about sustainable funding models and transparency practices - Documentation: Create guides for plugin developers on funding platform integration best practices ## 🧪 Hypotheses - Technical friction and poor guidance significantly limit adoption of donation platform linking among package maintainers - GitHub's visibility advantages create platform lock-in effects for funding-related metadata despite multi-platform publishing - Lightweight validation and improved UX could increase donation platform adoption rates by 200-300% - Maintainer skepticism toward monetization correlates with employer compensation and organizational policies ### 📊 Methodology - Survey design comparing random sampling of 50,000+ Python package maintainers with sequential follow-up targeting - LLM-based topic modeling using Llama 3.3 70B with 30-iteration robustness testing and human expert validation - Mixed-methods approach combining quantitative package analysis with qualitative motivation research ### ❓ Questions - How do funding platform adoption patterns differ across programming language ecosystems beyond Python? - What specific UX improvements would most effectively reduce technical barriers to donation platform integration? - How does maintainer funding success correlate with platform choice and metadata quality over time? ### 🔮 Future Research - Cross-ecosystem analysis of funding metadata patterns in npm, Rust crates, Ruby gems, and other package registries - Impact measurement study identifying library subsets that maximize ecosystem funding effectiveness - Longitudinal analysis of funding platform adoption following UX improvements and guidance interventions ### 💡 Implications - Practice: Package registry operators should prioritize funding metadata UX and validation features - Policy: Organizations should establish clear guidance for funding transparency in supported projects - Security: Outdated funding URLs create potential attack vectors and undermine trust in funding platforms - Education: Developer education programs should include sustainable funding and transparency practices - Funding: Grant makers should consider funding metadata quality when evaluating project sustainability ### 🧠 Learning Styles Assessment Reading level estimate: 14.2 Flesch-Kincaid Grade Level #### 👀 Visual learners - Present: Charts showing GitHub dominance, response rate statistics, topic modeling pipeline diagrams - Improve: Add funding platform comparison matrices, maintainer journey flowcharts, ecosystem health dashboards #### 🔊 Aural learners - Present: Video recording with clear narration and discussion period - Improve: Provide audio summary of key findings, podcast-format discussion of implications #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, analogies to traditional software distribution - Improve: Add glossary of funding platform terminology, story-driven examples from maintainer experiences #### 🧩 Kinesthetic learners - Present: Step-by-step methodology description, survey design process - Improve: Interactive checklist for implementing funding platform links, hands-on package analysis tools #### 🧠 Logical learners - Present: Clear research questions, statistical validation, systematic methodology - Improve: Decision trees for funding platform selection, cost-benefit analysis frameworks #### 🧑‍🤝‍🧑 Social learners - Present: Working group discussion format, collaborative research presentation - Improve: Peer review processes for practitioner guide, community discussion forums #### 🧘‍♀️ Solitary learners - Present: Written research paper, individual analysis and reflection time - Improve: Self-assessment tools for funding transparency, personal action planning worksheets #### 🌿 Naturalistic learners - Present: Ecosystem-level analysis, organic community patterns - Improve: Sustainability metaphors, lifecycle thinking about project funding ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive link text for references - Improve: Add alt text for charts and diagrams, ensure table headers are properly marked #### Keyboard navigation - Present: Standard video controls accessible via keyboard - Improve: Add timestamp navigation shortcuts, ensure all interactive elements are reachable #### Contrast and readability - Present: High contrast slides with readable fonts - Improve: Verify 4.5:1 contrast ratio for all text elements, increase font sizes for data labels #### Text resizing and reflow - Present: Slides maintain readability when zoomed - Improve: Ensure responsive design for accompanying materials, test at 200% zoom #### Media and captions - Present: Video with clear audio and transcript provided - Improve: Add closed captions, provide downloadable transcript with timestamps #### Forms and interactions - Present: Standard video player controls with labels - Improve: Add aria-labels for custom controls, ensure error handling for broken links ### 🌍 DEIB Assessment #### Cultural breadth - Present: International research collaboration, global open source perspective - Improve: Include funding patterns from non-Western ecosystems, multi-language platform analysis #### Inclusive language - Present: Professional academic tone, defined technical terms - Improve: Avoid assumptions about employment status, recognize diverse contribution models #### Neurodiversity support - Present: Clear structure with logical flow, consistent formatting - Improve: Add visual breaks between sections, provide content summaries #### Representation - Present: Academic and industry perspectives represented - Improve: Include voices from different project sizes, funding models, and geographic regions #### Psychological safety - Present: Respectful discussion of funding challenges and barriers - Improve: Acknowledge different comfort levels with monetization, avoid judgment about funding choices ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear hypothesis testing from quantitative observations to qualitative investigation - Inductive strength: Pattern recognition from survey responses to broader ecosystem implications - Causal reasoning: Identifying technical barriers as causes of low adoption rates - Analogical strength: Comparing funding metadata to other package registry quality issues #### Fallacies - Sampling bias: Acknowledged limitation that small sample may not be fully representative of maintainer population - Survivorship bias: Analysis may miss projects that stopped maintaining donation links entirely #### Tone of voice - Overall tone: Academic but accessible, collaborative research presentation with humble acknowledgment of limitations ### 🛡️ DARVO Analysis - Deny: No denial patterns observed - research acknowledges limitations openly - Attack: No attacks on subjects - respectful treatment of maintainer perspectives and constraints - Reverse victim/offender: No victim/offender dynamics present in research context - Emotional cues and rhetoric: --- ## Full Transcript [00:01] Okay, welcome everyone to the February [00:04] 11th funding impact measurement working [00:07] group. Uh, as always, the working group [00:10] is under the chaos code of conduct. So, [00:12] keep that in mind and please be kind to [00:15] each other. Uh, we have a few things on [00:18] the agenda today. Um, starting so we [00:21] have a we have a co-chair's update and [00:22] then uh, Alexandra is going to talk [00:25] about um some of some research. So [00:29] that'll be interesting. And then we have [00:31] a couple of other agenda items if we if [00:33] we have time um towards the end about [00:36] FASDM and then the practitioner funding [00:38] impact measurement practitioner guide. [00:42] Um with that I think uh Paul did you [00:46] want to did you want to take over and [00:47] facilitate since you've got the the [00:49] first bet? [00:51] >> Yep. Happily uh we'll do. Um so we have [00:55] an update from our side um which is I [00:58] think a combination of let's say some [01:00] sad news but also some very good news. [01:03] Um so um we've seen a bit of a change in [01:08] uh the formation of our co-chairs. Um [01:12] Kalian Osborne has uh left because he [01:15] started a new position um that will take [01:18] up a lot of his time. Uh and so Dawn and [01:21] I um uh were left with uh thinking about [01:25] who we'd like to join um uh as another [01:29] co-chair. Um and we invited Adrian who's [01:32] with us today um who is very kindly [01:35] accepted to join which we're very [01:37] thrilled about and excited about. Um [01:39] it's obviously a very natural fit um [01:42] given uh Adrian's position at uh LF uh [01:46] as director of quantitative research and [01:48] also past involvement um presenting work [01:51] on multiplier effects uh with NGI [01:55] comments. Um I'll give over the um uh [01:59] the space to Adrian in just a second to [02:02] say a couple of words. But before that, [02:04] I wanted to share um a message from Kon [02:08] uh who very kindly recorded a little [02:10] farewell um which means that we're going [02:12] to be in the interesting position of [02:14] playing a recording from Jity on Zoom [02:18] that is itself going to be recorded. So [02:20] we're going to have several layers of [02:21] sort of abstraction here and let's see [02:22] how the video quality holds out. Um but [02:25] yeah, I'll share my screen and uh let [02:28] Kian say a few words and then I'll hand [02:30] over to you Adrian. Um [02:33] okay, hope you can all hear this. [02:42] >> We are not hearing it at all. [02:44] >> Oh no, [02:46] sorry. Bear with me. Maybe what I'll do [02:50] is I might uh [02:53] we'll see if I can post this in the chat [02:55] somehow. [02:56] >> Yes, sure. [02:57] >> That might be better. Sorry about that. [03:01] >> No worries. [03:02] >> Okay. Well, in that case, I'll hand over [03:04] to you Adrian. Apologies for the [03:05] technical difficulties. [03:07] >> No worries. No worries. Um just as the [03:09] first thing, thank you so much Don and [03:10] Paul for um thinking of me and it's it [03:14] is really a great opportunity. I was [03:15] selling to them um already that um this [03:19] working group has given me a lot of [03:21] motivation actually and and was very [03:23] beneficial to the work that I'm doing at [03:25] NGI comments. So thank you for that and [03:27] circuit and Alexandra both um were very [03:30] active members of this and um helped a [03:33] lot even until now. So now now I'm very [03:36] excited to continue this as co-chair and [03:39] hopefully collaborate with all of you um [03:41] invite interesting speakers and discuss [03:44] much more about the impact of funding. [03:48] >> Hi Jer. [03:50] >> Very cool. Thank you for that Adrian and [03:52] yeah welcome aboard uh from everyone. Um [03:56] wonderful. Um I think with that um uh we [04:00] will turn to Alexandros [04:03] um to present uh his latest uh research [04:07] project. Um I think for those of you who [04:10] were with us last year, you'll remember [04:11] that Alexandros presented um last [04:14] autumn. Uh and as a bit of a followup, [04:17] so with that, I'll hand over to you [04:19] Alexandros. [04:21] >> Thank you very much. Um [04:24] let's see. [04:27] to make the screen share work. [04:41] Does that work? [04:44] >> Yep. We're seeing you [04:46] slides. [04:48] >> All right. Um yeah. Uh so thanks uh [04:51] first uh giving me the opportunity to [04:54] talk about this uh second piece uh of [04:58] research I've conducted or I've [05:00] submitted in end of end of January which [05:03] um uh hopefully is uh relevant to that [05:06] group. So um yeah the title of that uh [05:09] work is why authors and maintainers link [05:12] or don't link their Piper libraries to [05:15] good repositories and donation [05:17] platforms. And as we focus on uh the [05:22] funding side or uh the donation platform [05:25] side of this paper uh also the [05:27] presentation um kind of focuses on that [05:30] part um if you want to kind of read up [05:34] the other parts. I also linked the paper [05:37] um also provided um the replication [05:39] package in case you want to um dig into [05:43] the the the pipeline we used for [05:46] analyzing um these answers. So uh where [05:49] does this uh research come from? Um so [05:53] as Paul correctly said this is a [05:55] follow-up on a quantitative analysis [05:58] I've uh presented in October November [06:01] somewhere in autumn correct uh so where [06:04] we analyzed um to what extent pi [06:07] libraries uh link to donation platforms [06:10] on pi and github and um basically uh [06:16] yeah some um suspicious patterns um [06:20] camea came to our mind and we wanted to [06:22] basically understand what's going on [06:24] there. So um the paper is basically [06:28] um following up on some of these [06:31] insights you get from these information [06:34] here in the figures and the quote. Um so [06:37] um first we basically wanted to [06:40] understand uh why people use meaning the [06:44] gray and the orange bar which is [06:47] actually or which is actually pretty [06:50] small. So we wanted to understand why [06:52] they do link to donation platforms uh [06:55] but also uh understand in my opinion [06:58] even more important the big blue part [07:01] why they don't link to donation [07:02] platforms with all the benefits uh we [07:05] are aware of. So these are basically the [07:07] first two questions as we will see uh on [07:09] the next slide. And then here in this um [07:12] next [07:14] um graph uh noting that this is a lock [07:18] scale we saw that basically most of the [07:21] links um were found on uh GitHub [07:25] exclusively. uh yeah uh kind of raising [07:28] the question uh why maintainers [07:31] basically do not provide the information [07:35] on pipi as well given the information [07:39] that they already link their uh their uh [07:42] github repository so they did the work [07:45] linking their github repository but did [07:47] not uh basically make this follow-up [07:50] step to link their donation platform [07:52] which is then provided on github so we [07:54] we we were not sure about this part So [07:56] we wanted to understand this yeah huge [07:58] dominance of GitHub. And then the last [08:02] um question arised from the fact that um [08:06] yeah quite a quite a lot of these GitHub [08:09] sponsors URLs which were either linked [08:11] on Piper or on uh GitHub themselves were [08:14] outdated. um also raising the question [08:16] why people basically uh uh yeah don't um [08:20] use their time or uh update uh these [08:23] URLs uh at all. [08:27] um that came or that led to the foreign [08:30] problem and research questions. As I [08:33] mentioned before, you might wonder why [08:35] do these research questions start with [08:37] three and four and not with one and two. [08:40] And this is basically uh because I [08:43] copied that from the paper. Um meaning [08:46] if you go back to the paper and you try [08:49] to map what you have seen in the [08:50] presentation to the uh paper content, uh [08:53] I wanted to basically uh stay consistent [08:55] there. Uh so um if you read about the [08:59] research questions targeting um the [09:02] repository URLs they would start uh with [09:04] the numbering of one and two. So first [09:07] question as I mentioned is about um the [09:10] question why they do link to donation [09:13] platforms. Second question was then [09:15] about uh the question of this dominance [09:19] of GitHub meaning uh why they did not [09:23] add a URL on pipey but exclusively on [09:26] GitHub. Uh third question was about um [09:29] the GitHub sponsor URLs being outdated. [09:33] And the last question in my opinion one [09:35] of the most important ones here is why [09:38] they are not linking these information [09:42] to provide you some insights about the [09:44] methodology uh we applied here. Um so [09:50] as you probably uh expected uh we needed [09:54] to uh get the contact information of um [09:59] maintainers and authors of Pi packages [10:02] meaning uh we at the point in time it [10:05] was it started in June 24. We basically [10:09] crawled all the packages available on [10:12] the Python package index and then [10:14] extracted the email addresses um from [10:19] these packages uh via an official [10:21] endpoint which are uh voluntarily [10:25] provided by the uh author and [10:27] maintainers of these packages. What we [10:30] then did is basically um in a sequential [10:36] um pattern to create two independent [10:39] surveys targeting these authors and [10:41] maintainers regarding the topics of [10:43] repository URLs and donation platform [10:46] URLs. uh where both of these surveys [10:50] basically um base their questions on [10:53] these quantitative each on the [10:55] quantitative results. Um as we've uh [10:58] seen before, these surveys were were [11:00] then published um between the dates. Um [11:04] you can read here and in total um for [11:07] both of these surveys we got um yeah [11:11] over 1,400 um responses uh to these [11:15] surveys um which break down um to for [11:20] the repository u survey we um contacted [11:24] random randomly 50,000 of these um [11:29] maintainers um where yeah almost 6,000 [11:33] were uh basically not deliverable. Um [11:37] then leading to almost 1,400 uh [11:39] responses um leading to a response rate [11:42] of 3.1% which is pretty good in these um [11:46] yeah qualitative research area. Um we [11:50] also asked basically uh these [11:52] maintainers if uh we would be allowed to [11:55] uh follow up for further uh research. [11:58] And this is then um where we [12:01] sequentially uh uh contacted the [12:05] maintainers regarding the donation [12:06] platform survey uh where we um had the [12:10] allowance of 570 people to recont them. [12:14] uh were only two bounds and we got 67 [12:18] responses um which if you um um consider [12:22] that in isolation is a response rate of [12:25] 11.8%. [12:27] Um if you look at these numbers from the [12:30] perspective of this uh working group, [12:32] it's of course a pity that uh we [12:35] contacted the maintenance in uh that um [12:39] order and not the other way around [12:41] because for uh the first um survey we [12:44] got way more responses as we were [12:47] allowed to um yeah basically recont [12:52] to contact way more um Python [12:55] maintainers. [12:56] Um, regarding the survey in general, we [12:59] use open text questions uh to basically [13:02] capture maintainers motivations and [13:03] barriers beyond [13:06] um predefined answer options. So we [13:08] wanted to kind of um evoke the [13:11] creativity of these maintainers and not [13:14] of list the things uh the the research [13:17] had already in mind or we would come up [13:21] um as options. Um moving moving further [13:25] to the uh basically the analysis and the [13:28] pipeline we used to analyze all these um [13:31] answers. So uh we created a LLM based [13:35] topic modeling pipeline using a local [13:39] llama 3.3 instance with 70 billion um [13:44] parameters. Um we used batch prompting [13:47] to extract these topics um with at the [13:51] end um a topic reduplication step um to [13:56] kind of control granularity of these [13:58] resulting uh topics. Uh we evaluated the [14:01] whole approach um by repeating [14:04] um the pipeline 30 times and then me [14:10] measuring basically the extracted topics [14:12] on based on lexical similarity but also [14:15] semantic similarity um in order to [14:18] identify basically instances where the [14:22] wording has slightly changed in the [14:24] topic but uh the meaning has stayed the [14:26] same. Um and then in the end as [14:30] for um these LLM based topic modeling [14:34] approaches um these traditional [14:36] evaluation [14:37] um mechanisms don't work anymore. Uh we [14:41] also applied or validated our approach [14:44] uh with uh 23 human experts um on [14:48] multiple uh dimensions where we [14:49] basically asked them about [14:52] interpretability, relevance, granularity [14:55] and the duplication of uh the topic [14:58] modeling of the yeah topics basically [15:01] identified from our approach. So uh [15:05] maybe to give you a quick insight about [15:07] the statistics of the survey answers. So [15:11] um for each of the survey we considered [15:15] in the paper we had basically four [15:17] questions. Um what is pretty interesting [15:20] that even though um basically the number [15:23] of responses [15:25] vary significantly between the two [15:28] surveys, the mean character length of [15:30] the answers stayed basically on average [15:34] the same and was also within this [15:38] traditional tweet limit. um which is um [15:42] referred to um as working well with for [15:46] short um phrase uh shortterm [15:51] um topic modeling approaches um [15:55] identified in uh yeah related work. Um [15:59] what is or what what is to note here as [16:02] we focus on the donation platform URL um [16:05] that there are questions especially the [16:08] second and the third um which are not [16:12] answered that much but as I mentioned [16:14] before I think it is especially [16:16] important to understand why people do [16:18] not link these um URLs and um this is [16:22] basically the most answered question as [16:24] well. So um even though uh maybe the the [16:29] the results from [16:31] question two and three should be uh uh [16:34] yeah basically you used with caution um [16:38] the most important um answers to the [16:41] question four are there uh in a in a in [16:44] a pretty decent number. What is [16:47] basically the outcome of this whole uh [16:49] topic modeling pipeline? So um you can [16:53] think about that in the in the following [16:56] uh manner. So you basically get all the [16:58] answers then um you basically pro [17:01] provide the LLM uh with a question a [17:04] prompt which you can uh read in the [17:06] paper if you want and then basically um [17:10] by uh by by using batches of the answers [17:13] um the discovered topics as you can see [17:17] them on the right are identified. And [17:20] this is more or less uh the direct uh uh [17:22] output uh of the pipeline. So I think [17:25] the only thing which uh comes [17:27] differently is that there are [17:28] underscores um in the in the discovery [17:30] topics um uh if you directly consume [17:33] them from the pipeline. But this is [17:35] basically the output you get and then [17:38] you basically can uh can can have these [17:40] uh results for each um question [17:45] separately. um [17:49] uh because of time I would not go [17:51] through each of the questions and each [17:53] of the topic now separately but rather [17:56] discuss our uh takeaways and [17:58] implications for this working group on [18:00] an aggregated level in the end [18:04] um to also give you some insights about [18:07] uh the robustness and the human [18:09] evaluation results um we uh analyze in [18:13] the paper um wanted to to to show build [18:16] these two tables. So what we can clearly [18:19] see is that uh we uh basically create a [18:24] pipeline um which is pretty robust again [18:28] against um the execution of multiple [18:31] runs. So as I said we executed um each [18:34] of each pipeline with the two surveys 30 [18:38] times and um what what was always [18:43] achieved that um the coziness similarity [18:46] meaning the semantic similarity [18:49] um was higher than the jacket similarity [18:52] meaning that there are instances where [18:55] you have some small se uh uh syntactical [18:58] changes in the identified topics. [19:01] But um the semantics actually did not [19:05] change drastically. So uh even uh if you [19:08] execute uh these these these p this this [19:11] pipeline 30 times for uh both um surveys [19:15] you get almost like a 90% [19:19] um of the same results. Um what is also [19:22] pretty promising about the approach is [19:25] um the the the quality the human experts [19:30] evaluated the topics on. Um and what is [19:34] basically uh important to see here is [19:37] this red marked line where uh we first [19:40] ask the human raers um if basically the [19:46] identified topic is um is uh [19:50] interpretable interpretable is fitting [19:53] the question and is basically on the on [19:57] the right granularity meaning um yeah so [20:01] meaning uh it's not too specific and [20:04] actually 77% for the or 75% for the [20:09] donation platform URL survey agreed that [20:13] um 75% of these uh topics basically um [20:17] met all these three uh quality criteria [20:20] and actually only uh a low number of um [20:26] instances were defined as [20:28] uninterpretable or not fitting the [20:30] question or being too specific. There [20:33] were some doubt about um topics being uh [20:38] duplicate duplicates uh which is uh [20:41] basically indicated by this last number. [20:44] What is pretty good um that if you [20:47] basically [20:49] um calculate the interrator agreement [20:51] between all these human raers, you get [20:54] like a a moderate um agreement between [20:58] these uh humans. uh yeah which is uh [21:02] which makes our approach uh and the [21:04] results um pretty confident. [21:08] Moving uh to the last part which is [21:10] probably uh yeah the most important um [21:14] slide for uh this group. So what were [21:17] the key learnings if we focus on um the [21:20] answers and the topics we extracted from [21:24] the donation platform survey. So um if [21:27] we start with the first point the [21:29] motivations to link these donation [21:31] platforms are mixed. So it ranges from [21:34] altruistic reasons supporting OSS and of [21:38] course um the uh basically desire to um [21:42] get uh direct financial incentives or [21:44] support. Um but um we as I said before [21:48] we need to be a bit um [21:52] skeptical or we we need to uh take these [21:55] results a bit with caution as the AD ab [21:58] adaption is pretty rare and as um we [22:02] applied random sampling basically when [22:05] when uh selecting the the authors and [22:08] maintainers uh targeted for [22:11] participation only a small minority in [22:14] the end does include include these uh [22:16] donation platform links meaning that [22:18] these motivations we got here might not [22:21] not be fully representative. Um what we [22:24] saw that donation platforms are often [22:27] added only on GitHub due to higher [22:30] visibility and referral strategy. So [22:33] apparently uh the value on GitHub um for [22:37] the maintainers are higher to place it [22:39] there compared to Pi. Um apparently [22:43] there is um like technical difficult [22:47] difficulty, lack of knowledge and yeah [22:49] simple oversight as reasons which [22:52] prevent them to add these links. Also on [22:54] pipi um there is [22:58] um skepticism towards monetization um [23:01] employer compensation or organizational [23:04] policies or also simply they don't meet [23:06] these things um which limit the [23:09] abduction meaning now uh moving over to [23:12] this part um what are reasons basically [23:14] why maintainers don't add these links [23:17] and what we also saw that donation links [23:19] are missing or outdated due to unclear [23:23] guidance and limited feedback when these [23:27] links break. Um, in my opinion, I would [23:31] particularly give this paper a read [23:34] because it is pretty interesting how the [23:37] results from the repository URL survey [23:41] kind of overlap partly uh with the [23:43] results from the donation platform URL [23:46] survey for example. When looking at [23:48] these metadata quality issues where uh [23:51] yeah, some of these topics are basically [23:54] identified in both of these surveys. [23:57] what are the implications? So um we as [24:01] suggest she made that improving the [24:03] visibility guidance and kind of [24:06] implementing lightweight validation on [24:08] pi could lower the friction and [24:11] normalize the donation platform meta [24:13] data without pressuring maintainers. Uh [24:17] I would like to give uh one note or one [24:20] closing note uh regarding uh these [24:23] suggestions. Um I've recently listened [24:26] to the podcast to a podcast of Andrew [24:28] Nesbbit talking about um his research [24:31] basically on um package metadata also in [24:35] his working group and I am aware uh that [24:39] basically these development life cycles [24:41] of the pack package registry or package [24:45] managers are uh pretty slow but I think [24:49] it's still valuable to know these uh [24:53] informations. how basically for example [24:55] these um outdated URLs could be solved [25:00] by basically hinting um the the [25:03] maintainers by an email or any [25:05] notification [25:07] uh basically how such functionalities [25:09] maybe could um help um these um systems [25:13] in the future. Um yeah maybe as a small [25:17] outlook uh what might be interesting um [25:20] as future contribution to this uh [25:24] working group I uh quickly mentioned it [25:26] I think in the last presentation already [25:29] so I'm working on a impact related study [25:33] to say so so uh what I plan to do is [25:35] basically identifying a subset of [25:39] libraries which potentially maximizes [25:42] the impact on the ecosystem [25:44] um if theoretically being supported [25:47] whatever an impact means uh in that [25:49] situation um I will uh I will I will or [25:53] can read about talk about that uh in the [25:56] future and then what I basically plan to [25:58] do is break down um these subsets who [26:02] basically a maintainer set um who are [26:05] responsible for these libraries and then [26:08] kind of reconnect these libraries also [26:11] to metadata results I've already talked [26:14] talked about um which are basically [26:17] responsible for reachability and so [26:20] portability of these maintainers. So [26:23] maybe quick outlook which uh uh will or [26:26] hopefully will uh come in the future. Um [26:29] yeah, this is basically just one source [26:31] um where uh the Curan paper uh basically [26:36] is based on this um last research. And [26:39] now I yeah want to thank you for your [26:42] attention and I'm happy to answer your [26:44] questions. [26:47] >> Amazing Alexandra, thank you very much [26:49] for that. It's um also really nice to [26:51] see a kind of development of research [26:53] that or to see how the research that you [26:56] presented last year is continuing and um [27:00] without speaking for others in the [27:01] group, it's really great to see it [27:02] develop and kind of build on that. So, [27:05] thank you for coming back as it were. Um [27:09] I uh have a couple of questions myself, [27:11] but um I wanted to open it up to the [27:13] floor if anyone else wants to jump in. I [27:15] think I saw a few in the chat. Um, does [27:17] anyone want to start us off? [27:24] >> Uh, Gerard, please. [27:28] >> Hi. Um, [27:30] it's, um, [27:32] uh, first of all, thank you, Alex, for [27:35] your research. Um, it's quite, um, an [27:41] interesting topic. Um [27:44] but uh I was just having here some [27:48] thoughts about if you have any metrics [27:51] on [27:53] so what percentage of the pipi projects [27:58] that you search [28:00] were actually having their repos [28:04] uh pointing to GitHub [28:07] and what percentage of the active repos [28:11] were actually [28:13] the [28:15] GitHub um repos they were pointing to [28:18] that is uh you had reported some stale [28:22] repos [28:24] so that maybe the project have had [28:28] changed [28:30] uh from using GitHub into something else [28:33] and they forgot to update the pi record. [28:38] Um, and uh, this is important because [28:41] there's a a question about the [28:43] migration. [28:47] >> Sorry, I'm not hearing you anymore. Uh, [28:49] maybe I don't know if it's on my side. [28:55] >> No, I also lost his audio. [28:57] >> Okay. [28:59] >> Hi again. [29:00] >> Now, now, now you're back. [29:02] >> Is it Do you hear me? [29:04] >> Yes. [29:06] >> No. No. [29:07] >> Yeah. Yeah. Yeah. Yeah. Yeah. We can [29:09] hear you. [29:10] >> We can hear you. [29:14] It it was just a question that might [29:17] influence the results is that uh maybe [29:21] the pi records are not updated and [29:24] they're still pointing to an old uh repo [29:28] of the code and that creates [29:32] a sort of an error into your uh analysis [29:36] afterwards. [29:38] So um [29:40] that is your question finished or do you [29:43] want to kind of continue? [29:44] >> Actually [29:46] yes it's finished. This is mainly the [29:49] question. [29:50] >> Okay so regarding the first part um if I [29:53] have an analysis how many of um the [29:58] packages do link to GitHub repositories [30:00] and also [30:02] uh not outdated ones. there is basically [30:07] um a publication only on this part which [30:09] which kind of uh motivates the [30:14] survey for the repository URL which I [30:18] didn't talk now in this in in in this [30:20] presentation but this is part of the [30:22] paper. So there is basically um if I if [30:25] I jump back to to to to to to these to [30:27] these um to these figures, there is [30:30] basically um a similar paper or a paper [30:34] using similar methodologies um like the [30:37] one for the donation platform URLs which [30:40] analyzed at to what extent Piper [30:42] libraries will link to um GitHub [30:45] repositories. We did not include in the [30:47] selection of maintainers [30:49] um whether uh package would be actively [30:53] maintained or not. However you measure [30:55] that. So it's basically um taking the [30:58] emails of the maintainers and then [31:01] having these 180,000 emails. We [31:04] basically took randomly a third um of [31:08] these emails and um basically [31:12] tried to kind of approach so we we [31:16] didn't want to approach only actively [31:18] maintained ones because um I think [31:21] unmaintained or partly maintained [31:23] libraries are also a significant part of [31:25] ecosystem. So we wanted to kind of get a [31:28] broad picture of um maintainers or [31:32] participants for our [31:33] >> Okay, that was not really my question. U [31:37] question is that [31:40] >> if the project at some point had changed [31:43] and so you were looking at an [31:46] unmaintained repo although there was an [31:48] active one elsewhere outside of GitHub. [31:53] >> Mhm. It's a question about the quality [31:55] of data in the pi records. [31:58] >> Yeah. Um so no we so we would have not [32:02] catched if uh there if basically the [32:05] repo which is linked is not the the the [32:09] real one uh which is where the actual [32:12] development is taking place. No we would [32:14] not have able to catch that. [32:16] >> Just so that I can focus one more thing. [32:18] So your um source of data was the [32:25] was pi and not the actual project pages [32:29] if they existed. [32:31] >> Exactly. We [32:33] >> started No, no problem. Just so it was [32:36] clear. [32:36] >> Okay. [32:39] >> Thank you for that. [32:40] >> Zan, do do you want to jump in with your [32:42] question? Um and then maybe at 22 we'll [32:45] do any other business and just use the [32:48] last two minutes in this section. [32:51] >> Uh yeah sure. Um well my question is [32:53] that did we collect any information [32:55] about how much money they raise the ones [32:57] that have the link that's not in the [32:59] research right? uh just my when we read [33:03] about the articles uh on this uh [33:07] maintainers articles about especially [33:09] the ones that have a story about burnout [33:12] that they usually mention that they [33:13] raise very little money etc. So was [33:17] curious about that and then the other [33:18] thing is that I was also reading the [33:20] paper that you mentioned page rank to [33:22] understand sort of the criticality of [33:24] the packages. What was that method? Did [33:28] we talk about it? [33:30] You said that even the 1% of the [33:33] packages have very little uh uh links [33:36] and then you came up that with a page [33:39] rank. What what is that? [33:42] Sorry, I I I think it is not part of [33:45] that paper. I think it was the [33:48] >> maybe somewhere else. [33:50] >> Yeah. So I I posted I posted another [33:52] paper in another working group. Um but I [33:56] think like here in this in here in in [33:59] this paper I did not use the page rank [34:02] for any selection of libraries to be [34:05] honest. [34:07] >> Okay. Um yeah, I'll I'll check the paper [34:10] again. So that was my second question. [34:11] if there's a source for that. [34:13] >> Uh it would be interesting to check [34:15] that. [34:16] >> Yeah. So maybe maybe I'm I'm completely [34:19] confused now, but I'm pretty sure that [34:20] in this paper I did not use any any any [34:23] page rank. If I did I maybe we we get in [34:27] touch um outside but I'm I'm pretty sure [34:30] it was it was not used in that paper and [34:32] maybe you read another work of mine [34:34] where I did use uh the page rank for for [34:37] for for basically pack package [34:39] filtering. [34:41] Okay, I'll I'll write it in the chat. [34:44] >> Yeah, perfect. Thank you. [34:46] >> Great. Um well, first off, thank you [34:48] Alexandra for presenting that. Um I [34:51] might actually ping you with a couple of [34:53] follow-up questions I have myself, but [34:54] uh in the interest of time, um I think [34:57] we'll uh use the remaining five minutes [35:00] to just um wrap up. Um I might actually [35:04] hand over to Dawn if you wanted to talk [35:06] about the um practitioner guide. Um [35:10] please feel free. [35:12] >> Yeah, absolutely. So we we've basically [35:16] been working on a funding impact [35:17] measurement practitioner guide. So this [35:20] is something that the chaos project has [35:22] been doing and these are guides for [35:24] practitioners to um help them understand [35:27] some aspect of open source open source [35:31] projects uh using metrics. So the the [35:34] practitioner guides cover a pretty wide [35:36] range of topics. And so what we did was [35:39] we took the paper, the academic paper [35:42] that um Paul Kalin, I along with Merkco [35:46] presented at [35:48] the OFA symposium um a year and a half [35:51] ago, the one that was in Boston. And so [35:53] I basically took that paper and pulled [35:56] out some of the key points and rewrote [35:58] it for less of an academic audience and [36:00] more of a practitioner audience. So So [36:04] we have this practitioner guide that's [36:05] work in progress. So, what I would ask [36:08] of you now is if you'd like to uh give [36:10] it a read and give us any feedback for [36:12] ways that we can improve the guide, that [36:14] would be that would be helpful. I would [36:16] encourage you to look at a couple of the [36:17] other guides because it's it's kind of a [36:19] very specific format. So, it um it might [36:22] help you to understand what the [36:24] practitioner guides are are supposed to [36:25] look like, but um [36:29] uh but yeah, so it' be really good to [36:30] get your feedback on that. [36:35] >> Great. Definitely. Um I think with that [36:38] we've just got a couple of reminders um [36:40] to wrap up. Um for those who aren't [36:43] aware, there's the uh Linux Foundation [36:46] Open Source Summit in North America. Um [36:49] that's happening in May uh 18th uh to [36:53] the 20th in Minneapolis. Um the call for [36:56] papers um has been extended to February [36:59] 15th. Um so if anyone felt like uh [37:01] applying might be a very good [37:03] opportunity to highlight some of the [37:05] research that we talk about in this [37:06] working group. Um do feel free um [37:09] otherwise I think that's it from our [37:11] side. Any other business? Anything [37:13] anyone wants to share? [37:18] No. Okay. Wonderful. In that case um [37:22] yeah thank you all for being here. Thank [37:23] you again Alexandros for presenting. Um, [37:26] thanks for the great conversation and [37:28] also special thanks to Adrian for [37:30] joining us as new co-chair which we're [37:32] looking forward to very much. Cool. All [37:35] right, everyone take care. See you next [37:37] time everybody. Thank you. Byebye. [37:40] Byebye.  📄 **Full text:** ![[Full Document Contents/Articles/CHAOSS Funding Impact WG, Feb 11 2026.md|CHAOSS Funding Impact WG, Feb 11 2026 by YouTube]] ## Highlights - submitted in end of end of January which um uh hopefully is uh relevant to that group. So um yeah the title of that uh work is why authors and maintainers link or don't link their Piper libraries to good repositories and donation platforms. And as we focus on uh the funding side or uh the donation platform side of this paper uh also the presentation um kind of focuses on that ([View Highlight](https://read.readwise.io/read/01kpb43nfw48zn009h3xk8cdag)) - Tags: 👻 ai highlighted - part um if you want to kind of read up the other parts. I also linked the paper um also provided um the replication package in case you want to um dig into the the the pipeline we used for analyzing um these answers. So uh where does this uh research come from? Um so as Paul correctly said this is a follow-up on a quantitative analysis I've uh presented in October November ([View Highlight](https://read.readwise.io/read/01kpb43ng923r0e63t4x74mnbq)) - Tags: 👻 ai highlighted - then did is basically um in a sequential um pattern to create two independent surveys targeting these authors and maintainers regarding the topics of repository URLs and donation platform URLs. uh where both of these surveys basically um base their questions on these quantitative each on the quantitative results. Um as we've uh seen before, these surveys were were ([View Highlight](https://read.readwise.io/read/01kpb43nheq53qynm0mbefyap4)) - Tags: 👻 ai highlighted - were uh basically not deliverable. Um then leading to almost 1,400 uh responses um leading to a response rate of 3.1% which is pretty good in these um yeah qualitative research area. Um we also asked basically uh these maintainers if uh we would be allowed to uh follow up for further uh research. And this is then um where we ([View Highlight](https://read.readwise.io/read/01kpb43nj9swd01np2g3avrq5w)) - Tags: 👻 ai highlighted - capture maintainers motivations and barriers beyond um predefined answer options. So we wanted to kind of um evoke the creativity of these maintainers and not of list the things uh the the research had already in mind or we would come up um as options. Um moving moving further to the uh basically the analysis and the pipeline we used to analyze all these um ([View Highlight](https://read.readwise.io/read/01kpb43nk5kqn9c0d41wd94tqz)) - Tags: 👻 ai highlighted - which makes our approach uh and the results um pretty confident. Moving uh to the last part which is probably uh yeah the most important um slide for uh this group. So what were the key learnings if we focus on um the answers and the topics we extracted from the donation platform survey. So um if we start with the first point the motivations to link these donation ([View Highlight](https://read.readwise.io/read/01kpb43nnmjnqwsrqvb06btkrs)) - Tags: 👻 ai highlighted