mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
118 lines
11 KiB
Markdown
118 lines
11 KiB
Markdown
在标准建立之前，软件所存在的问题
|
||
============================================================
|
||
|
||
> 开源项目需要认真对待交付成果中所包含的标准
|
||
|
||
|
||
|
||
无论以何种标准来衡量，开源软件作为传统的专有软件的替代品而崛起，取得了不错的效果。 如今，仅 Github 中就有着数以千万计的代码仓库，其中重要项目的数量也在快速增长。在本文撰写的时候，[Apache 软件基金会][4] 开展了超过 [300 个项目][5]， [Linux 基金会][6] 支持的项目也超过了 60 个。与此同时，[OpenStack 基金会][7] 在 180 多个国家拥有超过 60,000 名成员。
|
||
|
||
这样说来，这种情景下有什么问题么？
|
||
|
||
开源软件在面对用户的众多需求时，由于缺少足够的意识，而无法独自去解决全部需求。 更糟糕的是，许多开源软件社区的成员（业务主管以及开发者）对利用最合适的工具解决这一问题并不感兴趣。
|
||
|
||
让我们开始找出那些有待解决的问题，看看这些问题在过去是如何被处理的。
|
||
|
||
问题存在于：通常许多项目都在试图解决一个大问题当中重复的一小部分，而客户希望能够在竞争产品之间做出选择，不满意的话还能够轻松选择其他产品。但是现在看来都是不可能的，在这个问题被解决之前它将会阻碍开源软件的使用。
|
||
|
||
这已经不是一个新的问题或者没有传统解决方案的问题了。在一个半世纪以来，用户期望有更多的选择和自由来变换厂商，而这一直是通过标准的制定来实现的。在现实当中，你可以对螺丝钉、灯泡、轮胎、延长线的厂商做出无数多的选择，甚至于对独特形状的红酒杯也可以专注选择。因为标准为这里的每一件物品都提供了物理规格。而在健康和安全领域，我们的幸福也依赖于成千上万的标准，这些标准是由私营行业制定的，以确保在最大化的竞争中能够有完美的结果。
|
||
|
||
随着信息与通信技术（ICT）的发展，以同样类似的方式形成了一些重要的组织机构，例如：国际电信联盟（ITU）、国际电工委员会（IEC），以及电气与电子工程师学会标准协会（IEEE-SA）。近千家财团遵循 ICT 标准来进行开发、推广以及测试。
|
||
|
||
虽然并非是所有的 ICT 标准都形成了无缝对接，但如今在我们生活的科技世界里，成千上万的基本标准履行着这一承诺，这些标准包含了计算机、移动设备、Wi-Fi 路由器以及其他一切依赖电力来运行的东西。
|
||
|
||
关键的一点，在很长的一段时间里，由于客户对拥有种类丰富的产品、避免受制于供应商，并且享受全球范围内的服务的渴望，逐渐演变出了这一体系。
|
||
|
||
现在让我们来看看开源软件是如何演进的。
|
||
|
||
好消息是伟大的软件已经被创造出来了。坏消息是对于像云计算和虚拟化网络这样的关键领域，没有任何单独的基金会在开发整个堆栈。取而代之的是，单个项目开发单独的一层或者多层，依靠需要时才建立的善意的合作，这些项目最终堆叠成栈。当这一过程运行良好时，结果是好的，但也有可能形成与传统的专有产品同样的锁定。相反，当这一过程运行不良时，坏的结果就是它会浪费开发商、社区成员的时间和努力，同时也会辜负客户的期望。
|
||
|
||
最明确的解决方法的创建标准，允许客户避免被锁定，鼓励多个解决方案通过对附加服务和功能进行有益的竞争。当然也存在着例外，但这不是开源世界正在发生的情况。
|
||
|
||
这背后的主要原因在于，开源社区的主流观点是：标准意味着限制、落后和多余。对于一个完整的堆栈中的单独一层来说，可能就是这样。但客户想要选择的自由、激烈的竞争，这就导致回到了之前的坏结果上，尽管多个厂商提供相似的集成堆栈，但却被锁定在一个技术上。
|
||
|
||
在 Yaron Haviv 于 2017 年 6 月 14 日所写的 “[除非我们协作，否则我们将被困在专有云上][8]” 一文中，就有对这一问题有着很好的描述。
|
||
|
||
> 在今天的开源生态系统当中存在一个问题，跨项目整合并不普遍。开源项目能够进行大型合作，构建出分层的模块化的架构，比如说 Linux — 已经一次又一次的证明了它的成功。但是与 Linux 的意识形成鲜明对比的就是如今许多开源社区的日常状态。
|
||
>
|
||
> 举个例子：大数据生态系统，就是依赖众多共享组件或通用 API 和层的堆叠来实现的。这一过程同样缺少标准的线路协议，同时，每个处理框架（看看 Spark、Presto 和 Flink）都拥有独立的数据源 API。
|
||
>
|
||
> 这种合作的缺乏正在造成担忧。缺少了合作，项目就会变得不通用，结果对客户产生了负面影响。因为每个人都不得不从头开始，重新开发，这基本上就锁定了客户，减缓了项目的发展。
|
||
|
||
Haviv 提出了两种解决方法：
|
||
|
||
* 项目之间更紧密的合作，联合多个项目消除重叠的部分，使堆栈内的整合更加密切；
|
||
* 开发 API ，使切换更加容易。
|
||
|
||
这两种方法都能达到目的。但除非事情能有所改变，我们将只会看到第一种方法，这就是前边展望中发现的技术锁定。结果会发现工业界，无论是过去 WinTel 的世界，或者纵观苹果的历史，相互竞争的产品都是以牺牲选择来换取紧密整合的。
|
||
|
||
同样的事情似乎很有可能发生在新的开源界，如果开源项目继续忽视对标准的需求，那么竞争会存在于层内，甚至是堆栈间。如果现在能够做到的话，这样的问题可能就不会发生了。
|
||
|
||
因为如果口惠无实开发软件优先、标准在后的话，对于标准的制定就没有真正的兴趣。主要原因是，大多数的商人和开发者对标准知之甚少。不幸的是，我们能够理解这些使事情变得糟糕的原因。这些原因有几个：
|
||
|
||
* 大学几乎很少对标准进行培训；
|
||
* 过去拥有专业的标准人员的公司遣散了这些部门，现在的部署工程师接受标准组织的培训又远远不够；
|
||
* 在建立雇主标准工作方面的专业知识方面几乎没有职业价值；
|
||
* 参与标准活动的工程师可能需要以他们认为是最佳技术解决方案为代价来延长雇主的战略利益；
|
||
* 在许多公司内部，专业的标准人员与开源开发者之间鲜有交流；
|
||
* 许多软件工程师将标准视为与 FOSS 定义的“四大自由”有着直接冲突。
|
||
|
||
现在，让我们来看看在开源界正在发生什么:
|
||
|
||
* 今天大多数的软件工程师鲜有不知道开源的；
|
||
* 工程师们每天都在享受着开源工具所带来的便利；
|
||
* 许多令人激动的最前沿的工作正是在开源项目中完成的；
|
||
* 在热门的开源领域，有经验的开发者广受欢迎，并获得了大量实质性的奖励；
|
||
* 在备受好评的项目中，开发者在软件开发过程中享受到了空前的自主权；
|
||
* 事实上，几乎所有的大型 ICT 公司都参与了多个开源项目，最高级别的成员当中，通常每个公司每年的合并成本（会费加上投入的雇员）都超过了一百万美元。
|
||
|
||
如果脱离实际的话，这个比喻似乎暗示着标准是走向 ICT 历史的灰烬。但现实却有很大差别。一个被忽视的事实是，开源开发是比常人所认为的更为娇嫩的花朵。这样比喻的原因是：
|
||
|
||
* 项目的主要支持者们可以撤回（已经做过的事情），这将导致一个项目的失败；
|
||
* 社区内的个性和文化冲突会导致社区的瓦解；
|
||
* 重要项目更加紧密的整合能力有待观察；
|
||
* 有时专有权在博弈中被削弱，高资助的开源项目在某些情况下会导致失败。
|
||
* 随着时间的推移，可能个别公司认为其开源策略没能给他们带来预期的回报；
|
||
* 对关键开源项目的失败引起过多关注，会导致厂商放弃一些投资中的新项目，并说服客户谨慎选择开源方案。
|
||
|
||
奇怪的是，最积极解决这些问题的协作单位是标准组织，部分原因是，他们已经感受到了开源合作的崛起所带来的威胁。他们的回应包括更新知识产权策略以允许在此基础上各种类型的合作，开发开源工具，包含开源代码的标准，以及在其他类型的工作项目中开发开源手册。
|
||
|
||
结果就是，这些标准组织调整自己成为一个近乎中立的角色，为完整方案的开发提供平台。这些方案能够包含市场上需要的各种类型的合作产品，以及混合工作产品。随着此过程的继续，很有可能使厂商们乐意推行一些包含了标准组织在内的举措，否则他们可能会走向开源基金。
|
||
|
||
重要的是，由于这些原因，开源项目开始认真对待项目交付所包含的标准，或者与标准开发商合作，共同为完整的方案做准备。这不仅会有更多的产品选择，对客户更少的限制，而且也给客户在开源方案上更大的信心，同时也对开源产品和服务有更多的需求。
|
||
|
||
倘若这一切不发生的话，将会是一个很大的遗憾，因为这是开源所导致的巨大损失。而这取决于如今的项目所做的决定，是供给市场所需，还是甘心于未来日趋下降的影响力，而不是持续的成功。
|
||
|
||
_本文源自 ConsortiumInfo.org的 [Standards Blog][2]，并已获得出版许可_
|
||
|
||
（题图：opensource.com）
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
作者简介：
|
||
|
||
Andy Updegrove - Andy helps 的 CEO，管理团队，由他们的投资者建立的成功的组织。他曾作为一名先驱，自1979年起，就为高科技公司提供商业头脑的法律顾问和策略建议。在全球舞台上，他经常作为代表，帮助推动超过 135 部全球标准的制定，宣传开源，主张联盟，其中包括一些世界上最大，最具影响力的标准制定机构。
|
||
|
||
---
|
||
|
||
via: https://opensource.com/article/17/7/software-standards
|
||
|
||
作者：[Andy Updegrove][a]
|
||
译者：[softpaopao](https://github.com/softpaopao)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://opensource.com/users/andrewupdegrove
|
||
[1]:https://opensource.com/article/17/7/software-standards?rate=kKK6oD-vGSEdDMj7OHpBMSqASMqbz3ii94q1Kj12lCI
|
||
[2]:http://www.consortiuminfo.org/standardsblog/article.php?story=20170616133415179
|
||
[3]:https://opensource.com/user/16796/feed
|
||
[4]:https://www.apache.org/
|
||
[5]:https://projects.apache.org/
|
||
[6]:https://www.linuxfoundation.org/
|
||
[7]:https://www.linuxfoundation.org/projects/directory
|
||
[8]:https://www.enterprisetech.com/2017/06/14/well-enslaved-proprietary-clouds-unless-collaborate/
|
||
[9]:https://opensource.com/users/andrewupdegrove
|
||
[10]:https://opensource.com/users/andrewupdegrove
|
||
[11]:https://opensource.com/article/17/7/software-standards#comments
|