设计「众人维护」的 BuidlerBoard | BeWater.xyz

https://buidlerboard.bewater.xyz

Talk is Cheap, Show me the Code

在 Web3 世界里一直流传着这样一句谚语：

Talk is Cheap, Show me the Code.

打嘴炮总是便宜的，请展示代码~

这句谚语有时会被质疑，有时候会被证实。

但是，就像学经济的同学会相信 「长期来看价格会围绕价值上下波动」，作为 Buidlers，我们很多人也会相信：

长期来看，项目价值围绕代码价值上下波动。

世界观基于这样一条「公理」的最大好处是 —— 具备一个在 「心智负担」 和 「效果」 之间具备极佳均衡的「标准」。

我们自然可以增加我们的心智负担，设计出一个更加复杂的「项目衡量标准」，从而增加我们对项目的 「评价效果」 。但对于 Buidlers 来说，心智是最宝贵的资源。所以，真的要这样做吗？确定「优化」不是捡了芝麻丢西瓜😂？

参考资料：「独立黑客创业操作系统」。

在进行了多种尝试之后，包括我在内的很多 Buidlers ，最终还会回归到这条朴素的公理。判断一个项目究竟是否该参与，最简单的决策手段就是打开它的 Github Org，翻阅翻阅它的 Repo，通常，30 秒内我们就能得到结论。

因此，就实际情况来看，BuidlerBoard 作为一种主观存在于各个 Buidlers 心里的排行榜实际上早已长期存在了。作为 Buidlers，我们用 Pull Request 参与了哪些项目，说明我们的 BuidlerBoard 里都有哪些 Repos 和 Developers。

「众人共同维护」的 BuidlerBoard

现在 BeWater 在做的，就是将每个 Buidlers 心中存在的主观 BuidlerBoard 更进一步，「升级」成「众人共同维护」的 BuidlerBoard。

很多有趣的创新，都来自于这种「公共化」尝试。

• 比特币：原来由中心化的机构维护各自的银行账本，升级成「众节点共同维护」就是 比特币。
• 微信读书：原本是大家自己做自己的读书笔记，升级成「众读者共同维护」一本书的读书笔记。
• ...

所以，BuidlerBoard 这个项目本质上是在探索如下问题：

• 如果推出一个「众人共同维护」的 BuidlerBoard，它会如何演化？
• 如果将这个 BuidlerBoard 作为基础设施，会有什么延伸玩法？

BuidlerBoard 将会如何进化？

目前发布了 BuidlerBoard 的第一个版本，包含基于 Developers 的 BuidlerBoard：

和基于 Repo 代码仓库的 BuidlerBoard：

除了一些手机端适配等常规的 Fix 以外，有如下一些「进化空间」：

• 项目提交入口

  通过提交入口，开发者仅需提交一个链接🔗，就可以将 Repo 添加进数据源，实现这一功能是实现「众人维护」这一特性的关键一步。

• 划分出 Github BuidlerBoard 和 BeWater Projects BuidlerBoard 两个版本

  目前先上线的是一个面向 Github 所有开源项目的 BuidlerBoard。为了鼓励 Buidlers 参与 BeWater Hackathon Platform，未来可能会针对在 BeWater 中登记过的 Projects 和对应的 Buidlers 推出 BeWater Projects BuidlerBoard。

• 链上化

  将 BuidlerBoard 数据在链上进行存储。

  这里有 Jolestar 老师提出的建议：

  Put the builder and repo info on chain, and sync the git root to chain periodically. And I suggest training an AI to give a score to the builder.

  Usage scenario

  1. Provide commit proof or contribute proof via the git root.
  2. Projects can airdrop to the builder via the info on-chain or proof.
  3. The AI agent on-chain can evaluate the builder and give a grant.

  —— https://github.com/orgs/BeWaterXYZ/discussions/575

  💡从 24 年开始，BeWater 从项目治理上开始了 Web3 化、Open-Source 化的实践，希望可以由「传统软件工程模式」向「无准入的、🌏全球化的、自进化的 Web3 软件工程模式」转变（ᕦʕ •ᴥ•ʔᕤ ）：

  https://github.com/orgs/BeWaterXYZ/

• 算法更新

  传统软件工程视角下，会把软件视为一个无机物，而「 Web3 软件工程」视角下，我们会把软件视作 「生命体」 ，这也是理解「 Web3 软件工程」这种新模式的关键点和难点所在。

  视为一个无机物，那么在最开始设计的时候就要以「不出错」、「无瑕疵」为设计原则，就像能工巧匠雕琢一件作品；

  然而，如果我们把软件视作一个「生命体」，那么设计原则就变成了「简单」与「可以自进化」。想一想在自然發生論下的生命起源吧！异常简单的初始原则结合时间的推演，最终演化出了复杂而健壮的生命体。

  同样的，我们需要从「简单的原则」起步，赋予其演化的空间与时间。

  以 BuidlerBoard 为例，使用简单的算法作为最初设计 ——

  用 Star 数作为 Developers 和 Repos 的排序依据。

  之后，我们让这个算法的进化由社区来推动 —— 是否有更合理的排序算法？来 Github Discussion 提出你的建议：

  ε(´｡•᎑•`)っ ~ https://github.com/orgs/BeWaterXYZ/discussions