从开源软件开发中体会到的心得
Mitchell Hashimoto 是一名开源软件工程师。由他托管到 GitHub 上的 开源项目 Vagrant，是一个用于创建和部署虚拟化开发环境的工具。近日，Mitchell撰文讲述了在开发 Vagrant 的过程中学到的有关开源软件开发的一些心得。
以下为原文文章：
把 Vagrant 做成一个相当成功的开源项目，这花费了我不少时间。但我从中也学到很多。此前，我并没有看过很多关于开源项目学习的文章，但由于这些知识很重要，因此我想和大家分享一下我的一些关于开源软件的心得。这些心得不仅和软件开发有关，还包含了作为一个开源项目的维护者，如何做好市场推广等方面的内容。
一、和软件开发相关的心得
下面这些是关于软件开发方面的心得：
1、态度友好
这一点是最重要的。有时，你可能会听到一个糟糕的创意，收到的pull requests里面尽是劣质的代码，甚至还要忍受用户的抱怨，尽管他们没有花一分钱。当你遇到这些情况，请记住： 即使用户不一定尊重你，你也要尊重用户。我曾经只因为一件事情而大动肝火，但是现在，我可以很自豪的说：无论遇到以上哪种情况，我的态度都会很友好。对用户有一个友好的态度是非常重要的。因为如果你的态度很友好，你会给别人留下平易近人的印象。而用户也会因此向你寻求帮助或参与到你的项目中来，做出贡献。这也正是开源运动的精髓所在。
2、不要为项目设置太过复杂的规则
除非你的项目很庞大，否则你不用太担心贡献者的编码风格。为你的项目设置过于复杂的规则将阻碍开发者参与到项目中来。空格、缩进等等这些编码风格所造成的问题都可以很容易的通过人工来修改。因此你无需为贡献者的编码风格不同而烦恼。相反，你应该感到高兴并接受这些真正优秀的贡献。好了，现在你该知道如何改进你的开源项目了吧？这很简单，接受这些优秀的贡献，做出改变，然后pull request。我一点都不担心编码风格、测试会带来问题。我很乐意看到这些贡献。
3、开发文档的编写是关键
虽然我没有证据证明这一点，但我可以毫不夸张的说：所有首次使用 Vagrant 的用户表示他们之所以选择Vagrant，是因为它的文档很优秀。虽然世界上最烦人的事可能就是编写开发文档，但如果你不能及时的编写文档，那么项目就会存在失败的风险。此外，别忘了开放文档的权限，以便于开发者能方便参与。
4、有明确的沟通方式
IRC（互联网中继聊天）、邮件、论坛……交流方式不限，但你需要为用户提供一个明确的、能得到及时回复（通常在48小时以内效果较好）的沟通方式用以表达他们的观点。对于Vagrant，我总是通过一个IRC频道和邮箱来和用户保持联系，并且效果很好。同时，如果用户和你沟通的方式越多，他们就会越信任你的项目。
5、你并不是什么都懂
有时候，你不可避免的会收到一些功能改进的请求，即便这些功能没有用。对于项目管理者来说，重要的工作是为这个项目指明发展方向，而不是专注于某些微观的具体的功能。这项功能是否于项目的发展相适应？它对用户有用吗？甚至是它对你有用吗？你需要思考这些问题来指导项目的发展。因此，你需要打开思路。因为你的用户比你清楚他们真正想要的功能是什么。但是，别忘了，你比其他人更清楚项目的发展方向。
二、和市场推广相关的心得
现在，你完成了一个软件项目的开发。但是如何让用户了解你的项目呢？下面是我关于市场推广方面的一些心得：
1、Hacker News
Hacker news 社区喜欢尝试新鲜事物，而且那里有很多的开发者。因此，你可以把项目提交到那里，同时标明你已经准备好回答任何问题。态度友好一些，因为你可能会被用户诘难。
2、和优秀的博客站点接触
几乎在每一个社区，特别是Ruby社区里有很多优秀的博客。它们乐于分享用某项特殊的语言或方法开发的很酷的项目。找到这些博客，并和博主联系，邀请他们参与到你的项目中来。这样做会有2个益处：如果他们愿意参与，那么你的项目不仅能得到更多的关注，而且你的想法也能得到更好地检验。
3、在聚会上做演讲（参加正式会议之前）
参加一些当地对你的项目感兴趣的聚会，并发表演讲。如果你是第一次参加，可以提前为演讲做好准备。不要通过在项目里添加手册的方法来宣讲你的项目，你应该把这个项目的发展方向当面展现给公众。如果你是第一次做演讲，就不要立即参加某些正式的会议，因为公众会记住你出丑的样子，下一次想要再做演讲就会变得困难。选择在聚会上做演讲则是一个比较好的方式。而且，在聚会上，你可以从真正关心项目的开发者那里得到一些重要的反馈。
4、在正式会议上做演讲
参加过一些聚会之后，就可以在区域会议上发言了。这些会议通常规模较小，但是主题很好，而且与会人员不会因为你糟糕的谈吐而轻视你。同时，大型会议也不可能允许你就一个新的项目发表演讲。好了，现在你有机会站在众人面前发表一场40分钟的演讲。在演讲之前，要确保你做好了准备。演讲时注意微笑，向公众展示你的理想并记下你收到的建议。
5、在大型会议上做演讲
现在，我要讨论的是像VelocityConf 或 QCon这种类型的大型会议。主办方将会让你在更多的人群前发表演讲（通常在500人以上），而且听众都是极其优秀的业内人士。如果你的项目对于听众来说较为陌生的话，你最好准备一个成功的案例来说明。而且这个案例最好来自于用户，这样才能证明项目的优秀性能。这些大型会议通常都会吸引一些重量级人士的参与（CIO、技术副总裁等等）。
三、有关软件工程方面的知识
在软件发布之前，有很多工作要做，一下是我关于软件工程方面的心得：
1、测试
我不认为这个有必要详说，但因为它是如此的重要，所以我还是要再发表一下看法。测试不是可有可无的工作。你必须及早的进行，并经常测试。此外，不要忘了集成测试。我曾做过很多的集成测试，而它们在 Vagrant 发布之前都是最有价值的测试。虽然单元测试能很快的捕获基本的错误，但是集成测试却能在版本发布之前找到最重要的错误。
2、支持Windows ASAP
Vagrant对 Windows系统的支持非常棒。虽然 Vagrant 现在功能很强大，但之前它却是一个噩梦。因为最初有很多开发者都不在 Windows 平台上工作，代码中多处函数都无法在 Windows 上运行。当时我简直不敢想象为了支持 Windows 我们要做多少工作，因为你要在基础代码中做出大量的修改。此外，还有很多 Windows 的开发者想要使用 Linux 风格的工具。
3、避免使用外部函数调用接口（FFI）
这更多是Ruby方面的事。Ruby的FFI库没有C标准库那么简单。我曾经在FFI上花了18个月的时间。或许我是最频繁使用FFI的一员？让我头疼的是FFI库定期升级更新，甚至更行到发布的补丁版本。有时候我清醒的发现仅仅是由于FFI的编译问题，Vagrant就不能在 Windows 上正常运行了。此外，我还发现在使用FFI的时候，callback函数的运行和内存管理变得很困难。在Vagrant 0.9版本以前，都存在严重的内存泄露问题。最后，我放弃了FFI，改用其它更好的库，现在，Vagrant又可以调用C标准库了。
4、和参与维护的开发者交朋友
每一个对某个函数库了解甚深的开发者都会在那个函数库里找到Bug。纵观整个Vagrant的开发历程，我曾在每个使用过的dependency里发现过Bug。我和所有的参与维护的开发者都有良好的朋友关系，因此，当出现问题时，我能很快的问：“这是你的Bug吗？要多长时间才能修复它？”。最坏的结果可能是在一个dependency里有一个Bug，但维护者既不修复它也不发布更新后的版本。
虽然我依然有很多知识要学习，但希望这些点滴经验能帮到那些正在做开源工作的开发者。
英文原文： Lessons Learned Building Open Source Software
以下为原文文章：
把 Vagrant 做成一个相当成功的开源项目，这花费了我不少时间。但我从中也学到很多。此前，我并没有看过很多关于开源项目学习的文章，但由于这些知识很重要，因此我想和大家分享一下我的一些关于开源软件的心得。这些心得不仅和软件开发有关，还包含了作为一个开源项目的维护者，如何做好市场推广等方面的内容。
一、和软件开发相关的心得
下面这些是关于软件开发方面的心得：
1、态度友好
这一点是最重要的。有时，你可能会听到一个糟糕的创意，收到的pull requests里面尽是劣质的代码，甚至还要忍受用户的抱怨，尽管他们没有花一分钱。当你遇到这些情况，请记住： 即使用户不一定尊重你，你也要尊重用户。我曾经只因为一件事情而大动肝火，但是现在，我可以很自豪的说：无论遇到以上哪种情况，我的态度都会很友好。对用户有一个友好的态度是非常重要的。因为如果你的态度很友好，你会给别人留下平易近人的印象。而用户也会因此向你寻求帮助或参与到你的项目中来，做出贡献。这也正是开源运动的精髓所在。
2、不要为项目设置太过复杂的规则
除非你的项目很庞大，否则你不用太担心贡献者的编码风格。为你的项目设置过于复杂的规则将阻碍开发者参与到项目中来。空格、缩进等等这些编码风格所造成的问题都可以很容易的通过人工来修改。因此你无需为贡献者的编码风格不同而烦恼。相反，你应该感到高兴并接受这些真正优秀的贡献。好了，现在你该知道如何改进你的开源项目了吧？这很简单，接受这些优秀的贡献，做出改变，然后pull request。我一点都不担心编码风格、测试会带来问题。我很乐意看到这些贡献。
3、开发文档的编写是关键
虽然我没有证据证明这一点，但我可以毫不夸张的说：所有首次使用 Vagrant 的用户表示他们之所以选择Vagrant，是因为它的文档很优秀。虽然世界上最烦人的事可能就是编写开发文档，但如果你不能及时的编写文档，那么项目就会存在失败的风险。此外，别忘了开放文档的权限，以便于开发者能方便参与。
4、有明确的沟通方式
IRC（互联网中继聊天）、邮件、论坛……交流方式不限，但你需要为用户提供一个明确的、能得到及时回复（通常在48小时以内效果较好）的沟通方式用以表达他们的观点。对于Vagrant，我总是通过一个IRC频道和邮箱来和用户保持联系，并且效果很好。同时，如果用户和你沟通的方式越多，他们就会越信任你的项目。
5、你并不是什么都懂
有时候，你不可避免的会收到一些功能改进的请求，即便这些功能没有用。对于项目管理者来说，重要的工作是为这个项目指明发展方向，而不是专注于某些微观的具体的功能。这项功能是否于项目的发展相适应？它对用户有用吗？甚至是它对你有用吗？你需要思考这些问题来指导项目的发展。因此，你需要打开思路。因为你的用户比你清楚他们真正想要的功能是什么。但是，别忘了，你比其他人更清楚项目的发展方向。
二、和市场推广相关的心得
现在，你完成了一个软件项目的开发。但是如何让用户了解你的项目呢？下面是我关于市场推广方面的一些心得：
1、Hacker News
Hacker news 社区喜欢尝试新鲜事物，而且那里有很多的开发者。因此，你可以把项目提交到那里，同时标明你已经准备好回答任何问题。态度友好一些，因为你可能会被用户诘难。
2、和优秀的博客站点接触
几乎在每一个社区，特别是Ruby社区里有很多优秀的博客。它们乐于分享用某项特殊的语言或方法开发的很酷的项目。找到这些博客，并和博主联系，邀请他们参与到你的项目中来。这样做会有2个益处：如果他们愿意参与，那么你的项目不仅能得到更多的关注，而且你的想法也能得到更好地检验。
3、在聚会上做演讲（参加正式会议之前）
参加一些当地对你的项目感兴趣的聚会，并发表演讲。如果你是第一次参加，可以提前为演讲做好准备。不要通过在项目里添加手册的方法来宣讲你的项目，你应该把这个项目的发展方向当面展现给公众。如果你是第一次做演讲，就不要立即参加某些正式的会议，因为公众会记住你出丑的样子，下一次想要再做演讲就会变得困难。选择在聚会上做演讲则是一个比较好的方式。而且，在聚会上，你可以从真正关心项目的开发者那里得到一些重要的反馈。
4、在正式会议上做演讲
参加过一些聚会之后，就可以在区域会议上发言了。这些会议通常规模较小，但是主题很好，而且与会人员不会因为你糟糕的谈吐而轻视你。同时，大型会议也不可能允许你就一个新的项目发表演讲。好了，现在你有机会站在众人面前发表一场40分钟的演讲。在演讲之前，要确保你做好了准备。演讲时注意微笑，向公众展示你的理想并记下你收到的建议。
5、在大型会议上做演讲
现在，我要讨论的是像VelocityConf 或 QCon这种类型的大型会议。主办方将会让你在更多的人群前发表演讲（通常在500人以上），而且听众都是极其优秀的业内人士。如果你的项目对于听众来说较为陌生的话，你最好准备一个成功的案例来说明。而且这个案例最好来自于用户，这样才能证明项目的优秀性能。这些大型会议通常都会吸引一些重量级人士的参与（CIO、技术副总裁等等）。
三、有关软件工程方面的知识
在软件发布之前，有很多工作要做，一下是我关于软件工程方面的心得：
1、测试
我不认为这个有必要详说，但因为它是如此的重要，所以我还是要再发表一下看法。测试不是可有可无的工作。你必须及早的进行，并经常测试。此外，不要忘了集成测试。我曾做过很多的集成测试，而它们在 Vagrant 发布之前都是最有价值的测试。虽然单元测试能很快的捕获基本的错误，但是集成测试却能在版本发布之前找到最重要的错误。
2、支持Windows ASAP
Vagrant对 Windows系统的支持非常棒。虽然 Vagrant 现在功能很强大，但之前它却是一个噩梦。因为最初有很多开发者都不在 Windows 平台上工作，代码中多处函数都无法在 Windows 上运行。当时我简直不敢想象为了支持 Windows 我们要做多少工作，因为你要在基础代码中做出大量的修改。此外，还有很多 Windows 的开发者想要使用 Linux 风格的工具。
3、避免使用外部函数调用接口（FFI）
这更多是Ruby方面的事。Ruby的FFI库没有C标准库那么简单。我曾经在FFI上花了18个月的时间。或许我是最频繁使用FFI的一员？让我头疼的是FFI库定期升级更新，甚至更行到发布的补丁版本。有时候我清醒的发现仅仅是由于FFI的编译问题，Vagrant就不能在 Windows 上正常运行了。此外，我还发现在使用FFI的时候，callback函数的运行和内存管理变得很困难。在Vagrant 0.9版本以前，都存在严重的内存泄露问题。最后，我放弃了FFI，改用其它更好的库，现在，Vagrant又可以调用C标准库了。
4、和参与维护的开发者交朋友
每一个对某个函数库了解甚深的开发者都会在那个函数库里找到Bug。纵观整个Vagrant的开发历程，我曾在每个使用过的dependency里发现过Bug。我和所有的参与维护的开发者都有良好的朋友关系，因此，当出现问题时，我能很快的问：“这是你的Bug吗？要多长时间才能修复它？”。最坏的结果可能是在一个dependency里有一个Bug，但维护者既不修复它也不发布更新后的版本。
虽然我依然有很多知识要学习，但希望这些点滴经验能帮到那些正在做开源工作的开发者。
英文原文： Lessons Learned Building Open Source Software