Show HN: BookStack – An open source wiki platform and alternative to Confluence
bookstackapp.com
bookstackapp.com
With Confluence backing away from their self-hosted offerings, hopefully many will find BookStack useful. It's not supposed to be a direct replacement, and the design & content structure is quite opinionated, but it can serve many of the same use-cases as Confluence had served.
For others that haven't tried it, here's what clicked for me:
- An opinionated hierarchy of Book -> Chapter (Optional) -> Page
- Great search
- WYSIWYG OR Markdown supported
- Great integration into Diagrams.net
I love it. Thank you, thank you, thank you.> WYSIWYG OR Markdown
I will state that switching between them is pretty flaky at the moment, is done at instance level and can cause HTML in markdown. Is designed to be choose-once-and-leave. That said, in rebuilding the editor I am aiming for easy and instant Markdown & WYSIWYG switching within editor.
https://ui.toast.com/tui-editor
I checked out a bunch of text editors on a past project and this one has worked very well as a WYSIWYG markdown editor.
I looked into the LaTeX support of it for a science editor projectg
Thanks for making it open so I could learn!
there’s a lot to be learned in any event, since a lot of my projects are night/weekend ones too.
Looks like a good Notion alternative too.
Because storing documentation in repos doesn't work great when you want to organize your documentation, discover or search it.
Having thousands of documentation files in a repo, next to the code is unmanageable, much more than thousands of documentation files in Confluence. In Confluence, you can put rights, tags, titles, organize in folders, assign owners, put comments, ....
Is Confluence good at it ? Not much, but it doesn't mean we should remove Confluence.
It's a problem.
But I still think that Confluence is better than nothing
Unfortunately the docs-in-repo + PRs-for-updates approach has way more friction for drive-by-corrections/commentary/Q&A from people not on the team, so it's not a holy grail either.
[0]: https://developer.atlassian.com/cloud/
[1]: https://gohugo.io
[2]: https://github.com/Redocly/redocI've taken to putting a link to the Confluence docs in the README so folks who find the code first can easily find the docs.
Middle ground I've found on some projects: very detailed code/data-oriented notes are in markdown in the repo, tied to a PR. Those doc files may reference external items like confluence pages or specific tracking ticket/URLs that relate to the code at hand.
I was on a team that had everything in confluence, and everything was impossible to find. The closest I came to understanding it was the confluence docs were always initial plans, but were rarely updated. When updated, you wouldn't necessarily know if you needed to look through 5 versions to see earlier thinking, or which links to 'updates' confluence pages you needed to trawl through. It was as much a problem of a growing set of contributors and growing departments than anything else, but there was a new 'direction' every 6-9 months (when new folks would come in) and "this worked at my old company" so they'd document stuff however they wanted.
No one on the dev team bothered to ever look there for anything, because it was simply pointless. Few people ever looked at it for anything more than "recent updates" to see what's changed in the last 2-3 weeks. Discoverability on the size of that project (and this is 'only' 5 years old ~80 people) was just useless.
A handful of folks did keep 'onboarding' stuff relatively up to date, but it was less than a year old at that point. I suspect that if those folks moved on, those docs may slowly rot.
On the whole, keep written docs both updated and useful and findable to a growing number of people with disparate needs and different contexts and backgrounds... it's a lot harder than it might seem when first considering it. Even if you have the people on a team with the aptitude for it, it's usually low priority in every work cycle, and the first casualty when trying to hit deadlines.
I once found a plug-in that did almost the same, allowed Confluence to read and render markdown files directly from (private) GitHub repos thus allowing me to get the best of both worlds!
- docs stays in the repo (thus is much more likely to actually get updated)
- docs get exposed in Confluence (thus is accessible for the business folks that does not do git)
- docs are easy to update (as you can use any editor: vi, emacs, IDE’s etc)
So conceptually the same as you’re solution ;-)
Unfortunately we did not implement the plug-in as we have too many eggs in the Jira basket (+1.000 users) which have the unfortunate side effect that the licensing price is derived from the +1000 users even though only the much lower number of devs would use it.
That is one repeated problem we face in the Atlassian stack (well a source of their income…)- even a seemingly cheap plugin (extension or whatever they’re called) ends up in the person suggesting how to ‘work smart/not hard’ having to find the funding typically a two digit thousands of € or year (thus I never bother with that anymore :(
Size of org/team is probably a factor, but the linking between the two products is one of the few things I see it has that most other tools don't. It's probably because most other tools are single-use, and they focus on one or the other, but not both sides.
And yes, it’s super bland and uninspiring. Just like Excel or Word. I consider it a feature.
Literally the only reason it exists. JIRA is the hook that gets companies on to the rest of the horrible Atlassian stack.
The main thing that led me to stop considering it pretty quickly is precisely the concept of books - I find it both unnecessarily complicated and unnecessarily limiting.
My Org now uses DokuWiki. It has a lot of issues (the prosemirror visual editor is a good start, but in beta and out of development, for example). But it's also the least sucking option I've found. Most Wiki software severely screws up the editing experience, which may not be such a good idea when you want to get people to document things. I'm glad Bookstack does this right.
I managed to migrate my private docs from DokuWiki to markdown but it wasn't easy and it took some manual editing. I'm much happier knowing that it's in Markdown format simply because of the options that opens up for me.
I may be asked to update $WORK's wiki, which is currently MoinMoin (IIRC), and am looking for anyone with more experience so I don't have to start testing from scratch. I've run MediaWiki before, but am not beholden to using it just because of past/current familiarity.
Importing from MoinMoin would be nice, but not absolutely required. LDAP integration (at least for authentication/LDAP binds) is mandatory, but LDAP group integration (authorization/permissions/roles) isn't mandatory: that can be internal to the app. Wouldn't mind it though: either Unix-style or AD-style (memberOf).
Bookstack has a lot more inherent document organization stuff (ie: books>chapters>pages etc), it's easy as hell to administer, and it looks gorgeous out of the box.
With vanilla mediawiki, sure. If you use Cargo or SMW, you can do pretty much anything you want, especially with Cargo. Add in Lua (Scribunto extension) and you have effectively a full extra layer in your stack.
(There's also DPL (Dynamic Page List extension) as an option; if what you're doing is easy enough to express, and you're just trying to build lists of pages, you may be able to get away with just doing DPL queries and nothing else beyond that.)
It might be more technically complex than you want it to be, but it's definitely not limited to categories.
The Collection extension did that, though, but Wikimedia's weird behavior around it and their multiple failed attempts at choosing a tech stack for output — OCG/ZIM, PoD/PediaPress, Electron (not that one)/Proton — much less the next step of building that functionality into a usable feature in MW, turned me off from trying.
I need to dig into BookStack (I imagine like most wiki flavors, it'll lack the templating features in MW that I rely on), but the fact that it's built on the book/chapter paradigm from the ground up instantly catches my eye.
I don't know many things about XWiki yet, but the main difference between MediaWiki and XWiki is probably the X in XWiki (eXtensible). XWiki is more like a development platform to build a website, a blog, or a collaborative platform (internal or public) that you can tailor to your needs. What you put as contents is highly customizable / scriptable and several Wiki syntaxes are supported. The XWiki syntax can be extended to support your custom features if needed. There are a lot of apps [3] to extend XWiki (some are paid, but open source anyway so you can compile them yourself). LDAP is supported. XWiki will also provide support or specific developments if needed.
MediaWiki is developed for Wikipedia first. That's what you can read on XWiki's website anyway. But if you don't need anything that MediaWiki doesn't already provide and like its UX, it can't be a wrong decision to go for it. Many people outside Wikimedia use it and the UX is familiar to everybody, and that's huge. Both tools can be self hosted (and MediaWiki is quite easy to install), MediaWiki is mostly in PHP, XWiki is in Java. XWiki can be hosted for you by XWiki SAS. They'll also help handle migrations from Confluence and are currently handling a lot of them, and I'm sure they will be interested by hearing about migrations from other tools too.
I guess WikiMatrix would be a good starting point [4]. XWiki also have comparisons to common collaborative platforms on their websites including MediaWiki. They are obviously biased, but don't lie neither. You might want to check them out.
I hadn't encountered Bookstack, before. The UI seems quite clean. I hope we'll have the pleasure to meet and discuss at some point! The UK is not far, we are neighbors. Hmm, neighbours!
edit: by the way, you might be interested by XWiki's online presentation at FOSDEM on the 5th of February [5], as well as any other presentation in the collaboration and content management devroom, because not everything collaboration is a wiki :-) [6]
[3] https://xwiki.com/en/offerings/products/business-apps
[4] https://www.wikimatrix.org/compare/moinmoin+mediawiki+xwiki+...
[5] https://fosdem.org/2022/schedule/event/collabxwiki/
[6] https://fosdem.org/2022/schedule/track/collaboration_and_con...
It definitely has a bit of a higher learning curve than SMW, especially for non-developers, and even for developers there's some kinda weird stuff going on with it (e.g. they have this HOLDS syntax sugar and list-type fields as an answer to SMW's ability to express one-to-many relations a bit more naturally than sql can; also there's this cargo_attach parser function that I forget to do 80% of the time and that's why my tables don't rebuild properly).
Anyway if anyone does use MediaWiki and is choosing between these extensions I'm happy to talk to you about them, this is what I do for my job & I have several years experience with both (though my SMW experience is somewhat outdated, since I switched to Cargo several years ago, and only recently have started using SMW again, and that only tangentially).
I've looked at a few very extensible and featureful wikis (XWiki, Tiki Wiki, TWiki, Foswiki), but for our usecase, they seemed overwhelmingly big (I know, I'm not easy to please). They're all almost application development/scripting platforms, which isn't necessarily a bad thing, but it would mean we'd have to learn a lot more if we wanted to modify parts of them. Of the four mentioned, XWiki looked like the most "polished", its conceptual model and code looked maintainable and it has a great number of actively developed plugins. If I'm not mistaken it even allows writing pages in Markdown, which was one of our criteria.
I also looked into taking a very lightweight wiki (LOC in the high thousands) and adapting it to our needs, but found that most of those didn't have a code model that would lend itself well to doing things like swapping out a custom format for Markdown, we'd basically be rewriting half the wiki at that point. Even DokuWiki, a relatively large project, is too blasé about running regexes on page contents for my taste.
We looked into BookStack, but didn't think its content model would work too well for our idea of a wiki as a "social" site. Maybe it's just the terminology, though.
In the end, we ended up running MoinMoin 2. It's in a perpetual beta state, but it is actively maintained. The main reason was its code quality: It's small enough that understanding how it all fits together is quick, and it's structured so that adding functionality or swapping out one part of it is easy (as much as it could be for software that's over a decade old, anyway). We're programmers anyway, so we decided to go with the ability to change the wiki to our liking over initial polish. So far, I've made a new theme, wrote a script for migrating from MediaWiki, changed out the Markdown parser and added SSO with CAS. The changes aren't public yet, but will be soon.
So far I'm happy with our decision, but note that my search was heavily subjective, you very likely have other requirements and preferences.
EDIT: By the way, the criteria were loosely:
- Modifiability (I wanted a custom theme, needed a non-traditional SSO option and could see us getting ambitious about custom functionality)
- Hierarchy + ideally tags for organising
- Ability to export some pages into a print version (annually published leaflet/book for new students)
- Permission system (which we hopefully won't need to use)
- Storing pages in Markdown (helps with converting for print too)
- Macros (I'm a fan, easy-to-write extensions would be just fine)
Just fyi, MediaWiki does have support for using a different page content mark up languages (Content models in mediawiki speak). In the default that's mostly only used for special purposes like CSS pages (See Special:ChangeContentModel), but the interfaces are relatively clean if you want to add your own.
The only problem is that Docusaurus is intended for static public documentation, so it does not provide user-accounts or multi-topic content-management that you would expect from bigger wiki-like projects.
I wish Docusaurus would expand its scope to serve as a wiki, rather than single-purpose documentation - but I understand these are different use-cases altogether.
https://demo.bookstackapp.com/books/bookstack-demo-site/page...
Instead of "Actions", "Page Navigation", "Book Navigation" it should be "Page Navigation", "Book Navigation", "Actions".
Note: this seems to be an issue when the window width isn't too high to put the actions at the right side. I only noticed it after i wrote the above since i use a narrow width for the browser as my monitor is large and it makes it easier to read text. Regardless, in this "narrow mode" i think the actions should be placed after navigation.
The API is excellent, and I've used it to build some custom stuff. They recently added webhooks too.
And Dan is pretty responsive on Discord if you need help.
Thanks for making it! I consider it to be the best theme available for DokuWiki and my organization uses a forked version of it (https://github.com/fablab-luenen/dokuwiki-krypton).
Please add it to this listing as well https://www.dokuwiki.org/template
Thanks again, your work is really appreciated!
I’m curious… I wondered what the red tape is like in organisations that use open source projects like this in order to setup a GitHub sponsorship or similar.
In a previous role at a cash-strapped startup I used open source software within my team and have to admit I never arranged any contributions to the OSS projects - though if I had my time again in that role I’d be more mindful about trying to do this. Especially I think when the project is a very small or “one person” team.
https://www.reddit.com/r/opensource/comments/rwmiwn/recommen...?
Really if we’re honest, any company using Bookstack should be able to afford to chuck you $20/month or something (barring perhaps one-person bootstrapped startups). It’s likely red tape, bureaucracy and the internal culture that prevents this more than financial means.
And especially so if support demands are being made of you!
Getting approval to throw an open source project some money is likely to be even crazier (probably not a concept they ever imagined).
Now by all means notion isn't perfect at all, but for me who just wanted to start writing notes it seems the right choice at the time.
I would like to switch to BookStack as it looks great and is a great product, but the one issue that worries me is when it comes to upgrades and migrations. Generally I found when upgrading database based platforms I end up messing up hugely causing myself a huge headache, and then eventually not upgrading at all. For example I used Monica CRM, and totally botched the upgrades eventually just closing it down and using Google contacts instead.
If there was an easy way to solve for that I'd definitely be on board with self-hosting it myself. But at the moment I just don't have the time to resolve upgrade issues :(
In Bookstack, making the server private is one or two clicks. In mediawiki you have to set at least half a dozen config file variables.
Adding any of a slew of auth methods is trivial in Bookstack. In mediawiki it's finding an extension, figuring out how to configure it, and then worrying about keeping it up to date.
Bookstack is focused on "books", chapters, pages, sections - not "pages."
It's perfect for what most people and projects need, and it looks fucking gorgeous out of the box to boot.
Thank you so much!
> In mediawiki it's finding an extension, figuring out how to configure it, and then worrying about keeping it up to date.
I've always attempted to be "batteries included" with BookStack due to this frustration. Means we have to be more limited in abilities but hopefully provide a better experience for what we do allow.
This isn't really true. During install process you are asked which you want. If you press the private button when prompted you get a private wiki. If you press public you get public.
If you want to change after you installed, you do have to edit a text based config file. You only have to edit two lines, but i appreciate that text based config file is a turn off for some people.
> Bookstack is focused on "books", chapters, pages, sections - not "pages."
I agree that this is a significant difference from mediawiki. You can do that sort of thing in MediaWiki, but you'll be swimming upstream.
[Dislaimer: im a mediawiki developer]
Doesn’t mean it’s a good product though. Especially the cloud version is progressively worse, especially with regards to performance. Glad to see some competition in the area.
It is usually a better idea to organize information by teams than topics in an organization. The reason is that if the tree structure is unknown to most people, they will not be able to find information easily nor to choose the right place to create information.
You shouldn't expect everyone to browse the whole documentation to understand how it is structured in order to be able to use it
I really like Outline https://www.getoutline.com/ as it is open source, self hosted and free if you don't use the Enterprise features. It really does seem to be a Confluence replacement. https://www.getoutline.com/compare/confluence-alternative
I know I can’t tell them how to build their product, but really?
1-10 people: 10 USD/month
11-100 people: 79 USD/month
101-250 people: 249 USD/month
Helping small ISVs turn their software into SaaS offerings.
A bit idealist and of course the contract would be more complicated, but to focus on the project while having established support would be ideal.
We're a managed cloud infrastructure business (since 2006), and also run our own public cloud.. Reach out to me via nick at mnx io.
At a minimum, I'd be happy to give you some pointers in this space.
I cut and paste the docker compose file, tweaked a few things, and hit the go button. Done.
It has good Kanban boards, but does not have custom fields, so everything is done with tags. Also lacks reporting.
In places where I work, the switch to Gitlab was intentional to keep things simple. JIRA had become a monster.
In theory I'm sure you could sit around, write a billion plugins to some other wiki software, and get to confluence. But you could also just pay for Confluence!
"As nice as Confluence but super speedy" is a ... $50 million dollar business (can't say billion cuz I mean atlassian does good work!)
In my experience with Confluence, the easiest and most comprehensive way to organize information is with tables. Having a quick way to merge, delete, color cells would be great. Right now, coloring and merging are hidden away in some menus, and deleting cells will shift the bottom toolbar with the table upwards, so you can't do it quickly.
I'm currently in the process of building a new content editor which I'm hoping would provide better opportunities to make such controls more intuitive.
I can't exactly remember, why I did not chose Bookstack, but I was positively impressed with the demo. Nice to see its continuously evolving.
I myself chose wiki.js back then.
For me wiki.js had more capability for importing previously exported pages from OneNote and a more flexible document structure. In the end we went back to confluence though, as wiki.js lacked the capability to change the effective directory path of multiple pages (had to be done one at a time or via the API).
I really like both bookstack and wiki.js and they occupy a very similar niche. Do check them both out.
My ultimate wiki platform wishlist: comments module, markdown and attachment import/export, extremely fast tree hierarchy editor and renaming, and a good editor that enforces a fully standardized markup. Looks are nice too.
Anyway, I was wondering if there is a plug-in infrastructure for BookStack in on the roadmap?
Thank you for the product. Looks neat in the minimum time I have spent on this so far.
That said, I have been opening up areas for extension, especially over the last year or two. The following systems are now available:
- REST API [1]
- Webhooks [2]
- Visual Theme System [3] (Overrides of any view/translations/icon used).
- Logical Theme System [4] (Back-end logical hooks/events/extension).
It's possible we could build a common container around these methods to form a "plugin" system but that would require significant time & thought. Not sure I'll ever soon go down that route though due to the cost it could burden upon the project. My current stance is providing opportunities for extension to those who'll be able to maintain it themselves.
[1] https://demo.bookstackapp.com/api/docs
[2] https://www.youtube.com/watch?v=_zIp1ruGpoI
[3] https://github.com/BookStackApp/BookStack/blob/master/dev/do...
[4] https://github.com/BookStackApp/BookStack/blob/master/dev/do...
Easy content insertion is also necessary. We haven’t yet integrated bookstack, but I don’t see any alternatives (sticking with the locally hosted requirement)
I would add Saga (https://saga.so) to the list of alternatives.
When a company hides the product that much and forces you to only experience it with a tour guide, it's tacit admission the product sucks.
Atlassian did not consider small businesses with regulatory requirements when it decided to push everyone to the cloud. Atlassian's cloud cannot ever meet my regulatory requirements, by 2024 I need to replace Confluence. There is no way I can pay for the cost of the Data Center version of Confluence you'll be able to self-host, over $20K/year to self-host Confluence is a non-starter.
Does BookStack index uploaded files for search? If so, what formats does it support?
Can pages (or books) be exported in common formats?
Any plans to support Postgres in the future?
No, unfortunately not. You can attach files but we only support indexing (And parsing) of core page content. Indexing other formats opens up a large branch of maintenance while adding potential confusion in the platform in regards to what's considered content.
> Can pages (or books) be exported in common formats?
Yeah, Both can be exported as plaintext, markdown, contained-html or PDF. The PDF export can be troublesome but works for most simple use-cases.
> Any plans to support Postgres in the future?
Not in sight for the near future. I'm not closed off to it but there are questions of support and maintainership. My detailed thoughts on additional database support can be found here: https://github.com/BookStackApp/BookStack/issues/76#issuecom...
Is there a way or do you plan to add page translations? Some of our contributors do not speak English and I wonder what is the best approach to have pages translated, apart from creating a copy of a page and keeping all copies in sync.
Things like gitbook (& docusaurus) can often be better for focused topics or when serving product documentation to users.
BookStack tends to work better as a mixed-topic, mixed-user platform. Along the lines of an internal wiki shared by different teams. I've seen people attempt to use BookStack as a replacement for GitBook but struggle due to the structure being different.
I like that it's OSS, and obviously many will like the option to self-host, however some like to also have the choice of it being hosted (mainly for ease of management/security) - this usually also offers a revenue stream for the project.
Quickly looking at it, seems like it would work out better than Confluence, which we've been using, but found it (Confluence) to be slow to fix/implement features.
There was a similar question earlier with my more verbose thoughts in regards to hosting: https://news.ycombinator.com/item?id=29852376
https://news.ycombinator.com/item?id=29858602
Nothing user-friendly like confluence but some core systems are available to customize and extend. Of course, since BookStack is open source, some people have taken the option of maintaining a fork with deeper customizations.
I'm currently rebuilding the editor; My goal is it have an easy WYSIWYG editor that allows instance back-and-forth switching to Markdown. One of the tricker parts is avoiding obscure/custom markdown syntax for non-common/custom content blocks, as one of my main principals is to ensure user content is portable/non-proprietary.
BookStack does support Markdown content editing although it is WYSIWYG or Markdown, jumping between the two isn't really supported (Yet, Hoping to achieve this later this year).
I am a big fan of journaling, documentation and having a knowledge hub. I am not sure what is out there for a monolithic yet shared and controllable knowledge hub.
BookStack does not have git-like versioning but content changes are versioned within the database for rollback/compare/viewing.
> What about login and admin stuff?
BookStack has multiple authentication options (Including email & password/LDAP/OIDC/SAML2) in addition to admin/user/role controls.
One question though, if I deploy a containerized version via docker and upload images, where do the images reside (it seems like the php uploads folder? Just curious if I had to redeploy the image what volumes I might have to mount as back-upp
How do the permissions work ? Same way as confluence (inherited) ?
I'm not sure how Confluence permissions work. Within BookStack pages (Main content) is generally within a hierarchy of Shelves > Books > Chapters > Pages. Both shelves and chapters are optional parts of the hierarchy,and Books can be members of multiple shelves.
General permissions (Edit/Create/Delete) can be controlled per-role, and multiple roles can be assigned to a user. Permissions can then be overridden per hierarchy item. Permissions for Books and Chapters will cascade to child items unless they're overridden.
I'll trial it out tomorrow. I can see on individual pages (books?) you're tracking changes, e.g. created and last edited. Are these changes tracked in a history page for version control by any chance, ssdanbrown/OP?
Most system changes (Create, Updated, Delete actions) are recorded and displayed in an audit log view for admins. As of the most recentl release, you can trigger webhooks upon any of these; Video example [1].
Changes to pages (where documentation content exists) do have their state changes recorded so you can revert/view/compare across versions of a page. The revision limit is set to 50 by default (I think) but this is configurable.
You can login to the demo as an admin to preview these features if needed [2].
[1] https://www.youtube.com/watch?v=_zIp1ruGpoI [2] https://demo.bookstackapp.com/login?email=admin@example.com&...
Thanks for creating this app.
Our API [1] has recently matured to now support the different content types so that could be utilised for such a migration job although the API is still growing to cover more actions/models.
Have recently been thinking about possibly offering some form of paid service support service to help the process and help fund the project.
Fortunately, a lot of the handling is open sourced in atlaskit.
Reason being, I always have troubling thinking about backup AND restore, but mostly because restore is a complicated mess (Especially when you start thinking about going across versions). Just achieving backup within the interface (Of database and uploaded files) is much more feasible.
That's a tricky one to answer! The authentication systems most likely, just because of the different standards and configuration that different people demand. I've had to learn LDAP, SAML2 and OIDC protocols to a level that allows me to confidently add & maintain these systems.
> non technical
Probably issue handling & management, from a mental point of view. Dealing with such a range of ideas and requests with an ever-growing list of features/issues/support-request has been tricky. I've had to learn to change my perspective and goals when dealing with GitHub issues.
In general the social side has been a massive point of learning and challenge to me. I've recently written about many of these more extensively here:
https://www.reddit.com/r/opensource/comments/qrksgh/bookstac...
And no, I will never not shit in Atlassian products until they fix performance. Trello is the standout. Thanks for not trashing it.
Maybe I'm missing something, but BookStack doesn't even have a notion of "teams" only roles. You can't give permission of a file to a user, only to all users who have a certain role.
But I'm certainly biased as I'm building a real Confluence alternative
Sure, but there are a lot of people within that range up to tens of thousands. I have had some people mention using BookStack within environments towards to tens of thousands (Although it's likely a lesser portion enganged). Just because it may not achieve that one factor does not discount it as an alternative for significant audience.
> Maybe I'm missing something, but BookStack doesn't even have a notion of "teams" only roles. You can't give permission of a file to a user, only to all users who have a certain role.
Yeah, we don't have the word usage of "Teams" but I'm not sure what that'd offer in addition to roles. Role specific permissions can be applied to any of the hierarchy elements (Including upon page content).
As for roles. In organizations of a certain size, the concept of role is not organization wide, but team-wide. You will set for example the editor role, for some people of the team "Operations". Don't really see how this can be done on BookStack
Good luck with dokkument! Hope you gain that large-scale enterprise segment!
Most wikis are terrible at evergreen notes: the only one I can think of that might be moving the ball forward is Athens Research though I wasn't able to get their self-hosted beta running and I host dozens of other services with Compose.
Obsidian might be good too, but they don't seem too keen on supporting large business collab usecases even though enterprise is a cashcow.
I disagree, Confluence is used by tens of thousands of organizations and they don't have a very good Sales strategy, that means a lot of business choose them when they could have choose something else. So I can't buy that it is terrible everywhere.
Can we do better ? Hell yeah. But I agree with you that most of Confluence competitors are in the SMB space even though money is in large enterprise. (But that's why we are building Dokkument)
That's not wikis that are bad at evergreen notes, that's evergreen notes that are not suitable for sharing with teams. Athens or Roam research, or others works well for one person, but can't work for teams.
I don't believe the number of users in an enterprise segment buying into a software is at all indicative of the usefulness of a piece of software. Atlassian products are typically sold between people who will not be the primary users of that software.
I have yet to see a SWE missing or desiring an Atlassian product. GitHub and other SaaS products yes but never Atlassian.
I also disagree that evergreen notes aren't suitable for teams. Notes that receive a lot of attention, or are high touch, are by definition evergreen. We need more of these in orgs but most of us don't know how to tend to our companies digital gardens. A huge part of it is wordly digital cruft akin to technical debt that accrues. As it grows in size it compounds the problem of discoverability.
Note-taking is a skill that receives precious little attention, despite being so critical to knowledge work AKA anything SWEs work with daily.
In organizations the best thing to do imo is to have everyone follow the same rules. Even bad rules that everyone follow is better than everyone following its own rules. And that's clearly one thing that Confluence sucks at. But the rules can't either be the same for anyone anywhere, so there is some balance to find. The other area that can help discoverability is curation
I would be happy to have a chat with you, don't hesitate to reach out to paul at dokkument com