尽管是虚拟举办,但今年的JuliaCon与我参加过的历届JuliaCon一样充满活力——开源技术计算社区的关键领导者们汇聚一堂,充满了新想法和热烈的讨论。虽然JuliaCon一直以来都受到需要大规模仿真和建模能力的学术科学家/工程师的欢迎,但最近几届会议的行业用户出席率大幅增加。
为了跟上这一增长趋势,今年的JuliaCon举办了比以往任何时候都多的面向行业的活动,从Jacob Quinn关于在Julia中构建微服务的研讨会到传统的年度Julia在生产环境中的BoF(“Birds-of-a-Feather”讨论会)。
这篇博文总结了一个类似的面向行业的会议:“将代码从封闭转向开放”的BoF,来自10多家公司的15多位社区成员参加了此次会议。会议的基本前提是
在私营公司/机构内部,很难实施有效的内部实践,使内部代码顺利过渡到高质量的开源贡献。在这个BoF中,我们将交流一些技巧,以最大限度地提高Julia生态系统中的开源影响力,同时最大限度地减少重构时间/工作量和代码波动。
在深入探讨之前,请允许我提供一些背景信息——我是Jarrett 👋 之前是麻省理工学院Julia实验室的研究软件开发人员,我在2019年离开那里,与一些才华横溢的神经科学+Julia朋友一起创办了Beacon Biosignals。我们正在开发技术,使大脑监测更容易获取、更易于解释和更具可操作性,而Julia生态系统在我们的许多早期成功中发挥了关键作用。
到2020年初,Beacon已经在内部积累了许多有趣的工作,我知道我们应该开源/上游,但也许不出所料,当有许多其他紧迫的问题争夺我们有限的带宽时,实际上很难优先考虑这样做。我猜想,在Julia宇宙中,我们并不是唯一一家经常说出“啊,我们应该在某个时候开源<内部工具>”但很少付诸行动的私营实体。
我还认识到每个组织都是独一无二的,Beacon面临的贡献挑战可能与其他行业用户面临的挑战不同。“如果我们这些行业人士能够聚在一起,为我们的组织倾斜开源的成本/收益天平制定策略,那不是很好吗?”我心想。于是,BoF的提议诞生了。
本文的其余部分总结了在JuliaCon随后的讨论中产生的想法、观点和结论。
Julia在行业中的许多早期采用者已经是Julia开源软件(OSS)生态系统中多产的贡献者(和雇主!)。以下是一些推动这些公司做出贡献的动机因素
保持社区的存在感对于招聘社区合作者和未来的正式员工来说非常重要,特别是为了吸引Julia社区中普遍存在的科学领域专家。
开源软件鼓励构建范围明确、可组合的API,并避免正交功能的过度耦合。
开源项目鼓励以一种降低贡献/协作障碍的方式来构建/维护项目
对Julia生态系统健康/增长的改进会惠及为其做出贡献的公司,因为更强大/功能更丰富的生态系统会吸引更多优秀的社区成员,并提高现有社区成员的生产力。
作为一门语言,Julia的强组合性(及其强大的包管理器)使得从一开始就构建和供应商自包含包变得相对直观。从一开始,此类包就比传统单片代码库的组件更容易与内部/私有代码分离,从而降低了公开发布它们的所需工作量。
使用开源依赖项的公司可以更容易地诊断/修复他们在特定使用依赖项时遇到的问题。将这些补丁上游可以使补丁由更广泛的社区进行测试和维护。
公司可以更容易地扩展开源依赖项以更好地满足其特定需求。通过将这些扩展上游(或以它们自己的形式发布为包),公司可以推动依赖项朝着对其最有影响力的方向发展。
行业用户在进行开源贡献时面临许多独特的技术和非技术挑战。以下是BoF上讨论的一些内容。
当可开源的代码具有需要保持闭源的非平凡(有时是传递的)依赖项时,就会出现此问题。例如,包A
大部分可开源,但依赖于内部包B
,而B
不可开源。
一种解决方案(可能需要少量或大量工作,具体取决于所涉及的实现)是对要开源的代码的API进行重构,使其具有一些形式的控制反转,允许代码的内部用户传入封装私有依赖项的值。这样做不仅可以解决你的开源问题,还可以使你的代码更具可扩展性和可组合性,以便内部和外部用户都可以更容易地从贡献中获得价值。
当开源代码具有许多下游闭源依赖项时,也可能存在此问题的另一种形式。多位与会者指出,组织有时需要在其包的开源版本之上实现/维护额外的内部包装器。
一位与会者提出,对于许多组织而言,允许员工进行开源贡献的第一个障碍是首先允许内部使用开源。对于没有开源经验的组织的决策者来说,很难理解开源的传统动机和论点。他们甚至可能对该流程的实际运作方式存在常见的误解。幸运的是,网上有大量针对此类受众的材料,组织成员可以以对其组织最有效的方式将其捆绑在一起。
BoF期间报告的一个困难是获得组织批准以宽松许可证发布软件。这确实很棘手,因为没有一个放之四海而皆准的解决方案适用于每一家企业,而且非技术决策者可能不了解开源的法律方面。在BoF期间,针对此主题提出了一些不同的建议/想法
组织可以指定一位受工程和业务利益相关者信任的知情决策者,赋予其对开源决策的最终否决权。在Beacon,这个人是首席技术官(我!),而在Zapata,这个人是首席产品官。无论他们的头衔或角色是什么,对于一个组织来说,拥有一位能够弥合技术和业务关注点之间差距的决策者至关重要。
组织应在最开始就在其开源政策中直接包含适当的许可标准。例如,以下是Beacon的政策,直接摘自我们的工程手册
任何可以合理地开源而不会损害Beacon的软件都应开源。如果开源会增加大量的维护/开发负担、引入新的安全风险或泄露宝贵的知识产权,则开源代码可能会造成损害。我们根据MIT许可证开源代码;它非常出名、没有争议,并且可能是几乎所有其他组织普遍接受的少数许可证之一。此外,它还可以作为我们开源决策的检查——如果MIT许可证对于给定的代码片段来说过于宽松,那么我们可能一开始就不应该开源该代码!
那些主要商业产品本身就是软件,而不是软件支持的产品或服务的公司,在区分可开源组件和不可开源组件方面可能会遇到更大的困难。在这种情况下,组织成员可以寻找其市场(或相邻/类似市场)中类似的公司,这些公司似乎“能够很好地进行开源”,并试图了解这些公司的决策,并弄清楚相同的推理是否(或不)适用于他们自己的情况。
如果可能,组织应与其知识产权战略相协调地制定其开源计划。预先制定包含开源的知识产权战略比在现有知识产权政策之上进行开源政策的改造更容易。对于后期公司,新产品/服务的发展可以提供一个机会来重新审视旧的知识产权模型,并将其改造为更适合开源的战略。
成功的开源项目的一个重要因素是CI日志通常应提供给所有贡献者。如果先前闭源的包使用了比公开提供的CI管道更好的属性的内部CI/CD管道,则满足此标准可能是一个繁重的标准。在某些情况下,可以使用更好的工具解决此问题的某些形式,例如,自托管(但公开可访问)的包注册表可以像Julia的通用注册表一样很好地销售开源包,但可能会利用自定义CI/CD进行预注册检查。
一位与会者提出了一个他们在行业中面临的非常有趣的挑战:理论上,他们的公司很乐意将其技术的内部实现贡献回开源社区,但实际上无法这样做,因为这将表明该公司正在从事其市场中某个特定领域的工作,而他们不想公开披露。解决此问题的一种方法是匿名开源实现;但是,这显然不是理想的,并且对业务关键战略信息的风险通常过高。
提交历史记录和相关的PR、问题等提供了有关设计决策的重要上下文,这些上下文理想情况下可以在从闭源到开源的过渡中保留下来。但是,这可能是一个重大的挑战,具体取决于代码的来源和文档实践。看来,如果……此过程更容易(或不那么必要)
……将设计决策及其动机作为惯例捕获在与历史无关的文档中。
…待开源的代码来自其自身代码库,而不是来自单体代码库。
…开发平台与开源平台相同,例如,从私有 GitHub 代码库迁移到公共 GitHub 代码库比从 GitLab 迁移到 GitHub 更容易(尽管Invenia已经证明后者完全可行!)。
BoF 最终涉及了一些高级要点
与开源相关的许多技术问题,也是构建健壮且模块化软件本身面临的难题。这个过程通常类似于(有时等同于)从以应用程序为中心的代码库中提取可重用库。Julia 生态系统通过为贡献者提供优秀的开源工具、精心设计的包管理器,以及当然还有高度可组合的基础语言,缓解了许多传统上与该过程相关的负担。
许多与开源相关的技术问题源于从闭源到开源的过渡,而不是开源代码的事后维护。这可能表明,在可能的情况下,尽早开源代码(甚至可能默认开源)更有利,以避免积累阻碍后期开源的技术/组织债务。
许多与开源相关的组织问题源于对关键决策者激励不足以及开源目标与业务目标错位。
在我看来,这最后一点是希望参与开源的行业用户面临的最具挑战性的障碍之一。为了帮助克服这个问题,我宣布了年度行业 Julia 用户贡献活动,这是一年一度的 Julia 社区黑客马拉松,参与的行业组织可以聚在一起回馈 Julia 生态系统。通过贡献活动,我希望我们能够…
…培养/加强跨组织边界的协作,并减少潜在的重复工作。
…既推动 Julia 生态系统为“生产”用途做好准备,也证明其已做好准备。
…为相关组织提供一个很好的宣传激励,让他们投入时间并参与开源工作。
…为整个 Julia 社区提供宣传和技术方面的益处。
…玩得开心!
对这篇博文、贡献活动和/或 Julia 在行业中的使用有任何想法/问题?加入Julia Slack的#industry-users
频道参与讨论!