Show HN: I am building an open-source Confluence and Notion alternative

Accessibility in both Notion and Confluence is absolutely abysmal. Any chance you have thought about this while working on Docmost so far? This is a pretty important thing for companies to adopt this, with ADA in the US and the upcoming EAA within the EU. Also it'd be nice to have a product that actually did their homework where this is concerned for once :) Let me know if you want me to give it a once-over. DIsclaimer: native screen reader user, blind person, developer, accessibility auditor and all that jazz.

kazinator · 2 years ago

> Accessibility in both Notion and Confluence is absolutely abysmal.

And that's just for people with typical hands and eyes.

Imagine of what it's like for people with disabilities.

input_sh · 2 years ago

Piggybacking to ask: I'd love to pay like a $100 to a person with disabilities to use my website for a couple of hours and shit on the experience. Has anyone ever done this? Is there a service you've used and have been happy with?

My exerience with automated tools has been less than stellar. Oh, an image has an alt tag? Congrats, it's accessible, even if that alt tag literally just says "alt tag". I also don't think "simply turn on accessibility features yourself" is a proper solution. It feels like there's a massive difference between me using such tools for the the purpose of testing one website and someone actually relying on such tools.

samspot · 2 years ago

I think you are talking about Usability here.

Usability: This button is hard to understand and/or confusing to operate.

Accessibility: I cannot operate the button AT ALL, cannot perceive it, or can only do so using advanced assistive technology tricks.

Pi9h · 2 years ago

I thought about it.

For example, the sidebar page tree supports keyboard navigation.

The UI library I am using, Mantine, follows accessibility best practices and has full keyboard support.

There is still a lot to do in this regard. As the project progresses, more support will come.

In the past, I built a Twitter bot (@threadvoice) to help people listen to Twitter threads in audio format ( https://twitter.com/Philipofficial9/status/11899711858004869... ). I had accessibility as one of my motivations while building it.

elliotec · 2 years ago

Also auth. I would rather just lose all my shit than try to go through the login rigamarole on either of these sites again.

j33zusjuice · 2 years ago

Are we talking about Confluence from Atlassian’s login? What’s so bad about it? It’s usually tied to your SSO provider, so you just have to sign in to your work account. In the server days, it was connected to your AD/LDAP password.

I don’t like Atlassian products very much for a lot of reasons (each iteration of the UI gets worse), but the login process has never been an issue for me, so I’m surprised to see your comment.

replwoacause · 2 years ago

How important could this be to companies really, if they are using Confluence and Notion, which are already doing this poorly.

hnthrowaway121 · 2 years ago

Depends on the company. In many areas companies are required to not discriminate against disabled employees. Just like your physical space must be accessible, your digital tools must be too. Otherwise you would might, say, pass on a more experienced and knowledgeable blind candidate in favor of a less qualified sighted person, because your internal tools can’t be used independently by a blind person.

Lots of companies are technically exposed to the risks related to this kind of thing, could be legitimately sued. But they don’t always recognize this aspect of their exposure.

It seems natural to me that this sort of thing will become more important over time.

More interesting to me though is what prompted your question. Parent requested making things accessible because that’s something as individual they need and benefit from. It wasn’t about how important it might be to “companies”. Individual people need accessibility.

jasonjayr · 2 years ago

I understand that in the US, the ADA can make for a nasty sting which can make them care in a hurry.

jack_riminton · 2 years ago

Whilst important, it certainly wouldn't be the top of my list of things to tackle when getting a project off the ground

zersiax · 2 years ago

And while that is a perfectly valid stance to have on this, you'll more than likely shoot yourself in the foot if you don't.

- Wayland didn't think it was important to immediately include this, and now we have the majority of linux distributions having serious issues with screenreaders and other assistive tech. Fedora's shipped with this broken for almsot a decade. Calamares didn't think it'd be important to fix and has been broken for about as long. - Particularly now, with devs grabbing a component library on top of React with a generous helping of CSS frameworks and third-party NPM-based extra bits that are all tangled together, and what have you, if you don't vet this stuff beforehand you'll have to retrofit half your UI to fix things after the fact. That, right there, is why accessibility seems so hard to implement.

Fixing a native HTML select for accessibility is easy; it already is. Fixing some componentized overengineered monstrosity that figured they'd get to it later and as a result doesn't speak with screen readers, doesn't work on phones, doesn't work when zoomed in, doesn't respond to speech recognition software, goes absolutely nuts when the user scrolls, and doesn't let you use it properly with a keyboard... yeah that is harder :)

