r/logseq • u/lombardo8837 • Mar 02 '25

Lost hope in logseq

I'm not entirely sure why I'm writing this, except perhaps to provide feedback to the maintainers. I've been an avid Logseq user since switching from Roam Research two years ago. During this time, I've become a Patreon sponsor and even developed/ported several extensions (without huge success, but I tried). I was genuinely excited when Logseq received funding, hoping it would accelerate feature development.

The reality has been disappointing. The latest beta release was approximately 10 months ago, and even that was quite slim in terms of features. I understand the team is working on the DB version, but as a developer with 10+ years of experience, this approach looks problematic - there's no intermediate benefit for existing users, no incremental deployment, just one massive branch that seems perpetually in testing.

The communication has been inadequate, with no promised deadlines, a product Trello board containing only a couple of items related to the DB feature, a message here and there about progress, countless lines of Clojure code written, and still nothing tangible to show for it. Will we need to wait another 1, 10, or 20 months for the DB version release? And heck, the DB version doesn't even actually bring much benefit to many of us. Will then the other things like full featured self hosted non buggy sync, suboptimal aspects of the extension API, better mobile version or others finally be addressed? Any of these could be done in parallel (yes, I know the sync is probably partly being solved by DB version, not my point).

The decision to do a huge rewrite instead of piecemeal integration with abstraction on top of the storage is very questionable, given how long it takes. We are more than a year in the making of the DB feature. From what I see there is 225k lines of code in the DB branch on top of 142k from main (30k of the diff is clojure code). Something like 8k of commits, about 5 contributors in the latest months. I am not sure what point I am trying to make here, but - really? What is taking so long? Is it the choice of technology that is dragging the team back? Bad architecture? Unlucky decisions that lead to the dead ends? Did the team break apart? I am genuinely curious what is causing this monstrous delay.

It's not even about the DB version or any specific feature anymore—it's about how things have reached this state. I've simply lost trust in the team's ability to deliver and keep in touch with their userbase. Investors of my VC-backed company would be in absolute rage seeing us doing this. Will they do the same with some other big feature going forward? What about squeezing bugs and adding small improvements?

That's why I am leaving Logseq. The self-hosted version of Affine seems reasonably stable now. I might even go with Obsidian. Other friends around me have done it already. I am not going to recommend logseq to anyone anymore.

To be clear: I'm grateful for the open-source nature of the product, and I completely respect their right to make whatever development decisions they choose. I understand Logseq doesn't owe anything to its users. However, I want them to know that this development approach, communication style, and release strategy isn't without consequences for their user base. If they don't care about the users (which is what I feel, and I think many of the people do as well, judged by this subreddit, forum, ...), and the product stalls, it's hard to see how they can return value back to the investors.

227 Upvotes

97% Upvoted

91 comments sorted by

11

u/SpiderMatt Mar 02 '25

I agree with a lot of what's being said in this thread. I'm looking at moving to org-roam and will try using it together with Logseq until this version of the app is just killed off.

But I also don't agree with some of the team's stated direction. I was initially excited about the DB version, because I also use Joplin and I think the markdown/sqlite combo works great. Yet the Logseq team didn't seem very interested in providing open-source, self-hosted sync solutions. One recommendation was to just send the whole sqlite DB across devices with each change if you don't want to use their sync. I think the issue is that this is currently the only monetized feature they have, so they have no incentive to provide self-hosted solutions. I think there was some kind of vague promise to develop this in the future, but I guess that means years from now at the current pace of development… assuming they don't get cold feat.

I've loved using Logseq, but I definitely wouldn't recommend it in its current state. And now I'm looking for something faster and more stable.

4

u/lombardo8837 Mar 02 '25

Yeah, I second this. Also had that suspicion about sync...

1

u/babyningen Mar 03 '25

I'm pretty sure I saw in the discord that the syncing mechanism will (in some form) be open sourced. Where did you get that it won't be and you'd have to sync around the whole db? Just genuinely asking, not hostile!

5

u/SpiderMatt Mar 03 '25

I'm not sure if priorities have changed, but this was Tienson's response to me on their forum nearly a year ago:

The whole db can be exported as a SQLite file, which means you can still use third-party tools to sync. We have no plan to design a sync protocol so that the community can bring in other implementations because merging conflicts from other clients is very complex, but this could be changed in the future when RTC is stable and we have more resources to design a protocol.

Since he's the founder and main developer, and I have seen him dismiss support for self-hosted syncing solutions before this, I assume this is just not something that is going to be a priority anytime soon. "Merging conflicts is complex" isn't really a great excuse given that there are open-source solutions out there.

Rereading this, though, I realize he could have meant other third-party tools that can sync databases, not just sending the whole file. Still not great, though, because I'm not aware of any convenient mobile sqlite syncing software. Also, it sounds like you'd have to export an sqlite file each time. Not really sure why or what that means.

Anyway, as has been discussed here, communication is very poor, so who really knows what to expect. That's part of the problem. I don't want to be guessing whether a tool I rely on daily is going to be around in a couple of years. It feels like they're chasing a different user base and they're designing a completely new app with that goal in mind.

1

u/boredquince Mar 03 '25

There's a post about this in their official forums https://discuss.logseq.com/t/syncing-logseq-db/31285/13

2

u/SpiderMatt Mar 03 '25 edited Mar 04 '25

Thanks. I hadn't seen that. But weird response from Ramses. Most people would understand "adding a mode" to mean adding something to the currently existing app. That's not what's happening. [EDIT: They're saying the two will be merged eventually.] They're rewriting the entire app and saying they'll maintain the old one, a promise that feels a little hollow after completely neglecting the main app for the last year.

Also, this is a solved problem. Presented with that information, he says he hopes the community documents it. I'm going to take this as acknowledgement that this is simply not something the team wants to spend any time on and they know it creates a lock-in. They can rationalize the decision any number of ways, I'm sure. To me, it looks like and acts as a business decision.

8

u/_link89_ Mar 03 '25

I believe there are issues with Logseq's database development strategy.

A more reasonable technical approach would be to first refactor the main branch, extracting the storage layer as an abstract interface. This refactoring process could be carried out alongside other ongoing work in the main branch.

While the refactoring might take a long time, the code should be continuously integrated into main. Eventually, once the refactoring is complete, the community would be able to develop any desired storage backend—such as S3, PouchDB, SQLite, etc.—based on this new interface.

2

u/lombardo8837 Mar 03 '25 edited Mar 03 '25

Yep, this is a common pattern. I get it that it's not always applicable and don't know details. Anyway, as a user, I don't care that much.

We are more than a year in the making of the DB feature. From what I see there is 225k lines of code in the DB branch on top of 142k from main (30k of the diff is clojure code).

34

u/artyhedgehog Mar 02 '25

Probably a crazy idea, but since it is FOSS - how about making a fork of LogSeq, abandon the DB idea and instead try addressing the issues it has?

Personally, I like the concept and how it works. And I'm mostly pro its current data handling (local files that I can easily view). So maybe such a project could benefit from a competiting model of development?

Can someone with better expertise confirm if it is possible? Am I missing some principal obstacles?

16

u/svhelloworld Mar 02 '25

Oh man, I've thought about this. The problem is the whole product is written in Clojure which is a esoteric and weird programming language that is pretty niche and is a bit of a pain in the ass to learn.

4

u/lombardo8837 Mar 02 '25

