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

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

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

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

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

大家想要的开源桌面应用在哪里？网络空间又如何呢？

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

例子寥寥无几。

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

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

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

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

痒点驱动模型

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

这完全合理，并且非常简洁地描述了实际发生的事情。Eric Raymond 在大教堂与集市中对此进行了更多描述，这本书被认为是理解开源的基础性著作。正如 Eric Raymond 所说

“每一个优秀的软件作品都始于挠开发人员的个人痒处。”

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

1. 它是你的痒处这一事实对于开发好的解决方案至关重要。如果您有问题并且您非常了解它，那么您就非常适合开始解决该问题。与对问题一知半解的“局外人”相比，您作为“局内人”更适合解决问题。因为它是你的痒处，所以你既有动力去解决它，更重要的是，你将对如何解决该问题有独特的见解。

2. 拥有类似问题的其他人对于构建社区至关重要。如果你的痒处是一个常见的痒处，并且你知道其他人需要你的部分或完整的解决方案，那么你很可能会看到贡献和/或采用的增长。这基本上是开源项目增长的秘诀。当然，成功的开源社区还有更多因素，例如治理、志愿者管理、理解内在和外在动机等等，但问题的核心是，如果您知道其他人也有相同的痒处，那么开源，即使退一步说，也是放大挠痒效果的绝佳模型。这也不是没有先例的，任何阅读过 John Abele 或 Everett Rogers 作品的人都知道。在外部世界，这个过程被称为“扩散”。

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

在现实生活中

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

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

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

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

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

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

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

当开发者解决他们遇到的、理解透彻并希望修复的技术问题时，它会非常有效。而当开发者解决用户问题，即不是他们自己的问题时，他们并不完全了解这个问题，并且所需的解决方案主要不是技术问题，那么它根本就不是很有效。

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

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

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

我们该如何解决这个问题？

我认为答案很明确。我们坚持痒点驱动模型。

这是一个解决问题的好方法。正是这个模型使开源能够在技术领域击败专有竞争对手。我们应该坚持下去，但我们需要在应用方式上保持一致。我们需要将有问题的人，那些有痒点的人，那些完全了解问题的人，置于解决问题工作的核心。

仅仅在以开发者为中心的项目文化中添加“用户体验人员”或“用户论坛”是不够的，无法解决用户需求。这种方法是一种临时的补丁，只能走这么远。我们需要回到痒点驱动模型的核心原则，将有问题的人（用户）带入解决方案模型的核心。

为此，我们需要开始问问自己，以用户为中心的解决方案模型对于开源可能是什么样的。

在你看来它是什么样的？