Get the top HN stories in your inbox every day.
ssddanbrown
maineldc
Thank you, thank you, thank you. I use started using bookstack when I realized that I wanted a place for long form / long term storage of documents separates from my Notes / To dos. I love it and I deeply appreciate your hard work.
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
ssddanbrown
Thank you! I love to hear about the specific features people enjoy.
> 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.
mjrpes
Have you looked at Toast UI Editor (MIT license)?
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.
rhizome
Just on a practical level, you might as well just disable the option to convert, especially if you're going to swap it out anyway. Sometimes just flipping the switch on a task opens up a little cognitive space for the rest of your work. :)
chrisweekly
Obsidian integration would make me (and likelya bunch of its > 400k other users) happy!
tough
outline has a nice rich-markdown-text-editor package for react based apps in case you can re-use it!
I looked into the LaTeX support of it for a science editor projectg
hardwaresofton
Bookstack looks like an amazing feat of engineering — it’s overwhelmingly the wiki I want to deploy given other F/OSS options. just today I was showing it to a friend and it is impressive how clean and considered it is. Thanks for maintaining and improving this project
ssddanbrown
Thank you! This kind of feedback means a lot, provides the fuel to avoid burnout.
bachmeier
Impressive that you've stuck to it for more than six years. I remember testing an early version. Looks like you've made a lot of improvements in that time.
ssddanbrown
Thanks! I've learnt a lot in that six years. I've been quite proud of our constant, yet steady, pace of development while retaining upgrade compatibility (where possible).
iambateman
I dove into your Laravel code the other day to see how you organized things.
Thanks for making it open so I could learn!
ssddanbrown
Happy to help! I will say that I would in no way present it as an example of a clean codebase. 6 years of weekend and night development, while having significant code understanding/learning during that time, has lead to somewhat of a mix of ideas and approaches. Constantly trying to re-align things though!
rhizome
Perfectionists don't ship, take an extra slice of pie!
iambateman
Totally makes sense!
there’s a lot to be learned in any event, since a lot of my projects are night/weekend ones too.
heywot
Funny to stumble on this thread just days after we started evaluating BookStack for internal use! Thanks for this piece of software. I'm really enjoying it so far and am looking forward to integrating it into our daily processes.
tailspin2019
This is superb. Thanks for making this.
Looks like a good Notion alternative too.
1cvmask
We could potentially add passwordless MFA from saas pass to your project. Good luck with it.
ssddanbrown
That's cool. I recently built MFA into the access flow, with a sight to extend methods where needed, although any instance using the SAML/LDAP/OIDC auth options could enforce MFA on the identity provider side.
Sheen96
Glad to see any alternatives to confluence (or Atlassian in general). I've used Confluence for a good 4 years or so and for the life of me, I can not fathom why anyone would use this for storing documentation for code etc, as opposed to storing things direct in a repo. I can understand it's use somewhat for business folks, but even then, the way of organising things is abysmal, every solution (such as rich text editing) feels very off the shelf/MVP, uninspiring UI, the list goes on. It feels like most companies that use it already use the Atlassian stack of JIRA/Bitbucket, then feel the need to tack Confluence onto the end because it's there.
polote
> I can not fathom why anyone would use this for storing documentation for code etc, as opposed to storing things direct in a repo.
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.
dont__panic
Confluence is a fantastic way to ensure that nobody ever finds your documentation. The WYSIWYG editor is so painfully slow, buggy, and laggy, it actually reduces the chance of anybody bothering to update documentation. When organizations change names, URLs change completely and you can sometimes never find a linked page again after it moves. Navigation in confluence is painfully slow, even though it's a bunch of static text. Embedding code snippets or images is an exercise in frustration.
It's a problem.
solarkraft
Confluence sucks! But it does have one of the best editing experiences I've seen (it also sucks, but less than the rest). You can privately draft pages before publishing them, get diffs of versions, it auto-saves and you even get real time collaboration with others. That's worth a lot, imo.
kyriakos
Agree about no one finding your documents. I have trouble finding my own documents in it, don't expect others to be able to find them. Unless you are absolutely obsessive about organisation and linking documents things remain a disjointed mess, would have been cleaner to store markdown in the file system in a directory tree than in confluence.
polote
I mean, I know. I've wrote an article called "We deserve better than Notion and Confluence" and I spend my days building an alternative to Confluence for orgz.
But I still think that Confluence is better than nothing
a10c
For what it's worth. I work at Atlassian and we don't use Confluence for documenting code.
caspar
Also an Atlassian here. For anyone wondering, we tend to use Confluence for planning, decisions, team process, tech specs, etc but use an internal view of DAC[0] for code docs. Think Hugo[1] crossed with redoc[2] with a dash of GraphQL support.
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/redocbbkane
There are a couple reasons I prefer docs in Confluence to docs in repo: - I can update the docs without going through Git peer-review (admittedly this is a culture issue, not a technical one). - We have "code-tangential" docs already in Confluence and it's nice to have one place to search - Non-devs (like lawyers) find Confluence more familiar
I'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.
mgkimsal
> I've taken to putting a link to the Confluence 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.
bitschubser_
In my old (and soon current again) shop we used confluence extensively, to get the best from both worlds we usually kept the documentation next to the code in markdown or asciidoc files and synchronized them to confluence in a CI/CD pipeline (confluence was read only for these sections) maybe I can open source these helpers when I'm back... a two way merge was also in the making :). we could sync whole file trees with automatic link crosslink generation, asset management and versioning support in confluence
tveyben
I face the same problem as our company is heavily using the atlassian products (Jira/Confluence…)
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 :(
polote
In my opinion this is the way to go, documentation close to the code but still indexed in a real knowledge management tool. That's one thing that we are building at Dokkument, but I would be really interested to know more about what you have done, especially how those files are then indexed on Confluence
bitschubser_
It just used the confluence REST API, so they where indexed like regular edits
mgkimsal
I always found the ability to draft confluence docs then create jira tickets from within confluence to be the 'obvious' use case, but I don't often see people do it. Or... I've seen some orgs do it a lot, and some not at all (even when they have both jira and confluence together).
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.
leokennis
I think Confluence “shines” as a sort of “Wikipedia for your company” with the added benefit that it’s simple enough that anyone can create a nice looking page and there are plugins to cater to different disciplines.
And yes, it’s super bland and uninspiring. Just like Excel or Word. I consider it a feature.
pm90
> It feels like most companies that use it already use the Atlassian stack of JIRA/Bitbucket, then feel the need to tack Confluence onto the end because it's there.
Literally the only reason it exists. JIRA is the hook that gets companies on to the rest of the horrible Atlassian stack.
kyriakos
As if jira itself is not horrible. But to be fair to jira I recently tried the cloud version which is untouched by any scrum masters or management and its way better than what I have to endure in my day job with hundreds of customizations it has received over the years to shoehorn every kind of metric
solarkraft
I remember considering BookStack while looking for a (surprise) replacement for Confluence.
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.
INTPenis
As a former DokuWiki user (both pro and privately) the biggest issue is when you want to migrate from DokuWiki.
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.
throw0101a
Can anyone with experience with multiple wiki platforms compare this with XWiki and/or MediaWiki.
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).
KennyBlanken
Mediawiki is page focused, needing a lot of tweaking to make it act like something other than a completely open public page editor. Trying to collect pages is annoying ugly; about the best you can do is with "categories." Mediawiki tries to do too much with document metatags and whatnot. Mediawiki is ugly/outdated looking (IMHO) and requires lots of php config file editing.
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.
RheingoldRiver
> Trying to collect pages is annoying ugly; about the best you can do is with "categories."
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.
trynewideas
I enjoy Cargo and DPL, they're powerful and great tools for automatically aggregating and filtering content, and I used both of them a lot at a MW that I was an admin on for several years. But it still isn't easy to build an ordered, hierarchical, book-like structure with book-like output, which was a constant request. It wasn't just technically complex (no users wanted to learn how to do it, they wanted one person to do it for them), it also didn't do the one thing most people wanted it to do.
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.
jraph
Future XWiki employee (should start in March!). Feel free to reach out to XWiki [1] [2], they'll be happy to answer your question and address your specific needs. They are nice. Feel free to contact me if you'd prefer but I'll be less competent than them for obvious reasons.
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...
zozbot234
There is a "semantic" extension to MediaWiki that makes it easier to support many enterprise use cases with data visualizations, custom queries (potentially referencing information from multiple wiki pages) and the like. It is somewhat widely used for wikis other than Wikipedia, that can simply defer to the Wikidata project for those needs.
RheingoldRiver
SMW works okay but if you have technical ability, I'd recommend Cargo (https://www.mediawiki.org/wiki/Extension:Cargo) instead. It's a somewhat limited SQL wrapper (limited - e.g. subqueries aren't supported, which can be annoying on occasion but tbh I've only missed them maybe 3 or 4 times, wiki queries tend not to be too complicated) which is roughly equivalent to SMW in maybe 50% of use cases I've encountered, inferior in maybe 2%, and significantly better in the rest.
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).
jraph
I didn't know! Linking for whoever would like to look into this.
dvdkon
I'm currently helping set up a wiki for students of a STEM faculty, and we've settled on MoinMoin (v2, that is). We're broadly building on a previous MediaWiki setup, which we've found to be too "Wikipedia-oriented".
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)
bawolff
> 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.
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.
arcastroe
I looked into a million wiki/documentation projects and my absolute favorite for consumption (reading and navigation) was Docusaurus [1].
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.
badsectoracula
From a quick look at the demo it looks nice, however i think that since people are more likely to read than edit, the "Actions" should be lower than the navigation panels. E.g. in this:
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.
IceWreck
I used to use Dokuwiki as my personal notes app/knowledgebase pretty heavily. Switched to Bookstack two years ago and never looked back. It has everything you need in a Wiki, no third party plugins needed like Dokuwiki.
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.
solarkraft
Huh, so that's why the last update of Argon was 2 years ago :-)
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).
IceWreck
Thank you for making this. I added a link to your fork at the top of the repo's README.
Please add it to this listing as well https://www.dokuwiki.org/template
solarkraft
There are still a few things I'd like to fix before really feeling confident in publishing it to the index, but I guess I might as well because it does already provide some value.
ssddanbrown
Thanks for the kind words! Always nice to hear happy feedback regarding the API, good to know it's getting some use.
pSYoniK
Really enjoy your project! Setting it up on a free Oracle cloud VPS is very straightforward, setting up automated backups is also very easy and restoring is again, very very easy! Thank you for your hard work on this project, it made me start working on my own take on how notes should be handled and it gave me a place to keep things that I find interesting and keep notes on everything I learned throughout uni over the past couple of years.
Thanks again, your work is really appreciated!
ssddanbrown
Thanks! Interesting to hear about the backups and restore being easy, I often hear complaints due to not having in-app backup/restore but the risk of causing issues, over doing that at an infrastructure level (Via mysqldump/file-copies), has always been a point of worry for me when thinking down the in-app route.
shdisi
Thanks for creating and maintaining BookStack. My company has used it for around three years, and recently integrated it with Okta for SSO. It’s fast, simple to use, and the recent search improvements have really made it an excellent product.
ssddanbrown
Awesome to hear. Especially happy to hear good feedback regarding the search improvements, I spent a good amount of time on those and this is the first feedback I've had since.
tailspin2019
Out of interest, does your company support the author via sponsorship or other means?
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.
ssddanbrown
I recently come across a similar question on Reddit. While I can't offer the company perspective I can offer a maintainer perspective:
https://www.reddit.com/r/opensource/comments/rwmiwn/recommen...?
tailspin2019
Great comment and very interesting to read your perspective on it.
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!
budafish
Some time ago I was trying to transition to platform to help me capture my own personal notes and organise my knowledge. BookStack was a good front runner, but I think the lack of mobile editing along with the hassle of upgrades made me end up using Notion.
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 :(
ssddanbrown
I can understand that, Especially since Monica and BookStack share the same framework. Database issues do happen unfortunately, although I take changes pretty seriously when approach schema changes. For those that have requested support upon such issues, I've been able to get them up and running again in the vast majority of cases.
punnerud
Should also check out MediaWiki. The last year the visual editor is finally included with PHP, making the installation simple: https://mediawiki.org/wiki/MediaWiki
KennyBlanken
A visual editor does not solve mediawiki's bloat which is useless for 99% of anyone who isn't Wikipedia or another large organization, nor MediaWiki being entirely organized around pages. Nor does it solve Mediawiki's ugly, Web 1.0 design.
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.
ssddanbrown
> 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.
bawolff
> 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.
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]
unixhero
No not really any point in also checking out MediaWiki. Bookstack has surpassed MediaWiki in usability by leaps and bounds. They are not even comparable any more, aside from being able to do wiki edits they are separate use cases by now.
ecshafer
This looks like a great piece of software. I was never a fan of Confluence, but that is more that Confluence, I feel is backwards. Since confluence, the few opinions is has, is reverse. You typically get some kind of set up like Confluence Space is owned by a person, who then adds approved editors. The default should be open editing, then locking down to specific people. What typically seems to happen in confluence shops is that information ends up being organized by TEAMS not by topic. Which is a terrible way to document. This idea of Books -> Pages seems to be more opinionated that would hopefully get people to not make this mistake.
Too
Used confluence in several shops and never seen anything like that happen. Sounds terrible. Spaces are usually few and edit for all. Must have been bad admins and management.
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.
polote
> What typically seems to happen in confluence shops is that information ends up being organized by TEAMS not by topic
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
Get the top HN stories in your inbox every day.
I've been working on BookStack for over 6 years now, learning a lot about open source project maintainership during that time. Originally developed it while looking for a documentation system for my mixed-technical-skill workplace. Wanted something easy to use without having to get finance involved when increasing our user count.
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.