Open source knowledge base software: the licence is the easy part

The short version

• Open source buys three things in a knowledge base: the right to change the code, direct access to your content, and an exit that needs nobody's agreement.
• The licence fee is zero and the work is not, so model self-hosting in hours rather than in seats.
• For an internal wiki that is never distributed, the difference between a permissive licence and a copyleft one rarely shows up in daily use.
• Source-available licences such as BSL and SSPL are not open source, however the download page describes them.
• If nobody on the team owns upgrades, a hosted tool is the better choice and the licence argument is noise.

What does open source knowledge base software actually give you?

Three things, and they are narrower than the word 'open' suggests. You get the right to read the code, change it and run it where you choose. You get your content sitting in a database you can query directly. And you get an exit that does not depend on a vendor's goodwill, because the software that reads your data is code you already hold. That is the list.

What you do not get is free. A Harvard Business School working paper modelled the replacement cost of widely used open source packages at around $9 trillion, by estimating what firms would have to spend to write the equivalent themselves. That is a model rather than a price list, built from Census II usage data, BuiltWith scans of almost 9 million company websites and COCOMO II cost estimates. Read it as a statement about how much labour sits inside software nobody invoices for.

For a knowledge base the practical translation is short. Open source moves cost from a subscription line to a people line. Whether that is a good trade depends entirely on whether you have the people.

Which licence matters, and when does it actually bite?

The one in the repository, and for most internal knowledge bases it does not bite at all. If you run a wiki for your own staff and never ship the code anywhere, a permissive licence and a strong copyleft licence feel identical in daily use. The difference shows up at two moments: when you embed the tool in something you sell, and when you host it for people outside your own organisation.

There are three families worth telling apart. Permissive licences, MIT, Apache 2.0 and BSD, let you do what you like as long as you keep the notice. Copyleft licences, GPL and AGPL, require that changes you distribute go out under the same terms, and the AGPL extends that obligation to users who reach the software over a network. That last clause is the one that catches agencies planning one instance per client. Source-available licences, including BSL and SSPL, let you read the code and restrict how you may run it. They are not open source.

The check takes five minutes. Open the repository, read the LICENSE file, then look at when it last changed. A project that has relicensed once has shown it is willing to, and the version you deploy today is the version you are entitled to keep running. If a tool is going to hold how your company explains itself, that history is worth reading before the migration, not after.

What the licence does not cover

• •Backups you have actually restored from, as opposed to backups you have configured.
• •Upgrades, including the database migrations between major versions.
• •TLS certificates and their renewal.
• •Single sign-on, and removing access the day somebody leaves.
• •Search that still returns the right page once the index gets large.
• •Whoever takes the call when it is down on a Friday.

What does self-hosting cost after the licence?

Hours from somebody who can be interrupted. That is the honest unit. The server is the cheap part. The expensive parts are the upgrade that needs a database migration, the restore test nobody scheduled, the certificate that expired on a bank holiday, and the directory sync that stopped quietly three weeks ago.

Most serious open source projects also sell a supported edition, and the shape of that pricing deserves a look before you assume open source is the cheaper column. Nextcloud, for example, publishes its enterprise price list openly, charged per user per year and quoted net of VAT. That is the same shape as a hosted seat price. You are buying support rather than permission to run the software, but it still lands on a per-seat line in the budget.

So model it in hours. Count the two upgrades you expect this year, one restore test, the SSO work, and the migration out of whatever you use now. If that comes to under a day a quarter and you have someone who can do it, self-hosting is fine. If nobody owns it, the licence saves you nothing, because a wiki that is six months out of date costs more than a subscription.

Self-hosted or hosted: how should a small team decide?

By asking who will own the upgrade, then by checking which of your constraints is real. Three constraints justify self-hosting on their own: content that cannot legally leave a jurisdiction, a client contract that forbids third-party processing, or an integration you need that no hosted product exposes. Price, on its own, usually does not.

If you want a public baseline for how firms of your size actually run infrastructure, rather than a vendor's claim about it, Eurostat's enterprise ICT survey is the thing to read. National statistical authorities surveyed 157,000 enterprises out of the EU's 1.53 million with ten or more employees in the first months of 2025, and about 83% of that sample were small firms with 10 to 49 employees. We do not have a figure for your sector, and we would rather say so than produce one.

