我如何在 6 个月内把 GitHub Store 做到 12,500 星——起步时我只有 16 岁
我用一周的 MVP 冲刺做出了 GitHub Store——一个面向 GitHub Releases 的跨平台应用商店。六个月后：12,500+ 星标、250,000+ 次更新分发，还有差点在 3,000 星时放弃的那段经历。
六个月前，我是一个住在乌兹别克斯坦的 16 岁少年，正想发布自己写的一个小 Android 应用。Play Store 的流程相对于这个项目的体量来说实在太重了，于是我干脆做了个替代品。
六个月后，这个替代品——GitHub Store——拥有 12,500+ 星标、推送了 250,000+ 次更新、支持 13 种语言，运行在 Android + Windows + macOS + Linux 上。几周前我刚满 17 岁。
这就是那个故事。包括我差点放弃的那部分。
Play Console 这堵墙
我以前往 Play Store 上架过应用。那些感觉值得——真正的应用、真实的用户，流程上的摩擦就是做事的成本。
这次不一样。我当时在参加 Philipp Lackner 的 Mobile Dev Campus 挑战，做了一个自己挺自豪的小副业项目，想把它发布出去。重读了一遍 Play Console 的要求之后，我直接停下了。
25 美元费用。政府身份证件。地址验证。20 名封闭测试者。至少 2 周的封闭测试。然后等待。也许能过审。
一个月的流程。就为一个副业项目。这笔账算不过来。
GitHub 本来就允许开发者在 Releases 里发布 APK。所以我想：那就在这之上建一个商店。
这个空白，就是这个项目。
我当时不知道的事
诚实地承认：开始做的时候，我并不知道 F-Droid 和 Obtainium 的存在。是后来——在我发布之后——别人告诉我的。如果第一天就知道，我可能根本不会做 GitHub Store，直接装个 Obtainium 然后干别的去了。
有时候，无知反而是一种特性。
为什么选 Kotlin Multiplatform
在这之前我做了大约两年的原生 Android 开发。Kotlin 是我的语言，Compose 是我的 UI 工具。
选 Flutter 意味着 Dart + 新构建系统 + 新调试器。选 React Native 意味着我不会的 JavaScript。选 Tauri 意味着我不会的 Rust。
KMP 让我把两年的 Android 经验直接带进桌面端，不用换语言、不用换 IDE、不用换思维模型。我选它是因为这样能更快发布。
一周做出 MVP，没用任何编程智能体
GitHub Store 的第一个版本只用了一周就发布了。
全力投入。翘了课。停了学习。有几个晚上几乎没睡。
零编程智能体。没有 Cursor，没有 Copilot，没有 Claude Code。只有 IntelliJ、Compose Multiplatform 文档、Ktor 文档，和我自己的双手。
首版包含的功能：
- 通过公开 API 搜索 GitHub Releases
- 资源过滤——只显示 APK 和桌面安装包，隐藏杂音
- Android 上点击即装，走系统安装器
- 一套 UI 代码：Android + Windows + macOS + Linux
粗糙，但真实。它能用。
在它严格意义上还算不上 MVP 的时候，我就把它发到了 LinkedIn——那是我人生第一条正式的 LinkedIn 动态。约 100 个互动、5,000+ 曝光，而我的主页之前基本是空的。几天后我又发到了 Kotlin Slack 社区。
增长轨迹
我从 2025 年 11 月 21 日开始，私有状态下开发了一周，11 月底把仓库设为公开。11 月 30 日——第一颗星。
12 月 15 日：100 星。
1 月 3 日：2,500 星。
我当时真的不理解发生了什么。增长先是缓慢，然后突然就不慢了。每个里程碑我都发了 LinkedIn 动态庆祝——那些动态收到的互动比发布时还多。
那段时间最大的放大器是 HowToMen——在大约 2,000 星的时候，他把 GitHub Store 收录进了他的”12 个比 Play Store 更好的应用商店”（Top 12 App Stores Better than Play Store）视频。他的观众正是这个应用的目标人群：注重隐私、本来就不信任 Play 的 Android 用户。那个视频之后，增长曲线完全变了样。
绕不开的比较：是的，我知道 Obtainium。“为什么不用 Obtainium？“这个问题我每周都被问。Obtainium 是面向高级用户的轻量更新器，适用于你已经知道的仓库；GitHub Store 是发现优先的商店，面向那些还不知道该装什么的人——而且是跨平台的。用 Obtainium，用 GitHub Store，两个都用都行。我们做了 Obtainium 导入/导出，应用库可以在两者之间一键迁移。
2,000–3,000 星时的低谷
这是我差点从这篇文章里删掉的部分。
在 2,000 到 3,000 星左右，我的状态变得很奇怪。埋头干了好几个月。产品在获得关注。人们在写好评。Issue 在堆积。
而我开始迷失方向。
我会打开仓库，然后只是盯着看。我为什么在做这个。会有人长期用它吗。星数是不是只是虚荣。我是不是在把人生花在一件无关紧要的事上。
那段时间我和 ChatGPT 聊了很多个小时。一两个小时的长对话。不是为了写代码——是为了出声思考。我的同龄朋友没有人在做产品。生活里没有一个合适的人，能接住这种自我怀疑。
把我拉出来的不是什么顿悟，而是一条条具体的用户消息。一位开发者私信说他的工作流因此改变了。一个 bug 报告以”我超爱这个应用，但是……”开头。一位维护者认领了自己的仓库，说这是他的项目第一次拥有一个真正的商店页面。他们没有人知道我在自我怀疑。他们只是在用一个东西的普通用户。
如果你正在做产品：低谷是真实存在的。外部的成功不会让你产生任何感觉，它只是摆在那里。真实用户的具体反馈才是有用的。让他们能轻松地联系到你。
我想对 16 岁的自己说的话
先发布，再了解受众。 我发布之前没有做用户调研。受众自己出现了——热爱折腾、讨厌广告、讨厌追踪、重视隐私的 FOSS 用户。了解这一点之后，后面每一个产品决策都有了着落：开源后端、零遥测、捐赠渠道、不搞暗黑模式。在调研做完之前就发布。受众教你的速度，比你的假设快。
KMP 真的能用。桌面端也是。 跨平台这个说法不是营销。
分发本身就是功能。 F-Droid、Obtainium 配置、Scoop、Winget、IzzyOnDroid——我每增加一个渠道，都是在增加一个产品功能。装不上你应用的用户，等于不存在。
和你的用户对话。直接对话。在应用里对话。 更新日志不顶用。大多数人不会读——我这辈子就没在 Play Store 页面上点开过”新功能”。所以我做了：每次更新后弹出的应用内更新摘要（简短、要点式）、用于问卷和安全通知的公告流、发送前可预览诊断信息的反馈卡片，还有一个 Discord。我做的第一次正式问卷告诉我的东西，是 12,000 颗星给不了的。
尽早本地化。 只要应用够好、而且他们读得懂，全世界的人都会用你的应用。限制因素是语言和网络。GitHub Store 支持 13 种语言，并通过一个能穿越防火长城的后端代理运行。这就是为什么这里有中文、俄文和阿拉伯文用户。
最难的部分不是代码。 没有人提醒过我低谷的存在。
接下来
还有很多东西在路上。一套比现在好看得多的新设计。更好的桌面端支持——可能会带上 Android 已经有的自动更新能力。比现在好 100 倍的用户体验。
最终会有一个付费档位。一条原则：GitHub Store 只对那些会产生实际运行成本的功能收费。存储、带宽、计算、监控。任何在你设备上本地运行的功能，永久免费。后端是开源的、可自托管的。之后会单独写一篇文章解释为什么。
如果你读到了这里——去试试它。如果它解决了你的问题，给它点颗星。如果没有，提个 issue。如果你是一位开发者，你的项目发布 APK 或桌面安装包，去认领你的商店页面（免费，即将上线）。如果你是某个地方的一个青少年，正在考虑要不要发布一个项目：直接开始。Play Store 可以等。GitHub Releases 就在那里。
—— Usmon（@rainxchzed）