运营中

花20年打磨"开源+付费版"战略,一个人把开源项目做到年营收超700万美元:Sidekiq的完成形态

Mike Perham开发的Ruby后台任务处理开源库"Sidekiq",以"免费开源+付费Pro/Enterprise版"模式独自运营,年营收做到超700万美元(约10.5亿日元)(他本人在2023年表示"比起100万美元,更接近1000万美元")。这是零员工开源商业化的一个巅峰案例。

花20年打磨"开源+付费版"战略,一个人把开源项目做到年营收超700万美元:Sidekiq的完成形态

(美元金额按1美元=150日元换算为大致日元数)

零员工、零销售、零广告,年营收超700万美元(约10.5亿日元)。开发了Ruby后台任务处理库”Sidekiq”的Mike Perham,用十多年时间,为”靠开源吃饭”这道老难题给出了目前为止最完整的一份答卷。作为个人开发的收入规模,这已经是世界级水平,但整个运营却始终异常安静。本文基于Indie Hackers播客(2017年)和saas.group的访谈,梳理其内部数字与设计逻辑。

时间线上的轨迹

时期事件
前史约20年软件开发经历,辗转十余家创业公司,并有5年以上参与维护Resque、Delayed Job等Ruby系开源项目
2012年在旧金山一边做咨询工作,一边用约2个月时间开发出Sidekiq并作为开源项目发布
发布约6个月后推出付费版Sidekiq Pro(当时年费1000美元)。最初的5至10位客户几乎是原有开源用户即时转化而来
发布18个月后收入趋于稳定,辞去全职工作转为专职
2017年月营收约8万美元(约1200万日元),客户约800家,年增速50%至100%。Enterprise版年费2000美元
2023年年营收超700万美元(约10.5亿日元)。本人表示”比起100万美元,更接近1000万美元”

事情的起点在客户现场。当时的咨询客户为后台处理耗费了十几台机器,Perham认为”同样的负载理应能用一台机器扛下来”,于是写出了Sidekiq。先有对性能的具体不满,后有产品的诞生;发布之后,他本职工作的雇主本身就是Sidekiq最大的用户,日常业务因此直接成了实地测试。专职之前的副业投入大约是每周20小时的夜晚和周末时间。在Resque和Delayed Job维护中积累的”这个品类到底哪里痛”的经验,是那约2个月开发周期背后的支撑。

“免费版自己去做销售”的结构

Sidekiq的免费版事实上已成为全球Rails应用处理后台任务的标准配置。开发者通过免费版建立信任,只有当业务发展到对可靠性和功能要求提高之后,企业才会购买Pro/Enterprise版(批处理、加密、优先支持等)。事实上,新客户中九成来自主动询价(inbound),完全没有销售、市场营销和广告。免费版的普及本身就是销售——所以一个人也能撑起年营收10亿日元级别的生意。

关键在于免费与付费之间的分界线。Perham把这条线划得极为精准——“业余爱好、小规模使用免费版就够了,真要在业务中认真使用,才会想要付费功能”。免费版留一手,普及就上不去;付费版功能弱,就赚不到钱。发布Pro版时既有用户中5至10家即刻转化为付费客户这一事实,说明发布后仅6个月,这条界线就已经划对了。这种界线设计本身,正是开源商业化的核心所在。

不打折、不雇人、不开例外

一个人支撑约800家客户(2017年时点)的运营模式,靠的是彻底”排除例外”。无论对方是谁,一律不打折。价格统一,谈判这个流程本身就消失了,销售成本归零。付款几乎全部通过Stripe自动化处理,发票支付仅限于最大的几家客户。日常支持大约每天6封邮件,对客户的主动接触被克制在每季度一次以内。连注册公司都推迟处理,收入超过工资之前一直以个体经营者身份运营。用他本人的话说:“不用担心文书工作,难的是把钱引进门。”

定价上也有自己的思路。Pro版年费1000美元、Enterprise版年费2000美元的水平,与企业软件的市场行情相比堪称便宜到不成比例。Perham考虑到”开发者市场还不习惯为工具付费”,有意从低价起步。想想咨询客户能把十几台机器换成一台,对企业而言,一年1000美元的花费靠节省下来的基础设施成本就能立刻收回,采购审批也容易通过。这种”低到不像话”的价格,支撑起了不需要打折、不需要谈判的结构,也体现在2017年时点50%至100%的年增速中。

而Perham在收到收购邀约后并未出售,也没有雇人,只是悄悄地涨价,继续做着同一份事业。如果说Transistor的calm company是团队版,那Sidekiq就是个人版”平静经营”的极致。在与VC增长压力毫无瓜葛的状态下,与Ruby社区共处十余年,没有哪个案例比它更清楚地证明了**“不做大的自由”能够与顶级收入并存**。

没做成的那些——Inspeqtor的教训

Perham也有失败之作。监控工具”Inspeqtor”作为向其他品类的拓展被投入市场,但没能像Sidekiq那样成长,最终被砍掉。同一位开发者用同一套”开源+付费版”模式挑战,若无法占据生态系统中必经基础设施的位置,就无法复现,这一失败从反面证明了Sidekiq的成功不仅依赖个人能力,更依赖于它牢牢占据了Rails任务处理这个”几乎所有应用都必经之处”的位置。

结构性风险也藏在同一个地方。这门生意的天花板和寿命,与Ruby生态系统的兴衰紧密相连,依赖单一语言社区这一点无从分散。而且从月营收8万美元到年营收超700万美元,走了将近10年时间。这门生意的复利并非来自速度,而是来自”不离场”。

可复现的条件与局限

对日本的开源开发者而言,能从这个案例中提炼出的一条通用规律是:“不是靠捐赠,而是面向企业的付费版,才是把开源变成职业的最粗的一条路径。“面对GitHub Sponsors和”开源疲劳”语境下反复讨论的可持续性问题,Sidekiq示范了一条通过功能设计让企业”愿意花钱”的路。

不过前提条件很重。目标开源项目要处在生态系统的标准必经之路上;要能切分出只有企业用户才需要的功能(加密、批处理、优先支持);还要能在转为专职前的18个月里,靠每周20小时的副业投入撑过生活。品类一旦选错,就会变成Inspeqtor,同一个人的成功与失败对比,比任何道理都更有说服力。

一起读读

出处

本文是对上述公开信息的摘要与分析。详情请务必确认一手资料。

本文允许在新闻媒体、博客或生成式AI回答中自由引用与转载:只需注明出处「Small Start(small-start.com)」并附上本页链接,无需事先联系。 转载与引用政策 →

相似案例

如果本页对您有帮助,欢迎分享
分享到X