u/Vivanotica

In a service like Notion, there is a clear danger. If the service got hacked or went bankrupt, I could lose my data. (although it's almost 0% probability) Or there may be a danger that some Notion employee could steal my data. (if data was not encrypted)

Arguing a danger like this makes sense, and should be considered.
Logseq and Obsidian resolve this issue by "storing all data locally"; this is it.

In Logseq, there's no reason the data should be stored as easily readable raw data (like Markdown) for this issue. If we have enough ways to export data, we don't have to care what format it's stored in. Because "we own the data".

I don't understand why people are obsessed with 'Markdown'. This is an open-source project. Even if the whole team just died tomorrow, we can find a way to get our data back.

Of course, it would be great if we had both performance and Markdown format, but Logseq doesn't fit with Markdown.

Saying “the team should maintain Logseq OG because of Markdown format support” is totally absurd.

As someone who used Logseq OG for quite a while and later moved to Logseq DB, I’ve been wondering why the Logseq team chose not to formally end support for the old version and focus entirely on the new one.

I understand that, in practice, the team is already putting most of its development effort into Logseq DB. But I think there is still a very significant difference between developing DB while continuing to maintain two versions and officially ending one version and concentrating the whole project around DB.

The main reason I think this matters is the community.

For a project like Logseq, I believe the user community is not just an audience for the software, but a major part of the product ecosystem itself. It consists of thousands of people who share workflows and methodologies, write documentation and tutorials, build plugins and themes, answer questions, report bugs, contribute code, and generally create the knowledge and infrastructure around the application.

In that sense, a healthy community can sometimes be almost as important as the core development team.

Obsidian is an interesting example. Despite competing with note-taking products backed by much larger companies and vastly greater resources, it managed to build an extremely strong position in the PKM space. I think its community ecosystem, including plugins, themes, workflows, tutorials, discussions, and the enormous amount of accumulated knowledge around the product, was one of the major reasons for that success.

This is why I worry about Logseq maintaining OG and DB at the same time.

Logseq OG and Logseq DB may share the same name, philosophy, and many surface-level features, but technologically and behaviorally they are increasingly becoming two different applications.

That creates a kind of community fragmentation.

A tutorial written for OG may no longer apply to DB. A plugin built for OG may not work on DB. Discussions about workflows become filled with questions about which version someone is using. Developers have to decide which platform to target. New users encounter documentation and advice written for two different generations of the application.

Over time, this makes it much harder for a single, coherent Logseq community to form around the product.

And I think this is potentially more damaging than the engineering cost of maintaining two codebases itself.

If this problem is not resolved, I worry that Logseq may eventually reach a point where one of the two versions has to be abandoned anyway. But by then, the community may already have been split for years, with plugins, documentation, workflows, and users distributed across two ecosystems.

From that perspective, it might be worth seriously considering a more decisive long-term strategy.

For example, perhaps the team could try to bring the two versions closer together. They would not necessarily need to become technically identical, but they could be made compatible enough that a single community ecosystem could realistically support both.

Or perhaps we will eventually need something ridiculous like Logseq OGDB that somehow combines the two. :)

Alternatively, the project may eventually have to make the difficult decision to officially discontinue one version and establish the other as the clear future of Logseq.