Cubby Clipboard

发布之后的表现

收入:indie 库(TrustMRR)没有这个产品库,同作者的其他产品(Ceiling、Toolport、Southbound)也没有。这符合产品形态:官网明说免费开源、无账号、无云、无遥测,产品包里也没有任何付款链接。没有收入,不是「没查出来」。

用户 / 下载:App Store、Google Play、Mac App Store、Chrome 商店四个库都没有库——只有 Windows 版,不进苹果/安卓/浏览器渠道是合理的。可观测的真实分发只有 GitHub Releases 和 Microsoft Store:2026-10-31 发布的 v1.3.8,x64 安装包 51 次下载、arm64 12 次、便携版 2 次、Store 包各 2 次GitHub API,截至 2026-11-02。官网和 winget、Store 也在分发,所以这不是全部装机量推断,但量级很清楚:几十到几百,不是几千。Microsoft Store 页面(apps.microsoft.com/detail/xpfcjg02ps9zb0)抓取返回空壳(JS 渲染),评分数抓不到,库里也没有——所以「Store 上有多少评分」答不了。

开发者关注:GitHub 库没有它(库里只收 ≥50 星,14 星进不了名单)库。现查 GitHub API:仓库已从 tsouth89 改名到 btsouth,建于 2026-07-16,14 star / 4 fork / 0 watcher / 5 open issue,最后提交 2026-10-31,120 天内 16 个 releaseGitHub API。fork/star = 4/14 ≈ 29%,超过「>15% 要追一步」的线,但追下来是基数太小 + 无内容镜像:四个 fork 里 Om-Beast、Nitjsefnie-OSC 都在 2026-07-18 建、当天后再没推送,slegarraga、harshvardhan60792 同样,没有一个带 star、没有一个改过默认分支GitHub API——这是发布日的一波无意义复制,不是真社区,也和刷 star 无关(星本来就少)。仓库不空:634 次提交、Rust/Tauri + React、GPL-3.0,不是 README 空壳。

讨论:HN 库没有(域名、github_repo、标题三种查法都空)库;X 本地库 core 圈 560 人里没有任何一条提到 cubbyclip/cubby clipboard,PH 给的 @cubbyclip 也不在圈子名单里库。网上检索也找不到 Reddit / HN 的独立讨论帖,只有自动收录站(toolradar、launly、aiindigo)和 PH 页本身。PH 有 11 条评论,是唯一有真人反应的场子。

官网与公开动态:两个域名都活着,版权年 2026,和 v1.3.8 同步。没有独立 changelog 页,更新说明走 GitHub Releases,作者另有一个自动生成的 ship log(southboundsoftware.com/ship)列全部 App 的发版。没有融资、收购、博客、媒体曝光。创始人的产品 X 号 @cubbyclip 只有 17 帖、15 关注者X 网页,2026-07-23 那条写「Cubby is currently #39 out of 401 products on @ProductHunt」——库里那天日榜记的是第 41 名,第 39 应是他发帖时点的实时名次,差两名,不算矛盾。

自报 vs 实际

• 自报:「Free and open source」官网——库与现查一致,官网、GitHub、Store 三处都是免费,可信。
• 自报:PH 发布日「#39 / 401」创始人推文vs 库里 daily_rank 41库:时点差,不是虚报。
• 没有找到任何自报的用户数、收入数、MRR。没有「100 万用户」这类需要核对的话术,这点反而干净。
• PH 档案 followers 40、reviews_count 0库,和 X 号 15 关注者、GitHub 14 star 相互印证:受众从未超过百人级。

为什么成了 / 没成

它没「成」,不是因为产品差——这是本档案里最反直觉的地方。作者的发版纪律相当罕见:120 天 16 个版本,每版都带安全修复(rustls、依赖 CVE)、无障碍审计、RDP/mRemoteNG 这类别人不碰的边角场景,连发布流水线从 22 分钟优化到 10 分钟都写了 PR 说明。产品定位也聪明:不去和 Ditto/CopyQ 比功能多,而是抓「Win+V 记不住 + 截图里字搜不到」这两个真痛点,并用「本地 OCR、无云无遥测」做差异化。

没成的理由是分发和收费模型,两个都可验证:

一是渠道基因不匹配。目标用户是「天天复制粘贴的 Windows 办公/远程工作者」,这帮人不在 Product Hunt,也不看 GitHub。PH 71 票换来的自然流量已经把上限暴露了:40 个 PH 关注者、14 个 GitHub star、最新版 51 次下载。唯一的规模化渠道是 Microsoft Store,而它对免费小工具几乎没有发现机制;Store 更新还因为「另一个提交占用」被 Partner Center 拒过(#342,2026-09-27)GitHub issue。

二是GPL-3.0 + 零收费把商业路径自己堵了。没有 pricing 页、没有内购标记、README 和官网都写 free,所以 TrustMRR 那条「公开真实收入」的路根本不存在——indie 库查不到它不是漏采,是产品从不产生流水。免费开源能带来 star 和 fork,但这个库的 4 个 fork 全是发布日的空壳复制,一个贡献者都没留下。

同作者的其他产品给了一个对照:同样是他做,Toolport 在 PH 拿到 343 关注,Omaroll 拿到 76 star,都比 Cubby 高一个量级——说明作者会做增长,只是 Cubby 这个故事在 PH 的受众里不成立。

对想跟的人

这个方向不缺需求,缺的是「愿意付钱的入口」:Ditto 多年不更新却仍被 2026 年的评测反复推荐为 Windows 首选,说明存量替代需求是真实的;但那批用户已经习惯了免费开源,你再去开一个 GPL-3.0 的免费替代,最好的结果就是 Cubby 这样——120 天 16 个版本、14 个 star、51 次下载。真正的坑有两个:一是别在 PH 上找 Windows 办公用户,71 票 / 40 关注换不动 Store 的冷启动;二是截图 OCR + 本地优先这个差异点支撑不了订阅——它是一次性的效率改善,用户装完就不打开界面了,所以你必须在第一天就选好收费形态(比如 Store 内购 / 一次性买断 / 面向 IT 的批量部署授权),而不是像 Cubby 一样把定价页做成 404 再靠 Github 发版硬撑。要跟就跟「远程桌面/远程支持的剪贴板可靠性」这一条,那是 Ditto 和 Win+V 都没解决的、且公司会付钱买的那一小块。

没查到的

• indie(TrustMRR)、App Store、Google Play、Mac App Store、Chrome 应用商店:库里没有该产品,也没有同作者主体库。
• Hacker News 库、X 本地库:零提及库。
• GitHub 库:14 星不到 50 星收录门槛,库里没有;上面所有仓库数据是现查 GitHub API 得到的官网。
• Microsoft Store 的真实评分 / 评分数 / 装机量:页面是 JS 渲染抓不到,库里也没有对应商店数据层,查不到。
• winget / Chocolatey 的安装量、官网 cookie-free 分析的后台数据:无公开来源。
• 创始人本人是否还有其他合作者、公司注册信息(Companies House 之类):未查到,档案里的「一人」是推断。