In this episode, we sit down with David, an expert in R programming for clinical trials, to discuss the evolving landscape of statistical programming. From his unconventional journey from journalism and philosophy into programming to his deep insights on the maintainability and stability of R in the pharmaceutical industry, David shares his perspective on the challenges and opportunities of open-source programming. He explores the key differences between R and SAS, the critical importance of backward compatibility, and how organizations can future-proof their R-based systems. David also introduces his work on PackageDiff, a tool aimed at addressing package stability, and shares his thoughts on AI's role in the space. This is a must-listen for anyone working with R in regulated environments.
Guest: David Bosak, R package developer and consultant specializing in clinical trial reporting and package stability, creator of the in-progress tool pkgdiff.
Host: Tomás Sabat Stöfsel, CEO & Co-Founder, Verisian
Topics: From journalism and philosophy to R development, the maintainability problem in open-source R packages, backward compatibility at enterprise scale, an Underwriters Laboratories model for package certification, FDA and regulatory considerations for R submissions, statistical incompatibilities between R and SAS defaults, AI's limited near-term role, R versus SAS pros and cons
The full episode can be found on YouTube, Apple Podcasts or Spotify.
David Bosak's path into statistical programming ran through journalism and a philosophy degree before he discovered programming during the internet boom of the mid-1990s. He argues the jump was less strange than it sounds: philosophy trains logical reasoning and rigorous documentation, both of which transferred directly into a programming career. His specific focus on R began in 2019, when three unrelated consulting clients, in pharma, insurance, and entertainment, all announced within months of each other that they were abandoning SAS for open source. Attempting his own first clinical table, listing, and figure (TLF) in R, he found the ecosystem simply wasn't ready for the task, and pivoted to building the packages needed to make that work possible instead.
The core issue, David explains, is that community-developed R packages can change or deprecate functions at any time, with no obligation to preserve backward compatibility, something he says he has not seen to the same degree across roughly 15 other programming languages. At small scale this is a minor annoyance. At the scale of a large pharma company running a clinical study with 1,000 programs, hundreds of studies, and an internal reporting system built on around 500 R packages, a single package developer renaming one function can cascade into a company-wide outage. Large companies with dedicated development teams typically handle this by running a scheduled upgrade cycle (roughly every six months) and dedicating an "all hands on deck" period to fixing what breaks, then revalidating. Smaller companies without those resources often simply freeze their R version for years, which David characterizes as not a real solution either.
David's proposed fix borrows directly from consumer product safety: just as Underwriters Laboratories independently tests toasters and electrical equipment before they reach consumers, he argues R needs an equivalent independent testing body for packages, one that could certify and publicly score backward compatibility so a package could carry a badge stating, for example, that it has been backward compatible for three consecutive years. Paired with this, he calls for a cultural shift among package developers toward building almost exclusively in base R (the stable core maintained directly by the R Core team, distinct from the far larger and inherently less stable ecosystem of community packages) and committing explicitly to not breaking downstream code, since R Core itself, with roughly 20,000 dependent packages, already treats backward compatibility as close to non-negotiable.
David notes the FDA has been patient and genuinely helpful toward the R community in public interviews, but has also acknowledged that getting a compatible R environment set up is significantly harder than working with SAS, where submitted code typically just runs regardless of which SAS version the agency has installed. The current practice of sending the FDA exact package version numbers (via renv) means any small deviation forces manual remediation on their end. David's proposed fix is a compatibility-check system, similar in spirit to his Underwriters Laboratories idea, that would let the FDA verify whether two package versions are functionally compatible rather than requiring an exact version match, which he argues would meaningfully lower the friction of R-based regulatory submissions.
Explaining one of the more consequential technical differences between the two languages, David points out that R and SAS statistical functions often produce slightly different results, not because either is wrong, but because of when each was built. SAS procedures developed in the 1980s locked in the state-of-the-art statistical method of that era as the default, adding newer methods only as optional settings to preserve backward compatibility. R, developed starting around 2000, defaulted to the state of the art at that later point, and only offers a SAS-matching option, buried in documentation, for programmers who need to replicate legacy results. The practical effect is that any discrepancy has to be manually walked up to a senior statistician for sign-off, a friction point he says directly contributes to the risk of R-based submissions running slower than SAS-based ones, which, if severe enough, could push companies back toward SAS regardless of licensing cost savings.
"We really need a very strong commitment to backward compatibility and like not breaking people's code, right? Creating packages that do not break people's code." — David Bosak
"Every time you add a package reference, you're essentially inviting that package developer to break your code, right?" — David Bosak
"Shouldn't we have one of these for open source? Some sort of organization, independent organization you could send your packages to, they could test it for compatibility." — David Bosak
"When I send SAS code to the FDA, they run it typically on whatever version of SAS code they have, and it always runs." — David Bosak
"If there's something that you don't like about the language, you can fix it, right? You're in full control of the language that you're using to do your work, and that's what I think is most exciting about open source." — David Bosak
Why is R considered less stable than SAS for clinical trial programming?
Not because of statistical capability, but because R's community-developed packages can change or deprecate functions at any time with no guaranteed backward compatibility, while R Core (the stable base maintained by the R Core team) and SAS both treat backward compatibility as close to non-negotiable.
What is David Bosak's proposed solution to R's package stability problem?
An independent certification system modeled on Underwriters Laboratories for electrical products: an organization that tests R packages for backward compatibility and publicly scores or badges them, so developers can choose stable dependencies with confidence.
Why do R and SAS sometimes produce different statistical results for the same analysis?
Because their default settings reflect the state of the art at the time each was built, SAS in the 1980s and R starting around 2000, not because either language lacks the underlying method. Matching them requires manually finding the right configuration option.
Why does the FDA find R submissions harder to review than SAS submissions?
Because R environments currently require exact package version matches (via tools like renv) rather than a simple compatibility check, and any small version mismatch requires manual remediation on the FDA's end, according to David Bosak's account of the agency's own public comments.
Will R overtake SAS as the dominant language in clinical programming within the next 5 to 10 years?
David Bosak declined to predict this, saying it depends on whether the industry achieves a genuine cultural shift toward minimizing package dependencies and prioritizing stability, a change he says no single person or organization can drive alone.
The Verisian Community Podcast brings together experts in clinical trials to exchange innovative ideas and best practices central to clinical reporting, submission and review. Aligned with Verisian's mission to accelerate the evaluation and market launch of new medical treatments, each episode features expert insights, with guests ranging from statistical programmers to medical writers, to discuss the challenges and opportunities of the latest software and technology.
You can listen to us on YouTube, Apple Podcasts or Spotify.
See Verisian in action. Share a few details and we’ll be in touch to schedule your demo.
Your request has been received. A member of the Verisian team will contact you shortly to arrange a demo.
