软件在标准制定之前的问题

开源项目需要认真对待在其交付成果中包含标准。
461 位读者喜欢这篇文章。
A guide to packing and preparing for a tech conference

Opensource.com

无论从哪个角度衡量,开源软件作为旧式专有方式的替代方案的崛起都是非凡的。如今,仅 GitHub 就托管着数千万个库,主要项目的数量也在迅速增长。 截至撰写本文时,Apache 软件基金会托管着 300 多个项目,而 Linux 基金会支持 60 多个项目。 同时,更专注于特定领域的 OpenStack 基金会 拥有 60,000 名会员,遍布 180 多个国家/地区。

那么,这张图景可能有什么问题呢?

缺少的是足够的意识,即虽然开源软件可以满足绝大多数用户的需求,但仅靠开源软件本身无法满足所有需求。 更糟糕的是,开源社区的许多成员(包括业务主管和开发人员)对使用最合适的工具来弥合差距不感兴趣。

让我们首先确定需要解决的问题,然后看看过去是如何解决这个问题的。

问题在于,通常有许多项目试图解决更大问题中的同一小部分。 客户希望能够在竞争产品之间进行选择,并在不满意时轻松切换产品。 目前这不可能实现,并且在解决此问题之前,它将阻碍开源的采用。

这也不是一个新问题,或者是一个没有传统解决方案的问题。 在一个半世纪的过程中,通过标准的制定,满足了用户对广泛选择和自由切换供应商的期望。 在物理世界中,您可以在无数的螺丝、灯泡、轮胎、延长线,甚至适合您选择的葡萄酒形状的酒杯供应商之间进行选择,因为标准为每种商品提供了物理规格。 在健康和安全领域,我们的福祉依赖于私营部门制定的数千项标准,这些标准确保了适当的结果,同时最大限度地提高了竞争。

当信息和通信技术 (ICT) 出现时,也采用了相同的方法,成立了主要的组织,例如国际电信联盟 (ITU)、国际电工委员会 (IEC) 以及电气和电子工程师协会标准协会 (IEEE-SA)。 随后成立了近 1,000 个联盟,以制定、推广或测试 ICT 标准的合规性。

虽然并非所有 ICT 标准都实现了无缝互操作性,但我们今天生活的技术世界之所以存在,要归功于数以万计的必要标准,这些标准实现了这一承诺,并在计算机、移动设备、Wi-Fi 路由器以及实际上所有使用电力的设备中得到实施。

这里的重点是,经过很长一段时间,一个系统演变而来,可以满足客户对广泛产品供应、避免供应商锁定以及在全球范围内享受服务的愿望。

现在让我们看看开源软件是如何发展的。

好消息是,伟大的软件正在被创造出来。 坏消息是,在云计算和网络虚拟化等许多关键领域,没有哪个基金会正在开发整个堆栈。 相反,离散的项目开发单独的层或层的一部分,然后依靠对等项目之间在堆栈上下游的实时、基于善意的协作。 当这个过程运作良好时,结果是好的,但有可能像传统的专有产品一样造成锁定。 当这个过程运作不佳时,可能会导致供应商和社区成员浪费大量时间和精力,以及让客户的期望落空。

提供解决方案的明确方法是制定标准,让客户避免锁定,同时鼓励通过增值功能和服务提供多种竞争解决方案。 但是,除了极少数例外,这并不是开源世界正在发生的事情。

这背后的主要原因是开源社区普遍认为标准是限制性的、不相关的和不必要的。 在单个、良好集成的堆栈中,情况可能如此。 但是,对于想要选择自由和持续、强大竞争的客户来说,结果可能是回到被技术锁定的糟糕旧时代,尽管有多个供应商提供类似集成的堆栈。

在 Yaron Haviv 于 2017 年 6 月 14 日撰写的文章“除非我们合作,否则我们将被专有云奴役”中可以找到对该问题的良好描述。

