TL; DR

• 见 节 未来 2,3

引言

• 四年前, 当我们亲爱的群主, 社会易姐QwQ, 还在上高中时, bilibili-API-collect 便已悄然在国际互联网的某个叫作 GitHub 的地方创立了
• 四年来, 随着易姐等开源社区众多贡献者们的共同努力. BAC 已从当初几个人的小项目成为了 14k 多个 stars, 几百贡献者, 大量人所依赖的知名项目了. GitHub Trend 榜单长期居高不下
• 本人有幸一次对 GitHub 的探索时, 发现了 BAC 项目, 并受此启发开始学习了 Java 语言.
• 至此, 距今三年前泽生注册的 GitHub 帐号终于开始活跃, 而 BAC 也进入了历史上的再一次高潮
• 而此时, BAC 早已处于 "山雨欲来风满楼" 的危机局面了

社群

• 当时 BAC 的 QQ 群还是二代目, 本人有幸在二代目初建之不久后入群. 但自入群后便未发布过什么消息, 唯见群友之各种技术交流
• 后来二代目于本年四月因鉴证被封, 俗称 "四月是你的谎言". 三代目群也在泽生生日前不久惨遭封禁. 而 TG 群此事却无人提及
• 而 BAC 的专门 TG 交流群, 尽管人数众多, 平日却无人交流
• 在泽生所见 BAC 时已经很乱了

管理层

• 通过长期接触, 以及 GitHub 一个微小的安全漏洞 (不知修了没有, 之前发群里了), 泽生得知了 BAC 的协作者们
• 加上易姐一共四个: 易姐, 小宇, z0z0r4, 进栈检票
• 目前已知的是, 易姐已经工作了, 很忙. 中间两位上高三, 很忙. 后面那位, 在听说 BAC 前就有所了解, 但不认识, 应该也忙
• BAC 管理层无人能应对项目日常维护更新, 最近一个月内的所有 Issues 和 PRs 全都积压着无人问津
• BAC 正处于无人管理的危险局面, Issues 与 PRs 无人管理, 过时内容未被发现
• 其实关于类似的现象, 早已经有 XZ Utils 的前车之鉴了 (虽然这俩完全就不是同一个类型的项目啊喂)

法律风险

• B 站, 哔哩哔哩, 是美股和港股上市公司. 既然与资本相关, 自然也不会是什么特别好的地方

• 因此, 您一定会注意到, BAC 的许可证是 CC-BY-NC, 不允许商业使用, 在一定程度上规避了风险

• 同时在 README.md 里也写明了, 仅用于学习与测试,试不得用于非法用途

• 另外 BAC 曾被 哔哩哔哩技术, B 站官方的一个微信公众号, 其中一篇文章点名, 说是什么 主站 API 接口破解项目, 差点没笑死

• 前段时间好像有个叫 aicc 的网站, 根据 BAC 提供的接口文档用爬虫大量爬取 B 站上的弹幕, 评论等信息, 而且毫无限制, 影响十分恶劣

• 简单翻了下这个网站里的内容, 发生了指向 bilibili-API-collect 的页面, 这是泽生第一次见到灰产利用 BAC 的真实案例

• 截图发到群里后, 易姐对此不满, 认为这在吸 BAC 的血

• 后续, 易姐电邮联系了网站的管理员, 要求删除与 BAC 的相关内容, 就这么简单

• 其实这是一个很好的更新项目许可证与免责声明的机会

分裂

• BAC 社区的分裂现象早已出现, 从大家所了解的信息完全不对称就可以看出
• 最初因 BAC 文档而兴起, 但后来随着各自发展却不再回报 BAC. 这种项目很多
• 就比如发现接口更新, 自己进行了修改, 却没有及时向 BAC 反馈. 这种行为听着很别扭, 对吧?
• 但由于许可证只是 CC-BY-NC, 没有规定 相同方式共享(SA). 这样一来许可证就形同虚设, 毫无意义
• 社区 QQ 群里一次关于若易姐去 B 站上班的讨论中, 有些人甚至希望 BAC 倒闭跑路, 内部明显已出现分裂 (内鬼整天只知道举报)
• 不同贡献者们以不同的方式重复描述相同的内容, 却没有相应的文档进行整理, 造成语义上的严重偏差