There is also a middle option people skip past. Several open source projects run their own hosted version. You keep the licence, the export and the exit, and somebody else runs the upgrade. For a lot of teams under fifty people that is the right answer, and it is worth checking which of your shortlist offers it before you provision a server.

Which open source knowledge bases do people shortlist?

They come in four shapes, and the shape matters more than the feature list. Wiki-shaped tools organise a page tree and are built for documentation that lives for years: BookStack, Wiki.js, XWiki, DokuWiki and MediaWiki all sit here. Document-shaped tools use a block editor and feel closer to Notion: Outline, Docmost and AppFlowy are names you will meet. Suite-shaped tools treat the knowledge base as one app beside files and calendars, which is where Nextcloud sits. File-shaped setups keep markdown in a git repository and render it with MkDocs or Docusaurus.

Pick the shape by how your content behaves. If pages are edited by many people and need review, the wiki shape wins, because the page tree and the history are the product. If most pages are written once by one person and read by everybody, the document shape is pleasanter and people actually write in it. If your knowledge already lives in markdown next to code, the git shape costs you nothing and gives you review for free.

This is a map, not a ranking, and we are not going to tell you which of them is best for you. Licence and hosting terms change, and some projects have relicensed, so check each repository yourself rather than trusting a comparison post, this one included.

How do you tell whether a project will still be maintained in three years?

Look at releases, and at how many people can merge. A project with releases in the last twelve months, more than one maintainer with commit rights, published security advisories and documented upgrade steps between major versions is a project you can plan around. One with a single maintainer, a long gap since the last tag and an issue tracker full of unanswered upgrade questions is a project you will end up maintaining yourself.

Self-hosting also means you inherit the dependency tree, and eventually somebody will ask you what is in it. Black Duck's 2026 analysis is built from audits of 947 commercial codebases, covering 2,843 individual projects, submitted between November 2024 and October 2025, largely for mergers and acquisitions, regulatory compliance and internal risk assessment. That sample tells you who asks for a software inventory: acquirers, auditors and enterprise procurement. Producing one is cheap if you start on day one and awkward if you start in the week of diligence.

None of this needs a policy document. It needs you to know which version you run, where the container image comes from, and that upgrading is one person's job rather than everybody's assumption.

How much should you trust the adoption figures you will read?

Less than the way they are presented invites you to. Most numbers in this category come from vendor-run surveys, and the methodology usually sits one click away from the headline. That does not make them worthless. It makes them weaker evidence than a mechanism you can test yourself in an afternoon.

Two examples, from sources we would otherwise happily cite. Atlassian's State of Teams work surveys 12,000 knowledge workers and 200 executives, and the page summarising it does not state the field dates or which countries were covered, which the linked PDF carries instead. The annual State of Open Source report, run by OpenLogic with the Open Source Initiative and the Eclipse Foundation, is the usual source for open source adoption claims; its 2026 takeaways page names the collaboration but not its own respondent count or field dates, and the previous edition surveyed 433 respondents between 17 September and 20 December 2024.

A few hundred self-selected respondents is a reasonable signal and a poor foundation for a decision about your own stack. So weigh the mechanisms instead. The upgrade either has an owner or it does not. The export either keeps your page structure or it does not. Neither of those will be revised next year.

Will it work as the base for an AI assistant later?

Ask three questions of every candidate, and ask them now rather than after you have 4,000 pages in it. Can you export everything in a format that keeps the structure, headings, hierarchy and links included? Does the API expose per-page permissions and not just text? Does every page have a stable URL that still resolves after somebody renames its parent? If the answers are yes, almost any of these tools can sit under an assistant.

A knowledge base is the input to retrieval, and retrieval quality tracks structure more than it tracks the editor. Clear titles, one topic per page and a hierarchy that matches how people actually ask questions do more for an assistant's answers than any row on a feature grid. Permissions matter for the same reason. An assistant that cannot tell who is asking will cheerfully summarise the page you did not want summarised.

The third question is about provenance. If the assistant cannot link back to the page it used, people will not trust it for long, and 'it is in the wiki somewhere' is an awkward answer when somebody asks where a figure came from. Stable URLs are what turn an answer into something a reader can check.

What to check before you shortlist