Lately, there’s been a lot of chatter from peoples around the fact that they cannot use a tool because it’s not open-source. The reasoning is that if it’s closed source and dies, then all your work in your notes is just as good as gone. All your years of note-taking are gone poof, and you have nothing to show for it. Then the logic goes you should only use an open-source tool, so if it dies, you can still use it, support it and fix things yourself.
While this can be true in specific scenarios, this sort of event is more an exception than a rule. On top of that, if you follow guidelines, like those I outlined in How to make your critical data last decades, you probably won’t consider a tool where that could happen to begin with, but it doesn’t mean it will be an open-source tool either. Open-source is a great movement and can bring many benefits, but it doesn’t guarantee longevity in itself. So you can source access into your decision for an app, but it shouldn’t be on top of the list.
Workflows and Notes first approach
Some of the fears around closed source note software often turn around: “What if it dies then I won’t be able to work the way I do now” or “I don’t want to invest a bunch of time in an app that might die tomorrow, and I have to redo everything or lose everything.” While those look like reasonable concerns on the surface, for the most part, they arise because you do not see farther enough. Given how fast technology is evolving and how massive changes can happen from one year to the next, wanting only to use tools that will “never die” is probably impossible. That doesn’t mean you should not care and chose something that could quickly die tomorrow and bring everything with it. What you need for this sort of decision is to look into the guarantee you can get from the app, things like export, portability, format, etc., and first and foremost, how you use it is crucial.
One of the core issues with many people’s note systems is that they design it around their tool first. If you create a system that takes advantages and requires all the bells and whistles that your particular note app of choice as you’re in for trouble. Doing things app first is the best way to get locked in an app in the worst-case or an app category in the best case. There are multiple reasons for this, but the core problem is simple: what if the app removes that feature? If it’s open-source, you could try to hammer it back in with effort, but then you’re still stuck. You also now have to support that feature for as long as you need it. A more viable way to solves this is not to use those features as the core of your system. Design a system that can stand on its own and work decently, then look at the features that could make it better or more streamlined. That way, the same issue of the app removing a feature means you fall back to the original working method. It might now take you longer, but it still works until you figure something else.
The same principle also applies to your notes. Your note should themselves be able to stand on their own and contain the ideas themselves. Like the workflows, you should not design your note for an app with things like queries, metadata, or graphs; the note should contain the information itself. A straightforward way to go about this is to keep your note in simple text form with minimal extra formatting. You can use universal formatting like highlight, bold, italics, etc. those will work everywhere. But as soon as it becomes application-dependent, you should stop and think twice about using it. That way, when your application dies (as they all end up doing one day or another), you can export your data and put them somewhere else. Doing that, you would probably end up losing some metadata on the notes and some of the formatting, but the core of the information will be there. An easy rule of thumb for this sort of design is: “If I lose access to feature, will note/workflow still make sense and work?” if the answer is “yes” or “yeah, but it’ll harder,” you’re probably fine. On the other hand, if the answer is “no” or “gonna be a big pain,” then you might be in trouble.
Open-source vs. Open standards
Now that we’ve gone over the workflow and notes issue, there’s another aspect of this, longevity. The thinking goes if you go with open-source, there’s no need to do all of the above. You don’t have to go thru all these trouble settings app agnostic workflow and self-contained notes if I can open the source and change things. The sad reality is that the only thing that open-source guarantee is in the name: you can look at the source. In general, with the source, there’s a build tool to allow you to build it yourself, but that’s it. There are no guarantees attached to open-source other than access to the source code, no support, no community, and no long-term vision or longevity.
So thinking you need to have an open-source note-taking app so you can be extra sure it’s OK to invest all your time and effort into it is a dangerous trap. If you’re not weary of your workflow and how you take note, you might end up locked in an open-source application, just like any other app. It might be less of a problem in some cases, but then what if the application developer or group quit. You could take it on yourself, but now you have another job, and you’re still stuck until you find a way to make another app works the same or change how you work, both requiring lots of effort, time, and energy.
On the other hand, peoples created open standards like Markdown, LaTeX, YAML, and others to work across any applications respecting the standard. In practice, this means your data in that format will work with any other application respecting that standard. There’s no requirement here that an application is open-source or anything. To switch applications the new app simply needs to respect the same open-standard as the previous one. From there, export your data, and you’re good to go. Sometimes the app may/can add to the standard for their own feature set, but that means, at worst, those extra won’t work in another app. That easy migration is why applications often use those standards to export your data, which in turn is a great way to prevent lock-in. For example, knowing your notes can be exported as Markdown is excellent; that means if/when the app you use dies or you want to change, you simply need another app that can read Markdown.
True longevity
At the end of the day, none of those issues requires open-sourcing an application. The open-source community can be a great place where massive projects get made, but that doesn’t mean it’s the only or best solution to every problem. True longevity is a challenging problem, and like most other tough problems, it requires effort and sacrifice. If you want true longevity, you need to be mindful of your choices and put in the effort to design a lasting system, not rely on open-source.