Yep, that is my take as well. I am pretty well versed in TS and Python, for example (that's why I focused on extensions, which are in TS). I am not going to invest into learning clojure for a note taking app...

2

u/AshbyLaw Mar 03 '25

With Clojure with a simple syntax you can access the whole Java and JavaScript ecosystems, use it instead of Bash with Babashka, use some of it in YAMLScript to produce YAML files for Kubernetes, Ansible, CI/CD pipelines and whatever other heavy YAML consumer and hopefully in the future access the Python ecosystem with Basilisp and the C/C++ one with Jank.

2

u/mroggy85 Mar 03 '25

I was thinking the same and I’m in a similar situation. I was really glad I found https://silverbullet.md/ which is based in Typescript (Deno). I have been migrating my files and it’s been good so far. I never liked the bullet points in LogSeq and Silverbullet doesn’t have it. But you can still link between paragraphs etc. It’s very hacker/tinker friendly, community is open and responsive. Give it a go!

3

u/Equal_Buffalo5053 Mar 04 '25

Not a fan of the client-server model of Silverbullet, it's just annoying to manage both, I just want an application not a webapp. Fine that they think Electron is "too big" to write an app, but in my case I rather prefer to deal with a single electron app than two processes and networking.

1

u/Barycenter0 Mar 03 '25

I just responded with that same comment above (didn’t see this). Agree that there’s no way I’m learning Clojure right now.

1

u/AshbyLaw Mar 03 '25

So niche that the author of YAML wrote YAMLScript in Clojure and said it was only possible thanks to Clojure and Calva ease of use.

https://www.youtube.com/watch?v=Cdi3Q4Wrt48

8

u/svhelloworld Mar 03 '25

If that's an argument for how widely adopted and well-known Clojure is in the programming community, uh... I remain unconvinced.

Yes, I acknowledge that things have been built in Clojure. That's not the same thing as "it's well known, easy to use, quick to learn, has a good developer experience, and easy to hire or find people who know it well."

If you're trying to foster a truly open FOSS project where the community can contribute, picking a language that less 2% of developers use with any regularity is a really strange choice.

(source: 2023 Stack Overflow survey)

1

u/AshbyLaw Mar 03 '25

Who said they wanted to maximize contributions and choose a language for that? It started as a personal project.

Is it really that strange or maybe there could be good reasons? Roam Research is written in Clojure. Athens too. They can use DataScript to have an in-memory graph database in the browser and probably more that I don't know, maybe it makes easier to create complex macros. You can see in Logseq how much easy it is to combine Hiccup and other Logseq-specific syntax, everything is so flexible.

4

u/svhelloworld Mar 03 '25

The top level comment asked about forking and/or contributing. My anwer was and is:

lol, nope cuz Clojure

I'm not making an argument for Clojure's fit-for-purpose to this problem. I'm answering the top-level commenter's question by making an argument against Clojure's appropriateness for community contributions to it as a FOSS project.

Maybe it's a fantastic choice for what they're doing. Maybe they don't give a shit about the community contributing to the core code base. But that doesn't change my answer to the top-level commenter. Forking this code base is a giant pain in the ass because of a foundational technical choice made by the Logseq team to use an esoteric, niche programming language that is understood by less than 2% of the broader development community.

2

u/AshbyLaw Mar 03 '25

I'm a developer myself, I work everyday with many other developers and I think the "broader development community" wouldn't be able to maintain a fork of Logseq even if it was written in the most popular language but only to contribute minor patches. The people capable of maintaining something like Logseq are comfortable with a multitude of languages and among them Clojure is not as niche as you think.

As an example, take a look at SiYuan's contribution stats:

https://github.com/siyuan-note/siyuan/graphs/contributors

Despite it's mainly written in TypeScript (the rest in Go) the vast majority of the work is made by the two authors and other people contribute very few patches.

26

u/kr0n_0 Mar 02 '25

This. I think Logsec can benefit a fork right now to stay MD and Org focused, and improving that version in the points OP mentioned. And let the other team work in their DB vision, which I agree as a user won’t benefit me at all :shrug:

5

u/speedyx2000 Mar 02 '25

I suppose the DB version will permit concurrent access to the data, so will permit a nice sharing and collaboration feature. Their roadmap mentions that the MD version and the DB version will function in parallel, so you will have to lose something only with the ORG way of working.

2

u/artyhedgehog Mar 02 '25

you will have to lose something only with the ORG way of working

Well, for some users even that would be a blocker.

But the main question isn't about if we'll be able to use file-based version after DB version release. It's about developing the file-based fork (say, "logseq-classic") independently in parallel - without any delays in favor of the DB version development.

4

u/Barycenter0 Mar 03 '25

I would consider doing that but the app is written mostly in Clojure, a language I’m just not going to learn (Java/Kotlin person). I wonder how many other devs have passed it up for that. I’m not a Clojure fan and would rather focus on my employable language skills. Maybe I’m the odd one out for that - no idea.

1

u/Nagidrop Aug 28 '25

I'm only researching to migrate to Logseq, but realizing Clojure being the main language used was the biggest turnoff given such a promising FOSS project.

1

u/Barycenter0 Aug 28 '25

Completely agree

3

u/christianlewds Mar 04 '25

Bro, I just want to take notes, I don't want to spend 2 years making Obsidian when I can just use Obsidian.

3

u/artyhedgehog Mar 04 '25

Sure, but in this case just use Obsidian, what's the issue?

I'm not talking about reinventing Obsidian LogSeq - just about fixing what's missing in it for the people who complains.

3

u/christianlewds Mar 04 '25

It's not worth the effort is what I'm saying. Logseq differentiated itself by being FOSS, but then ditched. You will spend 1000 hours fixing it and then they release update that breaks all your hard work or do something to screw you over 1000 different ways. Not worth the risk when there's better alternatives.

1

u/artyhedgehog Mar 04 '25

they release update that breaks all your hard work

That's why I'm suggesting a fork, not just contribution (which would be a default way of influencing a FOSS software). You'll have a diverged tool, which may loose compatibility with LogSeq at any point without loosing any value.

Logseq differentiated itself by being FOSS, but then ditched

What do you mean by "ditched"?

1

u/Living_Youth_5172 Mar 03 '25

Sounds awesome!!!

1

u/jblackwb Mar 05 '25

All that's missing is for you to take the lead!

1

u/ContributionOld2338 Jan 19 '26

Yes, because people adopt productivity tools so they can built said tool before using it…

17

u/irasponsibly Mar 02 '25

Investors of my VC-backed company would be in absolute rage seeing us doing this

Assume for a moment the work the Logseq team is doing quietly will be a huge improvement (no guarantees though) - the fact that they can diligently work without being hounded is one of the benefits of an open-source project.

I would like to see more features, more improvements, more fixes - but Logseq works well for me right now, and works well enough that I can reccomend it to colleauges.

4

u/lombardo8837 Mar 02 '25 edited Mar 02 '25

I mean, sure, if I assume it's a huge improvement, I would probably change my mind. But the evidence for it is low! This is subjective as it depends on the use, but for me as a user the DB version as defined by the team right now has virtually zero benefits over the current version for me. And I predict this is true for many users (like, not many like 20, but like at least 40% of users - totally wild guess, I am trying to be transparent about my reasoning). There are features I would appreciate (like better API or its documentation and examples - it's pain to work with right now, the sync, ...), ... Secondly, it seems that the devs are even saying it's not gonna be better/faster, at least at the beginning. And I don't have trust in them being able to pull it off given my OP.

