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

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)。这是我们都需要努力改进的事情。让我们看看可以澄清如何做得更好的四个问题。

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

你为什么做出这个决定?即使是开放组织也必须私下做出一些决定。例如,在 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

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