接上篇金钱与开源(part1)

虚拟小费

有一些项目设立了“小费”机制来展现你（对某人）的赏识。我比较熟悉的两个是TipTheWeb和GitTip。我不确定TipTheWeb是否还有人维护。GitTip比较新一些，而且现在看起来更流行。

两者都建立在道德的基础上，TipTheWeb的Eric Ferraiuolo是个非常和善和高尚的人，他们的目标就和字面上看起来一样，为了使互联网变得更好。GitTip的Chad Whitacre看起来同样也是为互联网做一些好事。

给某人一些小费看起来就像是行善。这在你不知道什么是合适的礼物情况下，一种展现对某人爱心和赞誉的方式。能让人在精神上和物质上得到满足。

话虽如此，我仍旧怀疑这种方式能提高项目的创建量。难道程序员仅靠这些捐款就能付得起房租？我肯定是不行的。

金钱肯定是有来源的，所以我不认为完全靠这种方式能支持一个开源项目进行下去。某种程度上，GitTip上的一些人有“真实的工作”，并且决定将一部分钱用来做捐助。在GitTip上给小费，然后希望人们对你负责，这看起来有点尴尬。小费是果而非因，也就是说，“我喜欢你所以才给你小费”，而不是，“我希望你为我做点事情，所以才给你小费”。

我不反对捐助。事实上，我觉得它很重要，这是我们这些有经济自由的人的一种道德需要。然而，我做过计算，尝试找出一种能让我的捐助利益最大化的方式，每个月给某个开发者5美元并不能让我伤筋动骨。这看起来更像是一个游戏，对另一个人表示尊敬和赞扬，并附带一点点金钱奖励。

这与花大价钱雇佣开发者来创造软件不一样。但是缺少了一种交易关系，这里能得到的收益是很少的。做营销的方式林林总总，我不觉得这种方式能有很高的商业价值。为什么不去雇佣这些开发者，然后得到更高的回报呢？

给小费的方式既有趣，又让人感觉愉悦。但是我很怀疑它是否真的能改变世界。这并不能保证你过上无忧无虑的生活，而且我感觉假如你真的靠小费来生活，那么它可能会改变你(编写代码)的初衷。

这让我想到了另一种有前途但是同样存在问题的方式。

奖金

无论何时我们都得对于钱的问题万分小心。很多研究发现事物的动机有外因和内因之分。假如我为了五美元去做一些事情，我可能享受不到免费做这件事的乐趣。就像Merlin Mann说的：“世界上有两种价值：免费，和成本。”

当然，“我将花X美元来请你帮我写Y功能”在软件界是一种通行的方式。大部分情况下，就我经验而言，它并不能取得很好的效果。任何人都不可能给出一个等价的条件。

一旦延期很久，双方都不会满意。通常这个时候甲方和乙方就开始扯皮，事情就杯具了。

BountySource是这个领域的后起之秀，它有一些有趣的特征。“Backers”既可以是个人也可以是公司。利用融资的形式来支付小费的想法很有吸引力，这样你就不必为某个个体负责了。而且，集成Github Issues的想法也很聪明。

但是我仍然十分怀疑BountySource能改造开源软件现有的生态环境。一个显而易见的缺陷就是奖励实在是微乎其微。而且，现在钱被提到了前面，热情就被商业所取代了。

举个例子，我刚刚获知在这个实现SemVer 2.0规范的Issue中有一笔87美元的赏金。

事实是，我已经和其他人一起着手写这样一份规范(在当时还很模糊)。一旦完成，我能遵守规范的唯一方式就是重写整个node-semver。这总共需要两周邹游的时间，包括将改动提交到npm上来让它起作用。

所以，虽然87美元看起来很诱人，但是我不能仅凭87美元来过两个礼拜。就算它有870美元，8700美元甚至87000美元，提高奖金也不是最好的办法。它尽最后的努力来使一个社区满足你的需求。假如社区根本不关心这事，那么他们也不会关心你或你的需求。

奖金机制在这里存在的问题就是，软件有时候并不是一个有着明确边界的产品。增加一个功能看上去更像收养一只小猫，而非投递一件包裹。假如你无论如何都想收养这只小猫，但是有些人想要花钱来让你收养另一只，就算能行，最后也会事与愿违。强扭的瓜不甜，最后可能导致的是一个糟糕的软件。

奖金可能在一个项目负责人希望激励成员找出bug或添加功能的时候有用。但是，项目负责人不可能给出组有的钱来请人开发(假如这样的话，还不如直接雇佣他们了)。假如一个项目负责人简单的声明，“我觉得x功能很有用，欢迎大家来实现它。”这已经起到了激励作用，奖金就完全没有必要了。最理想的情况，就像Mikeal Rogers出钱请人来找bug，这只是一种让人写代码的营销手段。

奖金只有在一个有明确目标的项目中才会起作用，就像查找安全漏洞。漏洞奖励计划发现给予奖金会比直接雇佣一个安全专家来的更行之有效。找出一些其他的有明确胜利目标的场景也是很有意思的。

