x-oss-process
我不花很多时间在开放源码项目的整个工作日（和许多晚上）上，我对OSS的使用形成了一种或两种意见-特别是在为项目做贡献时。
作为一个使用Github之类的工具的社区，我们已经走了很长一段路，这使得在野外发布OSS项目并接受贡献变得越来越容易。 尽管这样做，项目似乎以不同程度的成功支持用户。 一些项目蓬勃发展，慷慨地接受了社区的贡献。 其他项目在接受反馈方面做得很好，但是很大程度上由维护者来驱动项目的方向。 还有一些极端的做法是接受随心所欲地放弃的每个请求，或者无情地允许该项目腐烂并成为另一个废弃的github遗物。
随之而来的是越来越多的公司在OSS上建立业务。 不仅是零散的事情，而是由各种不同的人维护的整个复杂的软件生态系统。 这些业务中的每一个都有自己独特的怪癖，个性和约束。
我曾在其中一些公司工作，而且我知道这些限制和个性对于我来说改变起来并不容易。 我必须使用已有的东西，并尝试找到可以满足我需要的工具。 当我找到一种工具，可以满足我90％的需求时，我愿意全力以赴地推动它并使其对我有用，我将与该项目的维护者面对面。
我想说这总是很顺利，我总是能够以人们理解的方式来表达我的用例，并且我的用例总是与项目的意图保持一致。 如果我在某种特定语言上的技能水平始终可以与之媲美，并且我编写质量测试的能力始终很合适，那我会很乐意。 我很乐意始终了解该项目的路线图以及维护者对我应该如何贡献的期望。 这不是这样。
我可能觉得自己对某个项目的理解不够充分，有时甚至感觉到维护者不了解我。 更糟糕的是，当我（正确或不正确）向维护者解释我“只是不理解”的态度，而不是试图帮助我理解时。
这听起来对我真的很熟悉。 这听起来像是整个世界的观察，表明Dev＆Ops需要更加紧密地合作。 观察到，开发软件的人员需要与使用软件的人员更紧密地交互。 每个人都可以交流和参与的建立同理心和协作环境将帮助我们克服分歧。 对我来说，这个问题不只是我公司的开发人员。 这个问题扩展到构建我每天使用的系统的开发人员，而这些开发人员中的大多数都不适用于我的公司。
就像我们必须投资建立公司内部的关系一样，当您使用OSS时，您也必须投资建立与公司外部工作人员的关系。 这是双向的，维护者投入更多的精力来理解用户，这对每个人都越好。 这并不容易–因此，如果您不是维护者并且正在阅读本文，请了解与维护者的互动通常是在他们的全职工作范围之外，在他们通常的期限和压力之外进行的，并且这样做是因为他们喜欢从事一个项目。 如果人们像我一样，当某件事不再令人愉快时，我就会停止这样做。 投诉时请牢记。
此外，对于一个受欢迎的项目，用户与维护者的比例非常不平衡，不利于维护者。 他们的工作很艰辛，而对于那些为他们的用户而充满恩典和同情心的人来说，我很高兴。
因此，当我们谈论DevOps和Empathy以及所有这些使您的公司运转更好的好主意时，请不要止步于此。 考虑使您的工作存在的所有那些项目，以及使您的项目成功的所有那些用户。 尝试花一点时间互相了解，共同努力，使自己变得更棒。
翻译自: https://www.javacodegeeks.com/2014/03/empathy-in-oss-its-important.html
x-oss-process
