将代码从封闭转向开放:JuliaCon 2020行业Julia用户讨论

2020年9月16日 | Jarrett Revels

尽管是虚拟举办,但今年的JuliaCon与我参加过的历届JuliaCon一样充满活力——开源技术计算社区的关键领导者们汇聚一堂,充满了新想法和热烈的讨论。虽然JuliaCon一直以来都受到需要大规模仿真和建模能力的学术科学家/工程师的欢迎,但最近几届会议的行业用户出席率大幅增加。

为了跟上这一增长趋势,今年的JuliaCon举办了比以往任何时候都多的面向行业的活动,从Jacob Quinn关于在Julia中构建微服务的研讨会到传统的年度Julia在生产环境中的BoF(“Birds-of-a-Feather”讨论会)。

这篇博文总结了一个类似的面向行业的会议:“将代码从封闭转向开放”的BoF,来自10多家公司的15多位社区成员参加了此次会议。会议的基本前提是

在私营公司/机构内部,很难实施有效的内部实践,使内部代码顺利过渡到高质量的开源贡献。在这个BoF中,我们将交流一些技巧,以最大限度地提高Julia生态系统中的开源影响力,同时最大限度地减少重构时间/工作量和代码波动。

BoF的由来

在深入探讨之前,请允许我提供一些背景信息——我是Jarrett 👋 之前是麻省理工学院Julia实验室的研究软件开发人员,我在2019年离开那里,与一些才华横溢的神经科学+Julia朋友一起创办了Beacon Biosignals。我们正在开发技术,使大脑监测更容易获取、更易于解释和更具可操作性,而Julia生态系统在我们的许多早期成功中发挥了关键作用。

到2020年初,Beacon已经在内部积累了许多有趣的工作,我知道我们应该开源/上游,但也许不出所料,当有许多其他紧迫的问题争夺我们有限的带宽时,实际上很难优先考虑这样做。我猜想,在Julia宇宙中,我们并不是唯一一家经常说出“啊,我们应该在某个时候开源<内部工具>”但很少付诸行动的私营实体。

我还认识到每个组织都是独一无二的,Beacon面临的贡献挑战可能与其他行业用户面临的挑战不同。“如果我们这些行业人士能够聚在一起,为我们的组织倾斜开源的成本/收益天平制定策略,那不是很好吗?”我心想。于是,BoF的提议诞生了。

本文的其余部分总结了在JuliaCon随后的讨论中产生的想法、观点和结论。

公司为何为Julia的开源生态系统做出贡献

Julia在行业中的许多早期采用者已经是Julia开源软件(OSS)生态系统中多产的贡献者(和雇主!)。以下是一些推动这些公司做出贡献的动机因素

行业开源贡献的障碍

行业用户在进行开源贡献时面临许多独特的技术和非技术挑战。以下是BoF上讨论的一些内容。

“闭源开放”依赖链

当可开源的代码具有需要保持闭源的非平凡(有时是传递的)依赖项时,就会出现此问题。例如,包A大部分可开源,但依赖于内部包B,而B不可开源。

一种解决方案(可能需要少量或大量工作,具体取决于所涉及的实现)是对要开源的代码的API进行重构,使其具有一些形式的控制反转,允许代码的内部用户传入封装私有依赖项的值。这样做不仅可以解决你的开源问题,还可以使你的代码更具可扩展性和可组合性,以便内部和外部用户都可以更容易地从贡献中获得价值。

当开源代码具有许多下游闭源依赖项时,也可能存在此问题的另一种形式。多位与会者指出,组织有时需要在其包的开源版本之上实现/维护额外的内部包装器。

首先不使用开源的组织

一位与会者提出,对于许多组织而言,允许员工进行开源贡献的第一个障碍是首先允许内部使用开源。对于没有开源经验的组织的决策者来说,很难理解开源的传统动机和论点。他们甚至可能对该流程的实际运作方式存在常见的误解。幸运的是,网上有大量针对此类受众的材料,组织成员可以以对其组织最有效的方式将其捆绑在一起。

许可、专利和知识产权

BoF期间报告的一个困难是获得组织批准以宽松许可证发布软件。这确实很棘手,因为没有一个放之四海而皆准的解决方案适用于每一家企业,而且非技术决策者可能不了解开源的法律方面。在BoF期间,针对此主题提出了一些不同的建议/想法

开源先前使用内部CI/CD的包

成功的开源项目的一个重要因素是CI日志通常应提供给所有贡献者。如果先前闭源的包使用了比公开提供的CI管道更好的属性的内部CI/CD管道,则满足此标准可能是一个繁重的标准。在某些情况下,可以使用更好的工具解决此问题的某些形式,例如,自托管(但公开可访问)的包注册表可以像Julia的通用注册表一样很好地销售开源包,但可能会利用自定义CI/CD进行预注册检查。

开源工作可能会暴露战略意图

一位与会者提出了一个他们在行业中面临的非常有趣的挑战:理论上,他们的公司很乐意将其技术的内部实现贡献回开源社区,但实际上无法这样做,因为这将表明该公司正在从事其市场中某个特定领域的工作,而他们不想公开披露。解决此问题的一种方法是匿名开源实现;但是,这显然不是理想的,并且对业务关键战略信息的风险通常过高。

Git历史/元数据保留

提交历史记录和相关的PR、问题等提供了有关设计决策的重要上下文,这些上下文理想情况下可以在从闭源到开源的过渡中保留下来。但是,这可能是一个重大的挑战,具体取决于代码的来源和文档实践。看来,如果……此过程更容易(或不那么必要)

结论

BoF 最终涉及了一些高级要点

在我看来,这最后一点是希望参与开源的行业用户面临的最具挑战性的障碍之一。为了帮助克服这个问题,我宣布了年度行业 Julia 用户贡献活动,这是一年一度的 Julia 社区黑客马拉松,参与的行业组织可以聚在一起回馈 Julia 生态系统。通过贡献活动,我希望我们能够…

对这篇博文、贡献活动和/或 Julia 在行业中的使用有任何想法/问题?加入Julia Slack#industry-users频道参与讨论!