NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

关于是否需要开放 Web 基金的争论

  • 2008-08-28
  • 本文字数:1898 字

    阅读完需:约 6 分钟

OSCON 2008 大会上, David Recordon 宣布了开放 Web 基金(Open Web Foundation)的成立,其宗旨是:

……为“社区驱动的规范”打造一个家园。遵循和 Apache 软件基金类似的开源模式,本基金致力于构建一个轻量级的框架,来帮助社区处理必要的法律需求,以制定成功的而且能被广泛采纳的规范。 本基金试图打破为每个规范建立一个单独基金的趋势,并且意识到我们可以团结起来推广我们的努力。关于会员资格、治理,以及知识产权等等细节将于接下来几周内发布以征求公众评阅与反馈。

鉴于我们正在商定该基金的具体细节,我们鼓励并诚邀各路朋友参与商讨。如有疑问,请参考我们的 Q&A 页面。同样,我们更加欢迎您参与到我们的社区里,群策群力,一起讨论你希望看到的这一基金制定的规范。

多么令人称赞的目标啊,背后又有着 Google、Yahoo、O’Reilly 等等的大力支持,看上去似乎很是有趣。 Dion Almaer 为这一进展“激动不已”:

想像一下,当你想到一个绝佳的点子,比如 OAuth 之类的。这个想法越来越引人注意,于是更多的人想要参与进来。你怎么办?人们开始询问关于 IP 策略,治理,于是你突然意识到你正在创建一个“MyApiFoudation”。 等等!不是已经有够多的标准工作组与其它的组织在那里了吗,显然你犯不着去建立一个 MyApiFoundation 啊?

诚然,我们已经有了 W3C 和 OASIS,但那是给钱才能玩得起的。它们有它们的地位,但对 MyApi 却并不适合。 WHATWG 作出了卓越的工作,但 IP 转出(punting IP)仍然是个问题。

Myapi 有一些代码基础了,那么把它放在 Apache 如何呢?对于代码而言,Apache 再好不过了,但它不能处理其它事务,这也是它的好处。毕竟那并不是它的责任。Apache 做得非常好,特别是涉及到治理与孵化过程等方面。如果我们能有一个参与人(因此每个人都可以,相对于那些公司)和各社区(而不是老是那些来自同一个公司的家伙)具有相同价值观的类似组织该有多好啊!

这就是为什么我对开放 Web 基金充满希望。当你的主意对开放 Web 有帮助的时候,这是一个值得你注意的新的机会,一个能实现你的价值的地方。

尽管 OWF声明他们不会与其它的标准实体产生竞争,而是“跟一直我们打交道的社区目前都是以一种非正式(ad hoc)的方式聚集在一起,如果我们能帮助他们理清知识产权,那么将会为社区将开放规范提交给标准团体打开方便之门。”;然而别人却并不认为多一个标准组织有什么必要。像 Dare Obasanjo 所指出的那样,对 W3C 和 OASIS 的猜疑往往是它们收取费用(有时候会很高,但也有 $500 左右的个人会员资格),但仅仅因为这一成本就有必要或者足够理由另起炉灶吗?特别是自从 1992 年我们就有了 IETF 。Dare 继续谈到:

IETF 的会员政策再直接不过了;加入邮件列表。我在 RFC 4287 里被列为Atom 工作组的一员只因为我参与了 atom-syntax 邮件列表。关于知识产权,这个组织有着缜密思考而具体的策略,并有相应 IETF 规范进行详尽的阐述: RFC 3979:IETF 技术里的知识产权以及在 RFC 4879:关于 RFC 3979 中第三方公开过程的澄清里面的些许更新。

对于其它人关于“除了‘因为我们能这样做’以外似乎没有更好的OWF 创建理由”这样的意见, Bill 也表示赞同: > 我可以理解那些意欲对一个规范的整体社会性和技术导向保留控制权的人们想要避开它们的原因--这有点像启动你自己的开源项目(尽管我觉得 OWF 在 OSCON 上的揭幕毫不重要)。我曾经为 IETF,JCP 以及 W3C 都工作过,也站在了 OASIS 的门槛上。我认为毫无疑问你应该使你的努力融入这些组织,无论技术上还是政治上——政治,因为技术规范与开源项目的范围并不相同,它有着极大的经济影响面——换句话说,也许有些人的午餐都赌在里面了。也许这就是 OWF 存在的原因,谁知道呢。这么说,我实在想像不到为什么有些人想要重做全球性技术部署所要求的那些流程和知识产权(IPR)等等;这是极其重要的,容不得半点散失。

