I am on the side-line itching to jump into Logseq, but I still have doubts …
I currently use Joplin and for two main reason (aside that it is a great note-taking app):
It uses Markdown; so notes will not be locked in.
It is open-source (MIT License) so I do not have to worry about some company dying and the software as well.
I can self-host the synchronization server, using either WebDAV or the Joplin-server container (I use WebDAV).
I know Logseq uses Markdown and hence notes are easily exportable. But I am not clear on the other two points …
I see that Logseq uses AGPL license. Which should be even more strict about open-sourcing the code than the MIT license (if I understand correctly). Hence there is no need to worry about this aspect … correct?!
I know that the synchronization feature is still in development and testable by sponsors (I saw this in the settings; though I am unsure what “sponsor” means). From researching this forum, I have found out that there are other methods (Git, Syncthing, iCloud) to synchronize, but with mixed results.
So hence, my question, whether the synchronization-feature that is being developed will be self-hostable in order to have a reliable, but fully private way of doing the synchronization?
I realize that the questions above also raise the question of what the business model is for Logseq? How do the developers make their well-deserved money and how do I show my appreciation (i.e. pay), once I decide to commit to Logseq?
I see that Logseq uses AGPL license. Which should be even more strict about open-sourcing the code than the MIT license (if I understand correctly). Hence there is no need to worry about this aspect … correct?
Correct, because it is copyleft. All derivative works must retain the same freedoms as the original, if I’m not mistaken.
I think syncing has long been a pain point for many Logseq users, but because the developers only have one business model right now, I don’t think its a pain point they have any interest in solving for free. With the other options available, though, this seems like a fair tradeoff.
FWIW, I use both Logseq and Joplin to meet different needs. I prefer Joplin’s way of handling sync, which reads directly from a sqlite database. But I also like having git version control for my Logseq graph, which not even the native sync function offers.
I had some of the same questions, especially about the backend code, and posted them here.
Below is what I wrote. What thoughts do you guys have?
I would love to be able to self-host the backend used for the sync server. I understand that the sync mechanism is still under development, but given that are there plans to release the backend source code?
I know that in the past there were requests for the backend source code; but at that time logseq used the backend very differently, AFAIR it operated as a host for logseq pages which were shown in a browser. At present, logseq uses local files, and syncs them via the backend code, all of which must be a very different backend from what existed back in early 2020.
The readme.md says almost at the very top that logseq “…focuses on privacy, longevity, and user control.” That link to the gnu free software philosophy page lists the four essential freedoms of software that is under user control, which includes “2. The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.”
In the past, there were plans to allow logseq to work with git, which eventually was done, and so it could be used completely with only free and open source code. But currently the ability to sync is a major part of the software, and access to the full syncing code (including the server portion) is a precondition for having the freedom to study and change how the program works.
So is the backend source code going to be released? There are a lot of people who have contributed time/code and money to this project thinking that it was solidly on the foundation of free and open source principles with full user control. If this is not the case, that’s a problem.
I know the tone of this sounds demanding; but I do want to also express my gratitude for all that each contributor has given. This is an amazing piece of software, and I hope to see it made better still as time goes on.
Logseq Sync is designed for scalability (millions of graphs) and performance, we used AWS lambda && gateway a lot, DynamoDB, Postgres, which are very complex and not designed for self-hosted.
We’re not going to open-source Logseq Sync for both business and the above reasons, but we plan to design a protocol for self-hosted usage so that the community can implement different solutions on top of it.
Thank you for the insights into the stack that you are preparing for the commercial Sync function.
This is a very good starting point! That concept already works well with Tailscale / Headscale and also with Bitwarden / Vaultwarden, so we can expect the availability of a useful, reengineered Sync services at some point.
we remain free and will only charge for pro services like sync, collaboration, and publish
In addition to syncing a local LogSeq graph, does the intention of releasing the protocol also hold true for the expected collaboration features? This would be a very fine move, and allow more sophisticated usage scenarios of LogSeq in the wild.
Many thanks for all the effort and constant improvement of the platform! I hope it pays off in the long run.