Would a software development project be successful if everyone on the team spent their workday working on feature development? No, it would not.
Developing and maintaining a large-scale software system requires a gamut of efforts, some of which are visible, like feature development or code commits, others, like onboarding newcomers, responding to user queries, closing duplicate bugs, or helping peers, are less so, but equally important.
Such GLUE WORK–contributions that are critical to a project’s health–have been recognized as something that “brings the community together.” In some cases, GLUE WORK is recognized informally; It’s such a good feeling to have people come and recognize you. And it’s not just me, it’s the entire team” But, more often it remains unacknowledged. “No one values GLUE WORK contributions”. “I think they don’t get enough credit at times”.
These observations are not just anecdotal. They are grounded in a cross-community study involving over 200 OSS practitioners across ecosystems, including foundation-led projects, corporate-sponsored projects, and scientific communities. As shown in Fig 1, contributors participated through interviews, focus groups, and surveys, sharing firsthand experiences. Read the full Academic Paper for a deep dive into our methodology and cross-community findings.
Why GLUE WORK Is So Hard to Measure?
First, open source culture still heavily emphasizes visible code contributions. Commits and features are easy to point to, count, and celebrate. Maintenance, mentoring, and coordination are treated as background work, even though projects cannot function without them.
Second, GLUE WORK happens across many different spaces. It lives in issue comments, chat platforms, mailing lists, CI/CD logs, documentation, conferences, and social media. Most metrics focus on repositories alone, which means much of this work never shows up.
Third, many communities lack shared norms for acknowledgment. Even when people notice GLUE WORK, they may not know how or where to recognize it consistently. As a result, contributors doing this work often feel undervalued, leading to burnout and attrition.
We have developed a taxonomy of GLUE WORK to help OSS communities understand what it is, where to track, and how to acknowledge it by using the invisible labor theory from Hatton as an analytical lens [1] .
What is GLUE WORK in OSS?
Across OSS ecosystems, GLUE WORK can be categorized into four broad groups (see Fig 2, first column).
Code and Technical Management: This includes maintaining existing code, reviewing pull requests, writing tests, managing licenses, and responding to security incidents. These activities rarely result in flashy new features, but they are what keep projects stable, secure, and usable over time.
Mentoring and Support: Mentoring newcomers, answering questions, helping contributors navigate project norms, and providing end-user support are some of the most impactful contributions in open source. These efforts lower barriers to entry and play a major role in whether contributors stay.
Documentation: Writing and maintaining documentation, such as READMEs, tutorials, guides, and translations, makes projects accessible and inclusive. Much of this work is done by non-code contributors, yet it often goes unnoticed despite requiring significant effort.
Community Management: This includes governance, coordination, outreach, advocacy, and event organization. These contributions shape the social and organizational backbone of projects, but they are often invisible unless something goes wrong.
We have built an interactive Glue Work Community Diagnostic Board where you can explore these categories, vote on their impacts, and suggest new tracking methods.
Where Can We Track GLUE WORK?
GLUE WORK is not really invisible if you want to track it. In practice, most GLUE WORK does leave digital traces. These traces are often fragmented across multiple tools and spaces, and making them visible requires deliberate effort. You can start tracking GLUE WORK by expanding your view beyond code repositories (see Fig 2, second column, for the different channels where it leaves traces). At the same time, it is important to recognize that “traceability” does not automatically make GLUE WORK easy to measure, ethically safe to analyze, or straightforward to interpret. Below, we outline both where GLUE WORK shows up and what makes tracking it hard (and sometimes risky).
Version control and issue tracking systems: Platforms like GitHub and GitLab already capture many forms of GLUE WORK. Code reviews, issue comments, pull request discussions, and maintenance-oriented commit messages often reflect behind-the-scenes coordination: helping others land changes, unblocking work, triaging problems, and keeping the codebase stable. These traces are relatively easy to collect through APIs and repository logs, making them a common starting point for tracking GLUE WORK.
Documentation and project records: Documentation repositories, wikis, release notes, governance documents, contributor lists, and project roadmaps capture significant GLUE WORK. Writing and maintaining documentation, coordinating releases, and recording decisions are all traceable through these artifacts. Importantly, these records often reveal forms of work that sustain the project’s social and technical continuity, even when no new features are being added.
Infrastructure and automation logs: Behind-the-scenes technical GLUE WORK, such as testing, CI/CD maintenance, license checks, dependency updates, security responses, and reliability fixes, often appears in automation logs, pipeline records, and incident or alert histories. These signals are especially important for understanding long-term project health because they reflect ongoing maintenance that prevents failures rather than producing visible new functionality.
Communication platforms: A lot of GLUE WORK happens in conversations. Slack, Discord, mailing lists, and discussion forums capture mentoring, onboarding help, end-user support, and coordination work. These interactions play a major role in contributor experience and retention, yet they are rarely considered in project metrics.
Community events and outreach spaces: GLUE WORK also occurs outside traditional development tools. Conference organization webpages, onboarding sessions, office hours, advocacy, and community outreach often leave traces on event platforms, shared documents, social media, community websites, or video recordings. These traces may be scattered and informal, but they often reflect the work that expands participation and keeps communities welcoming and active.
Privacy, consent, and trust: Tracking GLUE WORK, across any of the above channels, raises important questions about privacy, consent, and trust. Even when traces are technically accessible or public, contributors typically share them with the intent of supporting the community, not to have their actions, conversations, or participation analyzed, aggregated, or turned into performance metrics. This is especially true for relational and situational work, such as mentoring, conflict resolution, or community care, whether it occurs in chat platforms, event spaces, or outreach activities. Analyzing such traces without care can feel intrusive or “big-brother-like,” potentially undermining trust and discouraging participation.
As a result, any effort to account for GLUE WORK should prioritize ethical data practices: treating traces as personal data when appropriate, minimizing collection, avoiding individual-level exposure, focusing on aggregated patterns, and being transparent about what is collected and why, including offering clear opt-out mechanisms. The goal is to recognize and support sustaining work, not to monitor individuals.
Power, visibility, and the risk of instrumentalization: What gets measured tends to shape what gets valued. When tracking GLUE WORK relies primarily on visible, countable traces, it can unintentionally reinforce a narrow view of contribution and overlook the relational, care-oriented work that makes communities inclusive and sustainable. In the worst case, surfacing GLUE WORK through simplistic metrics, such as leaderboards or activity counts, can reinforce existing power imbalances by rewarding volume over care, quality, and community impact.
These effects are compounded when tracking is perceived as surveillance rather than support. If contributors feel monitored or evaluated, GLUE WORK may be pushed into private channels, mentoring and helping behaviors may decline, or contributors may disengage from sustaining work that is difficult to justify under metric pressure. For tracking to be constructive, it must be framed as a tool for community learning, reflection, and recognition, not as a mechanism for individual performance evaluation.
How Can We Acknowledge GLUE WORK?
Tracking GLUE WORK is only a first step. Making sustaining work visible does not automatically mean contributors feel recognized or valued. Acknowledgment matters because it signals what a community cares about and whose work it notices. When GLUE WORK goes unacknowledged, contributors may still feel invisible, even if their efforts are technically traceable.
Acknowledgment does not need to be complicated or highly formal to be meaningful. What matters most is that recognition is visible, consistent, and aligned with community values. At the same time, acknowledgment practices shape norms and power within a project, and therefore need to be applied thoughtfully rather than mechanically.
Based on our observations across OSS projects, we outline three acknowledgment practices demonstrated in OSS communities that other projects could readily adopt with minimal effort.
Documentation-based acknowledgment: One of the simplest approaches is to acknowledge contributors in project documentation. Contributor lists, release notes, changelogs, and project websites can include not only code authors, but also reviewers, mentors, documentation writers, community organizers, and support contributors. Making these roles visible in project artifacts helps signal that sustaining work counts as part of the project’s success, not as peripheral or optional labor.
Communication-based acknowledgment: Publicly thanking contributors in everyday communication channels is powerful. Pull request comments, issue threads, mailing lists, Slack messages, and community meetings all provide opportunities to recognize GLUE WORK as it happens. Even a simple “thank you for taking the time” can strengthen a sense of belonging.
Announcement-based acknowledgment: Some projects highlight GLUE WORK through broader community announcements, such as newsletters, social media posts, release announcements, or blog posts. When done carefully, these acknowledgments can broaden shared understandings of what it means to “contribute” to the project.
By now, we have outlined what GLUE WORK looks like in OSS, where it leaves traces, and why it is so often overlooked by feature-centric metrics. Together, these perspectives help surface the breadth of sustaining work that keeps projects running, communities welcoming, and contributors engaged.
Join the Initiative. We are building a community-driven database to make the invisible visible.
- Visit the Glue Work Board to help us define consensus on how this work should be tracked.
- Download the Research Report to share these findings with your own community or foundation.
Reference:
[1] Hatton, E. (2017). Mechanisms of invisibility: rethinking the concept of invisible work. Work, employment and society, 31(2), 336–351.
