1. 为什么公司要将代码开源
1.1. 当公司考虑为开源项目作出贡献时，事情远比表面上看到的要复杂得多，更不用说启动一个开源项目了
1.1.1. 要想在组织内获得对代码开源的支持，首先需要了解开源的动机
1.1.2. 启动一个开源项目是一种挑战，而且确实值得骄傲
1.2. 降低开发成本
1.2.1. 底线是每个公司都会考虑的问题，这往往是关注开源的主要动机
1.2.2. 在软件开发中，无论是最初的开发还是维护，都需要付出成本，其中包括新功能的开发、修复错误和解决安全问题
1.3. 为客户添加新的特性或功能
1.3.1. 每个工具都解决一个具体的问题（而且解决得很好），并且被设计与其他工具配合使用
1.3.2. 开源的另一个方面是能够改进库和工具，以使集成或客户体验更好
1.3.3. 在开源中，这只是提交一个补丁并将其合并到主代码仓库的问题
1.3.4. 作为一个额外的好处，公司也不需要维护修复后的工具版本，这被称为上游工作，并且可以更容易地为公司的产品引入新的特性和功能，而不需要你做任何工作
1.4. 更快推向市场
1.4.1. Facebook（现在是Meta）、Apple（苹果）、Amazon（亚马逊）、Netflix和Google（以上公司统称FAANG），它们的差异化因素都是在开源的基础上构建解决方案
1.4.2. Meta在崛起的过程中大量使用PHP
1.4.3. 苹果在构建Mac OS X时使用FreeBSD和Mach内核项目的许多部分
1.4.3.1. 在从经典Mac OS转向Mac OS X时，苹果意识到价值在于用户体验层面，所以构建自己的操作系统内核并没有太大意义
1.4.3.2. 摆脱Copland项目
1.4.3.3. 使用已经拥有这些功能的内核和操作系统可以更快地将它们推向市场
1.4.4. 亚马逊、Netflix和Google都使用了开源，并为更大的开源社群构建了大量的开源项目
1.4.5. 许多初创公司都是从开源社群中成长起来的，或者开创了自己的开源社群以推动创新
1.4.6. 开源的价值在于构建生态系统，还有一个次要的好处，即不仅可以更快地进入市场，还可以更快地建立市场
1.4.7. Cloud Foundry起源于2011年Pivotal Software启动的一个开源项目
1.4.7.1. Cloud Foundry作为标准—并且通过代理，Pivotal Software成了市场的领导者
1.5. 能够集中投资
1.5.1. 不必为应用程序的每一层都配备专家，只需为业务至关重要的特定部分配备专家
2. 在内部获得对代码开源的支持
2.1. 回顾已经存在的项目
2.1.1. 开源项目的资源一直都很紧缺
2.1.2. 开发者也可能没有足够的资源来编写测试、构建文档、筛选传入的问题、回答问题和处理安全问题
2.1.3. 与孤军奋战相比，相互合作有助于提高项目的效率，产生更大的影响，并完成更多的功能和用例
2.2. 构建商业案例
2.2.1. 代码并不都是公司特有的，也不是核心代码，而且如果让外部人员参与，可能获益
2.2.2. 开发者正在寻求扩展代码或遇到具有挑战性的问题，希望利用更广泛的专业知识
2.2.3. 代码与公司正在使用的开源项目相关，可以基于该项目构建，也可以从中派生，并且用例可能适用于其他人，因此将其推到上游对公司和项目都有好处
2.3. 获得盟友
2.3.1. 预算盟友，他可以帮助资助开源项目所需的费用，并投入时间和精力
2.3.2. 技术盟友，可以是软件工程师、架构师或管理者，他们目前正在参与代码相关的工作，并有望在未来参与或受到开源提案的影响
2.3.3. 执行主管
2.3.3.1. 可能并不是在所有情况下都需要这个角色
2.3.3.2. 执行主管也可能和预算盟友是同一个人
2.3.3.3. 最大的区别是，主管的重要作用是确保开源能够在公司内保持较高的战略优先级，这使得未来更容易得到更多资源和预算
2.3.3.4. 随着时间的推移，这位主管可能有机会在公司内建立一个更正式的开源团队
2.3.3.5. 开源项目办公室(Open Source Program Office，OSPO)，一般都是跨职能团队，在公司内支持开源工作
2.4. 设定预期
2.4.1. 时间预期，无论是开源的过程，还是建立贡献者基础
2.4.2. 内部影响，有时所开源代码可能没有你想象得那么能被广泛应用，或者在一段时间内贡献不会很大
2.4.3. 努力，开源需要很大的努力
3. 开源项目或代码仓库的检查清单
3.1. 法律审查
3.1.1. 即将开源的代码实际上是公司的知识产权，因此在为项目作出贡献或在其中启动新的开源项目之前，需要让法律团队对其进行审查
3.1.2. 法律审查，尤其是在公司第一次考虑为开源作出贡献或启动开源项目时，通常需要提前进行大量的教育工作
3.1.3. 在开源法律领域有一些出色的专家可以提供帮助
3.1.4. 从法律角度看，公司需要决定承受多大的风险取决于机会的可接受程度
3.1.5. 公司通过开源公开拥有的代码，是从某种意义上将其知识产权交给了全世界，但对公司而言，问题在于这有多大价值
3.2. 技术审查
3.2.1. 团队应该对代码进行审查，以确保代码有效
3.2.2. 代码应该有文档支持
3.2.3. 清除可能与未开源的内部项目或工具相关的任何代码或注释
3.2.4. 应该测试代码以验证其是否能够正常工作
4. 衡量组织在开源方面是否成功
4.1. 开源的成功真的很难定义
4.1.1. 不像构建产品那样简单—在构建产品时，成功取决于用户或客户的数量以及由此产生的收入
4.1.2. 在开源领域，成功除了涉及使用情况，还包括对组织可能产生的其他潜在影响
4.2. 开源项目往往不直接与收入挂钩（毕竟你是免费提供代码），所以很难简明地定义总投资收益率(Return On Investment，ROI)
4.3. 设定（合理）目标
4.3.1. 有明确性、可衡量性、可达成性、相关性和时限性(SMART)的目标是一个很好的目标设定框架
4.4. 识别和展示组织所作的贡献
4.4.1. 公司面临的一个重大挑战是如何认识开源项目的影响，因为它不像商业产品和服务那样与收入或客户数量等有形结果相关联
4.4.2. 采用可以跟踪多个贡献领域的测量工具：对于较小的项目，GitHub社群指标可能很有用，同时集成了代码提交、开放问题、拉取请求和讨论
4.4.3. 通过将开源贡献与年度目标或KPI挂钩来激励团队：这将使开源贡献从“有时间就去做”转变为“这是我的工作的一部分，公司以此为标准评估我”，注意不要将其定位为负面的，而是要作为一个机会，因为没有人喜欢在感觉像苦差事的事情上被评估
4.4.4. 制订开源贡献的内部表彰计划
中国股票配资网网提示：文章来自网络，不代表本站观点。