riedel · 2 years ago

I think it makes sense to learn about it early and do a11y as much by design as possible. I think a universal design approach will help anyone. Many power users will appreciate good keyboard only navigation as a side effect. With a bit of a11y knowledge you might be able to catch a lot of low hanging fruits. Wouldn't do it with public procurement and overdone rigout in mind. Just spinning up a screen reader on an app can actually be a fun experience.

talkin · 2 years ago

That’s the most common approach, but a cynical rewording of that statement is: I’m not making it accessible by default.

These would be great:

- Managing pages in git/other vcs as plain text, using any editor I choose. I can commit pages using git or other vcs, don't have to use the browser to add pages.

- Writing pages in some markup language, maybe not markdown, as it is not expressive enough in some areas. Maybe markdown is possible for simple pages and the wiki knows it is markdown from the file extension, but the wiki also allows more powerful formats like restructuredText, which can be extended by the user.

- Server-side rendering of pages, that can easily be cached (since pages are files, one could easily check the shasum of the file to determin cache validity), which makes display of pages almost instant, as opposed to laggy shitty confluence.

mnahkies · 2 years ago

Not quite the same use case, but I've been really enjoying using https://nextra.site/ to create a static documentation site for one of my projects.

It's managed to strike a good balance of getting out the way and letting me mostly just write plain markdown, whilst being able to fall back to react components if needed.

With CD to GitHub pages on merge to main I think it's a pretty good experience

pembrook · 2 years ago

Why would you need a tool like this if you’re writing markdown docs outside the browser and version controlling them with Git? Doesn’t that defeat the entire purpose?

Or is it just you want a developer-native workflow to upload docs intended for the rest of the non-developer team?

In general, I would say that's a really bad idea. If you’re dumping this self-hosted (and probably bug filled MVP, as all are) on your team, yet never having to deal with the UI layer that everyone else does…it’s a recipe for revolt and tool churn.

I’ve seen this mistake a million times from technical founders. Same thing will happen with your marketing website CMS, after you realize static site + markdown + git doesn’t scale to non-dev humans and the headless CMS you picked (but never interact with) is actually trash in daily use.

zelphirkalt · 2 years ago

> Or is it just you want a developer-native workflow to upload docs intended for the rest of the non-developer team?

This. I am so annoyed by all the quirks and silly dysfunctional behavior of confluence, when all I need is a developer friendly workflow, that actually motivates to keep documents up to date and allows diffing easily and quickly and blaming and all that good stuff you get when you have git or other capable vcs.

> In general, I would say that's a really bad idea. If you’re dumping this self-hosted (and probably bug filled MVP, as all are) on your team, yet never having to deal with the UI layer that everyone else does…it’s a recipe for revolt and tool churn.

I don't see how. Users of the UI could, without explicitly knowing, save pages creating commits themselves. Maybe it could be difficult to square that with collaboratively working on a document in realtime though. If I had to choose between the two, I would pick git workflows any day of the week though and it is not so often the case in my experience, that people really work collaboratively on wiki pages of documentation.

> I’ve seen this mistake a million times from technical founders. Same thing will happen with your marketing website CMS, after you realize static site + markdown + git doesn’t scale to non-dev humans and the headless CMS you picked (but never interact with) is actually trash in daily use.

That is, why I am suggesting my points as additional, not as replacement. The non-devs can have their clicky bunty UI, but please let me use efficient workflows as a developer and don't create a sluggish experience in the browser, that will never motivate any dev to maintain documentation inside of it.

