Yes, exactly, we’re looking at that from different perspectives.
And while the engineering perspective is certainly important, it’s crucial to remember the end-user experience as well. I think that’s something a lot of open-source projects struggle with.
A few comments.
I think you’re misunderstanding my point about losing annotations.
I didn’t mean that logseq would screw up and literally lose the annotations.
Instead, what if, god forbid, some day logseq is not developed further?
Or a user wishes to switch his PKM tool for some other reason?
As a developer, you’re focused on improving the app, sure. But a single end-user has little influence on logseq’s survival or direction of development. So he has to plan for the case that logseq won’t be around for ever.
An anecdote: Polar reader was an awesome, open source PDF annotation tool.
Some day, the devs announced that they would switch to a client-server model, because syncing was a much-requested feature and this was the easiest way for them to implement it.
A little later they also decided to try and monetize their product and people now had to pay for the cloud-storage, which was also mandatory because of the new server-client model.
People were upset and there’s radio silence from the devs. The project is essentially dead now.
Moral of the story: a lot of users, including me, got burned and lost years worth of annotations.
Not to say that the same thing will happen to logseq, but there’s many ways in which a project can die.
And it’s much easier to sell users on an app where they do not have to fear losing their data.
To me, that’s one of the central promises of being ‘local first’.
With the notes being in Markdown, there’s little damage to fear there.
PDF annotations are trickier, because everyone uses a different format.
So it’s safest to follow a bigger project, like Zotero, which is likely to be around for longer.
If there’s reason to assume that Zotero’s structure for annotations will change in the near future, I think it’s reasonable to wait for the new format and built on that.
But, are there any specific reason why Zotero’s annotation format should not work for logseq?
Zotero, too, highlights and finds the annotations in the PDF, and extracts the highlighted area or text for display in the sidebar. What else does logseq need?
Regarding ‘ruin[ing] the purpose of a built-in annotator’, I disagree as well.
First, if there’s a two-way sync, the annotator is useful as it would still allow to quickly edit and make new notes in logseq without having to switch apps.
I just put emphasis on the Zotero-logseq direction, as to me this is more important.
Second, refusing to implement an awesome feature because it might make a good feature obsolete, sound like sunk-cost fallacy to me.