嗯，我理解您的意思，并且在论坛得到了很多想实现的效果上的帮助，我对所有“伟大的”（令我满意，觉得：牛比）的开发团队一向尊敬，没有开发者，就没有产品，我当然不会否定ob团队的审美，因为当我决定”以后就它了“的时候，我一定是认可的，并且现在我依然觉得满意。
产品能不断更新对我来讲是很棒的事情，我所困扰的是：上了一盘我们都认为可口的美食，在吃的过程中，你加了我忌口的佐料，这本来有更好的方法，分餐，给我一个选项，我可以不加。
香菜很微小，影响不了菜的整体，但不吃香菜的人会因为这一点点东西变得难受至极。
刚才回家前吃了一碗冰粉，这不正是Obsidian嘛，更新是添加山楂、折耳根、辣椒、芋圆、芝麻，花生，所有佐料我都要，独不要花生。在加佐料(更新)的时候，我可以选择不加花生，而不是只能加满全部佐料，再去想方法剔除花生，甚至像iphone资源库这种东西，完全无法去除，众口难调，关键在于能选择吃什么，不吃什么。
我觉得这么改还不错啊，感觉比之前好了，之前是库名是文件列表里面，看着还挺乱的，现在改到下面更清爽了 
楼主的这句话我还挺有感触的。其实就是顺序反了。
Obsidian 本体应该尽可能体积小、实现基础功能。任何优化性质的快捷输入、界面布局美化等，都应该留给插件和 CSS。
楼主提到“简化期”的概念，即减少安装插件，是一种很棒但很理想的状况。这表示开发团队需要的功能恰好和我们需要的功能重合，且没有我们觉得雷点的功能，这是非常难以做到的。
哪怕是 Obsidian 本体，这篇话题吐槽的文件列表，以及搜索、出链等软件核心功能，都依赖于软件的核心插件实现。
对于需求重合的人，这些核心插件在下载时默认打包到软件本体，可能是一丝便利，就像喜欢文件列表改动的人所感受到的一样。
但对于不喜欢其中一些功能的人来说，这些功能占用软件空间、不能像第三方插件一样卸载，导致 Obsidian 愈发臃肿。
Obsidian 只是一个很小的团队。具有优化性质的这些需要反复调试且个性化的功能，如果由开发团队承担，以目前效果来看，不够理想。
Obsidian 官方原则 (About - Obsidian) 也提到，他们希望这个软件是高度可定制和可扩展的，能够适应独特的需求。
所以我认为，合适的方向是，Obsidian 软件本体只作为运行插件的容器，优化结构、提供接口。如果官方有什么想自己实现的新功能，也可以写成插件，用户按需下载。
“软件本体只作为运行插件的容器”，这个观点并非我独创，而是我曾看到其他软件遵循类似理念，如 uTools。
诚然，uTools 是付费商业软件，而 Obsidian 要实现类似的功能，存在技术难点和源码泄露的安全隐患。因此，我依然理解 Obsidian 团队目前为止的很多选择。
作为用户，我们不负责理念的争端，只需要趁手的工具。我们不会也不可能对个别软件投入过多的热情。
站在解决问题的角度，如果目前的改动切实影响到了使用效率，且已切实有解决方案，我的建议是积极使用现有的解决方案。
当然，如同我希望官方的功能也是可卸载的，如果目前的改动虽有影响但还能接受，而现有的解决方案又不符合自身需求，保持现状、等待变化亦是一种选择。
1 个赞
Obsidian并不是开源的
Here the problem is also what you mean by “being open source”.
Is obsidian code released with an open source license (MIT, GPL, etc) ? No.Is a (minified/obfuscated/packed) version of the code available within electron? Yes.
用户可以看到Obsidian的一些代码，但是不能使用它们。如果在 github 上发布源代码并打算将其作为开源产品使用，Obisidian 团队有权提起诉讼。
原来如此，是一个法律意义上的定义问题，感谢提醒！我这么说确实会误导他人，造成法律风险。我修改一下。
认可，没有“雷点，即只有同，没有异，这是不可能也不合客观规律的，就像现在这个改动一样，千人千面，无论喜欢与讨厌的理由是什么，总归是两种状态：我用，我不用。
正如您所说，将尽可能多的改动留给插件与CSS，我也是这个观点：用插件与CSS做添加，而不是用它们做（功能上的）减少，
1.6这个改动是不可选的，如果它是一个类似”显示页面标题“，或者说使用暗模式or光模式的功能，我相信大家都会夸赞这个改动，因为喜欢它的人多了新功能，不喜欢的人可以不用。
谢谢回复。总体来说，我们都希望软件本体简化、通过插件（官方的或第三方的）和 CSS 自定义功能。
我的想法稍有不同。我不希望优化性质的功能默认打包到软件本体，即使可以关掉，它也要占内存空间。
如果 Obsidian 软件本体只作为运行插件的容器，核心插件和第三方插件一样能卸载，开发者可以更轻松地按照自己的喜好开发新插件，用户也不用总是下载大号安装包。
按照这个思路，旧版的文件列表可以是官方原先开发的插件，1.6 的改动是官方的新插件或补充包，想要旧版的就用旧插件，新版的就用新插件或安装补充包，皆大欢喜。
当然，目前这样的方法没有例子参考，所以很多人可能会用第三方插件现在的情况来想象核心插件也可以卸载的情况。由于 Obsidian 是本地存储，现在的第三方插件在某些情形下存在同步和迁移上的麻烦。但核心插件有官方优化，不一定要和第三方插件采取同样的方式，所以具体实施方法还有商议的空间。
我同意 @PlayerMiller 的观点，插件话开发思想，保持核心功能最小化。
但这个核心应尽可能的稳定，减少不必要的修改和向下兼容性。
我想吐槽的是，obsidian从1.5到1.6的升级确实导致一些插件失效或出现问题，至少这次向下兼容性不太好，我接触时是1.58，之前的升级不太清楚，但1.6升级确实带来了一些问题，包括主要样式等，与之前不同，导致某些插件样式出现了问题，用之前的样式覆盖就行了。但不可能用老版本样式覆盖，只能对比样式，找出差异，因为不是一处问题，且是别人的插件，不太熟，所以感觉很头疼。
我相信很多插件开发者都是业余开发的，如果频繁升级会导致问题，一方面开发者没有那么多精力修改，二是会使开发者失去信心和动力，对生态发展不利。
我也是这个看法啦，仅针对本次更新作假设：它若是一个跟显示标题栏一样的开关型改动，就不会有这么多的”讨厌“。
如果技术能实现的话，我也希望是Obsidian保持为最轻量的基础本体，一切变动以插件css形式实现，类似？BRAT
假设现有一个官方插件Wing——或者由它替代【核心插件】，在这里可以得到所有官方的功能与变动（官方团队是最核心并且专业的插件制作者，为什么不采用与第三方插件类似的嵌入形式呢，如果技术能实现的话），以与【第三方插件】作区分，我想使用某个功能，就在【wing】中下载并开启。
ob优秀的地方，就在于它可以做加减法，每个用户的ob都可以尽量符合的自己需求，如果官方的变更是固定不可选择的，或者为了取消某个功能，需要用户添加另外的功能，这会变得越来越臃肿，夸张的来讲，这不会成为一个半开放的印象笔记吗？它有多臃肿想必许多转战ob的朋友都了解。
固，我的看法同样是：
1. 保持ob的简洁本体——ob团队是创作者
2. 以一个类似【第三方插件】与【BRAT】界面的形式进行官方变动，让用户自己做加减法——ob团队是可靠的插件制作者
@wilson 是的，1.6 升级样式问题主要就是文件列表样式的问题，文件列表就是一个核心插件，如果核心插件可以自己选择要不要安装，其余基本功能一直保持稳定，这样的话也符合“核心稳定”的描述。
@ADYR禅云 谢谢分享想法。不过也像之前提到的，这里面可能有技术难点和一些安全和法律问题，所以还要看 Obsidian 团队未来的决策。
我说的不是文件列表和设置移动等这些，是整个app.css样式改动，因为我最近在修改webpage export这个插件，会导出app.css样式并复用，导致与老版本的不一样，需要调整，即我通过额外加入css使它兼容现在的插件，还要兼容老版本用户的样式。
那倒是。我也注意到有一些 Dom 的类名改了。
您好，我不是很理解这句话的意思？因为这次更新并没有给我“关”的选择，我需要为这种小的变更去添加一些除此以外没有需求的插件。
以及，我并不讨厌插件，我很喜欢ob的一点就在于它的很多插件与css，我是喜欢的，我讨厌这次更新最直接原因是，我在写作时会使用某个全屏主题（隐藏所有界面ui），但是新变动的这个功能会突出一块，非常影响我的观感。
我需要为这次更新去做一些额外的工作，让它回到我原来的工作状态。
找插件、css等等，本来我是在写作，但我需要为了保持原来的界面去做一些其它的事，破坏了我的工作状态。
所以我认为这种官方变动不应该是没有选择的，更新以后直接应用的，应该让用户有所选择，至少把这种会影响界面的“加法”交给用户自己去做。
在之前的某次更新，ob对表格进行了更好的支持，没有什么人反驳，因为它不影响界面，不会影响“工作流”，而这次的界面变动，破坏了我的工作体验。
固，如果可能，我希望能保持ob的简洁，以上述所言【wing】的行式进行更新，这样无论进行哪种程度的更新，其一，ob永远不会变得臃肿，其二，不会影响工作界面。
是的，需求一张嘴……我缺少这方面的知识，所以也只是“假设”，对这次更新的看法也是：给我一个类似“页面标题”的选择
的确是这样。不过，当然，为人所不喜的更新其实并不是只有这一次。例如：
所以我会说：
这里可以看到人们相关的讨论。
一种可能（而不是推荐）的方式是在内测版本出来的时候，就先了解一下到底更新了什么，有什么发生了变化，然后”手动“更新。
正因为用户只能被动接受别人的审美，别人的设计，
所以只得提前尽可能阻断这种传递。更新了反而变差，这是历来就被广泛吐槽的问题，无论是软件，还是网站。所幸Obsidian可以一键停止自动更新。如果到了无论如何也需要新特性的时候，这时候切换到旧版布局的插件或者css肯定也早就被先行者们写好了。安装一下也花不上几分钟的时间。
我在这里说的只是希望能为现在，以后今后的遇到破坏性更新的用户提供一种看问题的角度。
至于从如何向官方团队反馈，促成其进行修改，我觉得可能到英文论坛的相关帖子，或者到官方/kepano的推特评论区去说效果会更好。
我想补充一点，就是如果Obsidian想要做一些面向新用户的改动，可以使其不会波及到旧用户。具体表现形式，就是在一个可以配置的项目上，去修改默认配置，而不要动旧用户的已有配置。
多谢告知，但我目前应该不会去了解它了，因为读了几遍以后我明白自己不具备直接上手的能力。
正如我先前所言，简化期（乱编的名词）我希望自己更加专注，这并非不使用插件，而是把更多的时间花在事情而非工具上，打开ob是为了完成某项工作，而不是为了用ob而打开ob，曾经为了实现一些功能花掉一整天，甚至几天时间，打开ob那一刻想做的事情一点没做……笑.jpg
所以我才会对这次更新有很大的意见——它改动了基础页面，并且无法选择。
我没有在版本内测时花时间查看应用更新内容的习惯，因为我并不拒绝使用新功能，只是没想到这次它会改变基础界面，所以今天已经关掉自动更新啦，期待下次吧。
哪怕我非常讨厌这次更新，我依旧对开发团队保持尊敬，这的确是个很小的变动，只是，我不吃香菜。
这很棒。共勉。并且祝福你工作学习顺利。
您也一样，祝你健康。