The Review and Plan for Bilive

January 10, 2025 · 14 min read · Page View:

bilive 的 star 增长情况 (2025-03-09更新)

If you have any questions, feel free to comment below.

从 12 月 10 号正式上线生产版本的 bilive 到现在，已经过去了一个月了。目前 bilive 的 star 数已经突破了 300，实际用户数应该在 20 ～ 30 之间。当然 star 的数据本身没有什么意义，我真正追求的是使用者，但是 star 数据能够反映出项目实际浏览量，与其他工具类项目相比，我对于 bilive 的定位更像是一个产品，如何让这个产品积累足够多的用户和反馈，是我目前主要面临的问题。

项目的复盘 #

对于一个产品类型的项目，能在短暂的一个月里获得 300 的 star 数，如果放在工具类型的项目我认为是值得称赞的，但是对于一个产品类型的项目，我认为是一个正常的现象，复盘一下，它增长的原因可能在以下几个方面：

1. 实用：目前 b 站主要是年轻人居多，其中实际的开发者更是不计其数，因此一个实用的产品能减少很多理解的难度，加上 b 站录播员不计其数，因此对于目标用户来说项目是一个非常实用的工具。
2. 门槛低：我在开发的时候尽可能地降低了项目的硬件门槛，针对性地将 ffmpeg 的压制，弹幕的渲染对照最低的配置进行了优化，像我宣传的一样，一台十年前的电脑也可以轻松运行，降低了用户的成本。
3. 收入：项目的投稿还会存在一定的收益，一个随手能做并且完全不用监守的工具，还能有收入的项目，我相信很多人都会愿意去尝试。
4. 详细的文档：我写了一个非常详细的文档，包括了项目的安装，使用，以及一些常见的问题，尽可能地降低用户的上手难度。
5. 宣传：我认为宣传是一个不可缺少的环节，对于一个强绑定的工具，很难做到向当初字节宠物短视频一样的快速冷启动，因此我必须保持着一定频率的宣传，让项目保持在持续的曝光里。在之前的文章 Thinking About Advertisement from an Open Source Perspective 中我提到过这个项目推广的基本策略，在实际的用户积累中，我将项目主要在 linux.do 以及 v2ex 上进行了初步的宣传。这些渠道主要以垂直的开发者居多，在部署方面不会产生较大的问题。
6. 创新：市面录播的工具很多，竞品也有很多，通过对于竞品的分析，我能大概预估出这个项目的规模至少是 k 级别的增长，针对于及时的用户反馈，我尽可能从各个角度满足用户的需求，从压榨硬件的性能到增加字幕，定制化的弹幕参数以及优化流程做了很多创新。
7. 合规：对于内容平台，一个不可忽视的问题就是版权以及违规问题，在开始项目之前我就针对 b 站的版权情况做了详细的调查。
   • 首先，b 站对于自己的生态内的主播都有内容相关的所有权，因此对于录播稿件，主播除非涉及到个人隐私或者法律引战的部分会审核下架，其他类型不会被投诉下架。
   • 其次，b 站对于稿件审核较为宽松，很多时候总是能见到一些原版视频后面添一段不相关的片段或者直接在视频上贴一段评论就能上传成功，因为 b 站判断稿件是否重复或者违规条件卡的非常严格，只要不是完全一模一样，基本上不会被判定稿件违规。所以我针对弹幕的渲染以及识别字幕的方式很大程度上保证了视频内容的独一无二，保证了内容的合规性。
   • 最后，最重要的还是 b 站的官方政策，在前两个月推出了官方在直播流中剪辑的方式，鼓励二创作者边看边剪，因此 bilive 的工具很大程度上和 b 站官方的步调保持一致，都是对于整体生态的一种补充。

面临问题以及计划 #

