我想写这篇文章已经有一段时间了，但这是一个很复杂的话题。
最近，我在我维护的一些开源软件（OSS）项目中与用户发生了一些 "冲突"，我也看到我在Twitter上关注的一些人也在处理同样的事情。
正因为如此，我想分享一下我的观点，在使用开放源码软件时应该有什么样的态度和考虑。
公司与个人
在使用开放源码软件时，你首先要考虑的是，有两种项目，它们通常有不同的目标。
公司项目
很常见的是，那些与软件有关的活动或深入使用技术的公司会发布自己的开放源码软件项目。
这些项目通常是由公司的一些需求而产生的，而这些需求严格来说并不属于他们的领域。
通过发布这些项目，他们可以找到新的人才（在贡献者中），或者在行业中定位。
公司提供与这些开放源码软件项目有关的有偿服务也很常见，比如具体的托管或部署服务，或者只是使用这些项目的咨询。
个人项目
还有一些项目通常是由一个人或一个非常小的团队在他们自己的空闲时间里维护的。
这些项目是由一些人创建的，他们这样做主要是因为他们喜欢编程，想分享他们所做的事情。
这里的目标是获得一些知名度，展示一些技能，学习一些新的东西，并为开源社区作出贡献。
虽然主要目的通常不是得到钱，但他们经常接受捐款和赞助。
现在我们知道了开放源码项目的两个主要群体。有时我们认为它们是一样的，但公司项目通常是由公司支付报酬的人维护的，而且是在他们的工作时间内进行。
另一方面，个人项目不能得到那么多的关注和资源，所以他们不能像公司项目那样快速发展。
考虑因素
也就是说，当我们想使用一个开放源码项目或为其做贡献时，有几件事需要考虑到。
总是要有礼貌
在使用一个项目时，你很可能最终发现有些东西并不像你预期的那样工作，或者你会开发一个新的需求，而这个项目并没有提供解决方案。
当报告错误或要求新的功能时，总是要尽量礼貌。提供尽可能多的细节，要有描述性，帮助维护者重现问题。
如果有人要求你做一些测试，并把结果反馈给他，请尽量抽出时间来做。你可能认为这不是你的工作，但问题会更早得到解决，你也会避免挫折。
在报告问题时，我喜欢使用一个公式，它包括填写这个模板。
- 我做了*[行动]*。
- 我期望*[行为]*会发生。
- 但*[其他行为]*却发生了。
这将使维护者更容易看到用户的意图，并发现那些实际上不是错误的混淆。这样一来，帮助用户使用工具就会更容易。
不要认为任何事情都是理所当然的
仅仅因为你开了一张票，并不意味着团队会马上处理它。有几个原因可能会推迟它。
- 项目有其他优先事项。
- 它很难重现。
- 没有人可以做这个工作。
- 维护者只想把时间花在别的事情上（特别是在个人项目的情况下）。
在项目中工作的人通常处理的范围比你想象的要广得多，所以你必须要有耐心并理解这一点。
也有可能发生的情况是，他们并不真的想维护你提议的东西，尽管它对你来说是一个非常关键的功能，但一个项目永远不可能涵盖100%的用例。
考虑贡献
开放源码哲学的主要原则之一是合作。
如果你一直在使用一个开放源码软件项目，最好的方式是通过贡献它来表示一些赞赏，并与它的延续性进行合作。
有几种贡献的方式。
- 你可以改进文档。
- 你可以提供一些修复一些错误或改进代码的PR。
- 你可以提供一些关于一些新功能的PR。
- 你可以做一些经济捐助或赞助。
最后一种情况非常罕见，特别是在个人用户中，但如果你的公司正在利用一个开放源码软件项目，你应该考虑一下。
对于其他三种情况，如果你认为你可以提供一些帮助，有一些东西需要考虑到与前面的观点有关。你应该总是先问。
也许有人已经在做类似的事情，或者团队有一些想法，可以在开始实施之前分享，或者，正如我之前说的，也许他们只是不想维护它。
如果你先问一下，你会为自己节省一些时间和挫折。
遵循项目规则
所有的项目都有规则，我说的是任何类型的规则。如何写问题，行为准则，编码标准，在合并PR之前需要批准多少人......
你必须始终遵循这些规则。不要因为你认为它更好就试图强制执行一些东西。
如果项目要求使用空格缩进，但你使用了制表符，因为你更喜欢它们，如果维护者不想合并你的PR，不要生气。
不要把它当做个人问题
最后，由于前面提到的原因，会有一些你不喜欢的决定。
不要把它看成是个人行为，因为在大多数情况下，它不是。
你的问题可能被关闭，因为你没有遵循问题模板，或者因为他们要求你检查一些东西，而你在几天后没有给出任何反馈。
理解这种情况可能发生，你可以始终保持礼貌并展开讨论，但千万不要生气并指责团队不公平或以错误方式对待你。
总结
这篇文章描述了一套规则，应该可以帮助使用开放源码软件项目的人和维护项目的人相互理解，但重点是前者。
我将尝试写一些类似的东西，但重点是维护者应该如何做。显然，我们有时会忘记，在使用我们编写的软件时，还有人在信任我们。
