Wiki software is bought for the archive and compared on the editor

The best wiki software depends on who is going to read it, and for most companies that is everyone, in a browser, with no install. That puts Confluence, Notion, Outline and BookStack ahead of everything else on this page before any other feature is weighed. What separates them after that is not the editor.

A wiki is the one tool a team buys expecting to still be reading it in five years, and that expectation is the whole product. Almost everything in a working wiki was written before most of the people reading it arrived: the runbook from two reorgs ago, the decision nobody can remember making, the page that is eighty percent right. The lists currently ranking for this search sort wiki software on the authoring surface, which is the editor, the templates, the search box and now the AI assistant. Six of the top nine are published on the domain of a vendor selling a competing product. Not one of them asks what the reader who turned up afterwards actually gets.

So this page sorts on the three questions that reader has. Can they tell whether a page is still true? Can they see the pages written before they joined? Can they correct the one they found wrong? A different product wins each question, and the middle one has no good answer in any of them, which is the part Baalda is here for and the reason most of this page is not about Baalda at all.

Which wiki software should you pick?

Ten candidates, with the thing each is genuinely best at. Licences are read from each project's own licence file. "Not documented" means the vendor's documentation describes no such feature and I could not find one, not that a team cannot build something similar out of templates, banners and automation rules.

Two honest notes on that table. Outline is source-available rather than open source: its licence file is Business Source License 1.1, with an Additional Use Grant that lets you run it for your own organisation but not offer a document service to third parties, and a Change Date of 12 October 2030 after which it becomes Apache-2.0. And the question of where the text physically sits while the wiki is running, which decides what a migration costs you later, is a separate axis with its own answer. DokuWiki's own project page is the short version of it: "It works on plain text files and thus needs no database." That axis is worked through properly in Confluence alternatives that keep the markdown, and this page does not re-run it.

Can the reader tell whether a page is still true?

This is the question a wiki fails at most often, and exactly one product on the list treats it as a feature rather than a convention.

Guru builds the whole product around it. Its documentation puts it plainly: "Verification is Guru's way of marking content as trustworthy and current." A card carries a verification status, a named verifier and an interval, which can be 30, 60 or 90 days or "Does not expire", and setting an interval "triggers periodic reminders to the assigned verifier". The part that makes it work is the automatic invalidation: "If someone edits a Card but is not the named verifier (or in the verifying Group), the Card will become unverified." The badge cannot quietly stay green while the content moves underneath it.

Confluence's answer is a label. Content statuses shipped to Confluence Cloud and the three suggested defaults are "Rough draft, In progress, and Ready for review". Atlassian's own page is clear about who controls it: "Anyone with edit permissions can set the content status." Nothing expires it, nothing is notified when it changes, and an edit does not reset it. It communicates intent, which is useful, and it is not a review cycle. Teams build the review cycle on top with automation rules or a Marketplace app.

For the self-hosted engines, nothing is documented. DokuWiki, BookStack, Wiki.js, MediaWiki and XWiki all give you page history and a last-edited timestamp, and a last-edited timestamp is not the same claim: it tells you when somebody touched the page, not whether anyone has checked that it is still correct. Baalda has nothing here either, and that is a real gap rather than a positioning choice. If the main thing your wiki has to do is assert that an answer is current, Guru is the better tool and this page is the wrong page.

Can the reader see the pages written before they joined?

Here is the question none of them can express, and it is structural rather than a missing checkbox.

Every wiki on the list resolves access by container. In Confluence it is the space, then the content item, and Atlassian states the rule directly: "Confluence's permissions model is set up so that content can only be further restricted from whatever the container is set at. A content item cannot have greater access than its container, which may be the space or another content item." In Wiki.js it is the path: a group's page rules match with "Path Starts With", "Path Ends With", "Path is Exactly + Children" or "Path Matches Regex". In BookStack it is the shelf, book, chapter and page. In DokuWiki it is the namespace.

