> * 原文地址：[Why we never thank open source maintainers](https://www.codementor.io/windsonyang/why-we-never-thank-open-source-maintainers-ed0nsw3zd)
> * 原文作者：[Windson Yang](https://www.codementor.io/windsonyang)
> * 译文出自：[掘金翻译计划](https://github.com/xitu/gold-miner)
> * 本文永久链接：[https://github.com/xitu/gold-miner/blob/master/TODO/why-we-never-thank-open-source-maintainers.md](https://github.com/xitu/gold-miner/blob/master/TODO/why-we-never-thank-open-source-maintainers.md)
> * 译者：[LeviDing](https://leviding.com)

# 为什么我们从来不去感谢开源项目维护者

![Why we never thank open source maintainers](https://process.filestackapi.com/cache=expiry:max/resize=width:700/compress/r9dlNLxVS721wAQQJm6q)

你现在可以到 [Thank you, open source](https://www.thankyouopensource.com) 这个网站上为你最喜欢的开源项目写一句感谢的话了。

#### Long Version

下面是我对为什么我们从来不去感谢开源项目维护者的一些看法。

#### 这样的项目我也可以做啊

> “蛤？这项目对我来说也太简单了吧。”
>
> “我一周之内就能做一个更好的版本出来。”

确实，很多人都可以在黑客马拉松（hackathon）中建一个小工具，但是维护一个项目比建立一个项目要困难得多。开源项目维护者不仅仅需要写代码，更多时候还需要：

- 写项目文档；
- 检查 Pull Request；
- 看看大家提的 Issue；
- 为项目增加新功能；
- 在 Stack Overflow 等平台回答关于本项目的问题；
- 在 QQ、微信等用户群里和用户讨论，回答问题。

一个开源项目维护者必须一年到头无偿地做这么多复杂繁琐的工作。

#### 当我们很方便的使用开源项目时，太容易忘记项目维护者的辛苦付出了

我们如何使用一个开源项目：

1. 我们在网上搜索遇到的问题的解决方案；
2. 在一些博客和其他网站上进行搜索；
3. 我们点击这个开源项目的链接，读项目的 README。安装并进行测试。哈哈哈，问题解决了！
4. 我们转而看向了遇到的下一个问题。

开源项目就像水和空气一样，人们只是享受它带来的好处并且习以为常。我们不会对空气或水说感谢，因为我们不知道那是谁造的。但是我们知道是谁创建了这些非常棒的开源项目。但是我们知道这么棒的开源项目是谁维护的啊。

#### 项目维护者们并不在意这些

> 开源项目使用者可能会想：
> 
> “他们不需要这些，他们需要的是 pull request 和能够修复 bug 等实质性工作。”
>
> “我想他们更喜欢收到捐款。”

但是他们真的很在意，[有时候，开源项目维护者真的需要你对他说一声谢谢](https://news.ycombinator.com/item?id=15623604)。当然，如果你能为项目捐款再好不过了，但是我知道的大多数开源项目维护者目的并不是赚钱。他们最终可能赚了钱，但与开发项目的动机相比，顶多算是一个副产品。我注意到，开源项目常常比非开源项目要好。因为最出色的开发者是出于激情和利他主义来开发产品的。如果你没能力或者不想捐钱，你可以给他们写句感谢的话。

#### 我们真的太“忙”了

> “我们正在用双手改变世界。”
> 
> “我的项目必须在一周内启动。”
> 
> “我们每天都有数百封邮件需要回复。”
> 
> “我们只是没有时间。”

这些开源项目有更大的潜力去改变世界；或许其中的哪个项目已经改变了世界。

> Github 在 Rails 上使用 Ruby
> Instagram 使用 django
> 我们很多服务器都在运行着 Linux

可能没有这些开源项目就没有我们现在的这些项目。

十分钟，你可能做不了什么大事。现在社交媒体让我们养成了一种习惯，就是更愿意点击一个 upvote 或者类似的按钮，而不是花十分钟来写一封感谢信。尽管一个好的开源项目可能节省了不仅仅十分钟的时间。我在 ProductHunt 上公开 [www.thankyouopensource.com](https://www.thankyouopensource.com) 这个网站后，很多用户抱怨最低 300 个字符的限制条件。我设置这个条件是想避免像下面这样简单的话：

> “谢谢，你们太棒了。”
> 
> “非常感谢。”
> 
> “我很喜欢你的开源项目。”

我就得这些用户太“忙”了，没空写一封感谢信。但是这对我来说看起来像没有意义的垃圾邮件，我认为读这些就是在浪费时间。我们希望看到的感谢信是处于自愿的而不是义务的。这之间的不同对我们来说显而易见。我们希望维护者们知道我们为什么感谢他们的付出，他们的项目怎么帮助了我们，我们这些发自内心的感谢也是维护者们继续付出的强大动力之一。最重要的是，我们欢迎所有对维护项目感兴趣的人的加入，因为这确实是一件很棒的工作。一旦你成为了维护者，你会在感谢心中看到很多人对你付出的真诚的感谢。我建议在 GitHub 上加一个 **感谢** 的标签，不仅仅是感谢和激励维护者，更是邀请更多的人加入到其中。

#### Final thoughts

Maintainers are the friends we want and the employees companies look for. They have passion, willingness to share, and persistence. They are the real MVP and they deserve a thank-you note.

#### 什么是 [Thank you, open source](https://www.thankyouopensource.com) 🎉

这是一个非官方的，为大家向开源项目作者和维护者表达感谢的平台。同时它还为项目维护者们宣传其他项目提供了一个平台 🤙 


---

> [掘金翻译计划](https://github.com/xitu/gold-miner) 是一个翻译优质互联网技术文章的社区，文章来源为 [掘金](https://juejin.im) 上的英文分享文章。内容覆盖 [Android](https://github.com/xitu/gold-miner#android)、[iOS](https://github.com/xitu/gold-miner#ios)、[前端](https://github.com/xitu/gold-miner#前端)、[后端](https://github.com/xitu/gold-miner#后端)、[区块链](https://github.com/xitu/gold-miner#区块链)、[产品](https://github.com/xitu/gold-miner#产品)、[设计](https://github.com/xitu/gold-miner#设计)、[人工智能](https://github.com/xitu/gold-miner#人工智能)等领域，想要查看更多优质译文请持续关注 [掘金翻译计划](https://github.com/xitu/gold-miner)、[官方微博](http://weibo.com/juejinfanyi)、[知乎专栏](https://zhuanlan.zhihu.com/juejinfanyi)。