Also markdown does not do the job. It does not have some of the necessary building blocks. It is good for simple pages and perhaps a readme, but when it gets to proper technical documents, I would rather have something more capable. For example restructuredText, where you can define custom directives and so on. I used that before to make a little wiki with document interlinking functionality when rendering and used it to write a thesis. It is very capable. But there are others like org-mode format, and asciidoc and more. All more capable than standard markdown. (And yet, confluence has already issues with standard markdown, lol.)

An alternative is, of course, not to force devs to use confluence for documentation. Keep confluence to the marketting and sales fluff, and let engineers use efficient tooling, that they are already familiar with and that accompanies the code, instead of dividing documentation out into confluence, where it will quickly become unmaintained and forgotten.

FLT8 · 2 years ago

We use Jekyll for this at work, build the site using GitHub actions, and host through GitHub pages. Works a treat. Supports mermaid diagrams, mathml, ...

mr_mitm · 2 years ago

Have you seen MyST? It's just as expressive as ReST and much easier to write IMHO.

orthoxerox · 2 years ago

How did they come up with such a SEO-hostile name?

mikro2nd · 2 years ago

Just another vote against Markdown. Markdown is OK for simple docs, but very poor for wiki where inter-page links are the Magic Sauce. Creole markup is a lot better for wikiing imho.

I wouldn't store the file format in the file extension; rather store metadata properly as metadata. Chances are that the application wants to hold a lot more metadata anyway, so you're going to need a metadata storage scheme anyway. (Yes, I am a lone crusader for eliminating metadata from filenames.)

037 · 2 years ago

A little feedback: I want to try it (the website makes it look very clear and promising!), but the installation page [1] scared me and I almost left. Then I looked at the first instructions and they were for installing Docker. I know the section is named “Prerequisites,” but I was expecting just the docker-compose and some documentation on vars, given that the only way to install it is with Docker. Even the “Installation Steps” start with mkdir, cd, curl, vi, only to say “use this docker-compose.” The prerequisites can be important for many people, and there are many ways to solve this (if you think it’s a problem).

One thing to remember: devs and tech-savvy people skip everything and look directly at the terminal commands/code. It’s the reason you should never insert the “don’ts” in your repository readme too high on the page: they will be the first things we’ll cut and paste :D

This is not a criticism; it seems you did a wonderful job. Just the feedback of one of many dummy experimenters that you might lose on that page :)

1. https://docmost.com/docs/installation

Lucasoato · 2 years ago

I would remove the instructions to install docker: people can see them in the docker documentation, it doesn’t make sense to include them somewhere else.

Also I would use a .env file to manage the env variables, without requiring the user to modify the docker compose file. It’s very likely that people will version the yaml file, so it’s not a good idea to keep secrets in plaintext there.

https://docs.docker.com/compose/environment-variables/set-en...

TuringTest · 2 years ago

I would not remove them, but place them elsewhere, linked from the point you should run them at the install process.

It's very useful to have a complete 'getting started' page that get you from zero to working, without assuming that the reader understands what every intermediate step means. But as you said, the parts that are dependencies for other products can be encapsulated so that savvy users can skip them easily.

freedomben · 2 years ago

I may be unusual, but I much prefer the environment variables in a docker compose file. A .env feels like an anti-pattern to me honestly.

XorNot · 2 years ago

IMO if you want to drive adoption you need to ship an all-in-one container. Use runit, and stick the DB, redis and your app in the same container with one nice big data directory.

Because for most small teams with the ability to run containers, that's going to be all they ever need - and it means your "let's try it" experience is just `docker run <my container image>`.

RadiozRadioz · 2 years ago

Doing this as an optional extra alongside the regular app-only container is good, but it definitely shouldn't be the only way this is distributed. It's extremely inflexible.

grodriguez100 · 2 years ago

I know this is not the recommended practice, but I am working on a legacy project where we need to migrate to Docker and the first step (before decomposing in multiple containers) would be to have an all-in-one container running all services. I am looking for hints / recommendations on the best way to do this. Can you provide any pointers ?

href · 2 years ago

