放弃你的代码，而不是你的时间
开源软件
![](/data/attachment/album/201711/24/070812nzvnszsdnnsp7plq.jpg)


作为软件开发人员，我认为我们可以认同开源代码<sup> 注1</sup> 已经[改变了世界](https://www.wired.com/insights/2013/07/in-a-world-without-open-source/)。它的公共性质去除了壁垒，可以让软件可以变的最好。但问题是，太多有价值的项目由于领导者的精力耗尽而停滞不前：



> 
> “我没有时间和精力去投入开源了。我在开源上没有得到任何收入，所以我在那上面花的时间，我可以用在‘生活上的事’，或者写作上……正因为如此，我决定现在结束我所有的开源工作。”
> 
> 
> —— [Ryan Bigg，几个 Ruby 和 Elixir 项目的前任维护者](http://ryanbigg.com/2015/11/open-source-work)
> 
> 
> 



> 
> “这也是一个巨大的机会成本，由于我无法同时学习或者完成很多事情，FubuMVC 占用了我很多的时间，这是它现在必须停下来的主要原因。”
> 
> 
> —— [前 FubuMVC 项目负责人 Jeremy Miller](https://jeremydmiller.com/2014/04/03/im-throwing-in-the-towel-in-fubumvc/)
> 
> 
> 



> 
> “当我们决定要孩子的时候，我可能会放弃开源，我预计最终解决我问题的方案将是：核武器。”
> 
> 
> —— [Nolan Lawson，PouchDB 的维护者之一](https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/)
> 
> 
> 


我们需要的是一种新的行业规范，即项目领导者将*总是*能获得（其付出的）时间上的补偿。我们还需要抛弃的想法是， 任何提交问题或合并请求的开发人员都自动会得到维护者的注意。


我们先来回顾一下开源代码在市场上的作用。它是一个积木。它是[实用软件](https://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html)，是企业为了在别处获利而必须承担的成本。如果用户能够理解该代码的用途并且发现它比替代方案（闭源专用、定制的内部解决方案等）更有价值，那么围绕该软件的社区就会不断增长。它可以更好，更便宜，或两者兼而有之。


如果一个组织需要改进该代码，他们可以自由地聘请任何他们想要的开发人员。通常情况下[为了他们的利益](https://tessel.io/blog/67472869771/monetizing-open-source)会将改进贡献给社区，因为由于代码合并的复杂性，这是他们能够轻松地从其他用户获得未来改进的唯一方式。这种“引力”倾向于把社区聚集在一起。


但是它也会加重项目维护者的负担，因为他们必须对这些改进做出反应。他们得到了什么回报？最好的情况是，这些社区贡献可能是他们将来可以使用的东西，但现在不是。最坏的情况下，这只不过是一个带着利他主义面具的自私请求罢了。


有一类开源项目避免了这个陷阱。Linux、MySQL、Android、Chromium 和 .NET Core 除了有名，有什么共同点么？他们都对一个或多个大型企业具有*战略性重要意义*，因为它们满足了这些利益。[聪明的公司商品化他们的商品](https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/)，没有什么比开源软件便宜的商品了。红帽需要那些使用 Linux 的公司来销售企业级 Linux，Oracle 使用 MySQL 作为销售 MySQL Enterprise 的引子，谷歌希望世界上每个人都拥有电话和浏览器，而微软则试图将开发者锁定在平台上然后将它们拉入 Azure 云。这些项目全部由各自公司直接资助。


但是那些其他的项目呢，那些不是大玩家核心战略的项目呢？


如果你是其中一个项目的负责人，请向社区成员收取年费。*开放的源码，封闭的社区*。给用户的信息应该是“尽你所愿地使用代码，但如果你想影响项目的未来，请*为我们的时间支付*。”将非付费用户锁定在论坛和问题跟踪之外，并忽略他们的电子邮件。不支付的人应该觉得他们错过了派对。


还要向贡献者收取合并非普通的合并请求的时间花费。如果一个特定的提交不会立即给你带来好处，请为你的时间收取全价。要有原则并[记住 YAGNI](https://martinfowler.com/bliki/Yagni.html)。


这会导致一个极小的社区和更多的分支么？绝对。但是，如果你坚持不懈地构建自己的愿景，并为其他人创造价值，他们会尽快为要做的贡献而支付。*合并贡献的意愿是[稀缺资源](https://hbr.org/2010/11/column-to-win-create-whats-scarce)*。如果没有它，用户必须反复地将它们的变化与你发布的每个新版本进行协调。


如果你想在代码库中保持高水平的[概念完整性](http://wiki.c2.com/?ConceptualIntegrity)，那么限制社区是特别重要的。有[自由贡献政策](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)的无领导者项目没有必要收费。


为了实现更大的愿景，而不是单独为自己的业务支付成本，而是可能使其他人受益，去[众筹](https://poststatus.com/kickstarter-open-source-project/)吧。有许多成功的故事：


* [Font Awesome 5](https://www.kickstarter.com/projects/232193852/font-awesome-5)
* [Ruby enVironment Management (RVM)](https://www.bountysource.com/teams/rvm/fundraiser)
* [Django REST framework 3](https://www.kickstarter.com/projects/tomchristie/django-rest-framework-3)


[众筹有局限性](http://blog.felixbreuer.net/2013/04/24/crowdfunding-for-open-source.html)。它[不适合](https://www.indiegogo.com/projects/geary-a-beautiful-modern-open-source-email-client#/)[大型项目](http://www.itworld.com/article/2708360/open-source-tools/canonical-misses-smartphone-crowdfunding-goal-by--19-million.html)。但是，开源代码也是实用软件，它不需要雄心勃勃、冒险的破局者。它已经一点点地[渗透到每个行业](http://www.infoworld.com/article/2914643/open-source-software/rise-and-rise-of-open-source.html)。


这些观点代表着一条可持续发展的道路，也可以解决[开源的多样性问题](http://readwrite.com/2013/12/11/open-source-diversity/)，这可能源于其历史上无偿的性质。但最重要的是，我们要记住，[我们一生中只留下那么多的按键次数](http://keysleft.com/)，而且我们总有一天会后悔那些我们浪费的东西。


* 注 1 ：当我说“开源”时，我的意思是代码[许可](https://choosealicense.com/)以某种方式来构建专有的东西。这通常意味着一个宽松许可证（MIT 或 Apache 或 BSD），但并非总是如此。Linux 是当今科技行业的核心，但是是以 GPL 授权的。


感谢 Jason Haley、Don McNamara、Bryan Hogan 和 Nadia Eghbal 阅读了这篇文章的草稿。




---


via: <http://wgross.net/essays/give-away-your-code-but-never-your-time>


作者：[William Gross](http://wgross.net/#about-section) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
As software developers, I think we can agree that open-source1 code has [transformed the world](https://www.wired.com/insights/2013/07/in-a-world-without-open-source/). Its public nature tears down the walls that prevent some pieces of software from becoming the best they can be. The problem is that too many valuable projects stagnate, with burned-out leaders:

“I do not have the time or energy to invest in open source any more. I am not being paid at all to do any open source work, and so the work that I do there is time that I could be spending doing ‘life stuff’, or writing…It’s for this reason that I've decided to end all my engagements with open source effective today.”

—

[Ryan Bigg, former maintainer of several Ruby and Elixir projects]“It’s also been a massive opportunity cost because of all the things I haven’t learned or done in the meantime because FubuMVC takes up so much of my time and that’s the main reason that it has to stop now.”

—

[Jeremy Miller, former project lead of FubuMVC]“When we decide to start having kids, I will probably quit open source for good…I anticipate that ultimately this will be the solution to my problem: the nuclear option.”


What we need is a new industry norm, that project leaders will *always* be compensated for their time. We also need to bury the idea that any developer who submits an issue or pull request is automatically entitled to the attention of a maintainer.

Let’s first review how an open-source code base works in the market. It is a building block. It is [utility software](https://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html), a cost that must be incurred by a business to make profit elsewhere. The community around the software grows if users can both understand the purpose of the code and see that it is a better value than the alternatives (closed-source off-the-shelf, custom in-house solution, etc.). It can be better, cheaper, or both.

If an organization needs to improve the code, they are free to hire any developer they want. It’s usually [in their interest](https://tessel.io/blog/67472869771/monetizing-open-source) to contribute the improvement back to the community because, due to the complexity of merging, that’s the only way they can easily receive future improvements from other users. This “gravity” tends to hold communities together.

But it also burdens project maintainers since they must respond to these incoming improvements. And what do they get in return? At best, a community contribution may be something they can use in the future but not right now. At worst, it is nothing more than a selfish request wearing the mask of altruism.

One class of open-source projects has avoided this trap. What do Linux, MySQL, Android, Chromium, and .NET Core have in common, besides being famous? They are all *strategically important* to one or more big-business interests because they complement those interests. [Smart companies commoditize their complements](https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/) and there’s no commodity cheaper than open-source software. Red Hat needs companies using Linux in order to sell Enterprise Linux, Oracle uses MySQL as a gateway drug that leads to MySQL Enterprise, Google wants everyone in the world to have a phone and web browser, and Microsoft is trying to hook developers on a platform and then pull them into the Azure cloud. These projects are all directly funded by the respective companies.

But what about the rest of the projects out there, that aren’t at the center of a big player’s strategy?

If you’re the leader of one of these projects, charge an annual fee for community membership. *Open source, closed community.* The message to users should be “do whatever you want with the code, but *pay us for our time* if you want to influence the project’s future.” Lock non-paying users out of the forum and issue tracker, and ignore their emails. People who don’t pay should feel like they are missing out on the party.

Also charge contributors for the time it takes to merge nontrivial pull requests. If a particular submission will not immediately benefit you, charge full price for your time. Be disciplined and [remember YAGNI](https://martinfowler.com/bliki/Yagni.html).

Will this lead to a drastically smaller community, and more forks? Absolutely. But if you persevere in building out your vision, and it delivers value to anyone else, they will pay as soon as they have a contribution to make. *Your willingness to merge contributions is the scarce resource.* Without it, users must repeatedly reconcile their changes with every new version you release.

Restricting the community is especially important if you want to maintain a high level of [conceptual integrity](http://wiki.c2.com/?ConceptualIntegrity) in the code base. Headless projects with [liberal contribution policies](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source) have less of a need to charge.

To implement larger pieces of your vision that do not justify their cost for your business alone, but may benefit others, [crowdfund](https://poststatus.com/kickstarter-open-source-project/). There are many success stories:

[Crowdfunding has limitations](http://blog.felixbreuer.net/2013/04/24/crowdfunding-for-open-source.html). It [doesn’t work](https://www.indiegogo.com/projects/geary-a-beautiful-modern-open-source-email-client#/) for [huge projects](http://www.itworld.com/article/2708360/open-source-tools/canonical-misses-smartphone-crowdfunding-goal-by--19-million.html). But again, open-source code is utility software, which doesn’t need ambitious, risky game-changers. It has already [permeated every industry](http://www.infoworld.com/article/2914643/open-source-software/rise-and-rise-of-open-source.html) with only incremental updates.

These ideas represent a sustainable path forward, and they could also fix the [diversity problem in open source](http://readwrite.com/2013/12/11/open-source-diversity/), which may be rooted in its historically-unpaid nature. But above all, let’s remember that we only have [so many keystrokes left in our lives](http://keysleft.com/), and that we will someday regret the ones we waste.



1 *When I say “open source”, I mean code licensed in a way that it can be used to build proprietary things. This usually means a permissive license (MIT or Apache or BSD), but not always. Linux is the core of today’s tech industry, yet it is licensed under the GPL.*

Thanks to Jason Haley, Don McNamara, Bryan Hogan, and Nadia Eghbal for reading drafts of this.