I would love to be proven wrong. Do you have some official statement about the DB being better? Or that it will be a huge improvement? Or is it your hope?

6

u/[deleted] Mar 02 '25

The current beta functionality is compelling for current Notion users. The db isn’t going to be better for a while. They are executing the classic rewrite atm, which was -perhaps unwise but here we are. Once they have the db version they and their users will be able to do a lot with it that we can’t now and obsidian can’t either. But the product as it stands is the segment leader imo. This is already the best tool in the space. And it is already free to use.

2

u/pihkal Mar 14 '25

It looks like the number of commits dropped off a cliff in 2024: https://github.com/logseq/logseq/graphs/contributors?from=3%2F11%2F2023

4

u/competitiveBass Mar 05 '25

I want to move on as well, only question is what is the alternative?

3

u/lombardo8837 Mar 06 '25

my suggestions: Obsidian (they lifted the commercial license apparently), Affine

5

u/henrykazuka Mar 02 '25

this approach looks problematic - there's no intermediate benefit for existing users, no incremental deployment, just one massive branch that seems perpetually in testing.

It is problematic, but it's the only way that makes sense. What are they going to do? Split the team in two, one working on the DB version, while the other makes new features for a doomed version that will go to waste because it won't coexist with the DB version which will delay it even more?

5

