Tag: 开发者

本篇是“每天1个黑客案例”系列文章的第37篇，每工作日更新。

产品名称：FireFTP

产品简介：

浏览器中的FTP/SFTP插件，在浏览器中通过FTP/SFTP连接服务器。作为Firefox浏览器插件共13年、总计超过2500万次下载，顶峰时期每天有100万活跃用户使用。

现Firefox官方已停止对FireFTP的支持，因此作者也停止了继续开发和支持的工作（Chrome也不提供这种能力）。如果想要继续使用插件，作者推荐使用Waterfox浏览器。

FireFTP是一个charityware（可以理解为慈善软件），超过50%的收入捐给了慈善机构。作者公布了收入和捐款明细，13年间（截止2017年），FireFTP总计收到$166,896的捐赠款，其中$104,984捐赠给了慈善机构。

发布时间：2004.9

运营渠道：

Firefox插件库、FireFTP.net、GitHub

流量概况：

FireFTP.net：9,000UV/月（2018.7-2018.9均值），60%流量来自老用户回访，另30%流量来自搜索引擎，主要关键词为“fireftp”，可见搜索用户已经知道FireFTP。

盈利方式：

• 用户自愿捐赠（donations）

盈利能力：$1,000/月（2004-2017均值）

作者：

Mime Čuvalo（个人网站、GitHub），目前（2018.10）在Dropbox工作，还曾在Google、YouTube工作过，自己做过的独立项目除了FireFTP，还有FireSSH等，具体可查看作者的简历。

想法&MVP&启动：

FireFTP开发于2004年夏天，当时Firefox还没正式发布，还被叫做Firebird或Phoenix。那时作者刚刚获得波尔州立大学（位于美国印第安纳州）计算机科学学位，他说学校很差劲，很多东西他都得自学，所以FireFTP的第一版也很差劲。

FireFTP第一版于2004年9月发布在Mozdev.org（为Mozilla应用和扩展提供主机服务）上，作者还在Slashdot上发了一个帖子，这为FireFTP带来了很多流量和关注。虽然当时FireFTP充满了bug，但人们还是持续地使用它，这很让作者惊讶。

作者持续完善FireFTP，这在当时并不容易：那时他住在萨格勒布（南斯拉夫西北部城市），而且网络是按分钟计费的，下载一个Linux ISO就需要花不少钱，而且当时还没有很好的下载工具，如果下载到一半失败了那就惨了。除此之外，当时Mozilla平台几乎没有任何开发文档，再加上它是用JavaScript开发的，由于JavaScript当时完全不受尊重，所以也没有什么好用的工具，尤其是插件debug工具。

除了最初在Slashdot进行过宣传外，作者再没有做过任何推广。而FireFTP之所以能够取得后来的成功，是因为它连续10年一直是Firefox官方推荐的精选插件。作者坦言这起到了很大作用，形成了一个正反馈循环：他做了一个好的产品 → 官方推荐了它 → 他受到鼓励把产品做得更好 → 官方持续推荐。

至于FireFTP好在哪里，作者认为是它的易用性和简洁的UI设计。相比于Filezilla和其他FTP工具，FireFTP没有那么多用户用不到的按钮，更加简洁好用。

值得一提的是，2004年11月，FireFTP发布2个月后，Firefox 1.0正式发布。作者为Firefox的发展感到非常振奋，在这场大潮中贡献自己力量的感觉很棒。毫无疑问，FireFTP的成功也得益于它很早就加入了这场大潮。

14年后的今天，大潮已经落幕。Firefox不再为FireFTP提供支持，终结这场大潮的Chrome也不提供FireFTP所需的能力，作者也停止了继续开发和支持的工作。如果想要继续使用FireFTP，作者推荐使用Waterfox浏览器。

讨论：

FireFTP的故事读起来很享受，感兴趣的朋友可以去读下原文。故事中充满了早期的“古典互联网”的味道：网络按分钟收费、下载不能断点续传、开源、通过用户自愿捐赠获得收入、超过50%的收入捐献给慈善机构、Slashdot（作者称其为Hacker News 1.0）、Waterfox（水狐浏览器，forked from Firefox，为被Firefox抛弃的legacy extensions提供支持）。

不知道为什么，我觉得国外的互联网环境，或者是早期的国内互联网环境中，还能找到一些可以称之为“互联网精神”的东西，这些东西在今天的互联网，尤其是国内的互联网环境中越来越少了。

