One of the original differentiators of Obsidian was the lack of lock-in compared to Notion, Roam, or other tools. It’s just markdown! You can export it!
But lately I see so many workflows and plugins that are great but have features that seem to lock in notes to Obsidian or have a heavy reliance on plugins. From things like Dataview to small things like nested tags in YAML. Or block linking. Or embeds.
If Obsidian went away tomorrow, and you needed to use a more standard markdown editor or something VS Code, how much would your PKB break?
Is anyone else concerned about this? If I’m effectively locked into Obsidian, what difference is that compared to just using Notion or Roam. How are people mitigating this?
This maybe a legitimate concern. Maybe the devs or admin can provide us some input or maybe some roadmap.
I didn’t mean it so much from the development POV. I think that one of the biggest benefits of Obsidian is that people can make their own configurations, use their own plugins, and ultimately decide how much ‘lock-in’ they are comfortable with as a trade-off of powerful features in Obsidian or convenience.
Yeah, well … I do see us galloping away from portability, in a way. That’s why I try to use as few themes, icons and plugins as possible. But I wouldn’t really like to give up
Dataview
Templater
Obsidian Leaflet (maps)
So basically it’s every user’s decision how far (s)he wants to deviate from a “standard” that is not really one. You can operate Obsidian in a Markdown-compatible manner, but you lose lots of great functionality. A tradeoff, like with so many other things.
I guess what would hit me most if ever abandoning Obsidian would be the wikilinks, because to really function they need an indexing database, and using standard Markdown links isn’t a good option for me because of the missing suggestions.
Regading Obsdian Core,
Wikilinks are not part of the markdown spec [[link]], However, I believe they will eventually be included. If you are concerted about it, use standard markdown links.
Since wikilinks are not part of markdown, that’s even truer regarding header/block-links.
nested tags in YAML I am not sure what you are referring here. Tags (nested or not, in yaml or main text) are not part of the markdown spec.
embeds - what do you mean by this?
I am not sure I fully grasp your problem.
I will approach this from another angle.
Obsidian strives to support markdown 100% and be commonmark compliant.
Yes, there are augmentations (but not modifications) to markdown (e.g. handling tags or using wikilinks).
Plugins can add even more stuff in form of specialized codeblocks (add not modify).
I would like to point out that dataview, tasks, and most of the other plugins use your markdown/yaml files as the source of truth and do not store side information.
If you are concerned about the additions or the workflows enabled by the plugins, just don’t use them.
I’ve gravitated towards keeping my ‘content’ files separate from my ‘workflow automation’ files. The former are things like article drafts, concept exploration, book notes, meeting notes and are vanilla markdown, more or less. The latter are things like project/task scaffolding and workflow notes with heavy use of dataview, buttons, graphs etc. If Obsidian went away (the horror!) I would lose a lot of value of the scaffolding and automation notes, but the content notes would retain almost all their value.
The reason you use any Program A, rather than the next best Program B, will be that it gives you a better workflow in one way or another.
YAML itself is not part of markdown, but a markup language of its own; implementations in markdown programs vary despite a degree of standardisation.
afaics many users don’t care about lock-in and would be quite happy if Obsidian worked entirely from a database. They have nothing to lose by using any plugins.
I am sure that those like me, who want complete interoperability, make their own judgements about what they will and won’t use.
I stopped using YAML, and removed it from all my notes, when it was stated that it ought to be preserved for plugin use. I haven’t missed it.
I always use wikilinks. The speed difference is massive and it is a developing standard. Should it ever be necessary, I could convert it to markdown links.
Personally, I find that markdown itself is a bit of a lock-in as it is not accessible to many of the programs I like to use. Accordingly I prefer .txt where possible and use death_au’s txt plugin. That one increases interoperability rather than reducing it.
I’ve given up themes. I would think very carefully about any community plugin before using it. (I say would because, at the moment, the txt plugin is the only one I use but I am happy to consider others if I see the need.)
Seems to me that the Obsidian setup is ideal - those who want an all singing and dancing program and don’t care about lock-in have the options available if someone writes a plugin. And those want simple, safe, interoperable files can do that too, with nothing locked up.
But this involves no lock-in with Obsidian because the database can be recreated anew with every use. All the necessary information is stored in the files themselves.
And there are many more apps that support wikilinks. Off the top of my head, I know Foam (a VS Code extension) support it.
It does! But Foam doesn’t really support things like nested tags, tags in YAML, aliases, etc. If Obsidian went away tomorrow, and you moved to Foam, you could do it, but how much of the past PKB setup built around Obsidian-only or plugin-dependent features would truly work?
This was mostly my question the community — how are people balance the convenience of more dedicated Obsidian or plugin features vs the long term (“it’s just markdown!”) portability of Markdown, maybe WikiLinks (since those are fairly widely supported now), basic tags, some YAML, folder organization, and strong search.
It seems like you are aware of those tradeoffs with your setup. Many aren’t, to your point about people not caring about interoperability — which is totally fine! To each their own.
I’ve found that as I’ve gotten deeper into Obsidian, and with each release offering new features on top of what I just mentioned above, I’ve tried to resist being too reliant on some of the less portable things — the dataview plugin being a good example.
This is super interesting! I’d love to hear more about your setup because I think this strikes the right balance of taking advantage of amazing features like dataview, buttons, etc while keeping longer-term notes and knowledge as interoperable and portable as possible.
I should have specified — Wikilinks don’t worry me much as far as portability and future-proofing because — to your point — they are pretty widely supported at this point. I should have been clearer on that in the initial post.
But header & block links are less supported — and I’ve found myself struggling a bit with the amazing power they unlock in my notes in Obsidian and the fact that using them is a tradeoff with interoperability and future-proofing, to some extent.
The same goes for things like Aliases in YAML, tags in YAML, nested tags, and embedded WikiLinks (the ![[note link]] or ![[note name#^12345]] syntax).
I would 100% agree with you that these are augmentations not modifications and are still using Markdown files as their source-of-truth.
But if one were to fully use all of these features deeply in their PKB, they would be trading off some level of interoperability and future-proofing. So my question is really aimed at how people might mitigate that risk.
For future proofing, you may be interested in Markdeep, which can be appended to any markdown file and (AFAIK) supports linking to headers. Mind, I haven’t actively used it, but was interested in how it doesn’t require a specific ‘interface’ for editing and rendering Markdown files.
True. The plugin only enables part of Obsidian’s .md functionality.
For the most part the advantages of .txt outweigh the loss of Obsidian’s functions in those files, at least for me. I can always switch extensions for cases where that’s not true.
In my case it just means using Obsidian less. Other apps have better search (at least when most of my files are .txt), don’t break non-CommonMark formatting, and don’t risk hiccups if I use external scripts to modify or create notes.