许多软件开发人员都有自己的副项目，这些项目通常是开源项目。当这些开源爱好变得过于庞大时，开发人员该如何管理它们？
所有开放的业务和项目都面临这个问题：如果它们变得过于庞大，就需要更多成员来承担集体负担。他们的扩展策略非常重要。
一个受欢迎的开源社区最近就面临这个问题。该社区克服这个问题的方式教会了我们一些关于扩展开放式组织的艺术。
爆炸式增长
这个故事的核心是围绕虚拟专用网络软件 SoftEther 形成的社区。SoftEther 是筑波大学学生的成果，Daiyuu Nobori 是首席开发人员。Nobori 在 18 岁时开始开发 SoftEther 1.0（为了让他能够绕过他所在校园安装的防火墙）。该软件非常强大，甚至遭到日本政府的反对——因此，当时他甚至不允许将其作为免费软件发布。他创立了自己的公司 SoftEther Corporation，并在该公司下销售 SoftEther 软件。几年后，他继续开发，并将其作为硕士论文研究的一部分。
2013 年，他决定根据 GNU 通用公共许可证开源 SoftEther VPN 代码。他公司当时销售的 SoftEther VPN 版本更名为 PacketiX。在几周内，SoftEther VPN 获得了显着的吸引力，并成为最流行的可以绕过中国防火墙 (GFW) 的开源 VPN 应用程序之一。
SoftEther VPN 的巨大增长对 Nobori 来说是一个惊喜。最初，他对此感到高兴，并投入了大量精力来维护该项目。然而，随着时间的推移，优先级发生了变化，他无法像他希望的那样在该项目上花费那么多时间。一些贡献者向他的在线项目存储库发送了拉取请求，但这些请求被留在那里，等待他接受更改。
新社区，新担忧
人们担心缓慢的改变意味着该项目已经死了。有些人甚至提出了一个问题，直接询问 Nobori 该项目是否已经死了。几天后，Nobori 回复说该项目实际上没有死，但他想专注于软件的稳定性。实施新功能和更改需要彻底的测试，而这反过来又需要他花费大量时间。
用户和贡献者的不满情绪增加，Nobori 意识到他必须做些什么来解决这个正在分裂社区的问题。他只是一位经营企业的开发人员——但突然面临社区管理方面的挑战。经营一家制作开源软件的企业并非易事；现在，他必须管理和平衡社区期望和企业软件稳定性。最重要的是，他必须学习如何信任合适的社区贡献者。
这就是他所做的。
首先，Nobori 提出了对项目进行结构性更改的建议，这反映了 Red Hat 在其 Fedora 项目中使用的上游/下游模型。该模型允许一个上游项目接受最新的拉取请求、建议的更改和新功能，以及一个下游项目根据需要和适当性选择某些稳定功能并将其合并。这种改变允许想要最新功能的用户积极开发和测试这些功能，并向 Nobori 和社区提供反馈。另一方面，需要更高可预测性的公司可以继续使用稳定功能。
其次，Nobori 邀请个人成为上游项目维护者。用户对此感到兴奋，并提出了许多自己的意见。但现在 Nobori 又面临另一个挑战：关于应该如何完成这个模型的各种意见如潮水般涌来。例如，上游应该只是 GitHub 上的一个单独分支，还是应该是一个完全独立的存储库？社区继续讨论这些问题。
Nobori 的困境提醒我们，即使是组织中最聪明的人也只有一双手和一天 24 小时；一个人不可能做所有事情。即使是不参与软件业务或编程社区的开放式领导者也可以从 Nobori 扩展 SoftEther 项目的策略中学习。最重要的是，我们可以学习信任和授权在开放式组织中的重要性
- 通过信任创造激情。当人们感到被信任并获得某些权力时，他们会变得更有动力和热情地投入工作。Nobori 学会放手一些责任（因此也放手了一些权力），他的社区也因此奖励了他。
- 学会处理如潮水般涌来的不同意见。倾听他人的意见，尝试理解并与他们沟通，并从你学到的知识中做出最佳决策。最后，即使你作为领导者做出的决定与你在倾听时听到的意见不同，你的团队也会知道你已经理解了他们的观点，并且更愿意帮助你实现你的愿景。
最重要的是，SoftEther 的故事告诉我们，外面有很多人非常愿意帮助你承担重担。问题是：你愿意倾听他们的意见、信任他们并让他们帮助你吗？
评论已关闭。