真实故事。一个项目团队需要一个开源工具。根据他们公司的政策，团队要求他们的信息系统 (IS) 部门下载该工具。他们很快被大量问题和需要填写的表格轰炸，他们都照做了。信息系统部门对提供的信息不满意，也无法做出决定，然后将请求转发给了法务部门。
经过尽职调查，法务部门允许使用该工具，但前提是团队必须获得客户的批准（即：客户承担所有责任和义务）。所讨论的工具？不起眼的 unix2dos！
unix2dos 是一个工具，用于将 换行符 在 文本文件 中从 Unix 格式（换行符）转换为 DOS 格式（回车符 + 换行符），反之亦然——来自维基百科
团队认为不值得付出努力和花费客户的时间。他们悄悄地转入地下，下载并在个人电脑上使用了该工具。
这个故事的寓意是什么？
工程师在日常工作中需要并使用开源。他们愿意遵守公司的政策，但是当他们发现政策在某种程度上不合理并阻碍了他们的生产力时，他们会找到变通方法。是的，组织可能不喜欢它，甚至可能认为这是一个风险，但解决方案不是更严格的政策，而是在实践中有效的政策。
如何编写在实践中有效的开源策略
- 通常情况下，开源策略是由信息系统部门编写的，并且在字面上盲目执行，但精神上并非如此。一个好的开源策略最好由那些受影响的人员在现场编写和定义——工程师和交付团队作为主要利益相关者，而信息系统和法务部门作为次要利益相关者。
- 接受开源软件及其使用的现实，并将其视为一种推动者。许多组织以过于悲观的眼光看待开源，而不是将其视为业务推动者。开源现在已成为现实。开源组件构成了当今解决方案架构的关键部分。
- 认识到开源程序和工具的不同用途。并非所有开源软件的用途都是相同的。
三种常见的开源软件使用类别
- 作为工具： 开源软件在开发过程中以二进制形式按原样使用，无需修改，并且作为项目交付物之外的外部组件。 I集成开发环境 (IDE) 和编辑器，如 Eclipse、VI；编译器，如 gcc；文档工具，如 doxygen；Web 服务器，如 tomcat 或 glassfish；以及更多更多都属于这一类。符合开源许可的许可证对工具的使用方式没有任何限制，无论是用于商业目的还是个人目的。
- 作为项目交付物的一部分，无需修改： 示例包括 Javascript 库、Hibernate 等框架。此类用途需要考虑许可限制。例如，虽然 GPL 许可的软件不能与专有软件结合使用，但 LGPL 更宽松，允许它与专有代码链接。
- 作为项目交付物的一部分，需要修改： 此类用途需要更深入地了解所涉及的许可和条款，以便随后分发修改后的源代码。
公司的开源策略应该针对最常见的用途。在实践中，第一种和第二种用途比第三种类别更常见。最不常见的用途可以进行更严格的审查过程，同时为前两种用途创建自动化或快速通道的许可。
虽然许多客户都了解开源软件并鼓励使用它，但他们也对知识产权污染保持警惕——这是可以理解的。有些客户不想为使用的每一种工具而烦恼，而另一些客户则非常关注，并将每一种开源工具或程序都通过审批流程。该策略可以根据每个客户的偏好进行调整。例如，一套常用的工具可以在项目开始之前在工作说明或其他协议中列出并预先批准。
政策的执行也很重要。制定完善的政策是一回事。不得不一遍又一遍地向多个团队解释为什么我们需要特定的开源软件程序或工具（这些团队显然不了解 eclipse-java bundle 和 eclipse-jee bundle 之间的区别，或者为什么在 maven 构建期间下载 jar 包）是一件痛苦的事情。执行政策的人员（通常是信息系统团队）需要了解开源基础知识。例行的政策工作流程可以通过不断增长和自我学习的基础设施（如内部开源存储库）实现自动化，该存储库可以自动下载、跟踪和分发内部软件。
授权并教育人们！再多的政策措辞也无法涵盖所有方面。因此，技术人员理解他们在做什么至关重要。直线经理和技术主管需要被授权来指导、做出决策和采取行动。
2 条评论