Report back from CSCW 2026

@groceryheist, @yiweiwu, @kaylea, and @mako attended CSCW 2026 from Oct 10 through Oct 14. A previous blog post covers our presentations. Here we’re sharing some takeaways and highlights from the conference. I (Nate) wrote this post, so it naturally reflects my views most, but I’m also drawing on my conversations with the other CDSC attendees.

Takeaways from OSS + AI Workshop

Kaylea Champion, Benjamin Mako Hill, and Matt Gaughan helped organize a CSCW workshop on Open Source Software and artificial intelligence, and Kaylea, Mako, and Nate attended. The workshop was conceived and framed as a conversation focused on problems open source practitioners have raised related to building sustainable collaborative software projects in the open. However, I was both astonished and energized by how workshop participants’ focus seemed to shift toward more foundational and future-looking questions about the nature of collaboration and its role in software production in the first place. Kaylea shared how the OSS developers she has interviewed recently are using AI intensively and enthusiastically, and Mako seemed joyous at the fun he’s been having contributing in previously unimagined ways to projects like LaTeX. But even though AI seems to make open source developers more productive, it also raises the question: what makes code worth sharing at all? Nate shared how he’s used Claude Code to create a bespoke application for data annotation, and then three other attendees described doing the same thing. Should we share these software projects, even if they are idiosyncratic? How do ubiquitous AI tools change the role of open software and knowledge commons when the value of a project shifts from its code or features (which may be easy to replicate) to its reputation, trustworthiness, ubiquity, or role in a project ecosystem?

Mako, building on insights he also shared in a presentation at UT Austin in September about his new book Peer Production in the MIT Press Essential Knowledge Series (co-authored with Aaron Shaw and Christian Pentzold; available open access here), described a potentially deeper threat AI poses to Open Source now that Open Source developers are using AI coding tools. If I use a “frontier” agent to write a patch, and it generates buggy or otherwise inadequate code that I fix, it sends my corrections back to its company, which can use this information to train the next model version. In this way, AI agents collect knowledge from open source developers and aggregate it into new models, which their companies can then sell back to open source developers. This distributed production of knowledge, which is then aggregated and disseminated, resembles a peer production process, only the aggregate artifact is a private good (although distillation of open-weight models may transmit some of this knowledge into a commons in some sense). A CSCW poster by Caitlin Morris and Pattie Maes presented a system that I found really interesting for envisioning future modes of knowledge sharing among collaborators using AI tools.

Notes from the Lasting Impact Award

The question “what’s CSCW’s role in AI research?” was asked in one form or another in panels and conversations at CSCW 2026. Does CSCW need to jump on the AI bandwagon and study industry-facing problems? Maybe, but what makes that different from mainstream AI or NLP research? Should CSCW focus critically on social problems related to AI? Certainly, but that work also happens at FAccT among other conferences. What does CSCW have to contribute that other fields wouldn’t? Surprisingly, I found one of the most compelling answers in Nikki Kittur’s presentation at the session on the lasting impact award he received with Robert Kraut for their 2008 paper “Harnessing the wisdom of crowds in Wikipedia: quality through coordination“. Mako was also on the panel, and in his discussion he pointed out the same thing that impressed me from Nikki’s talk.

Nikki showed how the concepts of implicit and explicit coordination he and Kraut introduced in 2008 for understanding Wikipedia are useful for designing tools that use AI to support collaborative workflows in ways that just prompting a chatbot or agent can’t achieve. The more general answer, which I find inspiring, is that CSCW has built a rich base of concepts that can be productively applied to create new understandings of how AI can be designed, built, and used collaboratively. Nikki’s talk showed how engaging concepts from CSCW’s legacy can lead to novel research ideas, and I think such scholarship has a disciplinary character that can earn respect and distinction in a way that bandwagoning rarely does.

Highlights from paper sessions

Here are a few paper presentations by people outside CDSC we thought wroth highlighting. There’s one pick from each of us who attended. I (Nate) have lightly edited the others’ descriptions.

Nate’s pick: People Can Accurately Predict Behavior of Complex Algorithms That Are Available, Compact, and Aligned by Lindsay Popowski, Helena Vasconcelos, Ignacio Javier Fernandez Heinsen, Chijioke Mgbahurike, Ralf Herbrich, Jeff Hancock, and Michael S. Bernstein. https://doi.org/10.1145/3788067

This paper’s title is a great description of the findings and central contribution. The problem of designing algorithmic systems to make them less opaque and confusing is usually framed as making AI “explainable” or “interpretable”. This framing centers the model and seemingly constrains the solution space to the problem of making the inner workings of complex mathematical models comprehensible to end users.

I love how this paper reframes this problem from computational complexity to cognitive complexity in terms of a user’s ability to construct a valid intuition for the model’s behavior. Then they show that this sort of problem, which also seems closer to what many use cases actually need, is solvable by models that are good at one comprehensible and useful thing. This is a really cool example of positivist HCI research that conceives a theory by drawing from HCI and cognitive science and then tests it in a straightforward experiment.

