In 1976, a small group of computational scientists persuaded a federal funding agency to require that all software developed under its grants be archived and made available to other researchers. The rule was visionary, predating the open-science movement by decades. But it came with no dedicated funding, no storage infrastructure, and no plan for long-term maintenance. Nearly fifty years later, the mandate still stands, even though the telescope that inspired it has long been decommissioned and its entire optics budget is a line item in history. This is the story of a policy that outlived its original purpose, and what it reveals about the economics of scientific software.

The Mandate That Outlived Its Telescope

The rule emerged from a simple frustration. In the early 1970s, a team at the National Radio Astronomy Observatory was trying to reproduce a colleague's data reduction, only to discover that the FORTRAN code had been lost when a graduate student graduated and took his punch cards with him. The incident was not unusual. Across the field, software was treated as a personal artifact, not a scientific output. When the funding agency proposed a new directive requiring code archiving, it was seen as a radical move.

The mandate applied to all grants in computational astronomy and related fields. Researchers were required to deposit their source code, along with sample input and output, in a central repository within six months of project completion. The agency would maintain the archive, but only for five years. After that, the code was the researcher's responsibility. In practice, most codes were simply left to rot on magnetic tape.

The telescope that motivated the rule was a 36-foot radio dish in West Virginia, used for spectral line studies. It operated for barely a decade before being decommissioned in the late 1980s. Its optics budget, allocated for mirrors and receivers, was exhausted years before the telescope was shut down. Yet the archiving mandate, attached to the funding program that supported the telescope's science, outlived the hardware by decades.

Today, the rule persists in revised form, now covering all software produced under the agency's grants. But the costs have shifted. The central repository accepts deposits, but it does not guarantee preservation. Researchers who want their code to remain usable must pay for their own storage, often from soft money. The mandate, once a forward-looking policy, is now a quiet burden on the scientific community.

Who Pushed the Rule Through

The push came from a handful of computational scientists, led by a pioneer in numerical methods named Dorothy Chen. Chen had spent the 1960s developing algorithms for solving partial differential equations in plasma physics. She had seen too many promising results die because the code behind them was inaccessible. In 1975, she wrote a memo to the funding agency, arguing that without archiving, the scientific record was incomplete.

Chen's memo was circulated among a small network of like-minded researchers, including a young postdoc named Alan Turing (no relation to the famous codebreaker) and a veteran astronomer who had lost his own code in a lab fire. Together, they lobbied the agency's program managers, emphasizing that replication was impossible without the original software. They were not asking for new money. They were asking for a policy change.

The agency's leadership was sympathetic but cautious. Some officials worried that mandating archiving would burden researchers with paperwork. Others feared that the agency would be liable if archived code contained errors. Chen countered that the scientific community had a duty to share its methods, and that the risk of error was lower than the risk of loss. After months of negotiation, the mandate was approved, but with no dedicated funding attached.

Chen later recalled that the lack of funding was a deliberate compromise. The agency did not want to set a precedent for paying for software maintenance. It viewed code as a byproduct of research, not a research output in its own right. That assumption would prove costly in the long run, as the costs of archiving were simply passed on to grantees, who had to absorb them into their existing budgets.

The Economics of Archiving

Archiving code is not free. Even in the 1980s, storing data on magnetic tape cost money, and the tapes needed to be re-copied every few years to prevent degradation. By the 1990s, as data volumes exploded, the costs grew. A single archived dataset from a radio astronomy survey could occupy several gigabytes, which required dedicated servers and network bandwidth.

Today, a typical archive for a mid-sized computational project, including code, documentation, and sample data, costs somewhere in the low thousands of dollars per year to maintain, depending on the storage medium and the level of curation. That is roughly comparable to the cost of a mid-range laboratory instrument, like a benchtop spectrometer. But unlike a spectrometer, which is a one-time purchase, archiving costs recur indefinitely.

Researchers often pay for these costs out of their grant funds, which are already stretched thin. A principal investigator might allocate a few hundred dollars per year from a small grant to keep an archive alive. But when the grant ends, the archive often becomes an orphan. The funding agency does not provide post-grant support, so the code sits on a server, unmaintained, until it becomes unreadable.

The economic burden falls unevenly. Large research groups with substantial grants can absorb the costs. Small teams and early-career researchers, who are most likely to produce novel code, often cannot. As a result, the mandate has the perverse effect of discouraging code sharing, because the cost of compliance is real, while the benefit is diffuse.

Consider the case of a postdoctoral researcher in the late 1990s, who developed a sophisticated data reduction pipeline for a millimeter-wave telescope. The code was archived as required, but when the postdoc moved to a non-academic job, the archive was left without a maintainer. Years later, a graduate student attempted to use the code for a new project, only to find that it required an obsolete version of a numerical library and lacked any documentation. The student spent weeks trying to reverse-engineer the code, ultimately giving up and rewriting the pipeline from scratch. The archived code, despite being deposited, was effectively useless.

When the Telescope Dies, the Code Lives

The 36-foot telescope was decommissioned in the late 1980s, its optics budget long exhausted. But the code that was written for it did not die. In fact, some of it is still in use today. A spectral analysis package called SPECLINE, written in FORTRAN in the early 1980s, was designed to fit Gaussian profiles to emission lines in radio spectra. It was archived under the mandate, and it proved so robust that it was later ported to C and integrated into modern data reduction pipelines.

SPECLINE is now maintained by a small group of volunteers, mostly retired astronomers who remember the original code. They respond to bug reports, update the build scripts, and keep the documentation current. The funding agency that mandated its archiving does not contribute a cent. The volunteers do it because they believe the code is a piece of scientific heritage, and because it still works.

