Our great sponsors
-
-
formkiq-core
A full-featured Document Layer for your application, providing the functionality of a flexible document management system, including storage, discovery, processing, and retrieval. Deploys directly into your Amazon Web Services Cloud. 🌟 Star to support our work!
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
paperless-ngx
A community-supported supercharged version of paperless: scan, index and archive all your physical documents
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
https://github.com/DMSrs/dmsrs
It's written in Rust but I never managed to continue the project sadly :(
If you're not adverse to cloud file storage, FormKiQ Core (I'm a co-founder) is an open source document management system that runs on AWS and is designed to allow custom integrations.
There's also Mayan EDMS [1]. I have no experience with it, but looks sensible from the outside.
It seems like it manages some metadata around google docs, but google docs is doing all the heavy lifting (creating/editing/sharing documents). Which begs the question, why?
By titling itself as a document management system I would assume it would be something like paperless-ngx[0] or mayan edms[1]. The latter of which has a built in workflow system.
But by being tied to google docs you can't really self host the important parts
That seems something in the ballpark of my favorite wiki software:
https://github.com/gollum/gollum
Edit and view pages as a normal markdown wiki. But the backend is just a git repository of markdown files so you can also just use your text editor and git pull/push. Usable by any novice but with the ideal power user interface.
This reminds me a lot of the NY Times' Library project: https://github.com/nytimes/library. You use an editing environment that people are familiar with (google docs), and you build organizational and workflow stuff around it. Library rendered the document content itself with a link to edit (favoring the reader use case), whereas Hermes embeds the google docs UI.
The lack of code blocks in google docs makes it tough for a centralized document repository for an engineering org. For companies using Quip it could work really well...except that I don't think quip lets you embed the editor like that.
Everything that's been built so far for Hermes looks cool. My personal opinion is that it'll need more UX iteration for it to really take off.
For me it’s a JS engine for React Natve - https://hermesengine.dev/
But wanna say that I choose the “same” name for a related goal project https://github.com/Ideabile/ermes
Assuming that by Apache Oak you mean the Oak subproject of Apache Jackrabbit ( https://jackrabbit.apache.org/oak/ ), why would you consider it abandoned? Release 1.48.0 came out last week and it's been seeing steady activity throught the last years - https://github.com/apache/jackrabbit-oak/ .
I am a committer and PMC member in the project, so I may be biased.