None of them, however, quite fit with our use cases. We needed something that non-tech people could equally contribute to and maintain (so git with static pages was out, as were the many wikis that required writing content in Markdown without a WYSIWYG UI). We needed something with tight integration with Jira, as we frequently used the ability to display Jira issue reports and auto-create wiki pages. And we preferred something that could at least display Office-doc and PDF content transparently, although that was looser. I’m glad I never had to make that call, because killing our self-hosted Confluence was going to suck badly.

I’ll never not be upset with Atlassian over that mess. I get why they did it and even kind of understand doing it, but the whole thing was handled in the most user-unfriendly, tone-deaf way possible. And then to have their godawful cloud Jira meltdown happen shortly afterwards and have them not adjust any license terms in apology for it was the topper on the cake.

Use markdown files and a SSG. It is literally free. It makes documentation quick and easy to write which means devs are more likely to actually do it. The “markdown is not very good for tables” issue has been solved long ago with either plugins such as “advanced table plugin” for Obsidian or apps like the £10 one off payment app “TableFlip” by Brett Terpstra.

Have a look at the following stuff:

- AstroJS: SSG that allows you to use any JS framework you want.

- Docusaurus: React SSG designed specifically for documentation

- SSGs in other languages: Hugo(Go), Zola(Rust), Jekyll(Ruby)

Then just Google “git cms” for a list of different options on that front. I believe Netlify cms is probably one of the most popular.

- Alternatively just write, sync and publish all in Obsidian using the Obsidian sync and publish services.

As is always the case when trying to find viable alternatives for Atlassian products: this is harder than it seems.

Both are great and opensource, i am really happy about the decision...thanks Atlassian!

[1]https://www.xwiki.org/xwiki/bin/view/Main/WebHome

[2]https://www2.fossil-scm.org/home/doc/trunk/www/index.wiki

Obviously there's a bit of a difference in philosophy between Mediawiki and Confluence. But they are otherwise quite comparable in capabilities when it comes to outright information-sharing. Last I worked in this space, there were conversion tools between the two.

[1] https://www.mediawiki.org/wiki/MediaWiki

Of course there are also a number of semi-external search engines you can add on if you want that can improve results for plain search.

Finally, mediawiki tends to be a fairly rich/high quality data source for general purpose search engines to ingest. If you have a reasonably sized intranet that also happens to have a mediawiki wiki on it, you might end up getting better results for everything, not just the wiki.

For a small org of 50-100 on prem? That's practically idling. Once it's set up it can run almost indefinitely without anyone looking at it all too much. Depends on if you already have someone on site who can watch over an extra LAMP [2] server/vm/[docker] container, run occasional backups etc.

[1] Wikis have interesting properties wrt. Dunbar's number which do not quite fit in this margin.

[2] Linux/Apache/MariaDB/PHP

https://www2.fossil-scm.org/home/doc/trunk/www/index.wiki

This: https://support.atlassian.com/confluence-cloud/docs/comment-...

The comments are tied to specific sections, and sit in a sidebar. So you're commenting on a specific section, or even passage of text. It really makes a code-review style flow for content dead easy. If anyone knows of a similar capability in another product, I'd love to hear about it.

I also like how the documents are literally markdown files and you can synchronize/backup the data to a git repo and the data isn’t even reliant on the wiki.js instance you run to be readable.

[0]: https://www.getoutline.com/

We run a managed support function so if you need help, we can take on supporting you with a different product in place of Atlassian.

My biggest gripe is the lack of native code block support. There are ok workarounds but something native would be better.

Edit:

> By law we are not allowed to use a cloud solution.

Missed this on my first read. Shared notebooks should be able to be stored wherever you store things in your network.

Think "Intranet CMS". Announcements, event signup pages, "feelgood stories", all kinds of digital resources, and all with lots and lots of macros.

Sales won't commit their success story with a customer to your git repo. Marketing won't share their corporate design templates in your git repo.

I find AsciiDoc to be more robust, but I agree broadly that using text-based documentation in version control – and, ideally, published via the same kind of VCS-driven automation you’d use to build and pubish software from source – is the best way to do things.

I really wanted to have a nice private wiki at home, but i loathed (and still loathe) editing markdown files to do that. I really liked the editing experience in Confluence.

I was about to buy the self-hosted license and accept the 4GB-minimum-requirement tax, but then I gave MediaWiki a try, and so far i've never looked back.

Getting into mediawiki is definitely a journey, and it has it quirks, but it's been a lovely experience so far. It looks very nice (I'm using the Timeless skin with some minor css tweaks) and editing is a joy (the VisualEditor extension is now bundled with MediaWiki).

Also, turns out there are some companies selling specialized MediaWiki consulting, and there also is a company that sells its own MediaWiki "distribution" with some additional enterprise features (https://www.mediawiki.org/wiki/BlueSpice/en).

It checked all the boxes with respect to a WYSIWYG editor, configurable permissions and OAuth authentication.

[0]: https://www.bookstackapp.com/

https://js.wiki/

For wiki, as Confluence is, I'd rather propose something like Dendron.so[1]

1. https://wiki.dendron.so

When people host a companies code, the vendor ends up with a lot more support cases due to externalities that the vendor does not control and the customers of the product will tweak and modify it in ways the vendor did not expect and does not support. The customer can see under the hood and find embarrassing mistakes. The customer may have network configurations and use cases that the vendor never expected their application to reside and function in.

There are pros and cons to each method and both the vendor and customer stand to benefit from one method over the other but ultimately the vendor has to decide if they are willing to take on the extra support load and extra time to work with the customer to ensure best practices are followed for the app, the servers, for backups, for disaster recovery procedures, etc... In most cases the vendor does not have the ability to debug a customer hosted instance directly and depend on working with intermediaries sometimes over video chat screen sharing sessions.

Vendors are not suppressing self hosting due to technical overhead. In fact, you shrink both your operational expenses and technical overhead by delegating to your customers entirely running, securing, and operating your software.

Vendors are suppressing self hosting because it's not a revenue generation stream, and to peddle back FOSS commitments. Customers are required to pay for a cloud-hosted version, while self hosted is free. And while they're at it, why continue to support open source once you cripple the self hosted version and only support the opaque cloud version?

This same playbook has been executed time and time again. Elastic comes to mind as a prominent example.

That's why I said I don't like my own answer. I know its conditionally half true and I have always preferred to host things myself. I can put the right security controls in place and I can coordinate patch management to not conflict with customer code patch management. I am also a bit jaded after dealing with three-letter-agency funded hardware that must have a cloud connection to perform big data analysis on logs and totally not to have that back door connection into the datacenter and psychologically condition the network team into expected to see hundreds of GB of data flow to a cloud provider. But I tried as best I could to keep that out of my answer.

As a developer I never want to work on anything that isn't "cloud" (meaning hosted by us on our infra) ever again. It is sooooo much better in every way.

As a customer I hate cloud stuff. I wanna host it myself and have full control.

There are two business reasons I see that providing a self-hosted solution would actually be beneficial. First, it would expand the market potential to include companies that for whatever reason do not want to use the cloud system. Second, it would give another revenue outlet by charging hefty fees for support. How many companies like Apple sell a warranty that the purchaser might not ever use? I could see that happening here too.

Fossil is good. Some form of wiki based thing with the roots in distributed source control works well.

but if Sharepoint is an option, could it also be Nextcloud ?

This article summarizes it nicely. [1]

[1] https://www.govloop.com/on-premise-vs-on-premises-the-debate...