I am building Docmost, an open-source collaborative wiki and documentation software. It is an open-source alternative to Confluence and Notion.
I have been working on it for the past 12 months. This is the first public release (beta).
The rich-text editor has support for real-time collaboration, LaTex, inline comments, tables, and callouts to name a few.
Features
- Collaborative real-time editor
- Spaces (Teamspace)
- User permissions
- Groups
- Comments
- Page history
- Nested pages
- Search
- File attachments
You can find screenshots of the product on the website.
Website: https://docmost.com
Github: https://github.com/docmost/docmost
Documentation: https://docmost.com/docs
I would love to hear your feedback.
Thank you.
And that's just for people with typical hands and eyes.
Imagine of what it's like for people with disabilities.
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.
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.
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.
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.
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.
- 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 :)
You do not want to run this in Postgres, or any RDBMS for that matter. I promise you. Here [0] is `y-sweet` [1] discussing (at a shallow level) why persisting the actual content in an RDBMS isn't great. At $COMPANY, we ran Postgres on massive EC2s with native NVMe drives for storage, and they still struggled with this stuff (albeit with the rest of the app also using them). Use an object store, use an LSM-tree solution like MyRocks [2], just don't use an RDBMS, and especially not Postgres. It is uniquely bad at this. I'll explain.
Let's say I'm storing RFC2324 [3]. In TXT format, this is just shy of 20 KB. Even if it's 1/5th that size, it doesn't matter for the purposes of this discussion. As you may or may not know, Postgres uses something called TOAST [4] for storing large amounts of data (by default, any time a tuple hits 2 KB). This is great, except there's an overhead to de-TOAST things. This overhead can add up on retrievals.
Then there's WAL amplification. Postgres doesn't really do an `UPDATE`, it does a `DELETE` + `INSERT`. Even worse, it has to write entire pages (8 KB) [5], not just the changed content (there are circumstances in which this isn't true, but assume it is in general). Here's a view of `pg_stat_wal`, after I've been playing with it:
docmost=# SELECT wal_fpi, wal_bytes FROM pg_stat_wal:
wal_fpi | wal_bytes
---------+-----------
1641 | 11537465
(1 row)
docmost=# SELECT wal_fpi, wal_bytes FROM pg_stat_wal;
wal_fpi | wal_bytes
---------+-----------
1654 | 11656052
(1 row)
Now let's look at the search query [6], which I've reproduced (mostly; I left out creator_id and the ORDER BY) here:
docmost=# EXPLAIN(ANALYZE, BUFFERS, COSTS) SELECT id, title, icon, parent_page_id, slug_id, creator_id, created_at, updated_at, ts_headline('english', text_content, to_tsquery('english', 'method'), 'MinWords=9, MaxWords=10, MaxFragments=10') FROM pages WHERE space_id = '01906698-1b7c-712b-8d4f-935930b03318' AND tsv @@ to_tsquery('english', 'method');
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Seq Scan on pages (cost=0.00..12.95 rows=1 width=192) (actual time=13.473..48.684 rows=3 loops=1)
Filter: ((tsv @@ '''method'''::tsquery) AND (space_id = '01906698-1b7c-712b-8d4f-935930b03318'::uuid))
Rows Removed by Filter: 3
Buffers: shared hit=32
Planning:
Buffers: shared hit=1
Planning Time: 0.261 ms
Execution Time: 48.717 ms
It doesn't get better if I forcibly disable sequential scans to get it to favor the GIN index on `tsv` (unsurprising, given the small dataset):
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on public.pages (cost=106.29..110.56 rows=1 width=192) (actual time=17.983..51.424 rows=3 loops=1)
Recheck Cond: (pages.tsv @@ '''method'''::tsquery)
Filter: (pages.space_id = '01906698-1b7c-712b-8d4f-935930b03318'::uuid)
Heap Blocks: exact=1
Buffers: shared hit=41
-> Bitmap Index Scan on pages_tsv_idx (cost=0.00..106.29 rows=1 width=0) (actual time=1.231..1.231 rows=7 loops=1)
Index Cond: (pages.tsv @@ '''method'''::tsquery)
Buffers: shared hit=25
Planning:
Buffers: shared hit=1
Planning Time: 0.343 ms
Execution Time: 51.647 ms
docmost=# SELECT * FROM pgstatginindex('pages_tsv_idx');
version | pending_pages | pending_tuples
---------+---------------+----------------
2 | 23 | 26
docmost=# EXPLAIN (ANALYZE, BUFFERS, COSTS) SELECT gin_clean_pending_list('pages_tsv_idx'::regclass);
QUERY PLAN
--------------------------------------------------------------------------------------
Result (cost=0.00..0.01 rows=1 width=8) (actual time=16.574..16.577 rows=1 loops=1)
Buffers: shared hit=4659 dirtied=47 written=22
Planning Time: 0.322 ms
Execution Time: 16.776 ms
You should also take a look at the DB config if you're to keep using it, starting with `shared_buffers`, since it's currently at the default value of 128 MB. That is not going to work well for anyone trying to use this for real work.
You should also optimize your column ordering. EDB has a great writeup [8] on why this matters.
Finally, I would like to commend you for using UUIDv7. While ideally I'd love (as someone who works with DBs) to see integers or natural keys, at least these are k-sortable. Oh, and foreign keys – thank you! They're so often eschewed in favor of "we'll handle it in the app", but they can absolutely save your data from getting borked.
[0]: https://digest.browsertech.com/archive/browsertech-digest-fi...
[1]: https://github.com/jamsocket/y-sweet
[2]: http://myrocks.io
[3]: https://www.rfc-editor.org/rfc/rfc2324.txt
[4]: https://www.postgresql.org/docs/current/storage-toast.html
[5]: https://wiki.postgresql.org/wiki/Full_page_writes
[6]: https://github.com/docmost/docmost/blob/main/apps/server/src...
[7]: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/4...
However, do you think an application like this would be database bound? It feels like so many more things would limit throughout (and product market fit) before Postgres.
Given its buried a bit in their stack, they can always optimize later as well.
Re: optimize it later, your persistence model is the hardest thing to change once it’s built and full of data. I strongly recommend getting that right the first time.
Confluence itself uses relational databases including Postgres, and they seem to do well too.
And I know for a fact that both handle huge wikis. (hundreds of spaces, millions of document revisions)
You can store essentially anything in an RDBMS, especially Postgres. That doesn’t make it the right choice. It might make it easier, but easier isn’t the same thing as correct.
I am of course biased as a DBRE, since I’m the one who gets paged about problems caused by decisions like this. Then I get to deliver the uncomfortable news that everything needs to be overhauled, and inevitably am told that’s not going to happen, and to just figure it out.
Indeed, the Yjs state update can be problematic due to its growing size and constant updates.
I will have a look at MyRocks. Reference pointers sound more plausible.
I spent time analyzing and deciding my usage of uuid7 from different perspectives. From the git logs, you can see it came at the last minute.
I'd encourage you not to switch databases, or at least to defer this for a while. I can't imagine you'll have issues with the amount of WAL written for quite a while, and by that time, the world could be quite different (OrioleDB might be mature! https://github.com/orioledb/orioledb)
I appreciate you at least considering the various options. If you do nothing else, tuning Postgres parameters, optimizing column ordering, and removing duplicated indices will be a great step forward that is completely backwards-compatible.
Ed: looks like it https://pganalyze.com/blog/5mins-postgres-jsonb-toast
- 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!
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.
[2] http://xwiki.org
Noticed this example from your store embeds French flavor for me:
https://store.xwiki.com/xwiki/bin/view/Extension/Office365In...
- 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.
- PDF Export - Oauth2 - Revisions - History - Permissions - WYSIWYG/Markdown/Diagrams etc.
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.
I will admit that it would be very cool to see a client that abstracted got and markdown away for non-technical users.
I feel like obsidian with some more git polish could get it done.
Note how I said that git and markdown could be abstracted away, as in hidden from the user who can’t be bothered to learn. Use them under the hood, so at the end of the day your entire wiki is just a repo.
Me and my partner currently use Apple Notes for this, simple stuff like grocery lists, todo lists, etc. But Apple Notes perf is abysmal with real-time collab. The app constantly hangs and fans are spinning non-stop. iOS is not much better.
Async collaboration happens with git, synchronous can happen with any text editor that supports collaborative editing.
Probably runs on phones better.
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.
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.
Being markdown centric would be great. Makes this tool a great destination for so much markdown content already existing.
Material for Mkdocs does exactly this.
Unfortunately I’d never advocate for something like this at my work. Self-hosting doesn’t make sense in terms of total cost of ownership. I’d rather engineers spent time solving problems in our core business than making sure our wiki is online.
As with a lot of modern open source, the monetisation comes from providing a hosted/ supported cloud version so your engineers can spend their time solving your core business problems rather than making sure the wiki is online.
That said, it's a Beta, and they've put 12 months into it already to get it where it is.
It's great to have open source competition in this area, so the current lack of a cloud option should put it in the "awesome, I'll check it out, then wait for a cloud option" category.
The ability to self host also doesn't prevent someone, including the original developers, to also proving hosted services.
And since the presented tool is open source, it's also possible for another company to provide hosting.
Open source isn’t a business model.
Even if it's just a stop gap solution while we find a better solution to migrate to.
- 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.
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
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.
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.
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.)
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 :)
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...
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.
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>`.
* markdown support (for writing/formatting)
* mermaid support (for diagrams)
I would also like to be able to update a page through the API. Again, Confluence "technically" supports page editing through the API but it's so cumbersome that it's basically useless. The reason for this request is that we use our wiki to document certain activities (monthly security checks, AWS spend, etc.) and I have to manually update Confluence. It would be so much better if I could write a little Ruby (or Bash, etc.) to add content to a table in a page.
2. Collaborative editing makes updating content outside the editor tricky. It will work, but not very well. I will consider supporting content updates via the API in a future release.
As said in other comments, I work on XWiki. We support Markdown [1] to write documents, among other syntaxes (including (X)HTML), although it's way more limited than our own syntax.
For Mermaid, apparently there are initiatives to integrate it, but nothing finished [2, 3] I guess.
[1] https://extensions.xwiki.org/xwiki/bin/view/Extension/Markdo...
[2] https://github.com/jingkaimori/xwiki-mermaid
[3] https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Merm...
2. Mermaid support is coming.
Do fenced code blocks work as well?
Perhaps equivalently, use Markdown and store directly in the rendered HTML?
Knowledge management is a special area. Look forward to seeing this grow.
As a heavy user of both Confluence and Notion, and in the interest in seeing alternatives like this grow:
Is there any plan to make this tool local/offline-first and mobile-first? There's a big need in this feature, and something that's best baked into the bread early. It's a big gap of Notion and ultimately why I had to ditch it.
Confluence has some ways to at least cache enough of it, or use a plugin. Confluence is also massive, lots of features (including workflows and approvals).. it might be worth clarifying which ones you're covering and planning to cover.
Mobile-first? If you are referring to mobile apps, it will probably come in the future.
For now, it’s just me building. I am focusing more on building the core features of a wiki.
Thank you for your positive words. I appreciate it.
Thanks!
On to the option -- currently been giving Anytype a pretty hard go on the colalboration side, as well as playing with Obsidian to see if it can feed into it.
(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.
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?
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...
[4] https://dev.xwiki.org/xwiki/bin/view/Community/Chat
Note: Outline is another Open-Source Documentation/Wiki and Collaboration tooling option I like.
Outline is a great software, I have tried it.
I use PlantUML extensively and tools like Znai and others have native support for it.
Even being able to embed something like diagrams.net right into the page via plugin for the time being (and save the resulting file in the system) would be great.
On docmost.com, pinch to zoom is disabled when viewing screenshots (Firefox Android).
Unfortunately, there is no public demo yet. If you email me (in bio), I can create a demo for you.
I got it running in Docker. I had to run "docker-compose up -d" rather than the instructions' "docker compose up -d" (no dash), which just gave a confusing error message about not knowing "-d".
It looks great!
I got confused at first between Workspaces and Spaces. It seems that Workspaces contain Spaces which contain Pages? I like that, but the names seem too similar.
I noticed the page title doesn't update on some locations. E.g. I go into a page, the title updates, but then when I leave the note the title remains. Similarly the "Login" title persisted after I'd logged in.
It took me a minute to figure out how to access it from other computers on my local network, and the problem was I left the APP_URL as localhost. Confusingly, that partly worked, so it might be worth putting in a warning about it. With APP_URL set to localhost, if on another computer on the same network I go to <ip address>:3000, it redirects to <ip address>:3000/home, so something is connecting, but then nothing loads and it's just a blank screen (there's an error message in the browser console about failing to load resources from "localhost").
How and where are pages stored? I would love to use this, but need robust backup/restore.
Edit: It would be great if going to a page URL when not logged in would redirect to that page after login.
Edit 2: "Copy link" doesn't work? It pops up a message saying "Link copied" but it's not in the clipboard.
What was the thought process for AGPL instead of something else ?
AGPL is useful also for preventing commercial improvements that don't make it back into the general product.
I chose Node mainly because of Yjs, which powers the real-time collaborative editing.
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?
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.
Did you consider Nix/Guix instead of docker as a suggested way to deploy? Docker is a harmful and very common tool, witch lead to a gazillion of wasted resources and security nightmare due to pulling anything from unknown sources and put it in production.
Aside, similarly, MarkDown is popular but it's really a crappy set of markups that fails in the most useful productivity aspect: outlining. Org-mode is less known being tied to Emacs but it's far, far more featuresfull and immediate to use.
Beside that's I wish the best luck to all devs, there are gazillion of webapps all suffering the modern stack issue: inability to integrate anything, so the need to recreate the wheel everytime and incorporate a feature at a time to the point of being monsters, but your sauce so far seems to be the most polished I've seen.
Docker is not a hard dependency but it was the easiest way to document it and hope it works for everyone, given the Postgres and Redis requirements.
With time, I will create documentation for other platforms.
Thank you.
Do you have plans to offer a hosted/managed/SaaS service? As others have pointed out, not everyone wants to self-host, and offering a managed service doesn't diminish the advantages of it being Free and Open Source (assuming good data export/import features).
For comparison, the SourceHut project offers a managed service, which is well-run, well-liked, and brings them good revenue.
I consider NextCloud to be an example of what not to do. There are plenty of NextCloud providers, but (from what I can tell) none of them are closely tied to the development of NextCloud itself. Bug-reports to service-providers can be expected to be met with that's a NextCloud bug, not our problem.
This is something I’m going to keep a close eye on. My company is using confluence and I hate how slow confluence is.
Your marketing site, the menu doesn’t close when clicking on an item on mobile Firefox on IOS
I believe someone needs to be in charge of the documentation and have dedicated time for this. Other issues this person would need to make sure:
- keep a good structure
- avoid duplicated stuff
- avoid orphaned content
This can also be partially addressed by adding a mandatory step to update the documentation when performing tasks that require documentation.
I believe documentation with some stale stuff is be better than no documentation at all though. Imperfection needs to be tolerated.
My current take: no matter how you slice it, the above comment strikes me as a leading question that is way off target. Tell me if I'm wrong.
1. MediaWiki plugins? Never heard of them. Do you mean MediaWiki extensions? https://www.mediawiki.org/wiki/Category:Extensions
2. Are you suggesting that MediaWiki is relatively close to Confluence or Notion? In some way? What way?
I predict that the development effort required to adapt MediaWiki to a Notion-type product would be at least hundreds of thousands of dollars. To put it bluntly: foolish and a waste of money. Am I missing something? Tell me.
To better explain my point of view: Notion is a single-page application built (probably) with JavaScript or TypeScript. MediaWiki is rooted in a server-side, old-school web application style. It perhaps may have evolved some, but it has relatively little JS in comparison.
P.S. I realize this comment sounds grumpy. I suppose I find it rather silly and maybe even presumptive to read a comment like the one above. It is a leading question suggesting an incredible (as in unbelievable) claim. It suggests that Docmost is somehow missing a path forward requiring only 1% of the effort. Ok, that sounds appealing. If true. But its suggestion is just bonkers... MediaWiki as a jumping off point?. WAT? I have no relationship to Docmost, but I consider myself a bit protective of open-source developers, especially for a useful product with good potential. I recommend they tune out these kinds of comments for their sanity.
When I start working on the import feature, this will be possible.
I like the focus on UI (many open source projects missing this aspect)
Docmost does not depend on any Pro Tiptap extensions.
The team at Tiptap are doing something really amazing. I believe it is fair that they find avenues to make revenue from it.
I like Lexical, but I found Tiptap first and loved it.
Very long coffee breaks, maybe down the street, for documentation from across town to load. We didn’t attempt to update that documentation, so anything better, is better. I’m barely exaggerating
I also noticed that the documentation is using Docusaurus - it would be awesome to use Docmost for it, so that you have both a demo environment (at least R/O) and do dogfooding
I will definitely check it out.