We are still using Confluence on-prem (behind VPN). To switch, we need the following:

- An export function (PDFs).

- An integrated diagram editor like Gliffy.

- History / diffs.

Outline is the closest to this so far, but we are in no rush, so we'll watch the development of this as well. Thanks for sharing!

jraph · 2 years ago

Hi!

I'm working at XWiki SAS [1] on tools to migrate from Confluence to XWiki [2], an open source and powerful wiki software that was born at about the same time as Confluence.

We have all this. We offer support and consulting, including for handling your migration. Our migration tools try to keep as much of the content and its feature as possible, and we work on compatibility macros for this.

Feel free to reach us, or me.

[1] https://xwiki.com

[2] http://xwiki.org

Terretta · 2 years ago

Comprehensive site!

Noticed this example from your store embeds French flavor for me:

https://store.xwiki.com/xwiki/bin/view/Extension/Office365In...

eastbound · 2 years ago

Please, get a designer and redesign that logo in a more trendy way. That logo may have hurt your chances since 2008.

I think this misses the biggest need (which one might not consider if coming from Confluence):

- consolidation of wiki together with your code's READMEs and generated docs (e.g. sphinx, mkdocs, swagger, etc., anything that outputs documentation from your codebase)

Note on the "integrated diagram editor", this brings up another feature (though less critical than above):

- by standardizing on a docs-as-code abstraction like mermaid or kroki, you can then leverage (a) diffable diagrams as code, and (b) quite a few relevant OSS editors.

See VSCode extensions for a few different implementations, but that said, if you pick mermaid, then the same diagrams work in the wiki tool as on GitHub, as well as local-first open content format tools like Foam, Dendron, or Obsidian.md, which is nice.

viraptor · 2 years ago

The diagrams as code is not a one size fit all. I'd use mermaid for some technical things, but it's failing for communication/presentation purposes. You need to have the ability for arbitrary placement, annotations, flow. Mermaid is all fun until you want to connect two previously distant boxes and everything explodes - for long-term documentation purposes it may not even matter, but if I'm about to show it to anyone, I'm going to Excalidraw.

someone4958923 · 2 years ago

We use Bookstack[0] for this and I can recommend it. Free and open source.

- PDF Export - Oauth2 - Revisions - History - Permissions - WYSIWYG/Markdown/Diagrams etc.

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

lf-non · 2 years ago

Bookstack is quite nice but last I saw it doesn't support multi user collaboration which this tool seems to include as a core feature. That can be a big differentiator for a lot of people.

1. PDF export will come.

2. Diagrams will come too. MermaidJs is next on the line. Other diagram providers like Draw.io and Excalidraw will come once I figure out an efficient way to handle storing and retrieving their raw data.

3. There is support for page history. No diff comparison yet though.

itomato · 2 years ago

Mermaid is cool, but you need to land a Draw.io or Gliffy or Lucid.

gcanyon · 2 years ago

I haven't tried it in Confluence, but https://www.tldraw.com/ can be embedded in Notion at least, and works very well as a diagram editor.

digi59404 · 2 years ago

Congrats on this - It looks really good. We’ve been evaluating documentation tooling for our company. We’re in a weird regulatory environment where the documentation is created by someone else, but reviewed and approved by another person.

I bring this up because a feature that could set you apart from others is the concept of a “merge request” for documentation. Where someone can make a document, another can modify it and submit changes for review.

GitBook has this but it lacks in some other key ways for us.

salamander014 · 2 years ago

I’ve also always wanted this, but what I’ve realized after noodling on it a while is I’d really just prefer a way to use git, and push markdown documents to the Notes System.

I dont want a different system handling edits reviews and merges.

I just want CD to send my docs from git to a system that can properly host / give me the Doc-related features I need.

j45 · 2 years ago

If this could co-exist in the backend with an easy to use browser interface for the many who write text more than markdown, would be amazing.

Being markdown centric would be great. Makes this tool a great destination for so much markdown content already existing.

rubslopes · 2 years ago

