Executive Summary

Key Numbers

Source: BurnRiSc paper (arXiv:2609.19422, 2026-09-16)

Until now the only instrument for measuring burnout was the questionnaire. The widely used Maslach Burnout Inventory is a proprietary tool, and the freely available Oldenburg Burnout Inventory asks about two dimensions, exhaustion and disengagement. Both require the person to write an answer. The contributors most in need of detection do not respond, and the ones who already left are not there to respond. A questionnaire captures only the moment it was administered, so it cannot be run backward across the past either. CHAOSS, the Linux Foundation's open source health-metrics project, defines a burnout metric as well, but specifies it entirely through surveys and interviews.

The question the researchers put is this. Can that questionnaire be approximated from the record contributors already leave in public? So they mapped the Oldenburg inventory's two dimensions onto fourteen signals computable from GitHub. The seven on the exhaustion side include the share of activity outside working hours, the days a pull request takes to reach a merge, and how closely someone's writing resembles phrases that voice exhaustion. The seven on the disengagement side include monthly commit count, review participation, the proportion of pull requests opened and never closed, and whether first-person pronouns run singular or plural. That last one rests on an assumption that as distance from the team grows, "we" turns into "I".

The important design decision is how the scoring runs. Every signal is graded against that person's own past rather than an absolute bar. Contribution volume in open source varies by orders of magnitude, so thirty commits in a month is routine for one person and unusual for another. Each signal therefore becomes two numbers, where the current value ranks among all of that contributor's prior values, and where the slope of the last four months ranks by the same measure, and those two are averaged. A four-month exponentially weighted moving average damps single-month noise, and a sigmoid function pushes the result into a value between 0 and 1. Averaging the two dimension scores gives the burnout risk score for that month.

None of the fourteen weights were assigned by the researchers. An optimization algorithm fit them so that the comparison group, the activity collapse group, and the confirmed cases separate in that order, and the fit was run from four different anchor points so no single starting assumption could drag the result. Off-hours activity carried the heaviest weight, with commit volume behind it. Review participation and pull request rejection rate, at the other end, barely moved anything. Resampling the set 100 times and repeating the procedure left the separation margin steady, and that check is in the paper too. Still, the researchers attached a caveat against discarding the signals that came back light. The sample may simply have held few reviews and few rejections, and in an organization with a heavier code-review culture the same signals could carry different weight.

The signals drawn from text took extra work. A general-purpose sentiment classifier turned loose on a software repository reads words like "kill" and "execute" as hostile. So the researchers fine-tuned a sentiment classifier for this domain. Alongside it they wrote thirty seed phrases per dimension and measured how close a contributor's writing came to them, and a hand check of 90 sampled messages found that roughly two in three of the high-similarity hits were genuine. Sarcasm was the leading source of the misses. A machine does not cleanly separate someone joking that a project is killing them from someone who is actually spent.

The evaluation covers 68 contributors across ten repositories. Repositories qualified only if at least one contributor there had publicly disclosed burnout, because the design needed to compare disclosers and non-disclosers inside the same project. From each repository the researchers took the ten contributors with the most commits, added any discloser who fell outside that ten, reached roughly 100 candidates, then applied the three-year minimum tenure required to compute percentiles, which brought the number to 68. Those 68 split three ways. Ten disclosed burnout directly. Twelve saw monthly activity fall to half or less of its historical peak for at least two consecutive months and had the steepest drops. The remaining 46 are neither.

Lead time on the ten confirmed cases is the paper's central result. A score spiking for a single month is not a signal. Only a run that crosses the threshold and stays above it for three consecutive months counts, dated to the first month of that run. The threshold is not a chosen number either. At 0.412 it falls between the comparison group's peak distribution and the activity collapse group's. Read back across the 24 months before disclosure on that basis, six of the ten produced a signal 6 to 15 months ahead. Admitting the month of the highest score raises it to eight, at lead times of 5 to 16 months. With the lookback window removed entirely and any prior point allowed, all ten cross the threshold at least once, a number far too loose to carry an early-warning claim. Two cases land outside the 24 months, one flagged 40 months before disclosure and the other 52. An alarm that rings five years early is hard to call an alarm. Even so, the paper does not count those two as misses. The timing fell outside actionable range, while the direction held for all ten.