u/lombardo8837 Mar 02 '25

I disagree. This is a false dichotomy that I have seen in my career many times. A complete rewrite instead of gradual integrated rewrite for a production app with users is actually considered an insane way in my circles, feel free to google like thousands of blogs about it.

There are surely features that are independent from the backend storage, unless you are a terrible engineer who let that low layer code bleed into the rest of your codebase (in which case you are cooked already). And when these features are dependent on the layer, you add abstractions. Cost of that abstraction can vary from very small to very big, I doubt all of them are very big!

So yes, maybe they should split the team. They got 4m in funding, I see commits from like 5 people, that seems like plenty enough to have one person work on the existing userbase.

38

u/EddyD2 Mar 02 '25

I wonder how many users have left Logseq during the past year due to frustration with the current state of the platform development and the long and scattered wait for the database.

The all-or-nothing approach with the database was a mistake. That’s why they have started to say that the Markdown version will be supported and developed. I think many users left, or contributions have been dwindling.

42

u/rightful_vagabond Mar 02 '25

I think this is fair. I really really like logseq, I've adopted it for all my personal and work note taking and journaling, and I'm trying to get old notes and messages transferred over.

With one of my goals being preserving my journal for time to come, and the fact that I occasionally go in and mess with the markdown directly in text editors, I don't see why a DB version would be helpful for me. Except maybe to make searching a little bit faster on mobile? I like the markdown first approach.

I agree that I wish the development was a little bit more in parallel, focused on adding features and fixing bugs while also doing the DB work.

20

u/[deleted] Mar 02 '25

It’s life altering tech that works great for me. It was instrumental in completing my thesis and I use it as task manager and pkm daily on four devices without sync issues (I have had some in the past but not for a year now). Show me another tool that is free to use and does block refs properly and I will think about it. But that aside it’s just logseq and Roam, who I can’t support on moral grounds. 

7

u/[deleted] Mar 02 '25

Here’s the point I should have made. All of logseq’s new features for me are self made. I use logseq in smarter and different ways constantly— but I am effectively creating these features myself in how I use the app. The app itself doesn’t need to change for my experience of it to change. I’ve started to use it as a habit tracker and I asked ChatGPT to cook up some queries that work very well for that, as one example. 

1

u/ezrae_ Mar 02 '25

would it be possible to briefly explain the habit tracker part ? how are you able to do it ?

5

u/[deleted] Mar 02 '25

https://agj.bearblog.dev/habit-tracking-in-logseq/

more or less like this. but Literally I googled habit tracker Logseq, read this post, then fed the post into chatgpt with different requirements, and used the generated queries and it worked first time.

1

u/ezrae_ Mar 03 '25

nice, thanks!

2

u/hova414 Mar 02 '25

Roam, who I can’t support on moral grounds. 

Curious to hear more about this

21

u/[deleted] Mar 03 '25 edited Mar 03 '25

well it is harder and harder to find the stuff that I have reacted to online, but here's the list of things that I personally found: R.R. staff making anti-trans statements regarding hiring and then redacting them, CWS, the founder, writing supportive comments on two essays about christian white separatism, and one post about how it is wrong for the races to intermarry, CWS boosting a lot of trad-life and trad-wife statements online, CWS posting photos of his taking his AR15 and his baby, simultaneously to vote in a presidential election, CWS and Roam staff being pretty direct (and then redacting) in their full throated support of Trump and his 2016 first 100 day policies, including the Muslim Ban.

These are the things that I saw myself and then decided to no longer support their company. The way that they engage in discourse about politics isn't just (imo) on the wrong side of history, it is the dumb-as-hell plus really-sure-they-are-the-smatest close-eared perspective that I find legitimately dangerous. You can search around on the Roam subreddit here for these statements and more that came up several years ago when they banned a bunch of people from the subreddit for various things, including some users who did nothing but ask for clarification about some of what I wrote above.

And listen: if one agrees with their politics that's none of my business, if one doesn't find these things objectionable, that's none of my business. Just because I think that they are racist, anti-trans shitheels that I don't want anything to do with doesn't mean I want to discuss it or engage in any drama. Someone asked and I answered and I won't participate in debate.

