Frederick Reiber
27 October 2026

When graduate workers in Boston University’s (BU) computer science department walked off the job in 2024, they did so not knowing when they would next get a paycheck. Combined with Boston’s high rents and graduate workers’ limited savings, we realized the often limited union strike pay could not cover rent. Instead, we relied on a semi-automated mutual aid redistribution system maintained by rank-and-file workers. In this short provocation, we provide an overview of our system and its challenges, a brief historical account of how our system developed, and conclude with a guide on repurposing our system for future strikes.

Overview

Our system redistributed income from workers currently receiving paychecks to those who were not. Note that we intentionally avoid the term “non-striking workers” or “scabs” as we understood contributing a portion of one’s weekly paycheck as itself a form of participation in the strike, a strategy rooted in our understanding of academic production. In practice, workers donated roughly a quarter of their weekly pay, which was then redistributed to striking workers.

This redistribution was facilitated by locally run Python scripts connected to an SMTP server, with the main process broken into three steps. At the start of the week, organizers sent confirmation emails to each worker designated as a contributor, asking them to respond if their ability to send funds had changed. After a day or two to allow for any needed changes, the organizer then ran a second script matching contributing workers to receiving workers and sending a second round of emails detailing whom contributing workers should send money to, along with how much. Finally, at the end of the week, organizers ran a third script asking receiving workers to confirm that they had received all of their payments, allowing organizers to follow up with any workers as needed.

Initial worker information—including workers’ weekly contribution or required amount, payment mechanism, and a non-workplace email for sharing information—was gathered beforehand through a Google Form and stored locally on an organizer’s system. Additionally, much of the process was automated and thus required relatively little administrative overhead, allowing organizers to focus on developing relationships rather than spending time in spreadsheets. Finally, because there was no central hub of money, workers did not need to worry about finding a sponsor or structure to hold the fund, and a history of all payments was stored for tax purposes or in the event of back pay.

What It Takes to (Not) Work

A key enabling condition for this type of system is the availability of income for redistribution. Graduate workers in computer science are often among the highest paid within the university, and while their compensation still falls short of a living wage, it provides somewhat greater financial flexibility than in other departments. At R1 universities, computer science is also heavily research-oriented: our internal estimates suggest roughly 30 teaching assistants compared to 180 research-funded students. This funding structure creates a particular point of leverage, enabling workers to redistribute income in support of instructors on strike.

Having workers on research assistantships continue fulfilling work duties limits the overall scope of disruption, as much research activity proceeds uninterrupted. However, we assessed that a research strike would be difficult to sustain and, in many cases, unlikely to be the most effective use of collective resources.

A more immediate challenge lies in encouraging workers both to accept redistributed funds and to participate in the system. In our experience, hesitation stems from several factors. For workers not receiving a paycheck, reliance on mutual aid can introduce uncertainty, particularly for those without significant savings. To mitigate this precarity, our system incorporates regular check-ins with organizers—a practice we strongly recommend that future efforts maintain.

Stigma also plays a significant role. Even within academic contexts, workers may perceive mutual aid as akin to “taking handouts,” leading to reluctance despite clear material need. This dynamic was evident during initial data collection, when workers often reported conservatively low estimates of their financial needs.

We also encountered difficulties in getting workers to contribute funds. Beyond the obvious financial constraints, participation was lower in contexts where pre-existing social ties were weak and face-to-face organizing conversations and email chains served as the primary modes of contact. This suggests that redistribution mechanisms are more effective when embedded within strong relational networks. As we discuss next, such tools must be integrated into broader organizing efforts rather than treated as substitutes for them.

Mutual Aid at Boston University

The development and use of our mutual aid system did not emerge from nowhere, nor was it the product of a single individual’s design. Rather, it arose out of necessity: the need to engage in an indefinite, long-haul strike while collectively sharing the costs of our struggle.

Prior to the strike, we had little in the way of a concrete plan for sustaining prolonged action. Although many workers expressed support and a desire for improved conditions, they were often disconnected from strike planning and strategy, leaving decision-making largely to a core group of organizers and workplace activists.

However, once the strike was publicly announced, this dynamic shifted dramatically. Workers—many previously unfamiliar to organizers—began to show up in large numbers, filling our typically sparse conference room with graduate workers. For many, this marked their first meaningful engagement with the graduate union. It was during this initial department meeting that the need to materially support striking workers became clear. Teaching was already widely experienced as a burden for computer science doctoral students, with the strike introducing an additional layer of hardship.

In the aftermath of that meeting, workers—particularly those outside the “typical” organizer cohort—took the initiative to develop what would become our initial mutual aid system. The system evolved through several iterations, with contributions from a wide range of participants, eventually converging on the model described above.

It is critical to emphasize that this system was not the product of any single individual’s labor, but rather of relationships built before, during, and after that initial meeting. These relationships were essential not only for launching the system, but also for sustaining it over time. They became especially important given that, for many workers, the strike and the broader formal union were not always at the forefront of their daily lives. One key lesson that emerged was the importance of fostering a sense of connection—of knowing whom one was supporting within the collective.

The initial implementation of the mutual aid program spanned the full five weeks of the spring semester strike. During this period, we were able to fully support approximately half of the teaching workforce and ensure that no worker willing to strike was prevented from doing so for financial reasons. In the summer semester, we adapted the system to support mathematics graduate instructors, who, unlike their computer science counterparts, carried a substantially heavier teaching load. In total, we mobilized over $60,000 in support across roughly 70 workers within the department.

Recommendations for Implementing Your Own Mutual Aid Network

To help other workers considering implementing a similar system, we created a GitHub repository containing a documented and privatized version of our code. However, we do not recommend simply repurposing our code, as there are a number of design decisions that should be handled collectively and before use.

For instance, we elected to ensure that we had enough funds to cover striking workers ahead of time, and thus our code does not complete if worker needs are not fully met. Additionally, the system matches workers at random, which may introduce social friction, especially when not all workers know one another. Therefore, we strongly encourage workers to first develop a mapping of the conditions of their own struggles and strike, and then fit our provided structure to their needs.

Based on our experience, the core questions for such a collective discussion include:

• How much money is available on a week-by-week basis, and what should the recommended contribution amount be? Note that the recommended amount was often exactly how much people donated.
• How many workers are striking, and what is their total need? Are there enough funds to cover everyone’s total need? If not, how should the available funds be distributed?
• How do we address workers’ hesitation to participate, and how do we balance organizing labor with financial contributions?

The link to the GitHub repository is available here: https://github.com/FreddiSpaghetti/BUGWUMutualAid/tree/master

And the author is available for any questions at:
efreddyr@gmail.com along with Signal upon request