> I just want CD to send my docs from git to a system that can properly host / give me the Doc-related features I need.

Material for Mkdocs does exactly this.

https://squidfunk.github.io/mkdocs-material/

robjan · 2 years ago

This would be a great feature. We have a similar problem whereby there are official versions of documents which have been through a review process and the only way to work on the next version on Confluence is to have a separate working copy of the page which pollutes the search and gets messy very quickly.

Confluence 100% supports the situation you’ve described. The way I’m reading this is that you need to have a publishing workflow, or a document approval workflow, which Confluence can do. At one of my jobs, we wrote it with CQL.

xmprt · 2 years ago

Curious what other features you need where merge requests for documentation is the primary requirement but Git (or some other VCS) isn't sufficient?

How would you manage a Confluence document via git?

bjartek · 2 years ago

This would indeed be nice to have.

neilv · 2 years ago

I'm a huge fan of wikis, and of particular ways of using them within a company.

(But I'm not as big a fan of certain wiki software products that seem guided by enterprise sales to customers who don't seem to understand wikis. :) )

One thing an enterprise product did do passably well, for a big win, was integration of a drawing tool. Not everyone in a company needs that integration, but some users will, and its presence can mean that a super-helpful visual is captured when it otherwise wouldn't.

https://www.tldraw.com/ can be live embedded (in Notion at least, I haven't tried Confluence or others) giving you a very nice shared drawing ability within a wiki that doesn't otherwise support that functionality.

itissid · 2 years ago

Could you summarize a few nuggets of wisdom about why you like wikis? Specifically, what particular ways of use are the most effective within a company?

memset · 2 years ago

This is really cool! My big problem with most document software is:

1. Everything is locked in. I want to be able to easily export or back up my notes.

2. The pricing is so nickel and dimey. Have more than 100 nodes in the document tree? Upgrade your tier. Adding new people to projects is a buying decision every time and it’s fatiguing.

Can you tell us more about how it uses pg and redis?

Postgres is the primary database for storing all workspace and user-related data.

Redis is used for queues, collaborative editor state sync across servers, and WebSocket sync across servers. The last two functions are important when running the software on multiple nodes or replicas.

I work on XWiki [1]. Nice to see fellows building open source alternatives, we can't have enough of this. I hope you succeed.

It takes a lot and lot of work to build something comparable to Confluence. XWiki has been there since the beginning. How do you position yourself compared to XWiki? What made you decide not to join the forces?

[1] https://xwiki.org

Scramblejams · 2 years ago

I would love to migrate off Confluence to something open. I tried XWiki but the user experience seemed comparatively rough. Do you have a set of extensions you’d recommend to make it more palatable to those who want a Confluence-like experience?

Both Confluence and XWiki are huge and your experience is subjective, so it really depends on which parts you'd want to see improved. General improvement should not be made through extensions, it should really be done directly in the product. Quite some customers have pushed for improvements over the last months, for instance we now have page ordering in the navigation panel as a core feature thanks to their valuable feedback.

So don't hesitate to share your feedback on the project [1] (generic feedback is interesting to read but specific stuff is more easily addressed), read previous feedback [2], ask questions on the forum [3], chat with us on our community chat [4] or even report bugs [5]. See also the roadmap to see if something important to you is already scheduled [6].

If you have money to spend, also know that XWiki SAS [7] offers consulting and support and we address customer concerns. We also sell "Pro" extensions (with free trial) that cover some features that are expected by Confluence users, among other things [8] (while we sell these features, it's not open core. It's still (truly) open source: you can get the code under LGPL and all).

[1] https://www.xwiki.org/xwiki/bin/view/Survey/ProductFeedback

[2] https://www.xwiki.org/xwiki/bin/view/Main/Feedback/DownloadF...

[3] https://forum.xwiki.org/

[4] https://dev.xwiki.org/xwiki/bin/view/Community/Chat

[5] https://jira.xwiki.org/

[6] https://www.xwiki.org/xwiki/bin/view/Roadmaps/

[7] https://xwiki.org/

[8] https://store.xwiki.com/