In the winter of 2024, a synchrotron beamline at a major national facility shut down for what turned out to be four months of repairs. The closure was announced with three weeks' notice, leaving two research groups—one studying protein crystals, the other imaging soft tissue samples—with thousands of gigabytes of raw data and no way to collect more. They had booked beam time months in advance, paid for it out of grants that expected results, and now faced a choice: wait out the downtime or find a way to make the most of what they already had.

The two labs did not know each other well. They worked on different biological questions, used different microscopes, and had built their own image-analysis pipelines from scratch. But as the downtime stretched on, a postdoc in one lab reached out to a counterpart in the other to ask a practical question about segmentation. That conversation led to a shared repository, a rewrite of both pipelines, and a small but telling example of how research infrastructure failures can force collaborations that grants and incentives rarely encourage.

This article examines how a beamline closure catalyzed a collaboration that produced a shared image-analysis pipeline, and what that tells us about the economics of research software, the hidden costs of duplicated effort, and the unglamorous work of maintaining the code that makes experiments interpretable.

A Shutdown That Forced a Choice

The beamline in question was a high-throughput imaging line used for X-ray fluorescence mapping. It had been running nearly continuously for seven years, with only brief stoppages for scheduled maintenance. When a vacuum leak developed in the sample chamber, engineers initially estimated a two-week fix. That estimate stretched to a month, then two, then four. The facility sent out a notice: no new beam time until further notice, and no guarantees about the schedule.

For the two labs, the immediate problem was practical. One lab, led by a structural biologist, had collected a full dataset of protein crystals that needed segmentation before analysis. The other, a tissue-engineering group, had stacks of images from soft-tissue scaffolds that required similar processing. Both had scripts written by graduate students who had since graduated. Both scripts were undocumented, brittle, and tied to specific file formats from the beamline's older software version.

With the beamline down, there was no new data to collect, so the bottleneck shifted to analysis. A postdoc in the protein-crystal lab had been struggling with her lab's segmentation code for weeks, trying to adapt it to a new file format the beamline had introduced before the shutdown. A colleague mentioned that the tissue-engineering lab had solved a similar problem a year earlier. She emailed them, expecting a pointer to a paper or a script. Instead, she got an invitation to a video call.

On that call, the two labs discovered they had been solving the same problem in parallel for years. Both had written custom Python scripts to threshold images, detect features, and measure intensities. Both had spent months debugging edge cases. Both had documented their work in lab notebooks but not in code comments. The tissue-engineering group had even written a small library for handling TIFF stacks, but it was buried in a private repository and barely used outside the lab. The call ended with a decision: instead of continuing to patch their separate pipelines, they would merge them into one shared codebase.

The choice was purely practical: with the beamline down, the only way to make progress was to stop duplicating effort and start sharing. Within a week, they had set up a public repository, migrated both pipelines into it, and begun a rewrite that would take the rest of the downtime to complete.

The Hidden Cost of Image-Analysis Duplication

Duplication in scientific software is not new. Every lab that processes its own imaging data writes its own scripts, and those scripts are rarely shared beyond the lab. A 2021 survey at the University of Washington found that nearly 70% of respondents reported using custom code for data analysis, but fewer than 20% had ever published that code. The result is a vast, invisible landscape of one-off scripts, each maintained by a single person who may leave the lab at any moment.

The cost of this duplication is hard to quantify, but it shows up in time. A postdoc might spend a month adapting a segmentation routine to a new sample type. A graduate student might spend two weeks debugging a file-format issue that another lab solved years ago. These are not hours that appear in any grant report, but they are hours that could have been spent on science. For example, the Rice University engineers who developed a charge-based strategy for controlled peptide delivery (as described in their 2023 paper in ACS Applied Materials & Interfaces) almost certainly wrote custom image-analysis code to characterize their gelatin-based materials, but that code will never be seen by another group working on similar problems.

Funding pressure often pushes against reuse. Grants are awarded for novel results, not for reusing someone else's code. A principal investigator might worry that if their lab adopts an external pipeline, they will lose control over the analysis, or that they will have to learn a new tool that was not designed for their specific data. The result is a system that rewards reinventing the wheel, even as it pays for the wheel multiple times.