Kaylea’s pick: The Persistence of Retracted Papers on Wikipedia by Haohan Shi, Yulin Yu, Daniel Romero, and Emőke-Ágnes Horvát https://doi.org/10.1145/3817014

Kaylea wrote: It takes a (very) long time for retracted papers to get removed from Wikipedia, and the problem is worse for highly-cited papers but better for open access papers. I suspect that journals and academics can do more to set the record straight when retractions happen.

Mako’s pick: Creating Group Rules with AI: Human-AI Collaboration in WhatsApp Moderation by Gauri Nayak, Farhana Shahid, Kiran Garimella, and Aditya Vashistha. https://doi.org/10.1145/3816915.  

Mako wrote: A speculative design paper that worked with 20 WhatsApp admins to use an AI to generate rules. It’s an interesting experiment that I think challenges some things the CDSC work on rules has taken for granted and that uses methods extremely different from those we would use to approach the problems. The work points to a range of interesting future research directions for rule researchers.

Yiwei’s pick: The Activist’s Guide to the Decentralized Social Universe by Sybille Légitime and Harini Suresh. https://doi.org/10.1145/3817010

Yiwei wrote: I like how the authors of this paper take platform choice as a question of collective action, showing that leaving a platform only works if communities can find somewhere that fits their specific threats and resources.

Sources of Underproduction in Open Source Software

Although the world relies on free/libre open source software (FLOSS) for essential digital infrastructure such as the web and cloud, the software that supports that infrastructure are not always as high quality as we might hope, given our level of reliance on them. How can we find this misalignment of quality and importance (or underproduction) before it causes major failures?

How can we find misalignment of quality and importance (underproduction) before it causes major failures?

In previous work, we found that underproduction is widespread in packages maintained by the Debian community, and when we shared this work in the Debian and FLOSS community, developers suggested that the age and language of the packages might be a factor, and tech managers suggested looking at the teams doing the maintenance work. Software engineering literature had found some support for these suspicions as well, and we embarked on a study to dig deeper into some of the factors associated with underproduction.

Our study was able to partially confirm this perspective using the underproduction analysis dataset from our previous study: software risk due to underproduction increases with age of both the package and its language, although many older packages and those written in older languages are and continue to be very well-maintained.

In this plot, dots represent software packages and their age, with higher underproduction factor indicating higher risk. The blue line is a smoothed average: note that we see an increase over time initially, but the trend flattens out for older packages.

This plot shows the spread of the data across the range of underproduction factor, grouped by language, where higher values are indications of higher risk. Languages are sorted from oldest on the left (Lisp) to youngest on the right (Java). Although newer languages overall are associated with lower risk, we see a great deal of variation.

However, we found the resource question more complex: additional contributors were associated with higher risk instead of decreasing it as we hypothesized. We also found that underproduction is associated with higher eigenvector centrality in the network formed if we take packages as nodes and edges by having shared maintainers; that is, underproduced packages were likely to be maintained by the same people maintaining other parts of Debian, and not isolated efforts. This suggests that these high-risk packages are drawing from the same resource pool as those which are performing well. A lack of turnover in maintainership and being maintained by a team were not statistically significant once we included maintainer network structure and age in our model.

How should software communities respond? Underproduction appears in part to be associated with age, meaning that all communities sooner or later may need to confront it, and new projects should be thoughtful about using older languages. Distributions and upstream project developers are all part of the supply chain and have a role to play in the work of preventing and countering underproduction. Our findings about resources and organizational structure suggest that “more eyeballs” alone are not the answer: supporting key resources may be of particular value as a means to counter underproduction.

This paper will be presented as part of the International Conference on Software Analysis, Evolution and Reengineering (SANER) 2024 in Rovaniemi, Finland. Preprint available HERE; code and data released HERE.

This work would not have been possible without the generosity of the Debian community. We are indebted to these volunteers who, in addition to producing Free/Libre Open Source Software software, have also made their records available to the public. We also gratefully acknowledge support from the Sloan Foundation through the Ford/Sloan Digital Infrastructure Initiative, Sloan Award 2018-11356 as well as the National Science Foundation (Grant IIS-2045055). This work was conducted using the Hyak supercomputer at the University of Washington as well as research computing resources at Northwestern University.

FLOSS project risk and community formality

What structure and rules are best for communities producing high-quality free/libre and open source software (FLOSS)? The stakes are high: cybersecurity researchers are raising the alarm about cybersecurity risk due to undermaintained components in the global software supply chain—much of which is FLOSS. In work that’s just been accepted to the IEEE International Conference on Software Analysis, Evolution and Reengineering (‘SANER’), we studied 182 Python-language packages in the GNU/Linux Debian distribution, examining the relationship between their levels of engineering formality and software risk. We found that more formal developer organization is associated with higher levels of software risk, and more widely spread developer responsibility is associated with lower levels of software risk.

We studied software risk through the underproduction metric initially developed by Champion and Hill (2021). Underproduction is a measurement of misalignment between the usage demands of a software project and the contributions of the project’s developer community. As such, underproduction measures the risk that software will be undermaintained, possibly including a security bug.

