I'm writing a longer (as it seems) article on the lock-in effect of solutions like #Obsidian that are using open formats like #Markdown for storage. The file format is not the only thing that might lock you in.
I did already start with a list of arguments but also want to collect your ideas so that I don't forget a good argument.
Please, no emotions, just facts and objective arguments.
Reply here in this thread and I'll collect ideas from it. 🙇
I followed that idea for other purposes as well. For example when I was using PIM sync: Linux JPilot - Palm Pilot - iSync - Outlook - Exchange (decades ago).
Stick to the common denominator and avoid lock-in for future migration.
Since there are lots of alternatives that you could use without those restrictions, why do you still stick to Obsidian?
@publicvoit I don't think, that Markdown per se is a lock-in factor. Ideally, every tool would save everything as flat text files. That would truly be open, imho.
Ages ago, I was using a simple, text file based local wiki. Things got complicated ever since.
@gisiger It want to write about Closed Source lock-in effects that are using open formats.
OBTF? No. I found "one big text file". Do you have an URL where I can learn more about it? It seems to be very similar to my approach at least according to the number of files: https://karl-voit.at/2020/05/03/current-org-files/
@gisiger thank you for the reads! Out of everything I've tried for PKM and the like, I somehow never tried going with the OBTF. I guess the years that I haven't been using vim made me dread longer files like that, but I might give that a try and make extensive use of folding things by indentation.
@publicvoit Part of preventing lock-ins is working towards standardization. Markdown files do not offer enough functionality to do complex workflows. At some point referencing, time scheduling, tagging and other organisational principles are needed. It would be great if we aimed at standards + files. Obsidian tries to do this by openly providing documentation for the JSON canvas spec and thereby making it easily reproducible. This is the way.
However, I think that most people say that we already have Commonmark and others will argue that MD is not designed for that. An extendable LML is https://en.wikipedia.org/wiki/Asciidoc if I remember correctly.
@publicvoit I have never used Obsidian because it's closed-source - I really its backlinking feature, but I'd hate to have been accumulating a personal wiki of sorts for any amount of time only to find out that it's now less feature-rich or inaccessible because the board decides to pursue profits in a predatory way. I realize that it might be a stretch, but I'd rather not take my chances when there's safer alternatives.
I've used vimwiki since October 2024, but recently switched to Logseq as an experiment, and more convenient linking is basically the only reason I've decided to run this experiment. It's not that rare that I have to change a few filenames, which obviously broke references, so I either had to stick to the original filenames or run a script to update the broken links, but that gets tedious and involves me not forgetting to do it in the first place. The heavier solution that is Logseq does that for me.
The greatest point I see here is that I can rather easily switch from Logseq for any other software or go back to a text editor of some kind for my beloved .md files, even if with minimal changes to the files to get rid of some the software-specific markup. This is the true power of Markdown - it's basically just text with extra symbols that define the final formatting, and it makes editing it easy and enjoyable, while keeping any potential migration process and much less dreadful and dangerous.
Unfortunately, the linking is exactly the double-edged sword you're talking about it, both in Obsidian and Logseq, because its format is not Markdown-default: the double brackets/parenthesis/etc. surely won't be as easy to migrate if need be. While the page references ([[ and ]]) could potentially be resolved with a script or a vim macro, block references ((( and ))) are a greater risk, because these won't be worth much outside Logseq itself.
Over the years, I've gone from using strict plain text/Markdown for my notes and personal wikis to this, more complicated and daring relationship with a bigger tool like Logseq; I've tried various ways to format my texts, switching back and forth from more widespread long-form texts with empty lines for separators to bullet outlining, and I've developed my own syntaxes and legends for them. I've never found an approach that I would consider perfect. For now, it seems like going for an open-source tool that relies on an open-source extension is the best I can actually get, with the added benefit of other features typically included in such software.
For I now, I guess there's always a catch, always a trade-off.
@publicvoit I do use my own set of tools to check if my obsidian content valid in the sence I understand and need it. (markdown and frontmatter validation combined with https://pypi.org/project/obsidiantools/ )
E.g.:
The frontmatter-editor of obsidian is very helpful (for simple data structures), yet prohibits complex formats (which I sometimes use by editing in a different editor).
I also check (potential) obsidian extension before usage for markdown/python packages so support outside obsidian is ok.
@publicvoit Great idea. I had similar thoughts that fileformat ain't the only lock-in. There's more and it makes it hard to find a solution that lasts 10-20 years (e. g. to document tax-related things, server stuff or general knowledge that is timeless). That's why I'm a fan of OpenDocument and Microsoft as well. At least it's certain that I can still open my stuff in 10-20 years.
@clemensprill I have bad news about the Microsoft XML that got standardized. This has not much in common what you get when an up to date Office product generates when you save a file. 🤷🫣
@publicvoit if you only use things out of the box it's easier to switch out. Proprietary sync and publish can keep in non-technical users, but that's easy enough to replace with open tools. Notes made in Obssidian work can be opened in any md editor, but getting themes, keybindings, and file structure / backlinks the same when possible has cost. Plugins (even open) can be the hardest part of moving, as typically proprietary tools use custom APIs and DSLs and devs don't separate their concerns.
@publicvoit part of the lock-in effect for Obsidian is their live preview mode -- instead of seeing the underlying Markdown text, you see that text rendered in a way that is particular to Obsidian. When you combine Obsidian's unique extensions to Markdown (like callouts), along with themes and custom stylesheets, you're no longer working with just Markdown but Markdown as rendered by Obsidian...and then you're totally locked in despite the supposedly open file format.
@publicvoit It has. But so far Emacs is the only editor who supports it fully. Simple example: Authoring a README on Github. I can just write MD from my IDE, commit and push. Other contributors can do the same. I could also write ORG, since GH renders it … but not from within my IDE and contributers will complain about the „esoteric“ format. Wish it would be different but thats reality.
@publicvoit my personal conspiracy is this cult-like following is actually a marketing astroturfing made look like grassroots movement
For person in wiki-pkm-notes space it's unlikely to advocate for a single product THAT much. While there's not actually much of a substance to advocate for:
Yes, files are local, there are plugins and... so what? All use cases are covered by other products. Why be so insecure about some app you're using? 🤔
I don't think that Markdown (or any open file format; except proprietary extensions) is here the biggest factor which differs between lock-in effect and openeness.
I want to express that there are lock-in effects related to functionality even though the file format is open. There's still plenty left.
@publicvoit interested to hear your thoughts. I think I agree: although open data, schema and interchange would definitely hugely help, there does still seem to be a risk of lock in.
@publicvoit also think we can expect an ecosystem to provide an intratool data sea of some kind. So every tool is as able as any other to work with data, but specialises in the interface it provides on to data and the types of specialised domain data it works with
. We could also expect tools to openly support each others’ interfaces in an integrated way.
@publicvoit aren't we locking ourselves in by using emacs features too? Logseq is open source right? So at least there I don't see much difference (obsidian seems a different matter)
@publicvoit agreed with your thoughts on the matter. I think especially younger people need to think decades ahead. Be librarians of their future and protect information they collect. Looking back I wish I started using org and emacs much sooner...
@drizzy@publicvoit I am now almost 50 and for more than 25 years I am on the never ending quest of finding the right tools. The only future proof format is pen and paper. I lost a lot of data over the years, but I still have most of my notebooks from the past decades. I know, this is not the focus of this thread, but the longer I am in this game, the more I go back to pen and paper.
I'd actually love to use pen and paper but that doesn't even fulfill my most basic requirements and doesn't scale at all as long as there is no fool-proof offline handwriting OCR that works for me. 🤷 And even with such a solution, I'd have massive issues without a full digital version.
Add comment