如何在开放社区中做出品牌决策

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

Opensource.com

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

Docker 社区的反应绝大多数是负面的。截至撰写本文时,Moby pull request 在 GitHub 上获得了 7 个赞和 110 个踩。Docker 社区对这项不透明的既成事实公告感到沮丧,这项重要决定是由一个隐藏的内部圈子闭门做出的。这是一个典型的“为什么没有咨询我?”案例。

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

也许我们可以称之为“内部圈定”。

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

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

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

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

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

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

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

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

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

5 条评论

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

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

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

回复 作者 bcotton

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

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

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

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

回复 作者 whit537

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