如何在开放社区中制定品牌决策

Docker 最近的品牌重塑工作为公共决策提供了一个教训。
478 位读者喜欢这篇文章。
putting the pieces together

Opensource.com

4 月 18 日,Docker 创始人 Solomon Hykes 在 Docker 主要代码库中通过拉取请求发布了一项重大公告:“Docker 正在将其所有开源协作过渡到 Moby 项目。” docker/docker 代码库现在重定向到 moby/moby,Solomon 的拉取请求更新了项目的 README 和徽标以匹配。

Docker 社区的反应非常消极。截至撰写本文时,Moby 拉取请求在 GitHub 上获得了 7 票赞成票和 110 票反对票。Docker 社区对这项不透明的既成事实公告感到沮丧,这项重要决策是由一个隐藏的内部圈子闭门做出的。这是一个典型的“为什么没有咨询我?”案例。

“内部采购”是指在封闭组织的围墙花园内应用开源原则。Docker 在这里所做的事情似乎与此相反,即将封闭组织原则应用于开源社区。

也许我们可以称之为“内部循环”。

内部循环可能是一种难以抗拒的趋势。事实上,我最近在我参与的几个开源社区中看到了它的出现,包括 Sustain 会议(主要组织者举行私人每周电话会议),甚至开放组织大使小组(Red Hat 编辑私下控制 Opensource.com)。这是我们都需要努力解决的问题。让我们看看四个问题,这些问题可以澄清如何做得更好。

你是谁?封闭组织公开地做一些事情,与开放组织私下地做一些事情,这两者之间存在细微(但很重要)的差异。前者自然会倾向于做出封闭的决策,除非该组织有在特定情况下公开运营的 ulterior motive。但是,您越认同您的社区,就越会在您认为决策已定之前,审查大小决策成为第二天性。您将您的身份定位在哪里?在开放社区中?还是在封闭的内部圈子里?

您为什么做出这个决定?即使是开放组织也必须私下做出一些决策。例如,在 Gratipay,我们已确定“法律、安全、安保和支持事项”是开放决策制定的例外情况。但是,在公开宣布封闭决策时,解释您决策背后的思考过程将有助于您的社区接受您的决策。当 Gratipay 不得不因法律不确定性而重启时,我们花了大量篇幅向社区解释复杂的法律问题。是的,这需要做很多工作。但这对于维护甚至增强社区的信任是值得的。

封闭组织公开地做一些事情,与开放组织私下地做一些事情,这两者之间存在细微的差异。

Docker 有一些很好的理由将其开源项目重命名为 Moby,并且私下做出决定甚至可能是合理的。例如,将 Gittip 重命名为 Gratipay 需要两次史诗般的自行车棚。对于像 Docker 这样规模的社区,公开对话可能变得难以管理(尽管 Mozilla 最近的开放品牌重塑表明情况并非如此)。即使只用几句话诚实地解释一下,也可能将一些反对票变成赞成票。

您在哪里做出决策?让我们假设 Docker 到 Moby 的决策公开做出的(拉取请求实际上并没有说明)。它在哪里讨论的?在邮件列表上?另一个 GitHub 问题?Google Hangout?一个清楚标记为“更多详细信息”的链接使有积极性的人能够进行自己的研究并回答自己的问题。这也帮助人们更好地了解他们应该关注哪里,以避免将来出现意外。

您如何做出决策?指向来源的链接(或缺乏链接)给出了一些关于您的组织如何做出决策的隐含线索,但是,借用Python 之禅中的话,“显式优于隐式。” Jono Bacon 的社区的艺术》包含一整章关于治理和决策的内容。最近在平台合作主义运动中的会议书籍一直在探索合作治理模式与开源之间的关系。无论如何,设定关于如何做出决策的明确期望可以建立信任。

一旦尘埃落定,将 Docker 开源项目重塑品牌为 Moby 可能会被证明是一个不错的决定。但是,更开放的决策过程可能会在第一时间减少灰尘。如果 Docker 避免了“内部循环”——将封闭的决策制定引入开放社区——他们的品牌重塑本可以成为信任的来源,而不是紧张的来源。

User profile image.
我是 Gratipay 的创始人,Gratipay 是一个开放组织,其使命是培养感恩、慷慨和爱的经济。我们帮助公司和其他人为开源付费——我们通过自己的平台获得资金。在线下,我住在美国宾夕法尼亚州匹兹堡郊外,在线上,我住在 Slack、IRC 和 GitHub 上。

5 条评论

很棒的文章和例子,说明开放决策制定或至少公开决策背后的理由对于社区参与非常重要。这甚至可以应用于封闭的、等级森严的组织,以获得对闭门决策的支持和理解。太棒了!

很棒的文章,Chad!我见过的最成功的方法是在一个小圈子里制定一个计划,然后在采纳之前将其发布到社区进行完善。这仍然允许社区参与,但与从空白页开始相比,它有助于减少自行车棚效应。

好建议,Ben。我最近在开放组织大使小组中看到了这种过程运作良好。例如,当我们在几个月前过渡到使用 GitHub 时,Bryan 私下制定了一个计划,他在最终确定之前更广泛地展示该计划以供讨论。关键是要保持决策开放,直到每个人都有机会权衡。这可能很可怕,但正如您所说,有一些方法可以减轻一些风险。

回复 作者 bcotton

我认为,“将拟议计划提交社区讨论”的方法比“向社区提出问题或问题并等待其成形”的方法效果更好,因为这与开源软件社区的文化规范和预期实践相符,在这些社区中,寻求提出变更的人会随附示例代码,以演示这些变更的功能或效用。

事实上,在编码社区中,这可能是预期的方法:不要只是告诉我你想要什么;展示给我看。这效果很好,因为这些提案推进了明显的函数式/表演性语言,这种语言应该做一些事情,然后人们可以通过深入研究其机制、测试它、看看它是否真的有效等来回应提案。

在我们这样的社区(我们生产散文,而不是代码)中,或者在拟议的变更涉及我们称之为“治理模型”的那种特殊机制的情况下,这些变更与更抽象、更少功能性/表演性的事物有关,因此更难以以任何直接或明确的方式进行评估。

尽管如此,将小组可以回应的事物带到这里仍然是更可取的做法。

回复 作者 whit537

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.