想要了解更多，请查看：
Supporting a Larger Movement, and Earning Over $1.6k/mo – IndieHackers

查看其他案例，请点击：“每天1个黑客案例”文章目录

本篇是“每天1个黑客案例”系列文章的第29篇，每工作日更新。

产品名称：BugTower

产品简介：

为开发团队制作的问题跟踪（Issue Tracking）SaaS（Software as a Service）。

发布时间：2014

运营渠道：

BugTower.com

流量概况：

不足5000UV/月，40%流量来自老用户回访，30%来自搜索引擎，主要关键词为“simple issue tracker”。

盈利方式：

• 按月付费的订阅制（有免费试用期）

盈利能力：$820/月（2017.4）。

作者：

Kyle Connors（个人网站），开发者。

想法&MVP&启动：

作者在一家开发机构（应该是外包公司）工作，公司为各种各样的客户开发定制软件。客户中的大部分都不是技术人员，但他们需要深入地参与到软件的测试工作中，验证功能并报告问题。实现双方的沟通有以下几种方式：

• Email：这对客户来说最简单，但是Email可能会弄丢，而且很难管理。
• 开发工具：大部分问题跟踪（Issue Tracking）应用都是技术向的，要花很长时间去学习如何使用。许多客户都没有时间，也并不愿意去学习使用这样的工具，最后他们还是使用Email来提问题。
• 电子表格：基本上跟Email是同样的问题。

所以作者准备做一个简单的，任何人都可以直接使用的问题跟踪（Issue Tracking）工具。他没有做什么市场调研，仅仅是解决自己遇到的一个问题，他知道一定有其他人也有同样的问题。

他过去做过很多失败的业余项目，究其原因，有这么几条：

1. 解决的不是真正的问题。那些点子看起来很酷，所以他直接就着手去做了，直到后来才发现根本没有人用。
2. 想做的功能太多。每当看过竞争对手的产品后，就想要在功能上、设计上都赶上他们。
3. 想要使用新的技术（语言、框架等），学习和试错占用了太多的时间，真正开发的时间却很少。
4. 害怕发布。“还不够好”、“bug太多”、“人们会觉得它没用”，想得太多，最终止步不前。

这次，他知道他已经解决了第1个问题，因为这次是他自己遇到的一个真正的问题。当然这个产品不可能变成一个独角兽，但却确确实实是个痛点。他觉得如果自己能避免之前的那些问题，这次一定能成功：

1. 他专注于解决最核心的问题：一个可以创建和更新基本信息（标题、描述、严重程度）的工作流。
2. 使用自己熟悉的技术：Python和Django，服务器用AWS，支付用Stripe。
3. 发布。不再关心别人怎么想，只专心发布。

因为他还有工作要做，所以只能在周末进行开发，但他觉得在资源有限的情况下进行开发是一个好处，这让他只能专注于最重要的事情。最终，他花了2、3个月的时间完成了BugTower的MVP（Minimum Viable Product）。

MVP发布后，因为要尽快找到用户，所以作者暂时放弃了长期的流量策略，比如SEO。他用Google Adwords投放了搜索引擎广告，每天花费大概15-20美金，这为BugTower带来一些用户，但是对他来说太贵了。另外，他还在一些论坛做了发布。尤其是在Quora，许多人询问有什么“简单的bug跟踪工具”，他就回答BugTower，这为产品带来了许多关注，是BugTower获取新用户的一个稳定的流量来源。

BugTower最初包含了一个过于慷慨的免费套餐，以至于很多用户一直在使用免费版，没有升级的需要。后来他去掉了免费版，因为他需要知道用户是否愿意为BugTower付费，如果不愿意，那就要及时止损。结果证明用户愿意为BugTower付费，2017年3月，BugTower的月利润达到842美金。

有趣的是，他并没有把BugTower拿给公司的客户使用，因为他不想Push这个业余项目。

讨论：