然而，上面的只是一些例外，而不是常态。公司使用开源软件的时候通常并不会急着要某一个功能，或者在早期就发现一堆的bug。他们会与一些程序要保持联络来让他们的需求得以实现。这并不是明确的要求给程序加某个改动，而是在他们需要的时候，可以保证让程序加上这些特征。就像让某些人随时待命一样。

顾问合同

另一种给开源软件筹款的方式是签订一份顾问合同，用户可以向专家咨询，而专家则会仔细的对待这些问题。这可能包括登陆到某个系统或者临时帮程序员做debug，或解释一些稀奇古怪的错误消息，或检查代码来找出为什么它跑起来会这么奇怪。

Joyent付给我钱就是应为他们需要我来帮忙调试Node和npm的一些问题。

我想这应该是公司给开源软件开发者付钱的最通行的一种做法，相比于雇佣一个专业领域的开发者，这种做法更经济。

公司经常会使用很多不同的开源软件。假如签订顾问成本的开销比雇佣人来专管所有这些软件的成本要小，那么公司就可以从中获得好处了，他们可以花更少的钱，得到更好的服务。

此外，至少在理想情况下，这种激励并不让人反感。在产品中找问题是不可避免的，虽然这并不是很有趣。假如我知道我涉及其中，那么我会尽量写出强健，简单而容易调试的软件。这对每一个人都有好处，即使对于那些不为我的软件花钱的人。

当然，你任然可以发现有些不尽如人意的地方。但是“假如你给我X美元每个月，那么我会在24小时内回你邮件，并且每个月用N小时来解决你的问题。”要比“假如你现在给我X美元，我会在三个月内拿出你要的Y功能(而且不会有错)。”容易理解的多。在我平日的生活中，我仍然能感觉到在做着喜欢的工作，而且能帮助到有困难的用户。金钱是很有吸引力的一个东西，但不是至高无上的。

然而，这种方式任然存在很多问题。

我们的开源软件变得越来越模块化，而且相互依赖，“开发者”会变得很难追踪。这可能很快就会导致相互指责。假如你和某一个依赖我的代码的开发者签了合同，他们可能就会为了修改我的bug而迁怒于我，而且他们通常与我的想法不同。这种“分包”管理的方式看起来并不是很行之有效。

其次，大部分开源软件开发者并不擅长做顾问。擅长Javascript，运维或C语言不表示你就做给出最好的客户支持，或者你该做出那些改动。结果就是，开发者被大公司牵着鼻子走。软件变得越来越大而臃肿。这并不是一件很可怕的事，反正有大公司为它买单。但是它却忽略了中小型公司做需要的效率问题。

我们的软件变得越来越模块化和互相依赖，而且大部分开发者并不擅长推销他们的服务，那么第三个问题产生了。服务提供者必须很清楚明白自己能提供那些服务。比方说，你能对Node提供支持，但是你肯定不能保证对npm中的所有模块提供支持。

在理想世界中，这些都是可以解决的问题。这里有一大堆的问题，而且有无数的社会和技术问题等着人来解决。一个用户怎么可能找到合适的人来解决这些问题？又如何为这些问题公平的买单？你怎么才能避免开发者们在合作问题上起争端呢？

分出合理的技术水平，合理的分配收入，给正确的开发者分配任务，这是一个综合性的复杂问题。假设这不是很难而且现在已经有人能解决这个问题，是不现实的。

未来

我希望开源软件在某一天能被看成是一个“吃香的”职业，尤其是当你并没有在公司里获得一个“真正的”职位时。假如更多的人能享受自由的生活方式，而不用为他们的财政问题担心，这就更好了。这也可能应发更多的有趣的争论，像是为一个项目兼职，或是为开源软件的工作做出一些改变。

在技术行业中，人们始终能找到一起合作或创业的机会，或者给公司打工。我有很多很好的工作经历，通常是在不完全封闭的公司。然而，我并不认为这是让我们作为社会的一员而做出最大贡献的最佳方法。

那些自由软件开发者所得比不上其所付出，这是很可悲的。而更可悲的是某些人对这些做出巨大奉献的开发者的苛求。他们做出了巨大的贡献，而大部分却入不敷出。

大部分人都能做这类工作，而且可能会更有效率。但是，为了满足经济需要，他们最后还是找了份工作，这看起来是一种低效的做法。假如开源软件开发者能获得足够的动力和激励，谁能想象我们的发展会有多迅速？

附录：没有提及的话题

1. 为什么我做开源软件的时候更有创造力也更快乐？

2. 为什么开源软件对技术行业有帮助？

3. 对开放才算开源？“开放源代码” 对比 “开放式开发”

我不能对这些问题做出解答，应为这篇文章已经够长的了。我的目的不是在这里卖开源软件。请在今后的文章中关注这些话题。

参考

Money and Open Source