上个月,我询问了 55 位 OpenStack 开发者 他们为什么决定向 OpenStack 提交一个补丁,以及是什么阻止了他们贡献更多。 这个抽样调查的对象是在过去 12 个月中只贡献过一次的人,寻找轶事证据,以了解我们如何改善偶尔贡献者的体验。 对我来说,偶尔贡献者与核心贡献者一样重要,以维持 OpenStack 的中长期增长。
由于社区可能已经聘用了 Python 开发者和系统运维人员中的最佳人选,为了维持 OpenStack 的增长,我们需要挖掘更广泛的 Python 社区,以及来自其他语言(首先是 Java)的大型分布式系统的专家。 了解新贡献者在首次加入 OpenStack 时面临的障碍,是使入门更容易、使多次贡献更频繁的第一步。
回复者 大多是 OpenStack 的用户,也就是为内部使用而部署 OpenStack 的开发者和 DevOps 人员,以及为客户开发和部署 OpenStack 的系统集成商。 偶尔贡献者的第三类群体是使用或被 OpenStack 使用的项目的开发者,例如 Docker 或 Ceph。
提交补丁的主要原因 从 将补丁在上游维护的实际便利性,到修复错误(在概念验证或更高级的部署阶段发现)或添加/修复功能以更好地将 OpenStack 与其他项目集成。 最后,人们贡献补丁是为了个人成长和丰富简历。
为什么他们不提交更多? 有 三个主要的绊脚石。
- 法律障碍延迟了贡献,甚至 阻止了(至少)一个贡献。 延迟的原因包括与客户的 NDA、与公司政策不兼容(以开源许可证发布软件和签署公司贡献者许可协议)。
- 延迟的另一个原因是贡献在审查队列中花费的时间太长。 补丁进入 OpenStack 存储库所需的时间被多次提及。
- 最后,缺乏在业余时间修复的简单问题:显然,社区修复简单错误的速度太快了。
结果不能被认为是具有代表性的,但它们似乎证实了法律障碍和审查速度正在阻止更多的随意贡献。 虽然已经有很多关于如何提高审查速度的讨论,但改变我们合法处理贡献的方式需要做出巨大的努力来改变 OpenStack 基金会的章程。 难以找到简单的修复问题对我来说是新的:这可能表明有很多人加入社区来修复这些“唾手可得的果实”,或者其他原因。 我认为需要在这个领域进行更多的分析。
最初发布在 maffulli.net。 在 Creative Commons 下转载。
评论已关闭。