1. 很多Maker都会“出于自己的需求”去做项目，这个不是说通过自己的需求去发现用户的需求。而是为了表达自己想法、表现自己的能力，去做一个没有人用的产品，除了“表达”之外没有解决任何问题。当然对于自己的兴趣，去实现它也无可厚非，既能取悦自己，又能锻炼能力和积累经验。但是一定要在一开始的时候就认识到这两种项目的区别，不要把自己的“表达需求”当成用户的“索取需求”。
2. 还有很多Maker把自己的热情全部投放在“做出产品”的过程中，他们很享受这个过程，但并没有太多考虑推广的问题。实现产品消耗了他们大部分的热情，简单地在网上发布后，如果反响不好，也就没什么热情继续了。这种情况也是需要我们警惕的。“酒香不怕巷子深”的逻辑适用于资源匮乏的时代，而在互联网时代，连实物商品都可以在几天之内被快递跨越整个中国地运送，更何况是虚拟产品。
3. 然而对于个人项目来说，1个人既要实现产品，又要推广产品。这不仅仅是工作量的问题，更困难的是这里面涉及到思维模式的转换。实现产品和推广产品需要的是两种不同的思维模式，这一秒钟还在为实现一个功能苦苦思考，下一秒钟又要放下未完成的代码，去考虑如何推广，这种思维模式的不断切换会导致无法深度思考，结果可能使工作流于表面，效果不大。作者建议留出大段的时间（如几天）来专注于某项工作，某段时间只专注实现产品，另一段时间则只专注推广产品。

想要了解更多，请查看：
How I Finally Launched a Side Project and Grew It to $800/mo – IndieHackers

查看其他案例，请点击：“每天1个黑客案例”文章目录

本篇是“每天1个黑客案例”系列文章的第26篇，每工作日更新。

产品名称：Kernl

产品简介：

帮助WordPress付费主题和插件的开发者向他们的用户推送更新。

WordPress资源库中的主题和插件都可以通过WordPress自动推送新版本，而付费主题和插件则需要开发者自行发布新版本，Kernl就是帮助这些开发者解决这个问题。

发布时间：2015

运营渠道：

Kernl.us、Kernl.us Blog、Twitter

流量概况：

截止2018年10月，累计为279个主题和665个插件进行了1,179,320次更新。

Kernl.us网站流量很小。

盈利方式：

• 付费订阅模式

盈利能力：$920/月（2018.9）。

作者：

Jack Slingerland（博客、Twitter），1998年就开始从事互联网开发工作。

想法&MVP&启动：

2010年，作者在一家营销机构做WordPress工程师，经常需要人工为客户的网站上传主题和插件的新版本，他觉得这实在太麻烦了。当时他曾着手解决这个问题，但因为当时生活上有很多事情，所以就停下了。当时写的代码是后来的Kernl的前身。

2015年，他想找一个业余项目来帮助自己学习些新的技术，他想起了这个点子。当时市场上只有一个产品跟他的想法一样，所以他马上着手开干了。（后来作者觉得他还是太草率了，应该多做一些市场验证，但他当时并不是打算赚钱，只是为了学一些新技术顺便解决这个自己遇到的问题。）

作者利用业余时间制作MVP（Minimum Viable Product），一共花了4周的时间。他尽力只做最少的功能，专注于为主题和插件推送更新，他认为任何别的功能都会让他分心。

他在Hacker News和reddit的WordPress板块发布了alpha版本，免费，但是他告诉用户Kernl不会永远免费，两者都为他带来了一些注册。除此之外，他花了1个月的时间在Twitter上找到Kernl的目标用户，并不断地和他们交流。他还尝试了Google Adwords，但是转化效果很差。

alpha版本的任务是测试新功能，找bug，获得用户的反馈。当作者觉得对于产品的功能完全满意的时候，他决定开始beta版本，与alpha版本的区别就是不会再加入任何新的功能。beta版本的任务是增加稳定性，测试覆盖范围，并将用户转化为付费用户。

beta版向付费版的转化非常直接，作者创建了Stripe帐户，给之前所有的用户15天的免费试用期，不需要选套餐不需要提供信用卡。试用期结束时，有很多用户付费，在第1个月获利150美金。

2018年9月，Kernl的月利润达到920美金。

讨论：

1. 自己的需求，很可能也是别人的需求，这时，自己就是产品的用户，更能明白需要创造什么样的产品、需要解决什么样的问题。
2. 专注解决最核心的问题，做少，而不是做多，推荐了解混沌大学李善友解读的“第一性原理”。

想要了解更多，请查看：
Shipping Fast and Growing My Side Project to $550/mo – IndieHackers
Continuous Deployment of WordPress Plugins Using Kernl – Re-Cycled Air
Kernl Goes Beta! – Re-Cycled Air
0 to 1 Million: Scaling my side project to 1 million requests a day – Re-Cycled Air

查看其他案例，请点击：“每天1个黑客案例”文章目录