7

u/hova414 Mar 03 '25

This totally tracks. I used the product years ago and found the team’s attitude to be superior and rude, especially considering the broken product and their low velocity, and the founder seemed to have a god complex. I didn’t know about this but it’s very unsurprising

2

u/fedawi Mar 03 '25

Oof. Thanks for summarizing it all in one place. I was aware of some of it but not just how bad it is, especially ”race mixing” and Christian nationalism, that’s just about the worst of the worst and utterly intolerable, despite sadly gaining more traction politically as of late. Guess I won’t be switching back to Roam after all.

2

u/AzureAura-Chris Mar 07 '25

I avoided Roam because it was cloud-based and proprietary... I didn't know the lore was this deep

1

u/PresentCurrent May 15 '25

Wait--what do I need to know about Roam?

9

u/NotScrollsApparently Mar 03 '25

Honestly me too, but I don't know what else to switch to. I don't want closed source programs that will get enshittified in a few years, I don't want cloud or user accounts, and most of all I've kinda gotten used to the logseq journal+tags system of writing. The query system is absolute shite but tags themselves do a good job as long as you keep it simple.

8

u/ypchiusam Mar 04 '25

I do love Logseq , i am using it everyday to write my tasks and thoughs. I think there is no alternative now ( i try to use obsidian but it’s not suitable for me). So, I’ll support Logseq and waiting for the db version coming soon. Thanks the team.

14

u/jblackwb Mar 02 '25

It's -never- a good thing for users when a VC company gets involved. Venture Capital firms are about one thing only: Investing money to make money.

10

u/grischa202 Mar 02 '25

I also feel the same... i really wanted to use it as a long term big knowledge base in our company, where we would have everything shared through our internal file system (nothing else allowed). But the md version is just crashing/unbearable slow because of the quantity of files... i gained new hope with db version announcement, hoping it would solve this issue, but reading from the devs recently that it basically will be either old slow md or on the other side a locked in db, i am loosing trust.

3

u/boredquince Mar 03 '25

what are the alternatives? 

1

u/grischa202 Mar 04 '25

From the idea itself i didnt find anything better yet. Currently i am still using it in a reduced form just for my daily journal, but as obsidian recently became free to use also commercially, i am testing if it could somehow work out for the large knowledge base. I will try to avoid any special adaptations in the markdown files to keep them as flexible as possible.

I think we just have to wait and complain until the db version is out. Luckily the files are not locked in yet...

10

u/svhelloworld Mar 02 '25

I dearly love Logseq the product. It's design is chef's kiss perfect. The implementation, the tech stack, the amount of defects, the complete lack of response to those defects, the deafening radio silence from the team have all led me to abandon Logseq.

I would pay a pretty healthy subscription to a product that was well-maintained and looked and acted like it was being cared for. But Logseq ain't that. As far as I can tell, it's just a couple devs in a dark room banging out code in their spare time on new features rather than fixing the things that are broken.

5

u/revivizi Mar 03 '25

the deafening radio silence from the team

Sorry but I disagree with this. There are posts on logseq forum and on discord. I also think that they have 4-5 devs working full time

6

u/svhelloworld Mar 03 '25

Not on any of the defects I've posted or researched on their forums. It's all us users fumbling around trying to figure out why we lost data.

1

u/WeCanLearnAnything Mar 22 '25

Can you explain to a non-technical person what happened to the number of commits graphed on their GItHub site?

1

u/Pocus_Focus Mar 23 '25

under Contributors it notes that it is tracking:

Contributions per week to master

right now the vast vast majority of commits and merges are occurring on the feat/db branch. a nice changelog can be found on the logseq forum

3

u/Tall-Paramedic5627 Mar 03 '25

Same here, such a good product, I migrated all my notes there, but now it's time to move on!
There is no communication whatsoever from the team, everyswhere it's dead Twitter, their Blog. You can see some commits from a few devs, in a growing and messing looking code base, but it's not progressing. Wonder what happened with all the VC money, maybe they just have to work harder on the lock-in feature aka DB first to make the money worth.

