Bountysource CEO 谈论开源众筹和给开发者的赏金

还没有读者喜欢这篇文章。
Hearts, stars, and dollar signs

Opensource.com

大约十年前,两位朋友着手为开源软件创建一个完整的项目管理平台,名为 Bountysource。 那年是 2004 年,这两位朋友是 Warren Konkel 和 David Rappo,他们的愿景包括创建代码仓库、文件托管、问题跟踪和赏金支持。

两人花了几个月时间构建基本功能,但随后其他项目和工作妨碍了他们。 Konkel 后来成为 LivingSocial 的第一位员工,而 Rappo 则担任《吉他英雄》、《变形金刚》和《小龙斯派罗》等视频游戏的制作人。 Bountysource 联合创始人兼 CEO Warren Konkel。

朋友们去年年底重新联系,时机似乎适合重新审视 Bountysource 的概念。 Konkel 和 Rappo 查看了他们之前构建的内容,看看哪些仍然相关,并决定从零开始,于 2013 年重新推出 Bountysource,作为一个开源软件的资助平台。 现在,Bountysource 没有构建自己的项目管理平台,而是与开发者已在使用的服务(如 GitHub 和 Bugzilla)集成,同时专注于众筹。

Konkel 说,自今年早些时候推出以来,该网站上已发布了约 20,000 美元的赏金,其中 10-20% 已被领取。 许多其他筹款活动也在该网站上发起,其中近十几个超过了最初的目标。 该网站在短短的历史中最成功的筹款活动是 JS-Git,筹集了 34,596 美元 ,这在很大程度上归功于 Mozilla 和 Adobe 的慷慨捐助。

该网站使用“灵活资助”模式,这意味着开发者可以收集筹集到的所有资金,而无需考虑他们的资助目标。 该网站还允许用户为其项目的未解决问题或功能请求资助赏金,吸引开发者创建解决方案并领取赏金。

在本次采访中,Bountysource 联合创始人兼 CEO Warren Konkel 谈到了该网站的新重点,他计划如何使用 该网站最近获得的 110 万美元投资,并为考虑众筹其下一个项目的开发者提供建议。 

谈谈您为什么想要为开发者提供筹款渠道,而开源项目已经在 Kickstarter 和 Indiegogo 等网站上取得了成功。

虽然 Kickstarter 和 Indiegogo 上确实有许多成功的开源筹款活动,但我们并不认为它们是直接竞争对手。 这些平台作为实体消费品和技术的预售模式非常有效,但我们认为开源软件需要一种更好的资助模式,这种模式更符合软件的构建方式。 我们将筹款活动视为开源项目生命周期中的一小步,而是专注于在开发者和支持者之间建立长期关系。 当有人支持筹款活动时,他们很可能会支持后续的筹款活动或创建赏金。

Bountysource 的最终目标是什么? 您希望公司在未来几年内以什么而闻名?

我们希望 Bountysource 成为开源开发者可以以此为生的平台,任何人都可以在他们使用的开源项目中花钱加速开发。 鉴于开源软件已经高度众包,我们认为众筹是自然的延伸。

随着我们的成长,我们希望为全球开发者提供他们继续改进开源软件所需的所有工具。 这些工具可以是任何东西,从联合办公空间和笔记本电脑到教育和培训。 在企业方面,除了现有员工和承包商外,我们希望 Bountysource 被视为一种永久资源,可以帮助公司更有效地将资金投入开源。 很可能如果一家公司需要某个功能,其他公司也需要,而众筹经济可以发挥作用。

您最近获得了 110 万美元的投资(恭喜!)。 您能否谈谈您是如何获得这笔资金的,以及您计划如何使用它?

谢谢! 我的大部分职业生涯都是软件开发者,所以转型为 CEO 角色是一次有趣的旅程。 很早就清楚的是,Bountysource 具有很大的潜力,但需要一个优秀的团队来执行整个愿景。 一旦我们决定想要外部投资者,剩下的就只是解决问题了。 我们需要一份宣传册和一个清晰的愿景,所以我们一遍又一遍地迭代,直到我们对它感到满意。 然后我们需要尽可能多地与投资者交谈,以便找到合适的投资者。 然后我们需要逐行处理所有的法律和财务文件。 整个过程最终花了几个月的时间。 我们计划使用这些资金来壮大团队并加大营销力度。

您是否遇到过开发者或公司因有时与要钱相关的耻辱感而犹豫发布或回应赏金?

是的,我们有,我们认为这种犹豫是合理的。 然而,金钱已经在开源领域存在了几十年。 许多开源贡献者由他们的雇主支付工资来从事开源工作。 许多项目已经有捐赠按钮。 许多开源开发者围绕他们的项目开展咨询业务。 最终,开源贡献背后的动机已经大相径庭。 理解这一切的最简单方法是关注代码本身。 归根结底,如果高质量的代码被贡献给一个项目,那么代码背后的激励措施应该是无关紧要的。

