Very uncomfortable with Obsidian's direction (I'll address that in another post).
Very curious, please link here.-urlwolf
My concerns arise from my focus on long-term longevity and having all content safe in plaintext files. My original interest in Obsidian rather than competitor PKM apps, was its emphasis on local files. The picture in my mind was of a managing spider sitting on top of the files. The emphasis being on the primacy of the files. But now what I see is an increasing emphasis on Obsidian with much of the content value being embedded in Obsidian unique workflows.
FilesIf files are the long-term repository, then the relationships between parts of the content need to be embedded in the files. This suggests that large markdown files are superior to small ones; Obsidian is biased towards small notes in its design and the plugins do like wise. Tags are generally useful, but links (whether they be wikilinks or markdown) depend on a program to use them; wikilinks would still have a function because they are just text that makes sense in context. A further limit is that full functionality is reserved for .md files, and there is strong resistance to changing that. Personally I always wanted the option of working with .txt files (or indeed any other plaintext format) because all the programs I use will work with .txt files but many won’t open or save .md.
Having everything in local files is good. But when that everything includes multiple entries in YAML that’s not necessarily the case long-term. Especially if those entries have been made by long-deleted plugins. There’s already been an expansion of the number of json (etc) databases, and that will presumably grow further.
PluginsMuch of Obsidian’s popularity derives from its very active plugin developer scene and the rapidly growing number of plugins (c500 so far). But maintenance of these plugins is frequently less good. Bugs aren’t always dealt with, some appear to have been abandoned and not updated for the latest editor. There’s also a wide variety of approaches to coding and design; this is good for innovation, but not so good for an overall structure that’s easy to understand. I can only see maintenance becoming more of an issue over time.
The same is true of themes, and my impression is that most are not fully functional or don’t work in the new editor. Presumably this will stabilise as theme developers become accustomed to the needs of the new editor.
CommunityA Venn diagram of community attributes would probably have central overlaps of Students, Computer Science/Programmers, TTRPG players. I’d hoped that the WYSIWYG development of Live Preview would be used to attract a wider range of users, but it seems there’s little interest in doing that.
The large percentage of students in the community is good for enthusiasm and innovation, and the programming expertise facilitates plugin development. But longer-term, students generally throw off what was fashionable in the previous student generation and the students themselves move on to other, more time-consuming, activities; reliability and ease of use become more important than new and interesting.
In general, my impression is that only a small proportion of the community is strongly attached to local files; many would be quite happy if Obsidian was a database program that could read and save local files.
Glitches and bugsOne of the most impressive aspects of Obsidian in its first year was the speed and quality of development. Features worked well with each other and bugs were quickly addressed. Very impressive for a new program, and contrasted with most of its PKM competitors. But that has changed.
Live Preview has been public for well over a month, and large numbers of bugs are being squashed with every update, only for more to appear. Some of it is trying to accommodate CodeMirror 6 (most other programs using it, like Zettlr, seem still to be on 5), some of it is upstream (the aforementioned CM6 or Electron), some of it is understanding Apple issues (iCloud deleting files, Mac crashes (though these seem reduced now)); other issues from plugins and themes no longer functioning as intended. Time is also needed to check the code of new plugins and themes before they join the community list. Not all the issues are to do with core development, but they all use bandwidth.
My personal experience isn’t that things that don’t work, but that the experience of using Obsidian is rougher than it was when my expectation had been that it would become smoother as little issues were addressed.
Developer resourcesI don’t actually know how stretched the developers are. The core developers are a couple with a very young child, but there are also many very active volunteers and plugin developers. However, they have switched Dynalist into maintenance mode because Obsidian is taking all their time, and it
feels as if they are fully stretched just keeping all the plates spinning, with little time spare for starting more. And I know that it’s not easy to increase developer resources, even if the money and desire were there. Adding one new person would have a fair chance of reducing output; adding 2, 3 or 4 would force radical change of working practice.
OverallI feel as if the community is pulling the program in the opposite direction to my own needs, and I don't believe that heavy use of plugins enhances the long-term value of the notes. I don’t have a clear idea of what the program will look like in ten years time, but I’m not convinced it will be more useful or usable. My own approach is to keep things simple and use large markdown files with wikilinks. I use few plugins, none that pollute my notes, mostly simple and straightforward ones, and even then I have most turned off most of the time. I also use Typora and MarkText on files in Obsidian vaults; occasionally Logseq too.
The plugins I
do use most of the time include File Info (
not in the community yet) - I often have it open on the right so I can see the file stats while I use Typora or MarkText to edit the file in the vault, and txt as md.