Our work examines the relationship between risk due to underproduction and governance formality. We employed measures initially developed by Tamburri et al. (2013) and later re-implemented in Tamburri et al. (2019). These metrics use multiple measures of software project formality — such as the average contributor type, usage of GitHub milestones, and age — to evaluate how formally structured a given project is.

Plot of the relationship between mean underproduction factor and mean membership type (MMT), a metric encapsulating the diffusion of merge responsibility across a project’s developer community.



We used linear regression to conclude that more formal project structures are associated with higher levels of underproduction and thus, increased project risk. We also found that the share of community-members who have merged code into the main development branch is also related to underproduction, with lower levels of underproduction correlated with larger shares of community mergers.

Evaluated together, these two conclusions suggest that operating less formally and sharing power more equally is associated with lower underproduction risk. The development of FLOSS project engineering is a process laden with tradeoffs, we hope that our conclusions can help better inform community decision making and organization.

For more details, visualizations, statistics, and more, we hope you’ll take a look at our paper. If you are attending SANER in March 2024, we hope you’ll talk to us in Rovaniemi, Finland!

—————

The full citation for the paper is:

Gaughan, Matthew, Champion, Kaylea, and & Hwang, Sohyeon. (2024) “Engineering Formality and Software Risk in Debian Python Packages.” In 31st IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER2024) (Short Paper and Posters Track). Rovaniemi, Finland.

We have also released replication materials for the paper, including all the data and code used to conduct the analyses.

This blog post and the paper it describes are collaborative work by Matt Gaughan, Kaylea Champion, and Sohyeon Hwang.

FOSSY Wrap-up Bonus – Eriol Fox on User Research

Welcome to a bonus round of our series spotlighting the excellent talks we were fortunate enough to host during the Science of Community track at FOSSY 23!

Eriol Fox presented their talk, “Community lead user research and usability in Science and Research OSS: What we learned,” (due to scheduling issues, this landed in the Wildcard track, but it was definitely on-topic for Science of Community! Eriol introduced us to their work exploring how scientists and researchers think about open source software, including differences in norms and motivations as well as challenges around the structure of labor. They also brought along copies of their 4 super cool zines from this project!

You can watch the talk HERE and learn more about Eriol’s work HERE.

FOSSY Wrap-Up: CDSC presents Interactive Session — Let’s Get Real: Putting Research Findings into Practice

Welcome to part 7 of a 7-part series spotlighting presentations from the Science of Community track at FOSSY 23!

In this interactive session, Dr. Benjamin Mako Hill, Dr. Aaron Shaw, and Kaylea Champion hosted a series of conversations with FOSS community members about finding research, putting it to use, and building partnerships between researchers and communities!

This talk was (intentionally!) not recorded, but we’ve synthesized the resources we shared into this wiki page.

FOSSY Wrap-Up: Mariam Guizani on Rules of Engagement: Why and How Companies Participate in OSS

Welcome to part 6 of a 7-part series spotlighting the excellent talks we were fortunate enough to host during the Science of Community track at FOSSY 23!

In this talk, Dr. Guizani shared her work to understand the motivation for companies to participate in open source software development, encompassing the perspective of both small and large firms.

You can watch the talk HERE and learn more about Dr. Guizani HERE.

FOSSY Wrap-Up: Shoji Kajita on Research Data Management Skills Development Leveraged by an Open Source Portfolio

Welcome to part 5 of our 7-part series reviewing all the great talks we were fortunate enough to host during the Science of Community track at this year’s FOSSY.

In this talk, Dr. Kajita introduced us to the work being done as part of the Apereo (formerly JA-SIG/Sakai) to create FOSS platforms to serve as academic and administrative infrastructure in higher education. Research data management is a skill that emerging scholars must learn to do modern quantitative research — and this skill can be scaffolded and tracked via the Karuta portfolio tool.

Watch the talk HERE, learn more about Karuta HERE, and learn more about Dr. Kajita HERE.

FOSSY Wrap-Up: Kaylea Champion’s Lightning Talk on Undermaintained Packages

Welcome to part 4 of a 7-part series spotlighting the excellent talks we were fortunate enough to host during the Science of Community track at FOSSY 23!

Kaylea presented on her new research project to identify how packages come to be undermaintained, in particular investigating assumptions that it’s all about “the old stuff” — old packages, old languages. It turns out that’s only part of the story — older packages and software written in older languages do tend to be undermaintained, but old packages in old languages — the tried and true, as it were — do relatively well!

Watch the talk HERE and learn more about Kaylea’s work HERE.

FOSSY Wrap-Up: Anita Sarma’s Lightning Talk on Inclusion Bugs

Welcome to part 3 of a 7-part series spotlighting the excellent talks we were fortunate enough to host during the Science of Community track at FOSSY 23!

Dr. Anita Sarma gave us an excellent introduction to her and her team’s work on understanding how to make FOSS more inclusive by identifying errors in user interaction design.

Matt Gaughan delivered a rapid introduction to his dataset highlighting the numerous places where the Linux Kernel is using unsafe memory practices.

You can watch the talk HERE and learn more about Dr. Sarma HERE.