过时

其实... BAC 已经过时了... -Sess𝕏6cf(我说的)

• 上面这句话获得了包括易姐在内的一些人的认同. 实际上, BAC 中的大量文档具有严重的滞后性, 失效与更新的接口与参数无法及时的发现

• 就最近处理的直播 CMD 字段, 两三年前的 Issues 没人管, 已成天坑

• 别的 Issues, 特别是风控相关, 讨论的热火朝天, 基本结案, 但反观文档什么也没有, 甚至 PR 也没人提

• 此外还有一些 幽灵 Issues. 何为 幽灵 Issue? 打开 Issues, 发现 160+ 个打开的, 但仔细一检查, 发现有的甚至两三年前就早就修好了, 有的甚至接口失效了还没加进去

• 于是乎, 就有人一口气关到了 144 个, 但实际上还有十多个能关的, 但估计 GitHub 没想到有用户这么有行动力, 单个 PR 只能最多链接 10 个 Issues, 直接罢工

• 泽生已经去了每一个可以关掉的 Issues 下面评论, 说明已解决可以关闭. 估计当初发 Issue 的用户与有操作 Issues 权限的用户可能没空没看到等原因, 到现在还是有很多没关

• BAC 项目结构也挺过时的, 纯 Markdown 结构已经被包括易姐在内的很多人所诟病

• 这种写法在普通文档里还好, 一旦遇上非纯接口类的文档直接开始了百花齐放, 各种格式无奇不有. 只有你想不到的, 就没有贡献者们写不出来的

• 贡献指南 (根本让你找不着北) 严重不完善, 格式标准化, 通用字段规范化, 国际化(i18n) 等内容为 0.

• 为何不设立一个类似词典的结构, 用来处理通用字段, 特别是 字段名-释义 这类数据?

• VuePress2 的版本自从项目引入时就已更新许多, 除了错误修复还有一些有趣的功能, 项目中的版本早已过时

• 泽生曾试着更新, 并通过 Shiki 实现对 JSONC 的高亮, 并提了 PR, 尽管对于纯文本的高亮问题暂时未解决

• 并且, VuePress 是给 Markdown 用的, 不支持 protobuf 诶

未来

• BAC 正处于百年之未有大变局, 历史以来最困难的时期, 内忧外患, 无人维护, 社区分裂, 公关危机
• 解决 BAC 所处的困境的有效且唯一的方案只有改革
  • 更换或增加管理层人员, 解决无人维护
  • 增加示例代码库兼接口测试库, 方便 review 与及时发现接口过时
  • 完善自述文件及贡献指北及许可证, 缓解公关及入门门槛问题
  • 最后是重构, 彻底解决 Markdown 带来的可维护性与难标准化性
• 个人建议如下
  • 建立一个叫 BAC Community (也可以叫做别的更好听的名字) 的 GitHub 组织
  • 把原本的 SocialSisterYi/bilibili-API-collect 过户 (transfer) 过去, 原地址贴上迁移说明
  • 单独整一个存储库存放 proto 定义, 之前有人打算用 CSV 格式存放, 只要是人类可读的纯文本格式都欢迎
  • 增加示例代码库兼接口测试库, 各种编程语言可以混用, 许可证建议用 GPL (传染性) 或 MIT (单纯喜欢)
  • 另外许可证更换为 CC-BY-NC-SA 4.0, 在增加 相同方式共享 的同时也与目前兼容
  • 更新贡献指北, 顺带照顾唯一的 i18n 需求
• 这些事情除非相关人员真来要求或指定我来做, 否则我是不会有什么大的行为的. 主要是处于尊重以及自己的懒惰
• 咱就是说, 如果真的酱紫的话, 等出事跨省的时候, 是不是就不只易姐而是大家一起被抓, 这样想想居然还挺不错的诶?

祝

• BAC 在我走到如今的道路上起到了至关重要的作用
• 可以说, 没有 BAC, 我就不会学 Java, 就不会面向对象, 就不会有今天的成就
• 我只是希望 BAC 能越来越好, 也算是作为对大家的回报吧

追加: 前天在易姐 B 站 BAC 的 stars 数破千的动态下考古, 得到了咕的回复. 泽生本人目前也开始上高中, 不知能否也创造一个新的奇迹?