The two labs in this story were no different. Their duplication was not malicious or even careless; it was the default. Each lab had built its own pipeline because that was the path of least resistance, and because no one had shown them a better way. The beamline downtime changed the calculus. With no new data coming in, the opportunity cost of rewriting code was lower, and the benefit of sharing was higher.

What a Shared Codebase Unlocked

Once the two labs merged their pipelines, the immediate effect was speed. Where a single lab had maintained one set of scripts, now two labs contributed fixes and features. A bug in the segmentation routine that had plagued the protein-crystal lab for months was fixed within days, because the tissue-engineering lab had already solved the same problem for their scaffold images. The shared repository also forced a level of documentation that neither lab had maintained before, simply because the code had to be understandable to people outside the original authors.

Within a month, the combined pipeline was faster than either original. The tissue-engineering group had written a parallel processing module that could handle large image stacks on a multi-core workstation. The protein-crystal lab had a more accurate thresholding algorithm that reduced false positives. Together, the two labs produced a pipeline that could segment images in minutes that had previously taken hours, and with less manual intervention.

That speed unlocked a question neither lab had been able to ask before: high-throughput screening. The protein-crystal lab had been limited by the time it took to manually review segmentation results. With the automated pipeline, they could process a full dataset overnight, then spend the next day on the more interesting task of interpreting the features. The tissue-engineering lab began running parameter sweeps across their scaffold images, varying the segmentation threshold to see how it affected the measured pore size, something that would have been impractical before.

Reproducibility also improved, almost as a side effect. Because the code was in a shared repository with version control, the exact version used for a given analysis could be referenced in a paper. That is a small thing, but it matters. A reader who wants to reproduce a result no longer has to email an author and hope for a tarball of scripts. They can clone the repository, check out the tagged version, and run the analysis themselves.

The collaboration also brought technical challenges. The two pipelines had been written in different Python versions, and the tissue-engineering lab used a different image library than the protein-crystal lab. The teams had to agree on a common environment, which meant updating dependencies and testing on both labs' data. They also had to reconcile different file naming conventions and metadata structures, a process that took several weeks of weekly video calls and shared documents. These are the mundane but essential details of merging codebases, and they highlight why such collaborations are rare without a pressing reason.

Instrument Downtime as a Research-Economics Signal

The beamline closure was not an isolated event. Instruments at large facilities break down, and access is expensive. Beamline time at a synchrotron typically costs in the low thousands of dollars per hour when full operating costs are counted, though academic users often pay a fraction of that through their facility access fees. Even at subsidized rates, a day of beam time is a significant line item in a grant budget. When that time disappears, the investment in travel, sample preparation, and personnel is lost.

Downtime forces a rethinking of priorities. For the two labs, it turned attention from data collection to data analysis, an area that is chronically underfunded. Grants are written around instruments and experiments, not around the software that interprets the results. A new microscope or a new beamline is a capital expense that can be justified to a review panel. A postdoc who will spend six months writing a segmentation library is a harder sell, even if that library will be used by every lab in the field for the next decade.

The fragility of solo pipelines is a symptom of this imbalance. When a single lab owns the only copy of a critical analysis tool, the entire project is vulnerable to that lab's turnover and to the whims of a single developer. The downtime exposed that fragility in a concrete way. The protein-crystal lab's pipeline was unusable because the person who wrote it had left, and no one else understood it well enough to adapt it. The tissue-engineering lab's pipeline was in better shape, but it was still undocumented and tied to the original author's workstation.

Shared infrastructure reduces that fragility. When two labs maintain a codebase together, there is always someone who knows how it works. When the code is open source, the pool of potential maintainers grows even larger. The downside is that shared code requires coordination, and coordination is a cost that is not always recognized in the funding system. The two labs had to schedule meetings, agree on coding standards, and resolve disagreements about which features to prioritize. That work was not in anyone's job description, and it was not paid for by any grant.

From Two Labs to a Mini-Community

Within three months of the beamline reopening, the shared pipeline had been released under an open-source license. The decision was not automatic. The tissue-engineering lab's PI had initial reservations about giving away code that could be seen as a competitive advantage. But the protein-crystal lab's PI argued that the code was a method, not a result, and that sharing methods is standard practice in their field. The open license won, and the repository went public.

