mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-16 22:42:21 +08:00
VicYu
GitHub
commit
f2cea9047b
@ -1,136 +0,0 @@
|
||||
Translating by softpaopao
|
||||
|
||||
The problem with software before standards
|
||||
============================================================
|
||||
|
||||
### Open source projects need to get serious about including standards in their deliverables.
|
||||
|
||||
|
||||
|
||||
Image by :
|
||||
|
||||
opensource.com
|
||||
|
||||
By any measure, the rise of open source software as an alternative to the old, proprietary ways has been remarkable. Today, there are tens of millions of libraries hosted at GitHub alone, and the number of major projects is growing rapidly. As of this writing, the [Apache Software Foundation][4] hosts over [300 projects][5], while the [Linux Foundation][6] supports over 60. Meanwhile, the more narrowly focused [OpenStack Foundation][7] boasts 60,000 members living in more than 180 countries.
|
||||
|
||||
So, what could possibly be wrong with this picture?
|
||||
|
||||
What's missing is enough awareness that, while open source software can meet the great majority of user demands, standing alone it can't meet all of them. Worse yet, too many members of the open source community (business leads as well as developers) have no interest in making use of the most appropriate tools available to close the gap.
|
||||
|
||||
Let's start by identifying the problem that needs to be solved, and then see how that problem used to be solved in the past.
|
||||
|
||||
The problem is that there are often many projects trying to solve the same small piece of a larger problem. Customers want to be able to have a choice among competing products and to easily switch among products if they're not satisfied. That's not possible right now, and until this problem is solved, it will hold back open source adoption.
|
||||
|
||||
It's also not a new problem or a problem without traditional solutions. Over the course of a century and a half, user expectations of broad choice and freedom to switch vendors were satisfied through the development of standards. In the physical world, you can choose between myriad vendors of screws, light bulbs, tires, extension cords, and even of the proper shape wine glass for the pour of your choice, because standards provide the physical specifications for each of these goods. In the world of health and safety, our well-being relies on thousands of standards developed by the private sector that ensure proper results while maximizing competition.
|
||||
|
||||
When information and communications technology (ICT) came along, the same approach was taken with the formation of major organizations such as the International Telecommunication Union (ITU), International Electrotechnical Commission (IEC), and the Standards Association of the Institute of Electrical and Electronics Engineers (IEEE-SA). Close to 1,000 consortia followed to develop, promote, or test compliance with ICT standards.
|
||||
|
||||
While not all ICT standards resulted in seamless interoperability, the technology world we live in today exists courtesy of the tens of thousands of essential standards that fulfill that promise, as implemented in computers, mobile devices, Wi-Fi routers, and indeed everything else that runs on electricity.
|
||||
|
||||
The point here is that, over a very long time, a system evolved that could meet customers' desires to have broad product offerings, avoid vendor lock-in, and enjoy services on a global basis.
|
||||
|
||||
Now let's look at how open software is evolving.
|
||||
|
||||
The good news is that great software is being created. The bad news is that in many key areas, like cloud computing and network virtualization, no single foundation is developing the entire stack. Instead, discrete projects develop individual layers, or parts of layers, and then rely on real-time, goodwill-based collaboration up and down the stack among peer projects. When this process works well, the results are good but have the potential to create lock-in the same way that traditional, proprietary products could. When the process works badly, it can result in much wasted time and effort for vendors and community members, as well as disappointed customer expectations.
|
||||
|
||||
The clear way to provide a solution is to create standards that allow customers to avoid lock-in, along with encouraging the availability of multiple solutions competing through value-added features and services. But, with rare exceptions, that's not what's happening in the world of open source.
|
||||
|
||||
The main reason behind this is the prevailing opinion in the open source community is that standards are limiting, irrelevant, and unnecessary. Within a single, well-integrated stack, that may be the case. But for customers that want freedom of choice and ongoing, robust competition, the result could be a return to the bad old days of being locked into a technology, albeit with multiple vendors offering similarly integrated stacks.
|
||||
|
||||
A good description of the problem can be found in a June 14, 2017, article written by Yaron Haviv, "[We'll Be Enslaved to Proprietary Clouds Unless We Collaborate][8]":
|
||||
|
||||
> _Cross-project integration is not exactly prevalent in today's open source ecosystem, and it's a problem. Open source projects that enable large-scale collaboration and are built on a layered and modular architecture—such as Linux_ — _have proven their success time and again. But the Linux ideology stands in stark contrast to the general state of much of today's open source community._
|
||||
>
|
||||
> _Case in point: big data ecosystems, where numerous overlapping implementations rarely share components or use common APIs and layers. They also tend to lack standard wire protocols, and each processing framework (think Spark, Presto, and Flink) has its own data source API._
|
||||
>
|
||||
> _This lack of collaboration is causing angst. Without it, projects are not interchangeable, resulting in negative repercussions for customers by essentially locking them in and slowing down the evolution of projects because each one has to start from scratch and re-invent the wheel._
|
||||
|
||||
Haviv proposes two ways to resolve the situation:
|
||||
|
||||
* Closer collaboration among projects, leading to consolidation, the elimination of overlaps between multiple projects, and tighter integration within a stack;
|
||||
|
||||
* The development of APIs to make switching easier.
|
||||
|
||||
Both these approaches make sense. But unless something changes, we'll see only the first, and that's where the prospect for lock-in is found. The result would be where the industry found itself in the WinTel world of the past or throughout Apple's history, where competing product choice is sacrificed in exchange for tight integration.
|
||||
|
||||
The same thing can, and likely will, happen in the new open source world if open source projects continue to ignore the need for standards so that competition can exist within layers, and even between stacks. Where things stand today, there's almost no chance of that happening.
|
||||
|
||||
The reason is that while some projects pay lip service to develop software first and standards later, there is no real interest in following through with the standards. The main reason is that most business people and developers don't know much about standards. Unfortunately, that's all too understandable and likely to get worse. The reasons are several:
|
||||
|
||||
* Universities dedicate almost no training time to standards;
|
||||
|
||||
* Companies that used to have staffs of standards professionals have disbanded those departments and now deploy engineers with far less training to participate in standards organizations;
|
||||
|
||||
* There is little career value in establishing expertise in representing an employer in standards work;
|
||||
|
||||
* Engineers participating in standards activities may be required to further the strategic interests of their employer at the cost of what they believe to be the best technical solution;
|
||||
|
||||
* There is little to no communication between open source developers and standards professionals within many companies;
|
||||
|
||||
* Many software engineers view standards as being in direct conflict with the "four freedoms" underlying the FOSS definition.
|
||||
|
||||
Now let's look at what's going on in the world of open source:
|
||||
|
||||
* It would be difficult for any software engineer today to not know about open source;
|
||||
|
||||
* It's a tool engineers are comfortable with and often use on a daily basis;
|
||||
|
||||
* Much of the sexiest, most cutting-edge work is being done in open source projects;
|
||||
|
||||
* Developers with expertise in hot open source areas are much sought after and command substantial compensation premiums;
|
||||
|
||||
* Developers enjoy unprecedented autonomy in developing software within well-respected projects;
|
||||
|
||||
* Virtually all of the major ICT companies participate in multiple open source projects, often with a combined cost (dues plus dedicated employees) of over $1 million per year per company at the highest membership level.
|
||||
|
||||
When viewed in a vacuum, this comparison would seem to indicate that standards are headed for the ash heap of history in ICT. But the reality is more nuanced. It also ignores the reality that open source development can be a more delicate flower than many might assume. The reasons include the following:
|
||||
|
||||
* Major supporters of projects can decommit (and sometimes have done so), leading to the failure of a project;
|
||||
|
||||
* Personality and cultural conflicts within communities can lead to disruptions;
|
||||
|
||||
* The ability of key projects to more tightly integrate remains to be seen;
|
||||
|
||||
* Proprietary game playing has sometimes undercut, and in some cases caused the failure of, highly funded open source projects;
|
||||
|
||||
* Over time, individual companies may decide that their open source strategies have failed to bring the rewards they anticipated;
|
||||
|
||||
* A few well-publicized failures of key open source projects could lead vendors to back off from investing in new projects and persuade customers to be wary of committing to open source solutions.
|
||||
|
||||
Curiously enough, the collaborative entities that are addressing these issues most aggressively are standards organizations, in part because they feel (rightly) threatened by the rise of open source collaboration. Their responses include upgrading their intellectual property rights policies to allow all types of collaboration to occur under the same umbrella, including development of open source tools, inclusion of open source code in standards, and development of open source reference implementations of standards, among other types of work projects.
|
||||
|
||||
The result is that standards organizations are retooling themselves to provide an approach-neutral venue for the development of complete solutions. Those solutions can incorporate whatever type of collaborative work product, or hybrid work product, the marketplace may need. As this process continues, it is likely that vendors will begin to pursue some initiatives within standards organizations that might otherwise have made their way to open source foundations.
|
||||
|
||||
For all these reasons, it's crucial that open source projects get serious about including standards in their deliverables or otherwise partner with appropriate standards-developers to jointly provide complete solutions. The result will not only be greater product choice and less customer lock-in, but far greater confidence by customers in open source solutions, and therefore far greater demand for and use of open source products and services.
|
||||
|
||||
If that doesn't happen it will be a great shame, because the open source cause has the most to lose. It's up to the projects now to decide whether to give the market what it wants and needs or reconcile themselves to a future of decreasing influence, rather than continuing success.
|
||||
|
||||
_This was originally published on ConsortiumInfo.org's [Standards Blog][2] and is republished with permission._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Andy Updegrove - Andy helps CEOs, management teams, and their investors build successful organizations. Regionally, he’s been a pioneer in providing business-minded legal counsel and strategic advice to high-tech companies since 1979. On the global stage, he’s represented, and usually helped launch, more than 135 worldwide standard setting, open source, promotional and advocacy consortia, including some of the largest and most influential standard setting organizations in the world.
|
||||
|
||||
|
||||
via: https://opensource.com/article/17/7/software-standards
|
||||
|
||||
作者：[ Andy Updegrove][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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
|
||||
@ -0,0 +1,136 @@
|
||||
在标准建立之前，软件所存在的问题
|
||||
============================================================
|
||||
|
||||
### 开源项目需要认真对待交付成果中所包含的标准
|
||||
|
||||
|
||||
|
||||
|
||||
Image by :
|
||||
|
||||
opensource.com
|
||||
|
||||
无论以何种标准来衡量，开源软件作为旧软件的替代品而崛起，以独特的方式取得了不错的效果。 如今，仅 Github 中就有着数千万的代码仓库，其中重要项目的数量也在快速增长。在本文撰写的时候，[Apache软件基金会][4] 开展了超过 [300个项目][5]， [Linux基金会][6] 支持的项目也超过了 60 个。与此同时，[OpenStack 基金会][7] 在 180 多个国家拥有超过 60,000 名成员。
|
||||
|
||||
这样说来，图中的内容可能是错误的吧？
|
||||
|
||||
开源软件在面对用户的众多需求时，由于缺少足够的意识，而无法独自去解决全部需求。 更糟糕的是，许多开源软件社区的成员（业务主管以及开发者）对利用合适的工具解决这一问题并不感兴趣。
|
||||
|
||||
让我们开始找出那些有待解决的问题，看看这些问题在过去是如何被处理的。
|
||||
|
||||
问题存在于：通常许多项目都在试图解决一个大问题当中重复的一小部分。 客户希望能够在竞争产品之间做出选择，不满意的话还能够选择其他产品。但是现在看来，在问题被解决之前都是不可能的，这一问题将会阻止开源软件的使用。
|
||||
|
||||
这已经不是一个新的问题了，并且至今没有传统意义上的解决方法。在一个半世纪以来，用户期望有更多的选择和自由来变换厂商，而这一直是通过制定的标准来实现的。在现实当中，你可以对螺丝钉、灯泡、轮胎、扩展卡的厂商做出无数多的选择，甚至于对独特形状的红酒杯也倾注你的选择。因为标准为这里的每一件物品都提供了物理规格。而在健康和安全领域，我们的幸福也依赖于成千上万的标准，这些标准是由各自企业制定的，以确保在最大化的竞争中能够有完美的结果。
|
||||
|
||||
随着信息与通信技术（ICT）的发展，同样类似的方式形成了一些重要的组织机构，例如：国际电信联盟（ITU），国际电工委员会（IEC），以及电气与电子工程师学会标准协会（IEEE-SA）。有将近 1000 家企业遵循 ICT 标准来进行开发、推广以及测试。
|
||||
|
||||
如今在我们生活的科技世界里，执行着成千上万必不可少的标准，这些标准包含了计算机、移动设备、Wi-Fi 路由器以及其他一切依赖电力来运行的东西，但并不是所有的 ICT 标准都能做到无缝对接。
|
||||
|
||||
关键的一点，在很长的一段时间里，由于客户对拥有种类丰富的产品，避免受制于供应商，并且享受全球范围内的服务的渴望，逐渐演变出了这一体系。
|
||||
|
||||
现在让我们来看看开源软件是如何演进的。
|
||||
|
||||
好消息是伟大的软件已经被创造出来了。坏消息是对于像云计算和虚拟化网络这样的关键领域，没有任何单独的基金会在开发全部的堆栈。取而代之的是，单个项目开发单独一层或者多层，依靠每个项目所花费的时间及友好合作，最终堆叠成栈。当这一过程运行良好时，它不会创造出潜在的受制于传统的专有产品。相反，坏的结果就是它会浪费开发商、社区成员的时间和努力，同时也会辜负客户的期望。
|
||||
|
||||
制定标准是最明确的解决方法
|
||||
。鼓励多个解决方案通过对附加的服务和功能进行有益的竞争，避免客户选择受限。当然也存在着例外，就如同开源世界正在发生的情况。
|
||||
|
||||
这背后的主要原因在于，开源社区的主流观点是：标准意味着限制、落后和多余。对于一个完整的堆栈中的单独一层来说，可能就是这样。但客户想要的自由，是要通过不断地选择，激烈的竞争的。结果就回到了之前的坏结果上，尽管多个厂商提供相似的集成堆栈，但却被锁定在一个技术上。
|
||||
|
||||
在 Yaron Haviv 于 2017 年 6 月 14 日所写的 “[We'll Be Enslaved to Proprietary Clouds Unless We Collaborate][8]” 一文中，就有对这一问题有着很好的描述。
|
||||
|
||||
> _在今天的开源生态系统当中存在一个问题，跨项目整合并不普遍。开源项目能够进行大型合作，构建出分层的模块化的架构，比如说 Linux _ — _已经一次又一次的证明了他的成功。但是与 Linux 的意识形成鲜明对比的就是如今许多开源社区的日常状态。_
|
||||
>
|
||||
> _举个例子:大数据生态系统，就是依赖众多共享组件或通用 API 和层的堆叠来实现的。这一过程同样缺少标准的线路协议，同时，每个处理框架（ think Spark, Presto, and Flink）都拥有独立的数据源 API。_
|
||||
>
|
||||
> _这种缺乏合作正在造成担忧。如果不这样的话，项目就会变得不通用，结果对客户产生了负面影响。因为每个人都不得不从头开始，重新开发，这基本上就锁定了客户，减缓了项目的发展。_
|
||||
|
||||
Haviv 提出了两种解决方法：
|
||||
|
||||
* 项目之间更紧密的合作，联合多个项目消除重叠的部分，使堆栈内的整合更加密切；
|
||||
|
||||
* 开发 API ，使切换更加容易。
|
||||
|
||||
这两种方法都能达到目的。但除非事情能有所改变，我们将只会看到第一种方法，这就是前边展望中发现的技术锁定。结果会发现工业界，无论是过去 WinTel 的世界，或者纵观苹果的历史，他们自身相互竞争的产品都是以牺牲选择来换取紧密整合的。
|
||||
|
||||
同样的事情似乎很有可能发生在新的开源界，如果开源项目继续忽视对标准的需求，那么竞争会存在于层内，甚至是堆栈间。如果现在能够做到的话，这样的问题可能就不会发生了。
|
||||
|
||||
因为如果口惠无实开发软件优先，标准之后的话，对于标准的制定就没有真正的兴趣。主要原因是，大多数的商人和开发者对标准知之甚少。不幸的是，我们能够理解这些使事情变得糟糕的原因。这些原因有几个：
|
||||
|
||||
* 大学几乎很少对标准进行培训；
|
||||
|
||||
* 过去拥有标准专业人员的公司遣散了这些部门，新部署的工程师接受标准组织的培训又远远不够；
|
||||
|
||||
* 雇主代表缺足够的标准相关的经验价值；
|
||||
|
||||
* 工程师参与标准活动将会是最佳的技术解决方案，可能会对雇主的花费有更加深远的战略意义；
|
||||
|
||||
* 在许多公司内部，标准专业人员与开源开发者之间鲜又交流；
|
||||
|
||||
* 许多软件工程师将标准视为与 FOSS 定义的“四大自由”有着直接冲突。
|
||||
|
||||
现在，让我们来看看在开源界正在发生什么:
|
||||
|
||||
* 今天大多数的软件工程师鲜有不知道开源的；
|
||||
|
||||
* 工程师们每天都在享受着开源工具所带来的便利；
|
||||
|
||||
* 许多令人激动的最前沿的工作正是在开源项目中完成的；
|
||||
|
||||
* 在热门的开源领域，有经验的开发者广受欢迎，并获得了大量实质性的奖励；
|
||||
|
||||
* 在备受好评的项目中，开发者在软件开发过程中享受到了空前的自主权；
|
||||
|
||||
* 事实上，几乎所有的大型 ICT 公司都参与了多个开源项目，最高级别的成员当中，通常每个公司每年的合并成本（会费加上投入的雇员）都超过了一百万美元。
|
||||
|
||||
如果脱离实际的话，这个比喻似乎暗示着标准是走向 ICT 历史的灰烬。但现实却有很大差别。一个被忽视的事实是，开源开发是比常人所认为的更为娇嫩的花朵。这样比喻的原因是：
|
||||
|
||||
* 项目的主要支持者们可以撤回（已经做过的事情），这将导致一个项目的失败；
|
||||
|
||||
* 社区内的个性和文化冲突会导致社区的瓦解；
|
||||
|
||||
* 重要项目更加紧密的整合能力有待观察；
|
||||
|
||||
* 高资助的开源项目，有时专有权在博弈中被削弱，在某些情况下会导致失败。
|
||||
|
||||
* 随着时间的推移，可能个别公司决定的开源策略没能给他们带来预期的回报；
|
||||
|
||||
* 对开源项目的失败引起过多关注，会导致厂商放弃一些投资中的新项目，并说服客户谨慎选择开源方案。
|
||||
|
||||
奇怪的是，最积极解决这些问题的协作单位是标准组织，部分原因是，他们已经感受到了开源合作的崛起所带来的威胁。他们的回应包括更新知识产权策略以允许在此基础上各种类型的合作，开发开源工具，包含开源代码的标准，以及在其他类型的工作项目中开发开源手册。
|
||||
|
||||
结果就是，这些标准组织调整自己成为一个近乎中立的角色，为完整方案的开发提供平台。这些方案能够包含市场上需要的各种类型的合作产品，以及混合工作产品。随着此过程的继续，很有可能使厂商们乐意推行一些包含了标准组织在内的举措，否则他们可能会走向开源基金。
|
||||
|
||||
重要的是，由于这些原因，开源项目开始认真对待项目交付所包含的标准，或者与标准开发商合作，共同为完整的方案做准备。这不仅会有更多的产品选择，对客户更少的限制，而且也给客户在开源方案上更大的信心，同时也对开源产品和服务有更多的需求。
|
||||
|
||||
倘若这一切不发生的话，将会是一个很大的遗憾，因为这是开源所导致的巨大损失。而这取决于如今的项目所做的决定，是供给市场所需，还是甘心于未来日趋下降的影响力，而不是持续的成功。
|
||||
|
||||
_本文源自 ConsortiumInfo.org的 [Standards Blog][2]，并已获得出版许可_
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Andy Updegrove - Andy helps 的 CEO, 管理团队，由他们的投资者建立的成功的组织。他曾作为一名先驱，自1979年起，就为高科技公司提供商业头脑的法律顾问和策略建议。在全球舞台上，他经常作为代表，帮助推动超过135部全球标准的制定，宣传开源，主张联盟，其中包括一些世界上最大，最具影响力的标准制定机构。
|
||||
|
||||
|
||||
via: https://opensource.com/article/17/7/software-standards
|
||||
|
||||
作者：[ Andy Updegrove][a]
|
||||
译者：[softpaopao](https://github.com/softpaopao)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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
|
||||
Loading…
Reference in New Issue
Block a user