未来的商业模式将以社交、移动、云以及大数据等技术为基础,而IT部门也开始意识到要想在今后赢得成功,必须拥有理想的流程、工具以及文化加以配合与支持。而在这方面,开源机制拥有着极为显著的优势地位。
一旦大家决定将开源机制作为企业IT基础设施当中的关键性组成部分,则需要采取以下几个重要步骤:
非常重要的一点在于了解开源部署流程当中的哪些组成部分之间存在着重要的依赖关系。具体而言,大家需要确切掌握这些组件的社区规模、稳定性乃至建议性功能等等。当某些组成部分表现出相互间的依赖关系之后,我们必须保证不会把两种协作效果不理想、甚至有所冲突的组件结合在一起。
具体作法:调查自己的开源技术使用方式,弄清到底在使用哪些项目/产品。将这些项目/产品按照实用性、重要性以及关键性等不同级别加以划分。确保我们拥有内部员工或者商业支持来打理这些作用于核心业务或者面向客户领域的关键性或者任何重要项目。大家也可以使用Black Duck这类商业产品来帮助自身了解当前正在使用哪些开源产品/项目。
与专有供应商推出的产品不同,开源项目并不具备帮助服务台。因此自我依赖、自我解决就成了一种必然,这意味着企业IT需要充分参考到开源工作当中,并具备学习并推进开源技能扩展的主观意愿。
具体作法:在上一步所提到的开源项目/产品调查完成之后,我们接下来需要明确保障关键性及重要项目获得成功的前提性技能,并制定专门的规划来提升此类技能。在目前的招聘工作中,我们应当将开源技能需求列入其中,并作为对求职者个人能力的考核标准之一。而对于现有内部人员,请调查他们的技能储备并筹备用于提升员工能力的培训方案。另外,制定未来招聘规划以确保企业能够招揽到其它潜在技能的新型人才。
对于任何已经编写完成的代码,我们需要决定将其安置在何处。请记住,如果大家将其贡献到产品当中,那么这部分代码就会成为该产品的一部分,并永远存在于未来的各个版本当中。
具体作法:确定所有编写完成的代码都被扩展或者集成至各开源产品/项目当中。对于所有扩展代码(即那些驻留在项目/产品当中,并用于实现额外功能的代码),我们需要在默认情况下认定其应该被贡献至上游代码库当中。而对于集成代码,首先评估其中有多大一部分能够被发布至某项目/产品的上游代码库当中。对于任何必须被保留在企业内部的集成代码,我们需要确保为其制定一套长期维护方案并划拨相应的支持预算。如果大家目前尚未制定出用于支持代码发布的开源管理政策及执行流程,请立即着手进行开发。
虽然开源部署会带来一系列优势,但这并不意味着我们应当为每一款应用都采用同样的处理方式。相当一部分实例证明,专有产品在某些场景下仍然拥有无可比拟的实际收效。最重要的是,大家必须意识并了解到,项目当中的哪些部分更适合以开源方式处理,而哪些部分并不太适合。
具体作法:确保对各软件组件的每一项评估都着眼于专有与开源两类选项。制定出一套结构化评估流程与标准,以确保各组件在评估过程中遵循同样的方法并拥有公正的决策。当然,也必须为开源项目/产品的推进工作提供必要的投资,从而确保整个比较能够以完全对等的方式展开。
开源之所以能够获得成功,在很大程度上是因为人们会不断对相关软件加以改进。让用户以积极态度参与到代码调整工作中当然非常重要,同样的,与开源项目的各位领导者并肩协作自然更值得称道。分享成功的发展战略亦有助于强化整个社区体系——毕竟成功的开源实施工作需要以最佳实践以及他人的经验作为依托与基础。
具体作法:参加区域乃至国际开源技术活动及会议。确保员工参与到重要乃至关键性开源项目/产品的相关工作当中,同时对其加以鼓励。将经济资助视为开源项目/产品当中至关重要的实现环节。
很多IT机构都会利用开源组件来构建自己的新型应用程序,但他们往往忽略了一项事实——这些应用程序也会因此成为一种工程技术层面的赌博。IT机构将开源组件纳入自主开发的DevOps工具链的作法非常常见,但由此带来的问题是,随着时间不断推移、最初的工程技术人员将逐渐离职,而他们留下的缺乏说明文档的系统将成为一团解不开的乱麻。在此之后,IT机构将意识到开源也同时成了导致遗留问题的根源。
享受自由与灵活的优势并不足以推动大家不顾一切地选择以开源机制为基础构建应用业务。我们所编写的每一行代码都应该成为自身职责范围内的一部分,而非任由他人指挥的不确定因素。
企业IT的本质在于迅速发展,而在在一系列变化的推动下,开源亦逐步在每家企业的IT环境当中占据愈发高企的比重。随着越来越多机构投向开源这股浪潮的怀抱,必要技能也将成为决定最终结果的先决条件之一——这不仅是为了更为明智地运用开源资源,同时也是为了确保企业自身能够在第三方平台横行的世界当中继续保持必要的独特竞争力。
原文标题:How to embrace open source tools in the enterprise