“痒点驱动模型”如何解决我们的用户体验难题

图片来源：

Tony Smith via Flickr (CC BY 2.0)

开源是一种以开发者为中心的解决方案模型，简而言之，可以描述为构建开发者社区来解决问题。

在其最简单的形式中，该模型包含两个阶段。首先，开发者遇到一个问题（痒点），他们可以用一些新代码来解决这个问题，然后他们开始着手解决。其次，如果他们随后将其解决方案提供给其他开发者，它就可以发展成为一个蓬勃发展的开源社区。当它奏效时，这是一个令人惊叹的过程，正是这个简单的模型改变了计算机的历史。

但是，除了开发者解决开发者的问题之外，开源的表现并不那么好。这在开源圈子里已经被充分讨论过，通常以这样的问题来表达：“为什么用户界面如此糟糕？” 以糟糕的用户界面来定义问题是很常见的，但这可能只是对问题的肤浅处理。“面向用户”的开源项目不仅在用户界面上失败，而且在更深层次上未能满足用户需求。

在环顾四周，看看那些主要面向用户的可用开源解决方案时，你有没有问过自己，为什么开源似乎表现得如此糟糕？不仅仅是你最喜欢的桌面应用程序的用户体验感觉笨拙，而且为什么开源在桌面领域整体上没有胜出？

每个人都想要的开源桌面应用程序在哪里？网络空间又如何呢？

那些能够击败专有竞争对手的开源替代品在哪里？为什么开源没有在从文本编辑器到 CRM，从网络邮件到社交媒体的每个用户领域都击垮竞争对手？

例子寥寥无几。

我认为 Unity 桌面超越了竞争对手，Mattermost 和 GitLab 也比 Slack 和 GitHub 更好，但在这方面我并不占多数。

除了少数几个例子之外，我看不出有任何开源产品在满足用户需求方面击败了专有竞争对手。为什么开源在生产面向开发者的解决方案以及网络和互联网基础设施方面做得如此出色，但在面向用户的世界中却表现得如此糟糕？

我认为开源可以在社交网络、文本编辑器、CRM、网络邮件等方面占据主导地位。事实上，我认为开源模型具有一些本质特征，使其能够全面击败专有竞争对手。但这首先需要了解为什么目前没有做到这一点。

为了理解问题，作为解决问题的第一步，我们必须深入了解我们在开源社区中创建解决方案的方式。我们需要批判性地做到这一点，并准备好问自己一些难题。

痒点驱动模型

“每个优秀的软件作品都始于解决开发者个人的痒点。” -- Eric Raymond

Eric Raymond 提出，开源和自由软件有一种特殊的解决方案模型，他称之为痒点驱动模型。基本上，这个想法是，开源项目之所以启动，是因为有人在某个地方看到了一个问题（痒点），然后他们开始通过编程来解决问题（挠痒）。

这非常有道理，而且这是一个非常简洁的方式来描述实际发生的事情。Eric Raymond 在大教堂与集市中对此进行了更详细的描述，这本书被认为是理解开源的奠基之作。正如 Eric Raymond 所说

“每个优秀的软件作品都始于解决开发者个人的痒点。”

痒点驱动模型具有两个非常重要的特征，这两个特征在开源领域发挥了极其重要的作用

事实上，它是你的痒点，这对于开发一个好的解决方案至关重要。如果你有一个问题，并且你非常了解它，那么你就有很好的节奏来开始解决这个问题。与对问题一知半解的“局外人”相比，你作为“局内人”更有能力解决问题。因为它是你的痒点，所以你既有动力去解决它，更重要的是，你将对如何解决这个问题有独特的见解。
其他有类似问题的人对于构建社区至关重要。如果你的痒点是一个常见的痒点，并且你知道其他人也需要你的部分或完整的解决方案，那么你很可能会看到贡献和/或采用的增长。这基本上是开源项目增长的秘诀。当然，成功的开源社区还有更多因素，例如治理、志愿者管理、理解内在和外在动机等等，但问题的核心是，如果你知道其他人也有同样的痒点，那么开源，即使不是别的，也是放大挠痒效应的绝佳模型。这也并非没有先例，任何阅读过 John Abele 或 Everett Rogers 作品的人都知道。在外部世界，这个过程被称为“扩散”。

因此，痒点驱动模型，作为开源社区的模型，之所以真正成功，是因为你了解你的痒点，其次，你认识其他与你有相同问题的人，因此，他们希望分享或参与创建你的解决方案。到目前为止，听起来非常不卫生！

在现实生活中

在现实世界中，我们看到了这一点在发挥作用。也许这种文化的起源是 Linux。Linus Torvalds 有一个问题，他想要一个免费的操作系统（痒点）。他尝试了一下（挠痒），并向全世界发布了一封电子邮件，询问是否有人有兴趣和他一起解决这个问题。然后，我们知道剩下的故事：一个由社区驱动的大型挠痒，永远改变了计算机的历史。这就是痒点驱动模型以原型方式发挥作用的例子。

几乎每个成功的开源项目从第一天起都是这样演变而来的。开发者解决技术问题，并逐渐吸引其他开发者与他们合作解决或采用它。这个模型的核心是开发者。既有问题又有解决方案的人。我称这个模型为以开发者为中心的解决方案模型。它几乎是每个现有开源项目的模型。

所以，我们知道这个模型是强大的。我们已经看到了它能做什么。但是，我们有多少次停下来问自己，它不能做什么，或者它做得不好的地方是什么？我们多久问自己一次，它在哪里失败，为什么失败？我认为我们没有进行足够的这种对话。

让我们首先明确以开发者为中心的模型在哪些方面有效，从而开始考虑这些问题。嗯，它在解决开发者遇到的问题时效果很好，这些问题几乎完全或至少主要是技术问题。这就是为什么互联网基本上运行在从 BIND 到 OpenSSH 的开源层之上，以及为什么在没有开源的情况下，你在网络托管或容器世界中寸步难行。事实上，如果没有使用某种开源库，你几乎无法开发任何类型的软件。在解决这类问题时，以开发者为中心的模型完胜。

然而，虽然以开发者为中心的模型已被证明非常擅长解决技术问题，但历史表明，它在解决面向用户的问题方面并不是很好。如果它擅长做到这一点，我们应该看到开源在用户领域击垮专有应用程序。但我们很少看到这种情况。

难道是这个模型不擅长解决这类问题吗？

我相信问题就在这里。以开发者为中心的模型之所以适用于解决技术问题，是因为正如 Eric Raymond 指出的那样，有问题的人处于创建解决方案的核心。开发者了解他们的痒点。

当开发者解决他们自身的技术问题，他们理解透彻并想解决的问题时，它会非常有效。而当开发者解决用户问题，即不是他们自身的问题时，他们对问题不够了解，并且所需的解决方案主要不是技术问题时，它就根本不起作用。

这是因为在这些情况下，我们违反了痒点驱动模型的第一个要求：了解你的问题。开发者不像用户那样“了解”问题，因为它毕竟不是他们的问题。他们试图解决著名的 SEP，别人的问题（Someone Else's Problem）。因此，他们没有像用户那样对问题的怪癖和细微之处有深入的体验知识和理解。这是一种定性的、体验上的差异，但它很重要。

因此，我们得到的软件解决方案反映了开发者对问题的理解，并反映了开发者解决问题的方法；这种方法通常与用户对问题的理解或他们的需求不符。

在今天的开源领域，开发者是主要的解决方案提供者。当他们为自己构建解决方案时，这是一个几乎完美的模型。但是，当涉及到为开发者不完全理解其需求的用户群（因为他们不是用户）构建解决方案时，该模型就会失败。