跨项目集成在当今的开源生态系统中并不完全普遍,这是一个问题。 能够实现大规模协作并建立在分层和模块化架构上的开源项目(例如 Linux一次又一次地证明了它们的成功。 但是 Linux 的思想与当今许多开源社区的普遍状态形成鲜明对比。

例如:大数据生态系统,其中许多重叠的实现很少共享组件或使用通用 API 和层。 它们也往往缺乏标准线路协议,并且每个处理框架(例如 Spark、Presto 和 Flink)都有自己的数据源 API。

这种缺乏协作正在引起焦虑。 如果没有协作,项目就无法互换,从而对客户造成负面影响,基本上将他们锁定在其中,并减慢了项目的发展速度,因为每个项目都必须从头开始并重新发明轮子。

Haviv 提出了两种解决这种情况的方法

  • 项目之间更紧密的协作,从而实现整合、消除多个项目之间的重叠以及堆栈内更紧密的集成;
  • 开发 API 以使切换更容易。

这两种方法都有道理。 但是,除非发生变化,否则我们只会看到第一种方法,而这就是锁定前景所在。 结果将是行业发现自己处于过去的 WinTel 世界或整个 Apple 历史中的情况,在这些情况中,竞争产品选择被牺牲以换取紧密集成。

如果开源项目继续忽视标准的需求,以便竞争可以在层内甚至堆栈之间存在,那么同样的事情可能会并且很可能会在新开源世界中发生。 就目前的情况而言,这种情况几乎不可能发生。

原因是,虽然有些项目口头上表示先开发软件,然后再制定标准,但实际上并没有兴趣继续推进标准。 主要原因是大多数商人和开发人员对标准知之甚少。 不幸的是,这太容易理解了,而且可能会变得更糟。 原因有以下几点

  • 大学几乎没有将培训时间用于标准;
  • 过去拥有标准专业人员的公司已经解散了这些部门,现在部署培训较少的工程师参与标准组织;
  • 在标准工作中建立代表雇主的专业知识几乎没有职业价值;
  • 参与标准活动的工程师可能需要以他们认为的最佳技术解决方案为代价,来促进其雇主的战略利益;
  • 许多公司内部的开源开发人员和标准专业人员之间几乎没有沟通;
  • 许多软件工程师认为标准与 FOSS 定义的“四项自由”直接冲突。

现在让我们看看开源世界正在发生什么

  • 今天的任何软件工程师都不可能不知道开源;
  • 它是工程师们感到舒适且经常在日常生活中使用的工具;
  • 许多最性感、最前沿的工作都在开源项目中完成;
  • 在热门开源领域具有专业知识的开发人员非常受欢迎,并且薪酬溢价很高;
  • 开发人员在备受尊敬的项目中开发软件时享有前所未有的自主权;
  • 几乎所有主要的 ICT 公司都参与了多个开源项目,通常每家公司最高会员级别的综合成本(会费加上专职员工)超过每年 100 万美元。

如果孤立地看待这种比较,似乎表明标准将在 ICT 领域被扫进历史的垃圾堆。 但现实情况更为微妙。 它也忽略了开源开发可能比许多人想象的更脆弱的现实。 原因包括以下几点

  • 项目的主要支持者可能会撤销承诺(有时确实如此),从而导致项目失败;
  • 社区内部的个性和文化冲突可能会导致中断;
  • 关键项目更紧密整合的能力仍有待观察;
  • 专有游戏有时会削弱,在某些情况下甚至导致资金充足的开源项目失败;
  • 随着时间的推移,个别公司可能会认为他们的开源策略未能带来他们预期的回报;
  • 一些备受瞩目的关键开源项目失败可能会导致供应商退缩对新项目的投资,并说服客户对承诺开源解决方案持谨慎态度。

奇怪的是,最积极地解决这些问题的协作实体是标准组织,部分原因是他们(正确地)感到受到开源协作兴起的威胁。 他们的回应包括升级其知识产权政策,以允许所有类型的协作在同一保护伞下进行,包括开发开源工具、在标准中包含开源代码以及开发标准的开源参考实现等其他类型的工作项目。

结果是,标准组织正在改造自己,以提供一种方法中立的场所来开发完整的解决方案。 这些解决方案可以包含市场可能需要的任何类型的协作工作产品或混合工作产品。 随着这个过程的继续,供应商很可能会在标准组织内寻求一些原本可能进入开源基金会的倡议。

由于所有这些原因,至关重要的是,开源项目要认真对待在其交付成果中包含标准,或者与适当的标准制定者合作,共同提供完整的解决方案。 结果不仅会带来更多的产品选择和更少的客户锁定,还会让客户对开源解决方案更有信心,从而大大增加对开源产品和服务的需求和使用。

如果这种情况没有发生,那将是非常遗憾的,因为开源事业损失最大。 现在由项目来决定是给市场提供它想要和需要的,还是让自己适应未来影响力下降而不是持续成功的局面。

本文最初发表在 ConsortiumInfo.org 的 Standards Blog 上,并经许可转载。

User profile image.
Andy 帮助 CEO、管理团队及其投资者建立成功的组织。 在地区范围内,自 1979 年以来,他一直是为高科技公司提供具有商业头脑的法律顾问和战略建议的先驱。

1 条评论

将 NodeJS 模块的丰富性及其所有不同的风格与基于标准化 API 的 Java 库进行比较。 在我看来,当不同的实现提供相同的 API 时,生产效率要高得多。

© . All rights reserved.