A container has no notion of when a page was written. So a space permission returns the same answer for a page written in 2018 and one written yesterday, and the only lever an admin has for a new hire is the blanket one. That produces two bad outcomes and teams pick whichever they fear less. Open the archive and the new person reads the half that is wrong with no way to tell which half, which is the previous section's problem made worse. Close it and they read nothing that predates them, so they ask in chat, somebody answers from memory, and the answer does not land in the wiki either.

Baalda treats the archive and the current work as two different access decisions, because they are two different risks. Access is per folder and per note, resolved on the server, to one of edit, view or none. On top of that, Vault Settings carries a separate control called New members, which is also Can edit, Can view or No access, and it governs exactly one thing. The documentation describes it in a sentence: "What someone sees for the notes that existed before they joined. It is snapshotted when they join, so changing it later does not reach back into people already in the vault."

Underneath that setting is a default on the organisation and a per-member snapshot written the moment somebody joins:

organization_access_settings.join_default   -- 'private' | 'readonly' | 'open'
member_access_snapshots (organization_id, user_id, mode, access_revision, snapshot_at)

A trigger on membership insert copies the current join_default and ACL revision into that snapshot row, stamped with the time the person joined. The permission resolver then applies the snapshot only to notes whose creation time is at or before that stamp. Notes written after somebody joined fall through to the vault's live posture instead, and a grant written at a later ACL revision can still raise what the snapshot gave them, so it is a starting position rather than a permanent deny. The default, if nobody sets it, is private.

What that buys in practice is the setting most wikis cannot describe: new people get view on the ten years of pages that predate them and edit on everything the team writes from now on. They can read the archive and they cannot silently rewrite it, and nobody had to pick between the two with one switch. The mechanics of how the grants combine are in the access control documentation.

One more consequence worth knowing, because it cuts the other way. When access is taken away in Baalda, the local .md file moves to that device's trash on every device that had it, and live editing sockets are force-closed rather than left to expire. A revocation that left a readable copy on a laptop would be cosmetic. It also means a Baalda vault is not a place to put something you want somebody to keep after they leave.

Can the reader fix the page they found wrong?

Short answer: in every product here, only if somebody gave them edit rights, and the person who just hit the gap is usually the one with the least standing to ask. That is its own problem with its own answer, and the argument is laid out in how to write internal documentation rather than repeated here. The one thing worth adding in a wiki context is that the two previous sections make it worse together: a reader who cannot tell whether a page is stale and cannot edit it has no move except to ask a person, which is the failure mode a wiki was bought to prevent.

Where is Baalda the wrong wiki?

Most of the time, and the reasons are not small.

Baalda ships a desktop app for macOS, Windows and Linux and no browser client at all. If the point of your wiki is that anybody in the company can open a link and read a page, Baalda cannot do that and Confluence, Notion, Outline and BookStack all can. There is no published read-only site, no page comments, no approval workflow, no verification badge, and no mobile app. There is no page tree in the wiki sense either: it is a vault of folders and markdown notes with a graph over the links, which is a different shape from shelves and books.

The join snapshot has a limit too. It is set per vault, not per folder, so "the new engineer sees the engineering archive but not the HR archive" is not one setting. It is the vault-wide default plus explicit folder grants, which is more administration than a single switch and it is worth being clear that it is.

Baalda is Apache-2.0 and free to run locally or self-host. The managed backend is free for two people and one synced vault, and Team is $10 per seat per month, or $110 per seat per year, with a minimum of three seats. For a solo personal wiki that is more plumbing than DokuWiki needs, and DokuWiki is the better pick. For a side-by-side on the enterprise case, there is a Baalda and Confluence comparison.

So which one should you install?

• Everyone reads it in a browser and you already run Jira. Confluence, and expect to add an app or an automation rule for review.
• Everyone reads it in a browser and nobody will write markdown. Notion.
• You want to run it yourself and you want it to look good. Outline, as long as BSL 1.1 is acceptable to your legal team until October 2030.
• You want to run it yourself and you want it simple. BookStack.
• The answers have to be provably current. Guru.
• The archive matters more than the app. DokuWiki.
• It has to be markdown files your team owns, several people edit at once, and an AI reads through the same permissions as a person. Baalda, and read the browser limitation above first.