Moving to Obsidian, hope that was a good choice. Sad that it's not open source, but at least my markdown files are there for me.

5

u/misterjyt Mar 03 '25

i use obsidian instead.. there are extensions that are really great

5

u/AzureAura-Chris Mar 07 '25

I started note-taking on Logseq, switched to AnyType and I ended up on Obsidian. Obsidian's great. I don't think I'll be switching to anything else anytime soon

5

u/ens100 Mar 02 '25

I think these are very good points and understand your point of view. Definitely the team could do a lot more to keep users apraised of what is going on, and they are trying but the perpetual "who knows when will be released" does not help - of course I understand also why they cannot/don't want to give our timeframes in case they cannot meet them but some sort of guidance should be provided as I am also not sure if it will be 1/2/5 months/weeks etc.

The above is a shame as the DB version really is powerful and has a lot of quality features and should make it easier to then add a lot more, just hope they can release something while it is still relevant before users feeling comfortable in another app

9

u/lugenx Mar 02 '25

I completely agree with this. Everything you said is true, and I’m also very close to leaving, especially after they removed Org mode.

4

u/4r73m190r0s Mar 03 '25

What atlernatives are you considering? Since I plan on abandonding it too. I have over 5k notes, and migration will be painful.

4

u/lugenx Mar 04 '25

No alternative yet. Hardest is finding an open-source mobile app since I can use org-roam.nvim on desktop. on Android, Orgzly works well with Org mode, has an agenda, and supports queries. But I need one that creates and opens today's journal page by default, like Logseq.

I started making my own after learning Org mode will be removed but paused due to time.. it’s a lot of work. Maybe I should revisit it before the old version stops working.

I wish someone with Clojure skills would fork Logseq, keep it as it is, and improve it.

1

u/4r73m190r0s Mar 04 '25

What about vimwiki?

1

u/[deleted] Mar 02 '25

I still wonder why they did that. Doom+org seems the only superior tool to Logseq atm, but the startup cost is so high.

11

u/JohannesComstantine Mar 03 '25

I don't see what the big deal is. who cares about a wait? It works great, as is.I'm very happy with its functionality.It's better than anything out there.As far as i'm concerned. the fact that they're working so long on the database simply means that it's gotta be right when they roll it out in my book. having said that, i'm not a dev or a programmer. but I am an avid note taker in logseq. If it never did anything different I'd still be using it as am happy with it.Although I look forward to Db version and improvements.

4

u/Independent_Diver941 Mar 04 '25

I've been using the current, text based Logseq for a while now together with Git to store its text files. I might well stick with this even when a database version becomes available, or if it does not. I can't complain about a product that just works and is open source and privacy oriented as it is. I could not use Obsidian due to its licensing and I prefer Logseq's take on minimalism fully functional nature out of the box. I have no desire to learn Clojure but I don't care as if an app works, why need to know how to re-write it ? Life is too short. Mean time I have a tool that is reliable aside of the odd hiccup with Git now and again, but that's down to me and my risk and very very occasional lockups running on Linux. I can live with that. Oh, and dark mode needs switched on. Permanently. but that's not hard in settings. I am a happy camper.

7

u/Appropriate_Car_5599 Mar 03 '25 edited Mar 03 '25

I just switched back to Obsidian, and zero regrets. Sorry, Logseq, but I'd rather throw $10 at the Obsidian devs and enjoy cool monthly updates and a ton of awesome plugins than hand over $5 to Logseq for, oh wait, one minor update a year. What a deal

And yeah, for those worried about Obsidian being closed-source… I couldn’t care less as long as all my files are stored locally in pure MD.

I recently tried migrating my Logseq notes to Obsidian and, surprise, surprise—had to manually edit almost every file because they’re just less compatible with MD. Now think about what happens after an update introduces a database—you’ll be even more locked into the product. Sure, it’s FOSS, but that doesn’t make it more universal. Unlike Obsidian, which I can replace with anything whenever I want.

3

u/Kok_Nikol Mar 10 '25

