Can GitHub really work as an eQMS? Taking the objections seriously
OpenRegulatory spent years recommending GitHub and GitLab as QMS software for medical device startups, then reversed course. In "GitHub QMS: We No Longer Recommend It", Dr. Oliver Eidel describes what happened across several client projects that ran their QMS this way and lands on advising against it for everyone, without exception. His verdict on the client results: "the results aren't pretty."
I maintain an open-source eQMS baseline that runs entirely on GitHub, so you would expect me to argue with that article. I mostly can't. Every problem it names is real, and I have watched each of them happen. Where we part ways is the diagnosis. What Eidel describes is a bare repository full of markdown files, with humans expected to supply all of the process discipline. That pattern deserves to die. It tells you very little about GitHub as a QMS platform, in roughly the way a text file full of passwords tells you little about password managers.
He raises three problems. Here is where each one actually comes from, and what it takes to make it go away.
Problem 1: markdown tables
Eidel's first objection: every QMS grows tables, tables are unavoidable, and markdown tables become unmanageable past a handful of rows. His examples are software requirements lists, SOUP lists and traceability matrices, and his observed workarounds are all bad: spreadsheets committed to git, a QMS split between git and Google Drive, or one markdown-fluent engineer becoming the company's table-editing bottleneck.
He is right about markdown tables and wrong about the remedy, because the remedy is to stop putting structured data in prose documents at all. In the baseline, everything table-shaped is a structured file. The training matrix is YAML. The signer registry is JSON. The gap analyses against ISO 13485, IEC 62304 and the rest are YAML with one entry per requirement. CI validates all of them on every pull request, and the automation consumes them directly: reviewer assignment is computed from the signer registry, training issues are generated from the training matrix. A markdown table can do none of that. A validated YAML file is also something a regulatory person can edit in the browser with a schema check catching their mistakes, which is more than can be said for a fifty-row table in any format.
His examples deserve a specific answer too. A SOUP list maintained by hand is a liability in every tool, including a validated eQMS; it should be generated from your dependency manifests in CI, which is only possible when your QMS lives next to your code. Requirements and traceability matrices are product engineering artifacts, and the baseline deliberately keeps them out of the QMS repository; they belong in your product repositories with tooling built for the job.
Problem 2: non-technical people and git
His second objection is the one I take most seriously: the first non-technical hire, a regulatory affairs employee or an outside consultant, cannot realistically learn git and markdown within the constraints of a normal company. They want to write documents, not forge their own tools first. He concludes it is not a solvable problem.
It is not solvable by teaching, agreed. The baseline solves it by removing the requirement instead. Nobody outside document authoring touches git. Intake happens through issue forms: a CAPA, an audit finding, a complaint each opens as a structured GitHub issue with fields, not a blank markdown page. Review happens in the pull request UI in the browser. Approval is a button click followed by a PIN entry. Training arrives as an issue opened for you automatically, and acknowledging it is a signature, not a commit. A regulatory consultant can do all of their daily work without ever learning what a branch is.
The honest boundary: document authors still edit markdown and open pull requests. In a software medical device company those people overlap heavily with the engineers who already live in pull requests, so the ask is smaller than it sounds. But if your quality team works only in Word and will not move to browser-based review at all, this model is wrong for you, and no tooling will fix that.
There is also a bigger shift underneath this objection, and it deserves its own section: in 2026, the person Eidel worries about mostly does not type documents by hand in any tool. See the part the debate missed below.
Problem 3: review workflows and branch hygiene
His third objection: pull-request-based document review only works if everyone is hyper-disciplined. Keep each merge request to one document, merge promptly so branches don't go stale, agree on edits beforehand because collaborative suggestion-making doesn't exist in git. Miss any of these and you get a jumble of stale branches and unfinished edits that an auditor will not enjoy untangling.
This is the most revealing objection, because "it only works if everyone is hyper-disciplined" is a description of an unautomated process, not of a platform. Discipline you have to remember is a process smell; discipline a machine enforces is just how the system works. The baseline ships twenty GitHub Actions workflows for exactly this. A gate rejects any pull request whose description lacks the required sections and a signature declaration. Signatory reviewers are assigned automatically from the registry. And the workflow that answers the stale-branch problem directly: once the declared signatures are collected, the pull request merges automatically. Approved changes cannot sit around going stale, because nothing waits for a human to remember the merge button.
One factual correction to the original article: GitHub reviewers can propose concrete text changes as suggestions inside a review, and the author can apply them with one click. It is not Google Docs, and pre-drafting discussions still belong in an issue, but "collaborative editing is non-existent" was already out of date when the article was written.
While preparing this article, those gates rejected a pull request from my own account, the maintainer's, because the body was missing a signer-role declaration. Mildly annoying, and completely correct. The system does not know or care who I am, which is the entire point.
The part the debate missed: regulatory work is agentic now
Some fairness is due here: Eidel wrote his article in 2024, and it had no chance to rely on the capacities we have at our disposal in 2026. Both sides of the argument, as it stood then, assumed a human with a keyboard, typing documents by hand. That assumption is quietly expiring, and I would rather admit it than dance around it: most of the interaction while preparing regulatory documents already happens through AI agents. The first draft of a gap analysis, the SOP revision after a standard update, the summary of what changed between two versions, the write-up of a CAPA investigation. A person directs the work and owns the result, but the keystrokes are increasingly not theirs. Anyone claiming otherwise about their own team should check the browser history.
Once you accept that, the choice of representation looks different. An agent working inside a proprietary eQMS has to drive a web UI built for human hands, or go through whatever export the vendor allows. An agent working a git repository is in its native habitat. Plain-text documents, structured YAML, diffs, branches and pull requests are precisely the material coding agents are built for. The same repository serves both audiences with no translation layer: rendered pages and browser review for the humans, files and diffs for the agents. This also dissolves most of the non-technical-user problem from the inside: the regulatory affairs person never edits markdown by hand, because their agent does, and they review the rendered result.
What agentic work makes more important, not less, is a hard checkpoint where an accountable human reviews and signs what an agent prepared. The baseline already has one, and it was there before the agents arrived: the pull request boundary with a PIN-signed approval. An agent can draft everything and sign nothing. So Eidel's question, whether non-technical people can work in git, is turning into a different one: whether their agents can, and whether the humans keep a signing checkpoint the automation cannot bypass. Git answers the first natively, and the gates answer the second.
The signature question
OpenRegulatory's companion articles raise a fourth point worth answering: that e-signatures in a git QMS are probably not 21 CFR Part 11 compliant, so the approach only works for EU-market devices. For a name typed into a markdown file, or a bare review approval, that is true. It is why the baseline includes a signature worker that intercepts the approval event and demands a second, time-limited PIN before anything counts as signed, producing a record that binds the signer's identity, the declared meaning, the timestamp and the exact revision. The worker and the gates around it are in the open, in the repository's signature-worker service, and I walk the mechanism against each Part 11 requirement in Part 11 electronic signatures on pull requests.
What this does not solve
Running your QMS on GitHub still leaves you with work no repository can do for you. You must qualify GitHub as a supplier. You must validate the system, including the signature infrastructure, for your intended use and your risk profile. You must train people and keep evidence of it. You must tailor the procedures to how your company actually works, because an untailored QMS fails audits in any tool.
For fairness: OpenRegulatory sells a QMS product, and their article says as much with a wink. That does not make their observations wrong, and I have tried to engage with the strongest version of each one. My conclusion is simply different: the failures they document are failures of running a QMS on bare files and good intentions. The baseline exists so you can start from a governed, tested system instead. It is published at github.com/AliakseiT/dearauditor-qms-baseline under Apache-2.0 and CC BY-SA. Fork it, read the gap analyses, and judge for yourself whether the objections still apply.