Dare 抛出了一个问题来作总结:Google 搅合到这里面干嘛呢? > 我能理解那些刚从学校出来的乳臭未干的小子能够无视 IETF 并以为他们能重复发明轮子来拯救开放 Web。但我想不通的是 Google,这个有着不少雇员参与到 IETF 的流程里面并帮助制定了 RFC 4287 , RFC 4959 , RFC 5023 以及 RFC 5034 等等规范的公司,居然也会加入到这种行为里面来。Google 为什么要赞助这样一个与 IETF 相竞争而又不及IETF 完备的单独的标准组织呢,它甚至连公司赞助要怎么运作以及IPR 策略如何确定都还不知道?

我们会看到这一行为究竟是真的能发挥作用呢,还只是又一个昙花一现罢了。但是随着OASIS,W3C 以及IETF 的蓬勃发展,OWF 要想在短时间内发挥影响恐怕是很难了。查看英文原文 Debate Around The Need For The Open Web Foundation

2008-08-28 00:40644
用户头像

发布了 133 篇内容, 共 35.0 次阅读, 收获喜欢 1 次。

关注

评论

发布
暂无评论
发现更多内容

Stable Diffusion:一种新型的深度学习AIGC模型

蓝海大脑GPU

“信创”滚滚而来,私有化或将迎来第二春

WorkPlus

阿里大佬倾情力荐:Java全线成长宝典,从P5到P8一应俱全

三十而立

Java java面试

开源即时通讯IM框架MobileIMSDK的微信小程序端开发快速入门

JackJiang

从零学习SDK(3)如何安装和配置SDK

MobTech袤博科技

GitHub已开源—在国内外都被称为分布式理论+实践的巅峰之作

做梦都在改BUG

Java 数据库 分布式 系统设计 设计数据密集型应用

Flink MongoDB CDC 在 XTransfer 的生产实践|Flink CDC 专题

Apache Flink

大数据 flink 实时计算

四种常见服务限流算法解析

做梦都在改BUG

TiDB损坏多副本之有损恢复处理方法

TiDB 社区干货传送门

集群管理 6.x 实践 TiKV 底层架构

TiCDC 源码阅读(六)TiCDC Puller 模块介绍

TiDB 社区干货传送门

瓴羊Quick BI连续入选魔力象限ABI报告,实至名归

流量猫猫头

企业数字化升级迫在眉睫,瓴羊Quick BI工具应运而生

夏日星河

NFT交易平台商城系统开发技术

薇電13242772558

NFT

文盘Rust -- 用Tokio实现简易任务池

TiDB 社区干货传送门

开发语言

tiup cluster display 执行流程代码详解

TiDB 社区干货传送门

实践案例 集群管理 故障排查/诊断 安装 & 部署

精选2023年大厂高频Java面试真题集锦(含答案),面试一路开挂

程序知音

java面试 java架构 Java进阶 后端技术 Java面试八股文

知行合一!AI大模型与算法二三事

深数

深度学习 科普 数字化 NLP 大模型 LLM

一文彻底搞懂Raft算法,看这篇就够了!!!

做梦都在改BUG

牛客网2023Java最新面试宝典(附答案解析)正式开源

采菊东篱下

编程 java面试

漫谈 ChatGPT 与问答式 BI

观远数据

数据分析 BI ChatGPT

瓴羊Quick BI国产数字化智能工具口碑怎么样?30天免费试用

小偏执o

堡垒机厂商都是大企业吗?你比较推荐哪家?

行云管家

网络安全 等级保护

堡垒机主流品牌有哪些?如何选择?

行云管家

堡垒机 IT运维

APP频繁改版惹人烦?火山引擎VeDI来帮忙

字节跳动数据平台

数字化 企业数字化 企业号 4 月 PK 榜 APP改版

TiCDC 源码阅读(七) TiCDC Sorter 模块揭秘

TiDB 社区干货传送门

ByteBase是什么,他怎么和tidb结合提高工作效率的

TiDB 社区干货传送门

实践案例

快手基于 Apache Flink 的实时数仓建设实践

Apache Flink

大数据 flink 实时计算

5 大手段,打造单一可信源代码托管平台|极狐GitLab DevSecOps 助力 SLSA 落地之源代码篇

极狐GitLab

DevOps DevSecOps 源代码 安全审计 SLSA

干货分享|金融机构如何通过标签画像实现精细化客户运营?

索信达控股

值得一看!阿里内部“M9”级别全彩版分布式实战笔记

做梦都在改BUG

Java 架构 分布式 分布式事务 微服务

TiCDC 源码阅读(五)TiCDC 对 DDL 的处理和 Filter 解析

TiDB 社区干货传送门

关于是否需要开放Web基金的争论_SOA_Mark Little_InfoQ精选文章