The twelve activity collapse cases came out in a similar shape. Six were flagged 4 to 13 months before the collapse, rising to ten with the peak criterion added. These twelve, however, are not people confirmed to have burned out. Their activity curves bent in a similar way, which is why they were grouped at all, and the authors call the group weakly labeled.

Of the 46 comparison contributors, 35 never crossed the threshold. The other 11 did. The absence of a disclosure and the absence of a collapse is not evidence that nothing happened to those 11, the authors wrote. With the data in hand there is no way to separate someone who went through it without saying so from a score that rang for nothing.

The limits the paper writes down for itself weigh heavier. All ten confirmed cases are people who went through burnout and said so publicly. Whether the same signals appear in a person who burned out silently is untested. The search for cases ran on English keywords, so anyone who spoke in another language or in a private setting never entered the sample at all. There are fourteen weights and ten labels. At this point the paper pins its own result as a demonstration of feasibility rather than validation. In a check that held out one confirmed case at a time and refit on the rest, seven of the ten still sat above the floor. And the thing this score sets out to approximate is the Oldenburg inventory, yet the evaluation never lined the score up against inventory responses. It substituted lead time against disclosure instead, and the comparison with the questionnaire remains future work.

The last two items on the limitations list are of a different kind. One is the AI agent that writes code in a contributor's place. A state where the will has left but the commits keep arriving is now possible, and the problem sharpens once you recall that the two heaviest weights in this framework are off-hours activity and commit count. The other is text. Eight of the fourteen signals come out of commit messages, reviews, and issue comments, and if a language model helps write them, the signal stops measuring that person's habits of speech and starts measuring generated sentences. Which way that bias runs is not yet known. A language model may even out the prose and erase any trace of fatigue, or borrowing someone else's hand may itself mark depletion. Once tools begin leaving the traces on someone's behalf, reading what is left to guess at the person gets that much dimmer.

The paper calls open source close to a worst case for burnout. A maintainer absorbs demand that arrives without limit, with no manager to reallocate the work and no organization positioned to notice the decline. The seat a boss or a colleague would occupy in a company is, in open source, occupied by nobody.

In 2024 the xz Utils incident showed that this gap does not end as one person's misfortune. The maintainer who had effectively been running single-handed a compression library that ships in most Linux distributions was worn down, and had said as much in public. In a June 2022 message to the mailing list, the maintainer answered that interest had not been lost, but that the ability to care had been fairly limited, mostly due to longterm mental health issues. That reply drew prodding to hand the maintainership over, phrased as a suggestion to recognize one's own limits. As came out later, the accounts sending the prodding were not ordinary contributors but names that appear to have been moving in step with an attacker who had spent more than two years posing as a diligent contributor. Three weeks later the maintainer described that attacker as practically a co-maintainer already, and by the following year the project's outward contact address had moved to that side as well. The backdoor was planted on top of the access obtained that way. It stopped short of reaching the major distributions only through a coincidence. An engineer running micro-benchmarks on unrelated software needed a quiet machine, noticed that ssh logins were burning surprising amounts of CPU, and pulled the thread. The login timings published with that report ran 0.299 seconds on a clean system and 0.807 seconds on a backdoored one.

Set against that incident, the appeal of an early warning is plain. Had anyone known back then that the risk score on that repository had been climbing for months, the answer might have been to find people to share the load rather than to press for a handover. The paper's argument that burnout belongs to software sustainability stands at this point. The incident carries an inverted lesson of its own. In xz, the side that first read the maintainer's state off public traces was not anyone trying to help, but the side looking to use that state as leverage.

One step further along that appeal, the next question arrives immediately. Who sees that the score went up? The contributor seeing it, the project's leadership seeing it, and the company that employs them seeing it are three entirely different things. The paper has an answer to this question.

The conditions the researchers set down in the discussion section run three layers deep. First, this score is not a diagnostic tool. A high score should prompt concern, not a conclusion. Second, any real use has to pair a flag with a cheap, non-judgmental response. Not a formal report and not an intervention procedure, but the contributor reflecting on how they are feeling and taking a break if warranted. The third is the most explicit of the three. This framework should not trigger an evaluation initiated by someone else, the paper says.

