为什么你的开源项目需要的不仅仅是程序员

单靠开发者无法创建能够满足各种需求并具有长久生命周期的开源项目;现在是时候欢迎更多角色和人才了。
54 位读者喜欢这篇文章。
Teamwork starts with communication across silos

Image by Mapbox Uncharted ERG, CC-BY 3.0 US

为什么开源项目会失败?

缺乏资金当然是一个主要因素,但它远不是开源项目未能实现可持续发展的唯一原因。有时,缺乏对如何为广阔市场创建产品的理解,或者知识产权 (IPR) 方面的一些根本性错误——例如未能正确许可你的代码。

如果任何开源项目没有正确处理这些基本问题,就很难维持下去。 跨界协作和迭代及扩展的能力受到阻碍,创新受到扼杀。我在许多人道主义项目中尤其看到了这些致命的缺陷充满激情的项目而这令人心碎的。

构建角色多样性

开源倾向于开发者为开发者编写代码的情况下蓬勃发展。这就是为什么如此多的底层技术通过开源开发(例如,Apache 和 Linux)已经成功了.

然而,在为开发者以外的人创造高质量的用户体验和产品时,开源的记录就参差不齐了。这是为什么呢?

其中一个重要原因是,大多数开源社区不鼓励甚至不欢迎具有不同专业知识的人。有时,甚至没有人承认他们的贡献。程序员得到了所有的爱,而编码以外的角色和贡献甚至都没有被考虑。

可持续的开源需要社区拥抱和奖励许多不同的才能。当然,开发者绝对是必要的,他们必须是任何开源项目成功的核心。但是如果没有来自营销专业知识的贡献,例如,可能无法彻底了解用户想要什么。如果没有产品管理的投入, 你就有可能无法开发一个面向开发者以外用户的产品。企业通常会投资于这些和其他角色因为他们的各种贡献对于交付成功的结果和创建可以投入生产并获得社区支持以实现长期可持续性的产品至关重要。

我经常发现开源开发社区中存在的一种冲突是对产品或项目管理的厌恶。诚然,产品管理尤其在公司中存在控制问题——他们可能会试图做一些事情,例如主导市场,或者从一种稀缺而不是富足的角度出发。这体现在行为中,并且与开源的精神背道而驰。

但是,公平地说,我认为我们开发者也从未被教导如何与产品管理良好合作。我们被告知,“如果你做 X,更多的人会使用你的产品”,我们回应说,“不,你不能告诉我关于我的孩子的事情。”我们不想听到,“是的,但是如果你换尿布,更多的人会喜欢你的孩子”,即使这是真的。

开源并不总是拥抱开发者以外的人才,这是为了促进长期稳定而必须改变的事情。

IEEE SA Open 的诞生

建立鼓励项目可持续性所需的工具和流程是我们目前在架构和设计 IEEE SA Open 中的重点。为此,引入角色多样性,建立一个邀请和奖励这些多样化贡献的平台和工具,对于创建 IEEE SA Open 至关重要。

我们正在创建我们的社区、营销和技术入门指南,以确保新加入的项目自动获得他们通常无法从技术平台获得的某种程度的支持。我们正在考虑将成熟度模型提升到高级流程和实践。例如,进步到 能力成熟度模型集成 (CMMI) 的 4 级(定量管理)和 5 级(优化)需要测量。从一开始就正确设置我们的流程并分配正确的指标以告知更好、更一致的评估将支持我们的可持续性。

这是我们与 IEEE 的联系如此重要的原因之一。标准世界做得特别好的一件事是流程,特别是 IEEE 拥有确保其流程公平并基于为人类利益推进技术的历史。IEEE 在超过 160 个国家/地区拥有超过 419,000 名会员,是世界上最大的致力于为人类推进技术的专业技术组织。它的根源可以追溯到 1884 年,当时电力和电信开始对社会产生重大影响,如今 IEEE 拥有超过 1,200 项有效标准和 650 多项正在开发中的标准。

IEEE SA Open 可以借鉴 IEEE 通过经验获得的在可持续性方面的最佳实践和经验教训。我们的目标是弥合全球标准制定和开源开发者社区之间的差距。这绝对是一种平衡行为,我们尊重这一点!

我们正在与全球开源和标准社区中的所有人联系,担任各种角色参与创建 IEEE SA Open。您可以参与该诞生项目,而且现在是时候了。如果对你来说有一些非常重要的事情,并且你已经看到在开源中被忽视了,那么现在是参与、分享你的经验并影响 IEEE SA Open 的创建的时候了。你可以帮助确保我们不犯那些错误。我们需要你独特的见解和投入。

接下来要阅读什么

为开源做贡献的 8 种非代码方式

无论你是一名新手程序员、一名经验丰富的退伍军人,或者根本不是一名工程师,除了编码之外,还有很多方法可以为开源项目做出贡献。与...

标签
headshot of silona
Silona Bonewald 是 IEEE SA Open 的执行董事,IEEE SA Open 是一个全面的平台,为开源社区提供经济高效的选择来开发和验证他们的项目。

3 条评论

是的。这是一个实际存在的问题,并且具有明显的影响。项目通常由与可用性或图形人员说不同语言的程序员运行。社区有时通过 IRC 进行交流,大多数非技术人员都不熟悉 IRC。在一个著名的项目中,我被告知我需要使用命令行来贡献图形设计。一个可用性的基本原则,“倾听用户”,被“用户很笨”驳回。或者“如果我能做这个[黑客],用户也能做到。”存在文化差异,并且到处都有“局外人”的障碍。

你需要拥有一个热情的环境,无论那些来你这里的人有什么样的专业知识。有时你需要向提出问题或提出建议的人解释一些事情。通过解释,你就能帮助自己清楚地阐明你的项目是什么以及它是如何运作的。
有时人们似乎只是来抱怨。至少花时间倾听,然后指出你看到的他们思维中的错误是值得的。有时他们实际上有一个很棒的观点,只是没有很好地表达出来,因此经过一些来回的讨论,你会看到他们建议的优点。

感谢分享

Creative Commons License这项工作根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.