Zettelkasten Forum

Home› Software & Gadgets

future proof tools

zettelkastenzettelkasten
in Software & Gadgets

Hi,

Today I use Obsidia and want to move to something other

I would like to go with something that’s future proof and doesn’t have any vendor lock-in.
Something that is simple to use on Mobile and Laptops.

What can you suggest?

Comments

  • WillWill

    You might try The Archive! If the Archive has too much vendor lock-in and isn't future-proof enough, then Emacs might be your cup of poison.

    Will Simpson
    My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
    My Internet Home — My Now Page

  • andang76andang76
    edited May 12

    The only real future proof tool that come in my mind is Emacs.
    And it is not so simple :-)

    Even an open source tool that hasn't a solid history can be discontinued, vendor lock-in is not the only possibile factor for future proof.

    I've bet the future of my notes on markdown and having everything on my pc and not in the cloud, so Obsidian for me remains (I hope) a good solution.

  • GeoEng51GeoEng51

    @zettelkasten said:
    I would like to go with something that’s future proof and doesn’t have any vendor lock-in.
    Something that is simple to use on Mobile and Laptops.

    What can you suggest?

    I agree with @Will . I think your best bet for software would be the Archive, in terms of not having "vendor lock-in". You buy it once and get all future versions without cost.

    Having each zettel existing as a markdown (i.e., text) file makes it future proof from the perspective of not using a proprietary file format. And if you have it in this simple form, without a bunch of fancy add-ins, you can access it with a variety of software. Again, you're not tied to one vendor. I've already switched my Zettelkasten software using the same set of markdown files and will probably do so again in the future.

    Then you just have to ensure that you can access your computer files indefinitely into the future, so store them on your computer and on a good external backup drive (not the cloud). If you really want to be future proof, in this regard, also print out and store paper copies.

    There is no media that will last forever, although if you want better longevity than computer and paper, you might try papyrus or clay tablets or gold plates :wink:

    Having said all that, outside of some society meltdown, your longevity will likely expire before paper files :smile:

  • zettelsanzettelsan

    I use Emacs and am hopeful that the tool will serve me till the end of my life. Indeed, I am generally skeptical of longevity of software products, especially the ones that are closed source and/or offered by software venture business. That’s one reason why I remain within the Emacs ecosystem whenever I can, and haven’t used proprietary tools like Obsidian, Logseq, Notion, etc. With Emacs, though, the concern is not with vendor lock-in but the health of the developer community. Will Emacs stay relevant long enough, when the community is shrinking and learning curve remains high for newcomers? Will it ever be mobile friendly, when users increasing use them in place of notebook/desktop computers? That, I don’t know.

    That being said, I think vendor lock-in is less relevant so long as the product allows data export/migration in a widely available format. What you want to ensure is that your data are stored in a way that can be fully restored in a different environment. It’s kinda like choosing a web browser in that sense. So long as the content data are stored in the standard format (like HTML, CSS, etc.), then the data and knowledge being held remain the same; depending on your choice of web browser, they are rendered slightly differently and how you interact with them would change a little bit. But your contents and how they are related won’t change in essence. That’s what you want to care about as you accumulate your notes.

    So when I choose a note-taking tool, I would prefer one that adds few proprietary metadata as possible to function. If your notes are in Markdown, I’d prefer a tool that works within the constrains of the format, and not one that needs all kinds of auxiliary data for “rich” features. From what I see, many note-taking software are like that these days, which is a good thing.

  • AndyAndy

    @zettelsan said:

    That being said, I think vendor lock-in is less relevant so long as the product allows data export/migration in a widely available format. What you want to ensure is that your data are stored in a way that can be fully restored in a different environment.

    Exactly. What we want is data interoperability. As Dorian Taylor said in "Radical interoperability is a political agenda" (2022):

    The irony is that so much software, enterprise and otherwise, boils down to CRUD (create, read, update, delete) operations, and the user interfaces to perform those operations. There tend to be very few verbs besides. So the menu of things the software "lets" you do can really be framed as the complement of what it actively prevents you from doing. Software that fully exposes its data "lets" you do anything, because it's the data that matters.

    @zettelsan said:

    It’s kinda like choosing a web browser in that sense. So long as the content data are stored in the standard format (like HTML, CSS, etc.), then the data and knowledge being held remain the same; depending on your choice of web browser, they are rendered slightly differently and how you interact with them would change a little bit. But your contents and how they are related won’t change in essence. That’s what you want to care about as you accumulate your notes.

    The analogy of HTML : Browser :: Markdown : Zettelkasten is very direct, as Markdown was originally created as a lightweight markup language that could be converted to valid HTML. When thinking about interoperability, it would not be a bad idea to think about how to build a Zettelkasten that can be easily converted to a website, because Web standards have become the worldwide lingua franca of textual interoperability. (But this doesn't mean you would have to use Markdown; there are other lightweight markup languages that could work.)

    So when I choose a note-taking tool, I would prefer one that adds few proprietary metadata as possible to function. If your notes are in Markdown, I’d prefer a tool that works within the constrains of the format, and not one that needs all kinds of auxiliary data for “rich” features. From what I see, many note-taking software are like that these days, which is a good thing.

    I have learned about the most interoperable features of markup languages by studying and using the document converter Pandoc, which can convert between many different markup formats, and I recommend learning about it if you don't already use it.

    I wouldn't worry about how much metadata a software tool adds to files if the metadata is in an interoperable format like YAML that Pandoc can convert. You should use as much metadata as you need to accomplish your aims, in my view, and the more easily you can customize that metadata to fit your aims in your software tools, the better. Fear not the metadata!

  • zettelkastenzettelkasten

    Thank you for your input!
    At the moment, I’m using OneDrive to store my Obsidian files so I can access them across different devices.

    I agree that Obsidian may already solve the problem I’m facing.
    While I’m comfortable using Emacs, I’ve come to appreciate how Obsidian’s backlink feature adds a lot of value — it’s a big part of why I’m leaning toward it.

  • zettelsanzettelsan

    @zettelkasten said:
    While I’m comfortable using Emacs, I’ve come to appreciate how Obsidian’s backlink feature adds a lot of value — it’s a big part of why I’m leaning toward it.

    Is backlink such a special feature? I'm not sure how you are using Emacs for note-taking, but if you are using Org Roam, it is a built-in feature. There are now a few note-taking packages to choose from, so you should look at Emacs in terms of these tools, not just Emacs itself.

    I'm not shilling for Emacs, just so you know. I understand the learning curve and am just curious to know what prevent people from adopting it these days. At some point in future I might want to do something to improve the situation, if I could.

  • MummelMummel
    edited July 7

    New here, I want to put my two cents in because this is something I've been thinking about quite a lot. I fall hard on the "best tool is no tool at all" side of things which, and in this day & age, "no tool" actually means the tools your OS provides, tools you should expect any proper computer to provide.

    Keep in mind I'm also using Obsidian, it's too useful to pass up, and it CAN be used in a future-proof way... just need to think about how you're using it.

    Note naming and storage considerations

    If you just looked at your zettelkasten in a file browser, and you'd forgotten what your system was, could you navigate it? If you want to achieve that, look back at classic physical zettelkasten systems and consider what we can't just throw away.

    • We need index files ("MoCs") with human-readable names as entry points into the system. It should be clear that they're MoCs, probably by leading the filename with something for easy searching.

      • It may be tempting to use a filesystem folder structure of some sort (I certainly started that way) but it'll mess with link readability, and you shouldn't need this structure if your MoCs don't suck and you link enough. A single folder for other file-types like images to keep things tidy is good to have.

    • File names themselves should be relatively easy to search for in case links just don't work. Ironically physical cards have the advantage here as you can thumb through them. I personally can't stand the 12-digit yyyymmddhhmm format, files already have metadata and frankly I don't think knowing exactly when a file was created is all that helpful anyways.

      • Files and folders should be named in a way that computers don't hate. What this means in practice is your-note-or-file-here rather than Your Note or File Here. This isn't just for the sake of the OS, it's also for the sake of sane links no matter the markup format (no sticking %20 everywhere and no problems on Unix-like systems). Note that so long as your notes are all in the same folder, they literally cannot have the same names, your filesystem will stop you. No need to worry about that.

    • Back up your damn notes! In several places! Obsidian Sync is not a backup and can actually be inexplicably destructive. Put them on a separate drive, on a flash drive or two, in a cloud service somewhere, ideally all of the above.

    Note composition considerations

    • Our notes should follow common Markdown syntax as much as possible.

      • UNFORTUNATELY this means shunning Obsidian's lovely wikilink autocompletion features and going for the classic [display text](link) format. (Why Obsidian's autocomplete system doesn't support this format is beyond me. Does Logseq?)

    • The links themselves should be relative file path links, because that's probably the most robust format we can use when transferring our notes. At the very least it'd be relatively easy to automatically reformat them.

    • A big feature of markdown is the extent to which its syntax is human-readable. If you feel like you need a tool to read your markdown files, something is wrong. This is mostly something to think about when adding metadata and linking between notes.

      • This is part of why avoiding folders is helpful, you can just type [note](note.md) rather than [note](../../note.md), less clutter. Maybe this is also an argument for note names just being UIDs, actually, because[note](1234.md) might be a little more readable.

    • Metadata should, again, be as tool-agnostic as possible if you use it at all. It should be in a format which allows you to search single tags with nothing but a basic text search tool like grep or whatever your OS provides. That means something like [tag signifier]tag1 [tag signifier]tag2 rather than a comma-separated list, the tag signifier (or some other key for a key-value pair) must always be there. This could be achieved with YAML or simple hash-tags.

    HTML is rad

    More of an aside- I think it should become a habit to turn every file in the zettelkasten into HTML documents in a separate folder structure every once in a while. Easy enough to use something like Pandoc to auto-convert them. Even if you're not publishing your notes anywhere, those files will be readable with working formatting and links (if you're composing your notes properly) so long as web browsers exist, and I don't see web browsers dying any time soon.

  • s3this3thi

    Personally, I'm not too worried about the longevity of my Obsidian vault.

    I make sure I stick to a handful of core features offered by the app. I install a few plugins to improve the look and feel of the editor, but I don't use any plugins that modify the contents of my notes in any way. I also mostly rely on links between notes for organization, and rarely use tagging. I have some YAML frontmatter in all my notes, but it's more for my own reference rather than to support some specific workflow. If I need to automate something (a very rare occurrence), I use an LLM to write me a script rather than lean on an Obsidian-specific feature.

    Because of the way I use Obsidian, I'm fairly confident that I'll still be able to access my vault 20 years from now.

    Also, there are a ton of apps out there that are explicitly designed to be compatible with Obsidian vaults, and even more apps that just copy Obsidian's default behaviors because why not. A few months ago I tried opening my Zettelkasten vault in a bunch of different apps to see if they could make sense of my notes. These tools worked perfectly for me (but YMMV):

    • iA Writer
    • Visual Studio Code with the Foam plugin plugin
    • Zed with the Markdown Oxide plugin (this one should theoretically work with any text editor)
    • Emacs with obsidian.el plugin

    The internet tells me that Logseq and Zettlr also work well for working with Obsidian vaults, though I haven't tested them myself.

    Basically: you'll be fine as long as you stick to plain text and wikilinks.

  • bauxbaux

    @zettelsan said:

    That being said, I think vendor lock-in is less relevant so long as the product allows data export/migration in a widely available format.

    Totally agree.

    Future proof was one of my thinkering too before got a solution.

    My solution is really simple and based on text files, no more.
    Til text files will be usable, and I suppose 'em will ever be,
    I've no problem.
    Editor of choice is irrelevant. Format and protocol is relevant.

    Maurizio Boriani
    GPG key: 0xCC0FBF8F

  • jbzjbz
    edited 3:07AM

    I tried a lot of tools and finally found zk https://zk-org.github.io/zk/ and it checks all my requirements:

    • markdown
    • wikilinks
    • yaml frontmatter
    • search, backlinks, orphans, etc
    • CLI

    And it add LSP support (which I use with helix editor).

    And everything that zk does can be adapted as shell scripts (and so used in nearly everything else). Strong core principles make great tools.

    Post edited by Sascha at
Sign In or Register to comment.