ComputeShare: An Instrument for Studying Donated Computing

Volunteer computing has worked for thirty years on an odd premise: strangers give away a resource they own, continuously, to research they will never see the results of. Who agrees, how long they leave it running, and what framing of the cause moves either of those, is a behavioural question rather than a technical one.

It is also a question a survey cannot answer, because the interesting variable is not what people say they would give. It is how long the machine actually ran.

An instrument that asks and observes in the same session.

A participant arrives, consents, and reads what the research is for: that IIM Calcutta is collecting and analysing large-scale conversation data from social platforms to understand how misinformation spreads, what makes it travel, and how it moves opinion. Then they work: a short image-labelling task, where the images are tagged by type, shown in a randomised order, and the time spent on each one is recorded to the millisecond.

Then the ask. Will you contribute processing power? That decision is timed too — how long the screen was open before they chose.

What follows is the measure the study exists for. The donation is not a yes or a no. It is a timer the participant starts, can pause, and can stop whenever they like, with the instruction to keep the screen open while it runs. What gets recorded is seconds donated, how many times they paused, and how long the pauses were. Afterwards come a reflection and a background block: device, technical background, familiarity with distributed computing, eight attitude statements on a seven-point scale, and two personality items.

It is the same kind of apparatus as Token Impact, which asks people to give away tokens they earned, and sits on the same intake-and-session pattern as Research Lab. This one asks for something people do not usually think of as theirs to give.

It has not. That is the honest answer and it belongs on this page rather than underneath it.

Fifty sessions have been opened. Every record in every table belongs to a single pilot session I ran myself in November 2025, and the labels in it read “Test”. The one processing session in the database donated zero seconds. There are no reflections and no background responses, because nobody has reached those screens.

The instrument is complete. The study has not been run.

The code I wrote to fix the bug was the bug. Google sign-in failed, and four successive rounds of work made it worse: a check for whether the user was authenticated, then a redirect to login, then an initialising state, then error handling around all of it. None of it helped, because the platform already handled the sign-in flow and every addition interrupted it. The fix was deleting all four. I now treat a growing stack of defensive code around a failing mechanism as evidence that the mechanism is not the problem.

Pilot it twice, from the same browser. A second run from one browser reused the same participant identifier and the same session identifier, so two sessions were a single indistinguishable row. Had the study been fielded before that was caught, every repeat participant would have overwritten themselves. It was found by doing the boring thing twice.

Building the instrument is the easy half. This apparatus is more carefully measured than the one I did field — randomised stimulus order, dwell time per image, pause-level detail on the donation. It has no data. Token Impact is cruder and has a hundred sessions. What separates them is not the software.