1. 目前宣传以垂直的开发者居多，如果想要获得更加广泛的反馈以及积累用户，宣传是必不可少的。对于我这个应用的产品，短期的目标是获得 1k 次有效浏览，积累 100 个种子用户。我对于有效浏览的定义是用户至少仔细观看了项目的主页内容并且留下印象，在以后有相关需求时能够想到曾经看到过这个项目。由于 bilive 主要还是面向中文的观众，因此我在 Thinking About Advertisement from an Open Source Perspective 中提到的当时尤雨溪的推广路径很大程度上走不通，最近在 1000UserGuide 这个 repository 中发现了整理好的一些适合独立开发者和创业者推广产品的渠道，我大概分析了一下。目前还没有启用的宣传途径有：
   1. 阮一峰等开源作者以及自媒体的曝光。我认为 KOL 的作用还是非常大的，KOL 拥有最垂直类型的 followers，内容生态上一个简短的文章或者视频既不会让受众走马观花，也不会像重度的介绍以及文档让用户产生抵触的心里，对于能够留下印象的有效推广来说是一个不错的选择。
   2. 导航站：由于种种原因，我个人对于导航站不是特别看好。不过顺手能提交的我应该还会尝试。
   3. 常见的产品推广平台，例如 product hunt，即刻等。在这些平台上产品经理非常活跃，有时能收获另一个看待项目的视角。
   4. 个人影响力的曝光：我目前在一些博客平台上还有一定的 followers 基础，短时间内大规模推广应该会有一定的效果。
   5. 主流媒体平台的推广，例如知乎，b 站，小红书等，这一步更加偏向大众，等待稳定的生产版本发布后，会在这些平台进行推广。

2025 年 2 月更新，最近提交 bilive 到了 github 上一些开源项目收录的仓库。

2. 某些模块的自制与优化：目前上传部分采用的 biliup-rs 的模块，由于只是 cli 调用，少了很多优化内部调度或者异步的可能，因此我目前在做 python 重写工具并把它开源成 pip 库，方便更多人的使用的同时也能尽量避免下游工具故障引起的整个项目的阻塞。
3. 平台的广度受限：b 站市场受众还是不如几个大型的流媒体以及直播平台广泛，因此产品的用户上限较其他平台的竞品来说会小很多。
4. 语言的限制：目前 b 站主要还是针对中文用户，因此对于非中文用户也不会有使用的价值，对于产品的多样性来说，也会有一定的限制。
5. 更加规范化的结构：由于最早项目是我在服务器上写的 shell 流程，后来用 python 重构，虽然在重构的过程中已经重写了很多设计，但是很多地方还是不合理，例如日志模块，从最早的 shell 版本之后我都一直将运行的结果重定向到日志文件中，这本身是存在问题的，如果很长时间内没有报错以及中断，日志文件会随着时间的增长越来越大，变得难以排查和维护。对于以后的 docker 将服务独立出来乃至 k8s 进行管理，没有良好的日志设计都是非常致命的。后期会考虑使用 logging 模块对于日志进行管理，并且将日志改为基于时间的分段，无需累计单次运行的日志内容，运行过程中基于此刻的日期进行日志的分割与输出，方便定位和维护，同时还能将日志留存在控制台，方便后期 docker 的状态监控。这意味着代码一定要重构，并且重构不止一点，目前项目结构设计过于冗余的坏处就是，开发者看起来不清楚，我之前听过很多开发者谈论自己的项目，说想要设计得复杂，让其他人看起来不能直接用，这种观点是非常错误的。我一直认为，开源项目只有足够清晰，让开发者更容易上手，才会有更多的人一起做，才会真正促进项目的发展，大型的开源项目是无法通过几个人就能完成的，就像一家两个人的公司过于集中的股权是无法上市的。目前我的项目问题就非常严重，我深知项目能快速积累用户是因为功能有创新，有意思，而并非从代码乃至项目结构上能吸引到更多的用户以及开发者。一个清晰规范的结构以及一份详细的说明以及开发文档，是项目长期发展的基础。
6. 多平台的支持：根据收到的实际反馈，使用的用户大部分以 windows 为主，还有部分的 NAS 跑 docker 的用户，真正使用 linux 服务器的用户还是少之又少。虽然 windows 用户也能通过 wsl 进行部署，但是存在一定的部署门槛。纯 windows 系统的部署也会存在一些基础库的问题，例如 fcntl 关于锁的库主要操作的是 linux 的底层函数，因此不支持 windows。未来我会考虑针对 windows 平台进行针对性的适配。

Related readings

• Thinking About Advertisement from an Open Source Perspective