构建真实的开发者社区的三个重要步骤

如何在满足组织需求的同时构建社区? 这三个步骤可以帮助您。
325 位读者喜欢这篇文章。
A community building a barn

Opensource.com

随着越来越多的软件企业销售开源产品,我们看到,围绕这些产品构建开发者社区的重要性日益凸显,将其作为衡量成功的关键指标。快乐的用户是充满激情的倡导者,这些充满激情的倡导者可以提高公司产品的整体知名度。 将正确的、有影响力的声音吸引到您的社区中,客户会更有兴趣与您的公司建立关系。

然而,以正确的方式进行社区建设是一项微妙的平衡。 为了推动销售而削弱用户社区的需求,您的公司将会面临采用率下降和不利的品牌认知。 同时,对底线的关注太少对公司不利。 那么,如何才能有效地平衡这种紧张关系呢?特别是在开发者是“新造王者”,并且满足他们的敏感性是推动企业购买决策的基石的世界中?

在过去的一年中,我一直在思考如何在建立业务底线的同时有效地进行社区建设。 在本文中,我将概述构建真实的、富有成效的、可持续的开发者社区的三个重要步骤。

1. 了解社区成员的价值。

在担任 MySQL(可以说是有史以来最成功的开源软件业务之一)的 CEO 期间,Mårten Mickos 表示,开源业务的成功取决于服务好两个受众

“除非您同时服务于那些花时间省钱的人和那些花钱省时间的人,否则免费和开源软件业务将无法运作。”

对于提供开源软件解决方案的组织而言,了解公司生态系统中每个参与者的价值是使您的业务成功的关键部分。 您的客户、您的工程师以及仅使用贵公司开源产品的开发者都是您社区的一部分。

那些使用贵公司的开源代码但未使用任何商业产品的人代表了您业务生态系统中的宝贵组成部分; 他们通常是充满激情的倡导者、有影响力的声音,并且由于他们的错误报告和对重要边缘情况的识别,对您的 QA 和开发团队来说是一个福音。

2. 为社区贡献设定明确的期望。

明确要求您的社区提供帮助并没有错。 如果您希望获得倡导,请鼓励您的社区成员在聚会或会议上谈论您的技术; 开发者希望将他们的声誉与他们认为有用和优雅的软件联系起来,尤其是在它是新的和闪亮的时候。

如果您正在寻找错误报告和拉取请求,请通过以下几种简单的方式鼓励他们

  • 快速响应错误报告,最好在 48 个工作小时内,即使只是让报告者知道您正在调查它。
  • 拉取请求也是如此; 您不必合并每个 PR,但花一些时间评估 PR、评论创建的工作,如果未合并,请简要解释为什么您的公司不接受该代码。
  • 制定合理的贡献者许可协议,以便法律协议不会成为社区贡献的障碍。 例如,期望社区成员签署复杂的法律协议来更新简单的文档是一个不合理的障碍,并且会耗尽社区成员中的志愿精神。

即使您只是希望您的产品的开发者粉丝在他们的笔记本电脑上贴上您公司的贴纸,明确参与规则——并解释贡献的价值——对您的社区来说也是一个好习惯。 花时间编写良好的错误报告意味着该软件会为所有用户改进。 教别人如何使用您的软件会带来帮助别人的满足感,同时也为您的公司创造了更大的潜在客户群。 贡献于贵公司的代码库通常会导致您在社区中的声望相应提高,并且随着贵公司的产品被更广泛地采用,就业能力也会提高。

您会发现,您的免费(和开源)软件的许多用户很乐意花空闲时间为您的成功做出贡献,因为他们想“回馈”,以换取他们从您的产品中获得的价值。

3. 保持一致。

与您的社区成员(无论是您的客户、您的用户,甚至是您自己公司的开发者)的互动应该保持一致。 不一致会导致缺乏信任,而信任是成功的社区和公司的基本组成部分。

发布清晰、易于查找的路线图,以便每个人都知道您所采取的技术方向,这会有所帮助。 没有人希望花时间打磨您的公司不会接受的拉取请求,因为类似的功能已经在开发中,而那些这样做的人可以很容易地从充满激情的倡导者转变为直言不讳的批评者。

同样,如果您的产品线专注于支持您的开源软件产品,请不要提供“免费”支持来为您的用户社区做好事。 社区内的所有互动都会设定规范,如果社区成员曾经一次超越自我,他们可能会期望您的员工为他们遇到的每个问题都超越自我。 帮助您的支持人员拒绝那些会侵蚀公司底线的请求并没有错,尤其是当那些提供支持的人是您公司的开发人员时,他们需要将大部分时间集中在构建底层产品上,这些产品会促使客户有兴趣购买支持合同。

您会在此列表中添加哪些步骤? 请在评论中告诉我。


Amye Scavarda 将在 7 月 16 日至 19 日在俄勒冈州波特兰举行的第 20 届 OSCON 活动上发表 构建真实的社区:在交付客户价值的同时维护开发者价值

Leslie Hawthorn headshot
Leslie Hawthorn 的职业生涯一直致力于创建和培养开源社区。 她曾在财富 10 强公司、首次公开募股的初创公司和基金会董事会推动开源战略,包括在 Red Hat、Google、Open Source Initiative 和 Elastic 担任高级职务。 她目前领导 Red Hat 开源项目办公室内的行业垂直社区战略团队。

4 条评论

Leslie,精彩的文章! 我想在列表中添加“沟通”。

我正处于这种情况; 一家生产开源 CMS 的公司,拥有一个全球开发者社区。

保持参与者(公司员工、客户、合作伙伴、开发者等)之间的平衡需要在多个层面、多个参与者之间进行沟通。

罗宾,很棒的观点! 这是本文所源于的谈话的重要组成部分。 如果我能重述它并进行录像,我会向您发送一个指针。

回复 作者: robinmuilwijk

使用与您的最终目标一致的工具和方法也是一个非常好的主意! 例如,如果您是一个开放的社区,那么最好使用开放的工具。 如果,比如说,您采用 Slack 进行沟通(不幸的是,许多开放社区都这样做),那么您正在破坏一种开放的文化 - 强迫您的潜在贡献者同意第三方专有条款才能参与您的开放社区存在一些真正的矛盾(事实上,您正在将社区协作的完全控制权交给第三方)。

Creative Commons License此作品已根据 Creative Commons Attribution-Share Alike 4.0 International License 许可。
© . All rights reserved.