如何让开源更以用户为中心？

 

在一个真正的社区项目中，纳入设计和用户体验是一个具有挑战性的平衡问题，因为开源项目背后的激励模型。

 

根据《大教堂与集市》的说法，开源项目参与者的主要动机是“解决他们自己的痛点”。 这带来的一个后果是，在拥有多个独立参与者的真正开源项目中，协调贡献以支持以用户为中心的设计本质上是一种可选的额外功能。 我们都希望有一种方法能够将真正的用户体验质量作为开源项目的关键动力。 但有两个主要原因导致这具有挑战性。

首先，单个用户真的不知道所有用户想要什么。

  • 需要明确的是，我不是在重复“用户不知道他们想要什么”的陈词滥调。
  • 每个用户都知道自己想要什么，那些性格外向，能够公开清晰表达自己愿望的用户，往往能够为自己的需求提出令人信服的理由。
  • 但是，即使对于可以通过要求付款才能获得合格意见来排除大量声音的公司而言，对“用户想要什么”的总体评估也极其困难。 公司聘请产品经理，他们利用市场调研和个人经验来指导开发。 这是一项广为人知的工作，但即使有经验丰富的产品经理，专有项目也可能无法把握市场脉搏。
  • 用户投票不是答案，任何在 Bugzilla 中见过它的人都可以证明这一点。 我也不相信用户资助的赏金有助于识别广泛的用户需求，尽管它们为资助一些开源项目提供了一条有用的途径。
  • 尽管如此，在最终用户软件中，用户出现并要求实施或更改功能的情况非常普遍。 我经常看到社区成员努力对粗鲁、有权要求的白嫖者保持礼貌，他们向从未见过面、也无意感谢甚至付费的人索要东西。
  • 相反，用户需要熟练的倡导者代表他们发言，根据实用性、需求和可行性对功能进行优先级排序，并与开发人员合作以提升软件提供的用户体验。
  • 他们需要从基于实绩获得的地位出发，而不是任命。
  • 因此，我渴望开源软件采用以用户体验为中心的方法，而不是以用户为中心的方法，这两者截然不同。
  • 但这需要任命一位熟练的用户倡导者，而不是数百万个人的临时声音或具有 A 型性格的自我选择的子集。

 

其次，开源自由软件项目的开发人员不接受命令。

  • 这只是该模型的一个结果。 当许多人的内在利益重叠时，就会出现开源项目。 这种重叠并不会使他们的内在利益融合； 它只是在他们各自的生活中创造了一个领域，他们在其中与他人协作，或者使用他们与之没有其他关系的人的工作。
  • 缺乏任何其他关系是软件自由如此重要的原因。 通过保证每个人都可以使用、改进和共享软件，而无需参考任何其他人或实体，我们确保每个人都可以自由地满足自己的需求，而不会受到干扰。
  • 这种自由的必然结果是缺乏权威关系。 以不同方式使用软件的两个用户无法强迫对方改变他们使用软件的方式； 如果他们想要可互操作的行为，他们需要协商。 以不同方式从软件中谋生的两位开发人员无法强迫对方实施满足他们需求的功能。 相反，他们必须实施他们需要的代码，并与其他人协商将其纳入。 最后，想要实施功能的用户不能要求开发人员实施它。 他们可能会使它对开发人员有吸引力，也许通过在项目范围之外向他们付款。 但权威关系没有基础。
  • 这使用户体验专家处于不利的地位。 用户体验的观点本质上是用户体验的综合，因此不能完全代表个人。 用户体验还涉及指导他人如何塑造他们的代码，这发生在明确排除权力关系的环境中。
  • 此外，在一个协作项目中，每个参与者都自掏腰包（而不是指望项目付款），并满足自己的需求（而不是指示或付费让项目这样做）。
  • 用户体验专家和/或“产品经理”也很不可能有参与其中的外部动机。 因此，项目合作者中不太可能有人是用户体验从业者，即使他们是，他们这样做的外部动机也可能成为项目的担忧。

 

这并不是说项目忽略了用户体验。 两个例子

  1. Mozilla 在用户体验上花费了大量资金，并且已经能够提升对用户体验的尊重，使其成为开发人员的优先事项（当然 Mozilla 很特殊）。
  2. TDF 最近决定花费捐赠资金聘请一位用户体验专家来支持 LibreOffice 开发人员（他们已经得到了一个优秀的设计团队的支持），并且正在探索如何最好地帮助他与开发人员互动，这些开发人员不受任何实体的多数控制。

 

源于项目外部动机和奖励的自力更生是开源模型的基本组成部分。 虽然有些人对开发人员掌握所有决定权感到沮丧，但挑战他们对项目未来的权力，就如同堂吉诃德式地对抗源于内在自力更生的自然力量，注定会令人沮丧。 试图羞辱开发人员接受你的权威，成功的记录很差。

因此，如果您想将开源开发转变为以用户为中心的方法，您将需要回答以上分析提出的两个问题

  1. 哪些用户将成为中心，他们如何到达那里，为什么他们应该是那里的人，谁代表他们？
  2. 是什么激励了实际制作东西的人——开发人员、设计师、文档编写者——去做他们要求的事情。

 

我们需要探索建立用户体验从业者加入协作社区的动机的方法，以及使其贡献不违反源于缺乏权威关系的自然动态的机制。 Mozilla 有一种方法，TDF 有另一种方法。 也许其他人有他们可以分享的方法，我们可以从中学习？ 请在下面告知我们。

本文最初发表于 Meshed Insights，并由 Patreon 赞助人促成。

图片来源
“userCentric.jpg”，©开源促进会，2017 年，知识共享署名 2.0 通用许可协议 (CC BY 2.0)，是“计算机专家”的衍生作品（缩放和裁剪），©Karen Baijens，2015 年，通过 Flickr，并根据 知识共享署名 2.0 通用许可协议 (CC BY 2.0)获得许可使用。