您是否看到赏金所针对的问题类型有什么模式? 例如,您是否看到通常针对错误修复而不是功能请求发布的赏金更多?

一般来说,针对错误的赏金比针对功能请求的赏金更多。 这似乎是正常的行为,因为开发者经常会遇到错误并希望立即解决。 也就是说,随着人们越来越熟悉该平台,针对功能请求的赏金肯定在增长。 通常情况下,赏金会导致大量的评论,最终充实了功能请求背后的细节。 通过赏金,开发者可以快速了解社区最感兴趣改进的内容。

您会给正在考虑为其项目发起筹款活动的开发者提供什么建议?

筹款活动需要大量的计划和社区支持; 尽早开始吧! 请一位非技术朋友给您反馈。 在发布筹款活动之前,收集社区对您筹款活动每个细节的反馈。 筹款活动文本是否准确解释了您将交付的内容? 您是否清楚地说明了项目的需求? 您是否计划好了回报? 您是否有计划宣传您的筹款活动? 这些都是您在“上线”筹款活动之前应该回答的问题。 此外,不要犹豫与 Bountysource 团队联系,我们很乐意帮助您完成从开始到结束的整个过程。

还有什么我没有问到但您想补充或指出的吗?

在下个月内,我们将推出“赏金预算”计划,该计划将允许组织设定预算,并让他们的整个工程团队轻松访问发布赏金。 几乎所有开发者都将开源项目作为其日常工作流程的一部分,而 Bountysource 为公司提供了一种有效的方式,可以将资金投入到错误或功能请求中,同时让他们的开发者专注于内部优先事项。

我们已经在与 Gust 测试这个概念,Gust 是一个管理早期投资的全球平台。 他们给他们的工程师每月预算,让他们在他们在工作中使用的开源项目上创建赏金。 我们希望组织能够开始看到这其中的价值,并持续支持项目。

标签
User profile image.
Ginny Hamilton 曾是 EnterprisersProject.com 的社区经理,EnterprisersProject.com 是一个专注于 CIO 和 IT 领导者如何通过信息技术创造商业价值的在线出版物和社区。 Ginny 曾是一名记者,热衷于当地政治、新闻、技术和社交媒体。

5 条评论

开源正在统治。 但我认为这是必不可少的。 所有软件都应该是免费的,我甚至不想为我的 windows 付费。 谢谢

<ul class=field><li class=field-label-inline><a href="http://www.verveinc.com/ca/">free online gambling</a> </li> </ul>

嗯,我是 LilyPond 上的一位“众筹”开发者。 我们曾经有一个赏金系统,但效果不佳。 其中一个问题是赏金规模和总任务之间通常存在不匹配。 很多时候,“总任务”的最大部分是把赏金承诺者拉拢过来(大多数人早就解决了他们遇到的问题),并让他们相信你实际上解决了他们的问题。

但我在这里看到的最大问题是,理智的开发不是专注于解决问题,而是专注于避免问题,从小处来说是小心谨慎,从大处来说是致力于架构,将事物充分且稳健地分离,以至于解决一个问题不容易立即引发下一个问题。

如果你免费得到一辆汽车,而这辆汽车的资金来自让你支付维修和附加费用,那么如果这种商业模式实际上是可持续的,那么你不太可能长期对它感到满意。 最好的工作,但成果最少的,是那些没有留下任何愿望的工作,除了那些由于干净、布局良好且有文档记录的设计以及稳健的工作而容易被用户自己解决的愿望。

但这并没有为赏金留下多少空间。

现在我并不是说我对我在这些方面取得的进展感到满意,但我正在使用的“商业模式”基本上是没有赏金的。 人们付钱给我,但对我做什么没有发言权,只要他们对我为他们的钱获得了<em>一些东西</em>感到满意,即使那不是他们自己会想到的要求。

缺点是人们不能真正称之为可持续模式:没有足够的资金来支付项目上正在发生的所有工作,当然,许多对项目足够认真以至于贡献我生活的人也投入了大量的时间以及金钱。

当我们谈论众包或众筹时,难道不应该只是为所需的工作(尤其是开发工作)筹集资金,并在达到资金目标时开始工作吗? 我对 kanev.com 的家伙们的做法印象深刻 <a href="http://kanev.com/development" target="_blank">开发众筹</a>

福特不是说过“如果我问人们他们想要什么,他们会希望要一匹更快的马”吗?

从事独立微观管理和微观资助的任务并不一定会带来良好的架构和设计决策。

为什么没有主要的众筹项目来修补 Wine,使其能够与主要的 Windows 应用程序(如 Adobe 的 Photoshop 和 Illustrator)一起使用?

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 3.0 Unported License 获得许可。
© . All rights reserved.