The response was faster than anyone expected. Three other groups, all working at the same facility, adopted the pipeline within the first six months. One was a materials science group that had been using a commercial image-analysis package and was frustrated by its lack of flexibility. Another was a geology lab that had similar segmentation needs but had never considered using code built for biological samples. The third was a graduate student who found the repository through a search and was able to analyze her data without writing a single line of code from scratch.

The shared documentation lowered the entry barrier. The two original labs had written a user guide as part of their rewrite, partly because they needed it themselves. That guide, now hosted alongside the code, explains not just how to run the pipeline, but why certain parameters matter and what the common failure modes are. It is the kind of documentation that rarely exists for lab-written code, because it takes time that no one is paid for.

Peer review of code is becoming part of the workflow. When a new group adopts the pipeline, they often find bugs or suggest improvements. Those contributions are now tracked in the repository's issue tracker, and the original authors review them as part of their regular maintenance. This is a form of quality control that papers alone cannot provide. A paper describes a method in prose; a codebase demonstrates it in practice.

The Funding Lesson: Pay for Maintenance, Not Just Instruments

The story of these two labs is a small example of a larger funding problem. Science invests heavily in instruments and experiments, but it underinvests in the software and data infrastructure that make those experiments interpretable. A beamline costs tens of millions of dollars to build and millions to operate. The image-analysis pipeline that turns its data into scientific results was built on borrowed time and volunteer effort.

Maintenance is the unglamorous cost. Once the shared pipeline was adopted by five groups, someone had to respond to issues, update dependencies, and keep the documentation current. That work fell to the two postdocs who had started the collaboration, on top of their regular research duties. Neither had a line in their grant for software maintenance. When the protein-crystal postdoc finished her contract and moved to a faculty position, the pipeline's maintenance burden shifted entirely to the tissue-engineering lab.

A small stipend could sustain the codebase. An additional half-time research software engineer, funded for a year or two, could have handled the backlog of issues and added the features that the new user groups requested. That would cost a fraction of a single beamline's annual operating budget, but no grant mechanism existed for it. The facility itself had a software group, but their mandate was the instrument control software, not the downstream analysis tools.

The funding lesson is not that instruments are overfunded. It is that the research system treats software as a one-time cost, when in reality it is a recurring one. The Rice University engineers who developed the charge-based peptide delivery strategy, and the Phys.org story that covered it, are part of a system that celebrates new tools but rarely pays for their upkeep. A shared codebase like the one that emerged from the beamline downtime is a form of infrastructure, and infrastructure requires maintenance.

What This Means for Future Downtime

The beamline will break again. Instruments always do. The question is whether the research community will treat the next downtime as a crisis or as an opportunity. The two labs in this story found that a forced collaboration produced a better tool than either could have built alone. That outcome was not guaranteed. It depended on the willingness of two postdocs to reach out, the flexibility of two PIs to share, and the existence of a platform where the code could live.

Planning for downtime could make the response more routine. If facilities and research groups agreed in advance that shared repositories are the default for analysis code, then a shutdown would not require a heroic effort to merge pipelines. It would simply be a matter of pulling the latest version from a common repository and running it on the new data. That kind of pre-agreement is rare, because it requires trust and coordination that the current funding system does not incentivize.

Institutional incentives could encourage reuse. A grant reviewer might look more favorably on a proposal that commits to using a community-maintained pipeline rather than building a new one. A department might count software maintenance as a service contribution in a review dossier, the way it counts committee work or peer review. These are small changes, but they would shift the culture from one that values novelty to one that values sustainability.

Small collaborations can yield outsized returns. The two labs' shared pipeline did not revolutionize the field, but it made a handful of groups more efficient and more reproducible. It also created a template for how to respond to infrastructure failure: reach out, share, and build. The next time a beamline goes down, or a sequencer breaks, or a satellite stops transmitting, the researchers affected will have a choice. They can wait out the downtime, or they can do what these two labs did and turn a disruption into a collaboration. The outcome is not guaranteed, but the possibility is there. Will they have the incentives, the funding, and the culture to make that choice?