A practical rationale comes attached to that third condition. Once people learn that their behavior affects their standing, they hide the behavior. A developer who knows that a 3 a.m. commit gets reported to a manager writes at 3 a.m. and pushes in the morning. The signals the framework leans on then disappear, and the help those signals were meant to surface disappears with them. In the paper's own words, the goal is to identify people who need support, not to penalize them for needing it.

These conditions carry no guarantee once they leave the researchers' hands. On a second reading, most of the fourteen signals are not specific to open source. When someone worked, how much they turned up in review, whether they finished what they opened, whether their writing got shorter and flatter. These already pile up in internal git repositories, issue trackers, and messaging tools. One thing does differ from open source. Company logs were never public to begin with, and no employee ever considered them published.

Products that read employee activity to infer state are already on sale. The recent practice attaches a word like insight or wellbeing rather than monitoring. In a survey the Chartered Management Institute in the UK put to more than 900 managers in September 2025, about a third of organizations were running tools that look at login times, browser history, and email. Just over half of managers approved and 42% opposed, and the most common reason among opponents was that it undermines trust. In March 2026 came a report that a large investment bank was gathering junior employees' keystrokes, video calls, and scheduled meetings to estimate weekly workload. The bank's explanation deserves attention. The tool "is about awareness—not enforcement," the bank said, comparing it to the weekly screen time summary on a phone, and added that it is "designed to support transparency, wellbeing, and encourage open conversations about workload," and that it will not be used for evaluation. That is nearly the sentence the paper set as a condition. Catching burnout and managing attendance are that easy to tell apart in words, while the procedure of scraping logs and assigning a score is identical for both.

One item of future work sits in the paper's final paragraph: developing the ethical framing the paper sketches. The reason given is that inferring psychological state from public traces raises questions of consent and appropriate use. The people who built the technique said first that the conditions for it are less ready than the technique.

A distinction we lean on often in talking about data quality catches here too. A value existing, and a value carrying with it what it was made for and under what conditions, are two different states. A commit timestamp is a value stamped to record when code entered the repository. Gathering those values to estimate a person's mental state is not the original purpose. Using data past its collection purpose requires separate grounds, and the person on the receiving end has to know about it.

An organization moving to turn collaboration logs into judgments about people has a few things to settle before it starts. All of them are matters of documentation rather than technology, so settling them first costs almost nothing, and settling them later is not possible.

• Who can see the score. The person only, or managers as well. Is that boundary written down anywhere.
• What starts automatically when a score comes back high. If nothing starts, that has to be written down too.
• Whether someone can say they want out of the computation. What guarantees that a person who opts out is not penalized for it.
• Whether the list of logs feeding the input is published. Whether an employee can trace back the basis of their own score.

This study stands right now as a hypothesis, not a tool. Sixty-eight contributors and ten confirmed cases, and the ones who judged it that way are the authors themselves. But the time it takes a company to build something similar out of its own logs may be shorter than the time it takes the hypothesis to become a tool. Making a score accurate and deciding how far the score may be used are separate jobs, and only the first one is moving quickly right now.

Thank you for reading this far. The facts this article cites can be checked by anyone in the BurnRiSc paper and in the code repository the authors released. We would be glad to hear where your organization draws the line when collaboration logs get turned into judgments about people.

Academic paper & public materials

• 1.Sanko, T., Tian, Y., Guizani, M. (2026). "BurnRiSc: Toward Non-Invasive Burnout Screening in Open Source from Public Repository Signals." arXiv:2609.19422.
• 2.RISE Lab, Queen's University (2026). "RISElabQueens/BurnRiSc." GitHub — supplementary code, weight vectors, and per-repository statistics.

xz backdoor primary sources

• 3.Freund, A. (2024). "backdoor in upstream xz/liblzma leading to ssh server compromise." oss-security mailing list, 2024-03-29.
• 4.Cox, R. (2024). "Timeline of the xz open source attack." research!rsc.

Industry & press coverage

• 5.Soliman, I. (2025). "Third of UK firms deploy 'bossware' to track staff activity, survey reveals." People Management, 2025-09-17.
• 6.Burleigh, E. (2026). "JPMorgan has started monitoring the keystrokes, video calls, and meetings of its junior investment bankers." Fortune, 2026-03-24.