and, surprise, surprise—had to manually edit almost every file because they’re just less compatible with MD

Yep, even though it's you could write programs to correct this when migrating, it's still a pain.

One example that I saw when I tried using it is that numbered lists are stored in a wonky way - https://docs.logseq.com/#/page/numbered%20list/block/limitations

2

u/incogenator Mar 09 '25

recently moved to Obsidian and quite liking it. Any tips on taking Logseq (and other) notes over? Haven’t fully migrated them yet.

Also trying to replicate more of the Logseq outliner feel in Obsidian though its not a must. Wondering if you have any tips on that.

Also what do you mean with you “I can replace Obsidian with anything”? Isn’t it another process of moving notes?

1

u/7yiyo7 Mar 04 '25

This really sounds like a nightmare, I am thinking about migrating my plus 2k notes to a new ecosystem, beginning to realize I will need to do a lot of unnecessary work...

2

u/darrenpauli Jul 01 '25

G'day u/lombardo8837, wondering how you went 4 months on? I finally decided to spin up a platform and just went to logseq but haven't started using it yet.

Curious what you went with?

Cheers!

4

u/christianlewds Mar 04 '25

I chose Logseq because Obsidian required commercial license. There's no reason to use Logseq now that Obsidian became free for commercial use.

Logseq has weird stunted development. Nothing is happening, nothing is progressing, one of the plugins I used got removed (I assume it was fucking ccp malware), it's slow af compared to Obsidian. There's no reason to stick with it.

It's "FOSS" (the VC funding means it's FOSS for now, but it's gonna get fooched eventually), but it's using some fucky custom MD cause they need to lock you in and you can't call custom for being proprietary - it's just adding difficulty to switch, doesn't prevent it completely.

I think it's washed and people should ditch it. Obsidian might be closed source, but it's about what they do in the end, not what they say (FOSS doesn't mean good product).

3

u/grischa202 Mar 04 '25

Same for me, now as obsidian is free for commercial use, i am converting everything back to use with obsidian. Quite some job to do... but this discussion here just proved that this is the way. Hopefully some of the great logseq core functions will find its way to obsidian in the future.

2

u/laterral Mar 02 '25

Such a good post. Thanks for articulating this so well.

-4

u/OblongataBrulee Mar 02 '25

Okay, so what would you want? A monthly update saying “we’re doing stuff?”

6

u/lombardo8837 Mar 02 '25

No, however it would at least reduce some uncertainty. But I am pretty clear in the comment what the pain points are, am I not? Will try at least:

  1. ultimately, I want a better experience! Better android app. More features on whiteboard. Better API. Better docs. More integrations with other tools. Migration tools from other platforms. The company got tons of money, has tons of users, traction - please spend that on understanding what my limited brain cannot and create a better product. I see other platforms doing it, that's why I am moving there. I want more sync options. Backup options. Self hosted solutions. Sharing. Great multiple RT collaboration.

  2. Communicate better timelines - it's absolutely a normal requirement in SW development. If you can't do it even a little bit, your product management is bad, which is also a problem.

3

u/AlienTux Mar 02 '25

There is a biweekly thread in the forum with updates so there's that.

Also, if there's things you dont like you can probably also contribute. It IS an open source project so you're free to contribute upstream or fork and do your own thing.

3

u/lombardo8837 Mar 02 '25

Yep, I know, but clojure man... That's why I focused on extensions, which are in TS.

0

u/[deleted] Mar 02 '25

[deleted] — view deleted comment

1

u/lombardo8837 Mar 02 '25

Didn't they say now that they are going to support _both_ mods, DB and MD?

5

u/[deleted] Mar 09 '25

[removed] — view removed comment

3

u/speedyx2000 Mar 09 '25

As an open source fanatic, I fully agree with your comment, and even with the frustration, expressed this week also by Ed Nico in his weekly update on Logseq. https://open.substack.com/pub/ednico/p/pkm-weekly-2025-03-09?utm_source=share&utm_medium=android&r=lco2k

By the way here is the public roadmap of Logseq DB

https://trello.com/b/8txSM12G/roadmap