--- title: "为什么我们不需要另一个Fuwari" published: 2025-08-23 tags: - "OpenSource" --- 文章开头，我想问各位读者：开源社区给你带来了什么？ 它给予我技术交流的空间，带给我优质的项目与资源，或许还有更多。但是现在的它，带给我最大的感受就是悔恨，如果我不曾接触过开源，不曾了解过开源文化，或许很多事情会简单得多。 ## 破碎的理想国 理想的开源社区是一个梦幻的国度，所有人共同享有着代码，所有人也自然而然地反馈问题、提交修复和新功能。但是并不是所有人都满足这种生活，无论领导项目的是一个委员会，抑或是“仁慈的独裁者”，他们都希望自己是领导的那一方，在共产的土地上荒诞地索取满足自己欲望的地位与权力。 于是我看到了KernelSU分裂出了KernelSU-Next和SukiSU-Ultra，开源的ZygiskNext分裂出了ReZygisk和NeoZygisk，连LSPosed都出现许多分支各自为政。有些开发者宣称要维护项目的纯洁性，或是为了崇高的开源事业而奋斗，这是我勉强可以接受的理由，但是几个性质相同的项目同时诞生，他们又何尝不是在分裂社区呢？更可笑的是，他们在分裂着目标相同的一批人，分裂着他们自己。 分裂或许是安卓社区的常态，但不幸的是，就连个人博客这个人迹罕至的净土，也即将要受到分裂的荼毒。Fuwari作为一个热度高、性能及设计优秀、开发进度迟缓的项目，堆积了很多Issues和Pull Requests，于是令人担忧的情况发生了：一些人在MIT License的庇护下，挪用Fuwari和Pull Requests中的代码，站在巨人的肩膀上宣扬自己的功绩，仿佛是著作权的限制不存在了。 对于这种行为，我感到愤怒。最核心的冲突，在于他们的创造只是一些不成熟的新功能、或是一些微小的修改，既然如此，要做的就只有向Fuwari贡献代码、在社区分享经验不是么？然而事实是，他们想要的终究是一个“以我为主”的小圈子，在众人的关注与掌声中陶醉于自己工作的伟大。 他们的眼中没有开源社区，所有的用户都只是他们潜在的拥护者，忠诚度与服从性比测试与贡献代码更重要；他们的眼中甚至可能没有开源，毕竟开源是最好的护身符，只要亮出自己的Repository，就能站在道德的制高点。Bilibili和QQ是他们最常出没的平台，因为那里有着无数未曾了解过开源运动与许可协议的人，有技术不成熟、嘴巴倒是很甜的新手，会一声声地叫着“大佬”。 我并不反对Blowfish之类的Redesign，因为他们触及的是一个博客主题的核心，即设计。向主题添加新功能是合理的，但是向上游请求修改设计，是很难被允许的，此时自立门户，是审美自主性的体现，我表示理解。只是因为一些可有可无的功能，甚至还不一定能和主题的设计统一，可以是尚不成熟的Draft Pull Request，可以是富有想法的Fork，唯独不应该被称为一个新的项目。 ## 设计之美 Fuwari的设计深得我心，我相信使用Fuwari的大部分用户也是被它的设计所打动。曾经我也是急切渴望新功能与更新的用户，但是在和Saica的交流中，我不得不承认，在一个以设计为导向的项目中，功能有时候并不是我们应该首先考虑的方向。他对于添置新功能的保守，有现实生活的客观因素，更有对作品负责的真心。 > （另一方面）作为一个以UI设计为核心的项目，我会希望新元素的UI是在我自己调整到满意之后再放出的。 我希望使用一个功能丰富的主题，但是我更希望使用一个细致、设计完善的主题。外观是博客的皮囊，而内容是博客的灵魂，至于功能，更多时候是锦上添花，它无法取代外观设计带来的视觉体验，也无法成为展现自我的精神内核。一个音乐播放器、一个Live 2D并不能带来什么。 UI设计也并非想象中那么简单，在很多隐藏的角落，就有着各种不和谐之处。新增或调整一处功能就是如此，你觉得它可供使用了，但是它总是会适时告诉你：“能用不代表设计精巧，更不代表能有后续维护”。 ![设计细节](https://blog-static.xeonzilla.top/img/fuwari-is-all-you-need/01.avif "设计细节") 图中的各种细节甚至不需要特定的复现方法，只是随意阅览，即可找出问题。这未必是技术水平的差距，但一定是态度的体现，你想为用户呈现怎样的作品，设计在你的博客主题中占有怎样的地位，一切都不言而喻。 Fuwari的社区诞生了很多巧妙的解决方案，让我们得以在Saica正式归来前使用必要的功能，但这不代表这些功能是完备的、设计得当的。把一些试验品伪装成稳定版本，宣扬为最终方案，是对作品的亵渎、对用户的不负责。Author的信息是他参与社区的证明，如果连这些都要抹去，与偷盗无异。 ## 唯一即答案 我曾经也畅想过属于我自己的“Yet Another Fuwari”，用无需JavaScript的View Transition API代替Swup，用性能优异的UnoCSS代替Tailwind CSS，还要移除Stylus和Svelte，用原生的CSS和Astro组件取代。但是畅想了这么多点子，我该怎么维护它？设计上的复原与统一如何做到？更进一步的问题都没有答案。 维护一个项目，尤其是这类以设计为核心的项目，所付出的努力是一般用户难以想象的，一个活跃且气氛良好的开源社区，无疑是极大的帮助。拥有开源社区的项目，早已不是仓库Owner的个人作品，每一个Commits都有贡献者们的烙印，Contributors的名录也证明开源社区的无限潜力。 选择所谓的“新项目”、“新博客”而不是在开源社区贡献自己的力量，我无法理解，更难以接受。可悲的是MIT License允许了部分行为的发生，在这样的大环境下，远离开源的念头已经占据了我内心的上风。当开源的参与者们不再纯粹，甚至出现并非参与者的参与者，我们还有必要死守着几条没有法律效力的道德约束吗？倒不如直接闭源，还能“落了片白茫茫大地真干净”。 无止境的分裂和偷盗让我疲惫，这些与开源理念相悖的行径本不是开源的样子，却是它现在最真实的样貌。但是让我欣慰的是，Fuwari诞生出的社区还在活跃，有新用户涌入、新提交出现，这个项目远没有到沉寂消亡的时刻，我会在此心安处，坚守着唯一的答案。