参与开源社区——或者任何开放组织，就此而言——意味着与可能与你运作方式不同的人合作。他们的动机可能不同。他们的治理模式可能看起来很陌生。他们的目标可能不会立即引起你的共鸣。因此，如果你要一起工作，你需要清楚地了解是什么让项目运转起来——并迅速决定合作是否最适合你的团队和你的业务。
同样，如果你要发起一个开源项目，你应该问问自己，“我想吸引什么样的社区？” 然后你可以相应地计划和发出信号。
今年早些时候，Mozilla 和 Open Tech Strategies 发布了我们希望能够帮助解决此问题的工具的第一个版本。我们最近的报告 “开源原型” 确定了战略背景下的 10 种通用类型的开放社区（或“原型”）。该报告提供了描述这些原型的叙述，解释了是什么激励了它们，并概述了与它们合作的战略优势。我们还引用了每个原型的一些示例，并深入了解了构成它们的各种许可模式、治理模式和社区标准。
我们首先在 Mozilla 内部发布了该报告，为来自工程、战略和法律团队的代表举办了关于设计我们项目的研讨会。鉴于我们收到的积极反馈，我们随后决定更广泛地发布它——我想分享一下它是如何产生的。
开放式设计
我们启动原型工作是 Mozilla 更广泛倡议的一部分，我们称之为“开放式设计”。
该项目于 2017 年启动，首先全面审查了 Mozilla 如何与开放社区合作。Mozilla 是一个具有高度参与性的组织，以 2004 年推出 Firefox 浏览器的志愿者社区而闻名，我们希望正式和全面地审查和编目我们自己的最佳实践。
随着时间的推移，这些实践已经成熟并变得普遍。Mozilla 项目在 2004 年从其社区获得的优势在今天看来并非如此独特。事实上，似乎许多组织——包括商业组织和非商业组织——都在与社区合作，并采用以社区为中心的方法来实现其使命。
开放式设计着眼于整个组织边界的协作的各个方面。它着眼于更广泛的开放实践——超越开源软件开发本身——包括更结构化的方法，将用户洞察、行业协作、创新挑战和众包引入 Mozilla。
该计划的重点是 Mozilla 与其合作的不同社区之间的价值交换。开源一直对 Mozilla 很重要，Mozilla 理所当然地将其软件许可为自由和开源软件。这解释了项目周围强大的社区。但我们的工作对开源的战略应用具有更广泛的意义。
默认开放，一个悖论
在默认情况下软件是专有的组织中，试图开源任何特定资产的人通常必须用明确的商业案例来支持这一举动，包括对他们想要的市场影响的明确描述以及对最能实现此目标的项目结构的分析。
这里的悖论是，与采用更多专有模型的组织相比，使用开源作为其主要或独家软件分发模式的组织（随着时间的推移）往往对其开源的使用缺乏战略性。这只是他们“默认”的运营模式；他们的方法是日常生活中理所当然的一部分，不需要额外的理由。
更重要的是，围绕开源项目发展社区需要付出真正的成本——时间和精力。决策过程、社会规范的执行和频繁的沟通通常都是工程师的职责——而所有这些都会占用编写代码的时间。不同项目的要求可能会有所不同；一个旨在建立广泛用户社区的项目应该与一个寻求少数行业利益相关者作为合作伙伴的项目看起来非常不同。
很容易陷入陷阱，对一个你没有长期承诺或直接从中受益的社区进行大量投资。因此，对于你将要进行的任何开源社区投资，拥有强大的战略基础非常重要。
鉴于我们不需要为一个项目回答这个问题——而是希望能够一次帮助许多不同的 Mozilla 项目——我们确定我们需要一个框架（或一组方法）来提供指导并激发和验证思考。组织内部共享的词汇表意味着你可以传达大量共享的假设，从而实现更快、更丰富的关于项目战略和设计的对话。
我们假设世界上存在某种这样的分类法。我们惊讶地发现没有。
在与来自开源促进会和 Linux 基金会的专家交谈后，我们意识到，虽然对许可证、治理模式和技术应用进行了各种分类，但没有开源项目类型的总体分类法。幸运的是，我们在 Open Tech Strategies 遇到了 Karl Fogel 和 James Vasile。虽然 Karl 和 James 经常被要求提供这种指导，但我们了解到他们以前从未参与过总体分类法。但他们广度和深度的知识清楚地表明，他们将能够制作一份报告，以推进 Mozilla 的这种想法。
在充分了解我们的情况后，Karl 和 James 开始采访许多产品、工程或战略职能部门的人员，了解我们对开源的期望，并将该分析与他们现有的开源项目知识结合起来。从那里，识别共性（原型）的艰巨工作开始了。
几个月后，我们有了 1.0 版本，概述了 10 种原型，以及至关重要的，如何应用它们。
应用原型
为了充分利用我们在报告中详细说明的原型，项目需要了解其战略选择。也就是说，它需要了解其环境及其在该环境中的目标。
要了解项目的环境，重要的是要了解软件将部署在其中的上下文、它解决的问题以及为谁解决问题。例如，OEM 将嵌入以驱动他们要推向市场的新小部件的组件、面向前端开发人员的 Javascript 库或办公套件之间存在天壤之别。
了解项目潜在参与者的价值交换可能是什么也很重要——反过来，参与者正在与谁竞争（以及你的项目如何帮助他们）。OEM 可能希望明确地在不提供差异化的组件上进行协作，而软件开发人员可能会“挠自己的痒处”——使产品更好——当他们为开发工具做出贡献时。
在没有任何项目背景的情况下定义目标是具有挑战性的。在开放式设计框架内，我们鼓励项目考虑 Treacy 和 Wiersemas 的价值学科以及开源如何帮助他们。三个价值学科是
- 卓越运营
- 卓越产品
- 客户亲密度
。 。 。为了我们的框架的目的，我们将其调整为
- 降低开发和运营成本
- 开发更好的产品和服务以及
- 改变市场动态
换句话说，我们邀请项目负责人考虑开源如何根据这些维度改善他们的情况。将项目开发为开源的潜在好处是多种多样的；该框架既有助于对开源项目预期的影响进行分类，也有助于寻找额外的益处。
这是一个对人们有吸引力的典型例子：开源项目可能会吸引来自其他地方的投资，从而降低开发和运营成本。在某些情况下可能是这样（例如我们上面的 OEM 示例）；但是，开源代码库也可能以其他更微妙的方式提供帮助，例如增加你的招聘人才库、改善内部协作或仅仅提高员工士气。开源还可以帮助你更好地了解客户问题（尤其是在客户是可以直接参与项目并为其做出贡献的技术用户的情况下，例如软件开发人员为开发工具做出贡献）。最后，开源可以改变游戏规则，创建非正式联盟和合作伙伴关系，推动标准化，并且在许多情况下，可以更好地获得整体市场接受度（例如 Android 和 LibreOffice 所产生的影响）。
开源可以带来所有这些好处，前提是你积极寻求它们并能够进行所需的投资水平。这是一个通过它来理解原型的有益视角。战略必须立足于现实。
通过遵循这种方法，我们能够问自己正确的问题，并确定我们对任何开源项目的真正期望是什么。我们已经开始使用原型来思考我们产品、技术项目和内部工具的项目结构。我们也知道，该框架将通过来自 Mozilla 内部和外部用户的输入而得到改进，这就是为什么该项目现在已在 GitHub 上，并根据 CC Attribution-ShareAlike 3.0 许可获得许可。
我们确信这是一个对任何项目定义其开源策略都有帮助的工具。
评论已关闭。