Another example is a calibration routine used to correct for atmospheric opacity in millimeter-wave observations. Written in 1987, it was archived and then largely forgotten. When a new survey in the 2010s needed to compare old data with new, researchers discovered the routine and found that it could be used to cross-calibrate the two datasets. The code had outlived the instrument it was written for, and it proved essential for a project that had nothing to do with the original telescope.

These success stories are heartening, but they are the exception. Most archived code is never touched again. The mandate ensures that code is deposited, but it does not ensure that it is usable. Without documentation, without a maintainer, and without a clear license, most archived code is as inaccessible as if it had been lost.

The Replication Payoff and Its Limits

When archived code does work, it can have a real payoff. In 2015, a team of researchers reanalyzed data from a 1980s radio survey, using the original reduction software that had been preserved in the archive. They were able to reproduce the published results, confirming that the original analysis was sound. This kind of replication is rare, and it is only possible because the code was archived.

But the limits are stark. A systematic check of archived codes from the 1980s and 1990s, conducted in 2015, found that only a fraction, perhaps a third, could be run without modification. The rest required updates to the language, the compiler, or the operating system. Many lacked documentation, making it impossible to understand what the code was supposed to do.

The most successful replications often involve personal contact. A researcher who wants to reuse an old piece of code will track down the original author, who may still be alive and able to explain the quirks. This is not archiving in any meaningful sense; it is oral history. The code itself is often less important than the human memory of how it was written.

The 2015 check also found that the cost of making an old code run again can be substantial. One team spent several weeks updating a FORTRAN program to work with modern compilers, only to discover that the underlying algorithm was flawed. The replication effort was a waste of time, but it was also a valuable lesson: archiving code is not the same as preserving knowledge.

The Human Element: Why Some Codes Survive

What makes the difference between a code that survives and one that vanishes? Often, it is a dedicated individual who takes on the role of keeper. Take the case of the SPECLINE package: its survival is owed to a retired astronomer who had used the code in her doctoral work. She kept a personal copy, and when the original archive became inaccessible, she was able to provide the source to a new generation of researchers. This kind of informal stewardship is common, but it is fragile. When the keeper retires or passes away, the code may be lost for good.

Another factor is the code's design. Codes that are modular, well-commented, and written in a widely-used language are more likely to be revived. In contrast, codes that rely on proprietary libraries or exotic hardware are almost impossible to resurrect. A 2019 survey of archived astronomy software found that codes written in FORTRAN or C had a higher chance of being successfully recompiled than those written in less common languages. This suggests that the choice of programming language has a direct impact on the long-term accessibility of the code.

The social context also matters. A code that is associated with a high-profile result is more likely to be preserved, because researchers have an incentive to verify the result. Conversely, a code that produced a minor result is unlikely to attract attention, even if it is archived. This creates a bias in the historical record: we preserve the code that was important then, but we lose the code that might be important now for reasons we cannot anticipate.

These observations point to a deeper issue: archiving is not just a technical problem, but a social one. The mandate of 1976 treated software as a static artifact, to be deposited and forgotten. But software is alive, evolving with the hardware and the scientific questions it serves. A code that is not maintained is like a book that is never read; it may exist, but it does not fulfill its purpose.

Lessons for Today's Code-Sharing Push

The 1976 mandate offers a cautionary tale for the current wave of code-sharing requirements. Many journals now require authors to deposit code in a public repository, and some funding agencies have followed suit. But these mandates, like the 1976 rule, often come without dedicated funding. The costs are shifted to researchers, who must pay for storage, curation, and documentation out of their existing grants.

Some funding agencies have begun to experiment with small stipends for data management. For example, a few programs now allow grantees to include a line item for software preservation, typically a few thousand dollars per grant. These stipends are helpful, but they are not enough. The real cost of preservation is not the initial deposit; it is the long-term maintenance, which can span decades.

Best practice, as articulated by many in the computational science community, is to archive early and document lightly. Rather than waiting until the end of a project, researchers should deposit code as they develop it, with minimal but sufficient documentation. This reduces the burden of retroactive archiving and increases the likelihood that the code will be usable later.

But even with early archiving, the infrastructure must be funded. A repository that is not maintained is as useless as a code that is never deposited. The 1976 mandate failed to anticipate this. It created a policy without a budget, and the scientific community has been paying the difference ever since. As the current code-sharing push gains momentum, the lesson is clear: if you want scientists to share their code, you must be willing to pay for the shelves on which that code will sit.

There is also a counter-argument to consider: perhaps the mandate was never meant to guarantee long-term usability, but simply to create a record of what was done. Even if the code cannot be run, it can serve as a historical artifact, showing how science was conducted in a particular era. This perspective has merit, but it is not what the mandate promised. The policy was sold as a way to enable replication, not just to preserve history. The gap between promise and reality is where the costs have accumulated.

Another lesson concerns the role of incentives. The 1976 mandate imposed a cost on researchers without providing a clear benefit to them. In contrast, modern code-sharing requirements are often tied to the promise of increased citation and visibility. Some studies have shown that papers with publicly available code are cited more often. This creates a positive incentive for researchers to share, which may offset the costs. However, the effect is not uniform, and early-career researchers may still struggle to find the time and resources to curate their code.

Finally, the 1976 mandate highlights the importance of adaptability. The scientific landscape has changed dramatically since 1976, with the rise of machine learning, cloud computing, and collaborative platforms like GitHub. A mandate that was designed for punch cards and magnetic tape is not necessarily suited to the modern era. Any new code-sharing policy must be flexible enough to accommodate new technologies and practices, or it will quickly become obsolete.

The telescope that inspired the mandate is gone, but the mandate remains, a quiet monument to a good idea that was never fully funded. Its legacy is not just the code it preserved, but the questions it raises about who should bear the cost of scientific memory. As we move forward, we would do well to remember that the cost of forgetting is often higher than the cost of remembering.