Open Source QMS Software Overview: GitLab As QMS?
Anyway! If a page on SourceForge is one of the top results when googling “Open Source QMS Software”, that can’t be a good sign. The QMS software industry already is incredibly shady, full of enterprise vendors with opaque pricing models (“contact sales for pricing”) who like to hold your data hostage by not allowing you to export it. Therefore it would be a very welcome change if there would be great open source QMS software.
Let’s take a look at what your options are. Before that, let me briefly dive into which features you actually need!
Requirements Of Open Source QMS Software
- Some sort of document management system with versioning and electronic signing.
- A way to manage requirements and link them to things (e.g. tests).
Quick side note: We actually started working on that and have released Formwork, our own QMS software, which has super-transparent, fair pricing and enables you to export your data any time. It’s really cool, but I may be biased. Check it out.
Back to topic! If you look at the two requirements above, you might notice that it’s unlikely that any open source software would cover both of them at the same time. You have document editors (like Google Docs) and you have “requirements management tools” (like GitHub Issues), but those two are often quite different.
That’s why I would also look at them separately, even though I will talk about some tools which cover both and.. ah, it’s just complicated. You’ll see!
Document Management With Open Source QMS Software
The problem here is that you’re essentially looking for an open source version of Google Docs, and something like that currently just doesn’t exist.
You do have options though: If you either expand your search towards “markdown-based document editing”, you end up with git-based solutions (GitHub, GitLab, etc.); or, if you expand your search towards “Google Drive - like software”, you end up with software like Nextcloud and Etherpad. I’ll describe each of them below.
First off, let’s start with the git-based (markdown) approach as that’s a solution which I’ve seen with a few consulting clients in the past.
git (GitHub, GitLab, etc.)
The idea here is to store all your documents as markdown files in a git repository. There are quite a few positive aspects to this: Firstly, you’re independent of wherever you host your git repository - you could host it on GitHub, GitLab, or even on a self-hosted GitLab instance for more control over your data. You also get what I like to call “perfect versioning” as, well, versioning markdown documents in git is pretty solid and you can show auditors every little change. That’s cool.
However, we strongly don’t recommend a git-based approach. If you’re now thinking “the dude just wants to sell his own software”, no, that’s not the case here. We’re pretty agnostic about the software our consulting clients use, and we’ve worked with a few companies using a git-based QMS in the past. All of them ended up being major catastrophies, that’s why I’d like to prevent that from happening at your company.
The first problem is that it only works as long as everyone on your team is able to write markdown documents and interact with git. That might seem like no problem when your company consists of 3 dudes writing software, but it will become a major problem once you onboard your first regulatory (or other non-technical) person.
The second problem is about exportability: Notified bodies tend to be pretty low-tech institutions, and they generally require you to hand in your documentation as PDFs. So you’ll need to code a few custom scripts to convert your markdown files to PDFs. If you’re using additional GitHub / GitLab features like Issues, then you’ll have to code even more scripts to fetch those from the API and export them as PDFs. That’s all doable, but you’ll have to ask yourself whether you really want to spend your time writing scripts instead of building your product and getting regulatory approval for it.
And, finally, editing large tables in markdown sucks. You might think “not such a big problem” but I have to caution you, this is a big problem, because regulatory documents contain big tables.
If you still want to pursue the git-based QMS approach, check out our article on how to set up a QMS in GitHub / GitLab, and more importantly, our article on why we no longer recommend it.
Nextcloud
I’ve run a self-hosted Nextcloud installation for a few years and it seemed pretty solid. The usual caveats of open source software apply: The UI is slightly less polished than many commercial products, and you might occasionally run into bugs. But I didn’t find any showstoppers.
That being said, I only used it for managing files, and not even in a regulatory compliance context. I also didn’t try out the “Office” / document editing feature, so I don’t really know how solid that is.
Regardless, it’s a viable option. If you end up using a self-hosted Nextcloud instance for your QMS, the usual requirements apply: Documents have to be electronically signed and you need to keep old versions of documents around. These problems are not unique to using Nextcloud, they also apply when using generic software like Google Drive. Check out my article on setting up a QMS in Google Drive to see how you can solve those problems - the lessons there apply to Nextcloud, too!
Etherpad
Are Companies Using GitHub, GitLab, Nextcloud, Etherpad as QMS?
And that’s all the document management software I know of. That being said, I could be missing something, so feel free to reach out if you’ve found any suitable software!
Requirements Management With Open Source QMS Software
Your software requirements and software tests are what I call requirement-based information, and you could either also save them to your documents - in that case, you’d just have many large tables which list your software requirements - or, you could save them in a more structured way.
You could either use GitHub issues (or the GitLab equivalent) for those, or you could set up a more elaborate ticketing system. Either way, you typically end up with the same set of benefits and drawbacks.
Let’s look at the features you need first and then discuss the tools after that.
A great example for this (at least in my mind) is the documentation and association of software requirements and software tests. You need to document those to show auditors 1) what the hell your software does and 2) how you’ve tested it. A quick example of a magic Covid screening app:
Req ID |
Description |
Test IDs |
---|---|---|
1 |
The software diagnoses Covid with selfies. |
1, 2 |
2 |
Users can log in with Facebook. |
2, 3 |
Those are the software requirements which describe what the software does. Each requirement has its own, unique ID (leftmost column), and is linked to one or multiple tests (rightmost column). Accordingly, you’ll have your software tests:
Test ID |
Description |
Req IDs |
---|---|---|
1 |
Run integration test with diagnosis features. |
1 |
2 |
Test selfie feature. |
1, 2 |
3 |
Do login with Facebook. |
2 |
Ah, and now you already see the mess which is developing: Due to the many-to-many relation between software requirements and tests, you end up with this ugly columns which attempt to link the two together. This will result in major chaos if you continue storing this sort of information in tables (or spreadsheets). And that also answers the question what regulatory compliance employees do all day long, they often handle these tables because there’s no better software out there (now we have Formwork, of course).
Okay, but this was actually about which features open source software would need to have to manage requirements. You’ve seen above that you have to be able to store your information (software requirements etc.) in a structured way, and you must be able to link them with other things (software tests etc.). So far, so good.
But there’s more. You need to version these requirements, too. In other words, you need to reproduce these requirement lists for each version of your product. This is often very tricky in most tools.
Let’s look at some examples.
Requirements Management In GitHub / GitLab Issues
You could link things by mentioning their ID in the description field - you could e.g. link to issue #1 by simply mentioning #1 somewhere in the text.
Those are the good parts.
The bad parts are that you can’t easily export all of this as PDF, you’ll have to write yet another custom script for this. Also, it’s not versioned really well (or at all), so you’ll have to diligently export everything for each version of your software and archive it. If you ever forget to do so, you’re screwed because you can’t reconstruct old versions of all issues at a certain point in time.
So.. yes, it’s technicall possible to do requirements management in GitHub / GitLab, but I would not recommend it. I haven’t seen this implementation in clients so far, which is another (negative) data point. The git-based QMS companies actually ended up writing everything in markdown documents which presented its own set of (terrible) challenges, but still might have been a better option here.
Requirements Management In Redmine
One such tool is Redmine. You can think of it as an open-source, better version of Jira. I looked into it quite extensively two years ago or so and it actually seemed viable for medical device compliance. I didn’t follow through with using it because I ended up coding my own software which became Formwork.
Generally speaking, the benefits of Redmine in comparison got GitHub / GitLab are that you can define arbitrary ticket types and link them with each other in a better way.
I’m not sure about the exporting aspect though, you might still need to write a custom script to export everything to PDFs (if you want to automate your regulatory compliance, get used to writing lots of custom scripts).
I’m also not sure if / how it solves the versioning problem. When I looked into it, there wasn’t a way to have true versioning of multiple items at the same time. So you’d still have to export everything for every product release you do.
There are also alternatives (although not many), a noteworthy one is Phabricator which unfortunately is no longer maintained. It also looked pretty cool but my impression was that it has less users and less of a community around it than Redmine, and it seemed really complex and had many weird names for its different modules. In any case, I wouldn’t choose it as it’s not maintained.
Conclusion: Which Software For Open Source QMS?
The same goes for open source QMS software. You have many different options and it’s not even clear based on which metrics you should compare them. I’ve attempted to create some tables to help you out.
Table: Document Management For Open Source QMS
Name |
Directories |
Versioning |
Signatures |
---|---|---|---|
git (markdown files, GitHub / GitLab) |
Yes |
Great |
Needs workaround |
Nextcloud |
Yes |
Needs workaround |
Needs workaround |
Etherpad |
Not sure |
Not sure |
Needs workaround |
Looking at this table, your options suck.
Let’s look at requirements management software next.
Table: Requirements Management For Open Source QMS
Name |
Can Export |
Versioning |
Mental Pain |
---|---|---|---|
Write tables in documents |
Yes |
Yes |
Very high |
GitHub / GitLab Issues |
Coding required |
No |
High |
Redmine |
Coding required |
No |
High |
Yeah, things don’t look much better on the requirements side. Ironically, the “manage everything in document tables” approach actually fares quite well if you look at the most important aspects.
Which Open Source QMS Would I Choose?
Well, this whole search for open source QMS software prompted me to develop our own QMS software called Formwork, and I think it compares really well - among other things, you get perfect versioning and perfect exportability. But then again, it’s not open source (but you can export all your data any time!).
Still, if I had to choose an open source QMS software now.. hm. I really don’t know. My intuition would be to go with git, simply because it requires the least “devops risk” - you could simply back up your git repository locally any time, whereas with Nextcloud / Redmine you’d have to do more fancy database backups.
But then again, the markdown-based documentation aspect really sucks and I’ve seen multiple companies struggle with it (a lot).
So I probably wouldn’t choose any of those and I’d go with Google Drive instead. Sure, it’s not open source, but it’s cheap and easy to use. If I had more of a budget after generating some revenue, I’d of course choose Formwork, haha..
Good luck with your choice! And if there’s anything I missed, let me know!
On a different note: Do you need any help with your EU MDR efforts?
We've worked with 100+ companies and helped them certify their devices in weeks, not months. Talk to us now – first calls are free! Check out our services and prices here.
Or, if you don't like talking to humans, check out our Wizard. It's a foolproof, step-by-step video course for getting your compliance done yourself.
And if you're looking for the best QMS software for lean, founder-led companies, check out Formwork. It automates your compliance, and there's even a free version for you to try out!

All You Need to Know About QMS Software

Free QMS Software: Google Drive, SharePoint, GitHub, GitLab

Setting Up a Quality Management System (QMS) in GitHub / GitLab
Congratulations! You read this far.
Get notified when we post something new. Sign up for our free newsletter.
No spam, only regulatory rants. Unsubscribe anytime.
0 comments
No comments yet. Be the first one to share your thoughts!

Dr. Oliver Eidel
Through OpenRegulatory, I’ve helped 100+ companies with their medical device compliance. While it’s also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)
If you’re still lost and have further questions, reach out any time!