I recently googled “Open Source QMS Software” and one of the top results actually was a page on SourceForge. That made me realize that I’m old. Do you remember SourceForge? It was something of a GitHub predecessor, only more broken and not owned by Microsoft, hehe. Good times.

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!

The features which need to be covered by QMS software are no rocket science (even though some QMS software vendors would like you to believe otherwise). In greatly simplified terms and in the true spirit of this website, here’s what you need:

And that’s it. If you’re now wondering why QMS software is so expensive, yeah, I also have no idea, it’s a similar mystery like the hidden UFOs in Area 51 and ships disappearing in the Bermuda triangle. But, rationally speaking, QMS software is not very complex and therefore shouldn’t be very expensive.

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!

Let me get started with the biggest anticlimax you probably don’t want to hear: I don’t think there’s a whole lot of great software in this space.

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.

This is the only open-source approach which I’ve seen companies actually use up to their audit, that’s why I’ll talk about it first.

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.

Those were the git-based approaches. Now, as mentioned above, if you expand your search towards “Google Drive - like software”, that would lead to Nextcloud (GitHub link) which I actually think is pretty cool. Think of it like a self-hosted Google Drive (or Dropbox, if you’re my age). Additionally, you can also edit documents in Nextcloud, they call it Nextcloud Office.

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!

Besides Nextcloud, there’s also Etherpad, but I’m not sure whether that enables you to persist documents and manage them in a folder structure. It does have some pretty cool real-time collaboration features though. Just like with Nextcloud and Google Drive, you’d need to solve the electronic signing and versioning problem.

So, have I ever seen companies use this software for their “production” regulatory compliance? So far, I’ve only seen a few git-based approaches and none in Nextcloud and Etherpad, so.. you’d be the first company to use them (not sure if that’s good or bad - probably bad). Speaking of git-based approaches: All of the ones we worked with ended up becoming a major fiasco, therefore we no longer recommend them.

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!

Next up, requirements management. That’s the second point you need to cover when looking for open source QMS software. The general concept is this: You have document-based information which you save to (surprise) documents in GitHub / GitLab / Nextcloud etc., and then you have requirement-based information which you save to.. well yeah, where do you save it to? It depends, actually.

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:

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:

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.

You could use GitHub or GitLab issues for this. The general idea would be to introduce a whole bunch of different tags (e.g. SoftwarweRequirement), and then each of those “items” simply becomes an issue with its unique ID. The tag would determine what sort of item each issue actually is.

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.

If you go further down the rabbit hole of open-source requirements management systems, you usually end up finding obscure tools with user interfaces which look like Windows XP, or what I like to call the Web 1.0 (that’s still an upgrade from the typical user interfaces of eQMS software though, those tend to look like Windows 95).

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.

If you’re now more confused than before you started reading this article, welcome to my life as a regulatory consultant. For every problem you try to solve, three new ones pop up. Great.

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.

Looking at this table, your options suck.

Let’s look at requirements management software next.

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.

Finally, what would I choose if I would found a startup?

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!