开源

开源

AWS回应Elastic修改开源协议:创建“真正”开源的Elasticsearch分支

科技创新fanta2 发表了文章 • 0 个评论 • 101 次浏览 • 2021-02-04 10:11 • 来自相关话题

来源于公众号“程序猿DD”前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License而在不久之后,云服务商Logz.io公司就对这一... ...查看全部

来源于公众号“程序猿DD”

前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License

而在不久之后,云服务商Logz.io公司就对这一行为表达了自己的不满。

但是事情还没完,就像最近国内某郑姓女星的瓜层出不穷吃都吃不完一样,开源协议的宫斗剧也是一出接着一出。

当初Elastic公司改变协议的一大目的,就是针对自己的竞争对手AWS(Amazon Web Services——Amazon云服务)。为此Elastic公司的CEO,Shay Banon甚至曾经发文怒斥过AWS的一些行为。

如果说Logz.io公司还只算小打小闹,那么就在前几天,1月21号,AWS 官方做出回应,宣布将基于目前仍为开源状态的 Elasticsearch 和 Kibana( 7.10 版本)创建分支,开源许可证也会继续使用 Apache License 2.0。(和Logz.io公司发文中的意图不谋而合)

为了确保这个分支能够健康的持续发展使用,AWS 也宣称会负责后续的维护工作。

微信图片_20210203173028.png当然,和Logz.io公司发文中直接开怼Elastic不同,AWS更多的采用了隐晦的嘲讽模式(大公司的公关团队就是不一样!)。例如,AWS 声称自己将要创建的这个分支才是真正开源的 Elasticsearch,显然是在暗喻 Elastic 公司即将采用的双许可证方案(SSPL + Elastic License)算不是真正的开源,因为上述两个协议都不是 OSI (Open Source Initiative,开源促进会,批准开源协议的机构) 批准的开源许可证。微信图片_20210203173031.png

不过,AWS类似的事情并不是没有过。早在2019 年AWS就推出一个 Elasticsearch 的发行版——Open Distro for Elasticsearch,当时他们就对外标榜这款采用了 Apache License 2.0协议的产品,是 100% 开源。

AWS做这个申明的时候似乎忘了Amazon 靠着 Elastic 开发出来的东西赚到的钱就比他们自身赚到的还要多,因为这些内容可以跟 Amazon 的其他产品结合得更紧密,让别人使用更方便。

也为了这个Open Distro for Elasticsearch,Elastic 就在当年在加州联邦法院起诉Amazon 侵犯了自己的商标,一次次的矛盾升级之后最终才导致了Elastic痛下决心,进行开源协议改变。

不知道这一次,之前习惯了白嫖的AWS,是否能做出一个更好的开源Elasticsearch,让我们拭目以待!


开源模式反击之后,白嫖服务商竟然大叫“好自为之!”

科技创新徐凤年 发表了文章 • 0 个评论 • 95 次浏览 • 2021-02-04 10:11 • 来自相关话题

来源于公众号-程序猿DD还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。这一举动自然引起一些用惯了白嫖的云服务商的不满,这不... ...查看全部

来源于公众号-程序猿DD

还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这一举动自然引起一些用惯了白嫖的云服务商的不满,这不Logz.io公司官网就发布了一篇,简单总结就是:Elastic,你不讲武德!

微信图片_20210203173353.png

Logz.io公司描述到,Elastic的举动,已经在开源社区引起了轩然大波,无数依赖于Elasticsearch的组织都开始混乱无比。(潜台词:用惯了别人的东西一下子没得用了不知道该咋办)

而Logz.io声称已经联系了很多类似的组织,这些组织的共同点,就是认为Elasticsearch和Kibana应该保持开源而不是使用SSPL。Logz.io正在和这些组织商量一起打造一个真正的开源的Elasticsearch和Kibana版本。

所谓的真正开源,是Logz.io似乎准备自己搭建一个永远用Apache 2.0协议的Elasticsearch和Kibana项目,而维护整个项目的将是他们与多个志同道合的组织。(潜台词:以后没有白嫖的东西了,不自己做还能怎么办呢)

Logz.io公司同时还重申了自己公司的立场:

作为一个客户至上的组织,Logz.io公司最关注的是客户和社区用户的成功。Logz.io公司致力于用最好的平台来支持社区,以满足社区成员的可观察性需求。Logz.io公司将继续致力于在未来支持Kibana和Elasticsearch,并为客户提供最好的观测平台。

这里稍微介绍下,Logz.io公司主要基于AI的日志分析平台致力于帮助用户公司跟踪网站、应用及软件的情况,以避免发生代价高昂的停机故障。这些基本都依赖于Elasticsearch、Logstash和Kibana(ELK)堆栈的云服务分析日志。 所以说,Elastic的这次改变对他们是毁灭性的打击。

说够了远大前景,自然要吐槽下不满,文中,Logz.io公司对于Elastic团队的不满溢于言表:

Logz.io公司自从2014年来一直很敬佩Elastic,钦佩他们的公司文化、领导及业务(潜台词:先夸夸你再摔你),但是在最近几年,Elastic对于开源项目的投入已经江郎才尽,所有的心思都花在了商业上。同时认为Elastic决定关闭源代码以阻止竞争是一种背叛,背叛了他们的初衷:

微信图片_20210203173359.png

同时Logz.io公司认为一家价值数十亿美元的公司试图残酷地阻止竞争迫使社区用户为Elasticsearch付费,是不讲武德的!(潜台词:你家大业大,你给我白嫖下咋的了,你就应该继续免费,然后再战胜我们这些白嫖的人,这才是厉害啊)

最后,Logz.io公司相信,在Apache2下合作提供Elasticsearch和Kibana开源,对Logz.io公司的客户来说是正确的。对于任何依赖这些开源项目的人来说,这是正确的做法。最重要的是,Logz.io公司认为这对开源软件的未来是正确的。(潜台词:白嫖用户来关心开源软件的未来了!)


拒绝白嫖!开源模式的反击:向不要脸的云服务商收费!

科技创新王叫兽 发表了文章 • 0 个评论 • 77 次浏览 • 2021-02-04 10:11 • 来自相关话题

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给... ...查看全部

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给他一样。

遇到这种人,气不气?

其实这种人不在少数,也正是有这样的人,才会有拿来主义,才会有做事毫无底线的云服务商,才导致了开源商业模式一再萎靡。

当然,老实人并不代表着一定要被欺负!就在1月15号,Elastic 公司 官方宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这次变更的主要针对目的,就是那些毫无底线的云服务商!

微信图片_20210203172125 (1).jpgElastic 公司 的CEO Shay Banon在他的博文中解释到:

虽然,从Apache 2.0 变更为 SSPL 与 Elastic License会改变一部分源代码,但是对于绝大多数的使用免费版本的用户及Elastic 公司的云客户以及自主管理软件客户也不会受到影响。唯一会受影响的,就是云服务商。

SSPL 允许用户以自由且不受限制的方式使用并修改代码成果,但是SSPL也有自己的要求:那就是如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

由此将限制云服务商在不对项目做出任何贡献的前提下,发布云服务商自己的 Elasticsearch 与 Kibana 服务,从而达到保护Elastic 公司的权益,亦可以让公司在开发免费产品方面持续投入的热情和资源,避免恶性循环。

微信图片_20210203172149.png

对于为什么会这么做,Shay Banon也给出了自己的解释:

长久以来,云服务商不断地肆意的将免费的开源软件集成到自己的云产品中,同时将其作为自己的云服务解决方案给予客户使用,俗称白嫖~造成了许多客户越来越多的放弃这些开源厂商的付费版本,直接断绝了开源厂商的经济来源!

早在Elastic之前,就有不少开源公司进行了变更:

Redis、MongDB、OpenCV、Google,Elastic绝不会是最后一个。

此次Elastic主要是借鉴了MongoDB的类似经验。

微信图片_20210203172152.png早在2018 年 10 月,MongoDB 就已经宣布将开源协议从 GNU AGPLv3切换到 SSPL,无论当时如何引起部分用户的不满,MongoDB 至少目前还很健康的继续经营,股价也从 2018 年的不足 100 美元 / 股涨到现在的 361 美元 / 股。可以说是开源公司学习的楷模。微信图片_20210203172155.jpg

SSPL 就是由 MongoDB 最初创建的可提供源代码的许可证,旨在体现开放源码理想的许可证,允许自由和不受限制地使用,修改和重新分发。

SSPL最简单也是最核心的一点就是前文提过的:如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

SSPL 是基于GPLv3 的 copyleft 许可证。并没有经过 OSI(Open Source Initiative,开源促进会,批准开源协议的机构) 批准,因此官方还特意声明:为了避免混淆,我们暂时不将两个产品称为开源,而使用“免费和开放” 进行描述。

有时候甚至会觉得,SSPL纯粹就是被那些习惯了白嫖的云服务商逼出来的产物,就像当每个人做事都只顾着看别人的成效数字,又有几个人能真正做好事呢?


开源商业模式正在被云服务商杀死!

科技创新柠檬^ 发表了文章 • 0 个评论 • 66 次浏览 • 2021-02-03 17:20 • 来自相关话题

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是... ...查看全部

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是开源的,也是让众多程序员喜欢他们的原因之一。

但是昨天看到了一个让我震惊的新闻:最新版本的Mapbox GL JS将不再是开源的!!!

作为个人来说,我并非是一个完美的热衷于开源的粉丝,因为我知道,创建和维护开源代码是多么一件吃力不讨好的事情,真的是非常累人,所以我一直很尊敬那些愿意开源的程序员,并且哪怕是开源,哪怕是对方过去已经丢弃不用的想法,我都觉得自己没有权力肆意使用对方的想法和知识产物。

但是同样的,直到昨天看到那个新闻之前,我仍然对商业开源软件抱着些许的客观、浪漫、自欺欺人的想法。在我的想法中,这是一个在当下重名利的世界中,保持着那颗开源的心,一直以开源做为自己的商业模式,持续走下去的童话故事,而Mapbox就是故事的主角,

去年的时候我也写过关于Mapbox商业模式的文章,就是他即提供了一种免费开源的版本,也提供了一种收费的版本,这些收费版本当然有一些独到的免费版本没有的功能。 听起来,有点像王者荣耀中有皮肤和没皮肤的概念。

如果对开源的商业模式有进一步了解兴趣的,建议可以看下Joseph Jacks的博文,链接地址如下:https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c044da7c

在最初的时候,没有人相信这种模式管用,但是随后发生的一切让人大跌眼睛,像Elastic、D2iQ(以前的Mesosphere)、MongoDB和Cloudera这样的几十家公司,都通过这种过往没出现过的方式,成功赚取了数十亿美元的投资。当然和现在相比,那个时候他们开放的开源版本可是开放好多。

直到今天,看了那个新闻之后,我们不由得感慨,开源模式即将死去!

那是什么让他从一时兴旺到如今的一命呜呼呢?

云服务商!

我们先回到Mapbox的例子,在Mapbox GL JS使用的案例中,Mapbox最早的决定是,开源其基于浏览器的地图渲染器的最早的两个版本(像我们熟知的Snap-Maps、纽约时报和CNN都用过)。自2014年首次发布以来,它在web开发人员中一直非常流行。一旦你知道你在找什么,你就会开始到处看到它。

微信图片_20210120152742.png

而对于我自己来说,当我的团队开始构建一个标记卫星图像的项目时,我才亲身体验了Mapbox GL JS的功能是有多么强大。使用Mapbox GL JS的功能,支持复杂几何图形的自由形式绘图,最终的成品是可以在地图上形成形状,也就是说是我的标记是被投影到地球上的一个真实位置,而不是简单的仅仅是悬浮在想象中的二维空间。这种效果让人感觉明显和直截了当,非常好用。

但事实上如果我不用Mapbox GL JS,从零开始设计就会非常非常困难。因为即使是用徒手画的简单形状也可以包含数千个单独的点。这样的话很快,我的屏幕上就会被数十万个顶点的形状填满,然后很显然,我的浏览器就会崩溃。而Mapbox GL JS是通过调用计算机上图形卡来帮助解决这个问题,如果不依靠Mapbox那几万小时的艰苦的工程工作,我们不可能在预算和时间有限的情况下完成该功能。Image for post

而这周Mapbox决定公布一个Mapbox GL JS的新版本,这个新版本不再开源瞬间震撼到了我!不仅仅是因为之前的V1版本是一个广受欢迎的开源版本,而是因为Mapbox作为一个开源代码的代名词给予我的那种崇高的敬意。在我的看法里,如果你要描述Mapbox是一家怎么样的公司而不提到开源,就像你和一个从未喝过的人谈到巧克力牛奶时不说这是一种液体一样!

Mapbox迄今为止,仍拥有超过800个开源项目,并在Github公共存储库活动方面一直名列全球前40名。并且Mapbox一直在给世界上知名度最高的开源软件贡献者提供各种工作机会,不仅仅是地图行业。

所以说,到底突然发生了什么?

其实,一切都源头还都是因为开源不再是一个在当下这个时代能站得住脚的商业模式!

Mapbox选择保持Mapbox GL JS的V2版本的专有权而不再开源就是一个强烈的信号。虽然这信号背后到底代表着什么还不是很清楚,但是已经让我咬牙切齿。。。

在我看来,这已经意味着我们要迎接一个时代的结束,这预示着代表着开源这种商业模式的寿命的终结!

其实我的潜意识里一直有着这个想法,早在Mapbox的新闻之前,但是Mapbox的新闻是真正为我心中猜想敲上实锤的那最后一击。

为了了解即使像Mapbox这样的公司也决定从开源转变的原因,我觉得可以先看下Mongo DB和Redis Labs这两个行业同行之前已经发生过的故事。

就在两年前,知名科技博主Ben Thompson写过一份文章,文章中阐述了一份总结关于AWS(Amazon Web Services——Amazon云服务), MongoDB和开源代码的经济回报。按他的说法就是:如果你提供了你的独家代码作为开源代码,并且让它变得流行起来,那么那些云服务商必然将用这些代码来为他们自己所用,为他们制造一些竞争性的服务,就好比用你制作的武器来攻击你一般,并且他们的心中没有丝毫歉意和犹豫,他们的眼中只有利益,对于这种行为,你的律师最后只会对你说一句无能为力,因为你曾经自己将这些内容开源了!

Ben在文中提到AWS推出了一项与MongoDB和Redis的付费产品直接竞争的对手服务,但也没有完全击败对手。事实上,自从那个时候起,MongoDB的股价从那时起已经上涨了275%,Redis在几个月前刚刚筹集了1亿美元,正式跨过了10亿美元的神奇估值门槛。

微信图片_20210120152751.png

但我想表述的更重要的不仅仅是Mongo和Redis在受到AWS的攻击后依旧蓬勃发展,而是他们是如何做到的?

这两家公司都以公司一贯的方式反击:一支知识产权的律师大军。

Redis采取了一种策略,在现有开源工具的更新版本中加入了一个有着严格限制性条件的commons条款,不过这让一些著名的开源代码的支持者非常不满:

微信图片_20210120152753.png

鉴于此,Redis后来用了另外一种方法,申请了一个完全新颖和独特的许可证,虽然这不会比commons条款更糟,但几乎可以肯定的是也不会更好。

另一家公司MongoDB呢?它也采取了俗称poison pill(毒丸) 的法律策略,在AWS推出竞争性的服务后不久,它就为自己的软件申请了一个新的、同样是虚构的许可证Server-Side Public License (SSPL)。

这些动作都是为了对抗云服务商的一系列举措。

更准确的说,他们的开源产品对任何有规模的公司都会起到使用时是否合规这个问题。

当然,这么做的代价就是Redis和Mongo从根本上减少了开源的开放性。从结果看,他们做的很好,虽然这是以牺牲了它们最初的理想为代价的,但毕竟活着是最重要的。

但是很多开源作者觉得自己被出卖了一样,我能理解他们的感受,但是我也理解Redis或MongoDB这么做是理性的生意行为。

回到Mapbox上,至少已经有一家云服务商公开的将Mapbox的代码复制并粘贴到他们的收费服务中: Azure,微软的云服务

去年,Azure发布了由Mapbox GL JS支持的地图样式,它是Azure地图服务的一个关键特性。为此,Mapbox甚至在他们公司的博客上写了一个声明。

虽然我们可以理解为Mapbox写这个声明是件好事,但我严重怀疑这是导致了Mapbox GL JS不再开源的开始。毕竟,在竞争无比激烈的公共云世界里,一旦一个云服务商开始提供服务,其他服务商肯定很快就照猫画虎一样开始提供类似服务。Mapbox终于发现自己的处境与MongoDB和Redis是如此的相似:它们在为那些万亿美元的科技巨头免费提供研发基础!

与Mongo和Redis不同,Mapbox最终还是抵抗了一些冲动。他们没有改变产品开源部分的基本许可证,而是彻底打破了这一局面。旧版本仍然是一个成熟且非常有用的版本,将保留其原始的许可证。同时Mapbox召集社区成员无限期地维护这个版本,我希望这会有用。

而新版本将保持一定程度的公开(例如代码都发布在Github上)。但是它不再是开源那样的了。对我来说,这感觉是一个更诚实的方法,而不是试图用一个没见过的、完全未经证实的许可证或一些“看似明白”的条款来穿针引线制造一种假象。

有些人可能会觉得这是一场悲剧,因为这意味着社区捐献可能会减少。诚然,尽管贡献者名单很长,但Mapbox的现任和前任员工还是贡献了最大的份额。但是这个项目已经吸引了一个庞大的、全球性的工程师群体,他们用它来建造东西,对它进行技术讲座。毫无疑问,昨天对于那些充满创作热情的用户来说的确是一个悲伤的日子。他们会继续过下去,但肯定有一种莫名的失落感。

至于这么做是否偏离了Mapbox最初的使命或公司文化?我想这条来自一位自公司成立以来一直在公司工作的现任员工的微博很好的总结了这一点:

微信图片_20210120152756.png

现实中很多事情都是很无奈的,毕竟我们要吃饭要生存下去。

很久以前我天真的以为围绕开源建立一家公司是很容易的,并且其他人都会很道德的使用这些开源的信息,但是现在我不再敢肯定这些。

我仍然相信开源是世界上一股强大的向善力量。我仍然认为,有的公司可以战略性地、认真地为开源做出贡献,不仅为自己的使命服务,也为集体利益服务。

但是,相对的,我再也不相信那些靠着风投存活下去的公司能够负责任地推行这种策略,将软件作为其价值主张的核心。我不再认为这是一个可行的模式,因为或快或慢,他们都会被他们的野心所吞噬,因为如果不这么做,他们最终只能在被自己的武器干掉和背叛最初的理念中间二选一。

昨天真是令人难过的一天。不仅仅因为Mapbox的宣布令人失望,而且就在昨天,我终于不得不向自己承认一点:

云服务商真的杀死了开源!

(来源于公众号:程序猿DD)


开发者真的喜欢开源吗?

IM即时通讯大兴 发表了文章 • 0 个评论 • 74 次浏览 • 2020-09-07 10:03 • 来自相关话题

作者 | Matt Asay译者 | 风车云马,责编 | 屠敏出品 | CSDN(ID:CSDNnews)FaunaDB创始人埃文·韦弗(Evan Weaver)有一个疯狂的想法:只要给开发者一个开放的API和一个适合他们开发的模型,那么云是最好的选... ...查看全部
作者 | Matt Asay

译者 | 风车云马,责编 | 屠敏
出品 | CSDN(ID:CSDNnews)

timg.jpg

FaunaDB创始人埃文·韦弗(Evan Weaver)有一个疯狂的想法:只要给开发者一个开放的API和一个适合他们开发的模型,那么云是最好的选择,即便是Linux和Kubernetes这样的开源平台。也许他们不想为任何代码做“手术”。那么,他们感兴趣的是云,而不是代码?

这是一个大胆的想法,倒也存在合理的地方。然而,当我向业界的重量级人物提出这个想法时,他们却因为各种不同的原因否定了。根据Lightspeed的投资者瓜拉夫•古普塔(Guarav Gupta)的说法,“开发人员对开源有着深深的喜爱和欣赏,几乎像是上瘾了”,而这是开发人员对API所没有的感觉。

有没有一种方法既能方便地使用API,又不会失去开发人员对开源社区的归属感?答案似乎是肯定的,但实现起来有点复杂。

不要忘记数据

StrAPI提供一种开源headless CMS,它的联合创始人兼CPO Aurélien Georget认为,开源的持久魅力不仅在于代码。例如,StrAPI的许多客户都想要定制他们的CMS。在这种情况下,云服务不能满足他们的需求。

即使他们不想修改代码,数据也会驱使他们这样做:“我们的用户对他们的代码的所有权不感兴趣,而是对他们的数据感兴趣。出于数据隐私的原因,或者从法律的角度出发(例如银行、保险、公共管理等部门),他们需要在自己的数据中心运行他们的代码——并保存他们的数据。”当然,这并不是说Weaver坚持以API为中心的方法是错误的,“每个解决方案都应该是面向API的,”Georget赞同道,“因为它让开发人员富有创造力,想象新的用例,并进行创新。”

Georget表示,使用云服务或许会更方便,但对于某些类别的应用程序或客户来说,这并不总是可行的。

DataStax为ApacheCassandra数据库社区提供代码和操作技巧,其首席宣传官PatrickMcFadin认为,API可能会成为一扇单向的门,过去开放的API随着时间的推移会被锁起来,或者被挡在付费墙后面。未来数据之争只会带来严重的专利化。相比之下,代码可以免费提供,因为它不是大多数企业(包括软件供应商)的核心“业务”。

Instaclustr的首席技术官本•布罗姆海德(BenBromhead)有一个理想的折中方案。Instaclustr将ApacheKafka等开源软件作为托管服务运行。只要建立的云服务严格遵守开源标准,他们就不会真正失去代码或数据的独立性。

开源数据层技术保证公司完全控制自己的数据和流程。通过选择100%的开源技术,公司可以拥有自己的代码,并保持不受供应商或技术的限制。比代码本身更重要的是,真正的开源技术确保了公司的关键信息流程不会被提供专有解决方案的供应商所破坏,也不会在任何情况下干扰公司充分利用自己数据的能力。

核心在于信任

这让我们回到了古普塔的观点,即开源有一些不同的,也许更好的东西。尽管“人们最终还是想以云服务的形式消费”,但是他认为,代码对于营造真正的技术亲和力——甚至对技术的喜爱和欣赏——是至关重要的。

您能通过API实现这种“亲密”(cosmic closeness)吗?古普塔认为不会。他说,“如果你是开源的,那么很容易构建社区,而不是带API的黑箱云服务”。因为,“作为一名开发者,你想通过自己的感觉和理解来开发它,并成为团队的一部分。”

这种开源运动的核心是信任:开放代码、开放路线图、开放交流、开放决策。这就是像Instaclustr这样的云供应商的成功之处:云的易用性以及对开源的信任和控制,可以为客户提供他们想要的东西。好的开源公司会建立起令人不可思议的信任。明智的云计算公司不甘示弱,一定不会让开发人员缺失在开源社区中的那种信任和喜爱。

原文:https://www.infoworld.com/article/3572324/do-developers-really-care-about-open-source.html


AWS回应Elastic修改开源协议:创建“真正”开源的Elasticsearch分支

科技创新fanta2 发表了文章 • 0 个评论 • 101 次浏览 • 2021-02-04 10:11 • 来自相关话题

来源于公众号“程序猿DD”前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License而在不久之后,云服务商Logz.io公司就对这一... ...查看全部

来源于公众号“程序猿DD”

前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License

而在不久之后,云服务商Logz.io公司就对这一行为表达了自己的不满。

但是事情还没完,就像最近国内某郑姓女星的瓜层出不穷吃都吃不完一样,开源协议的宫斗剧也是一出接着一出。

当初Elastic公司改变协议的一大目的,就是针对自己的竞争对手AWS(Amazon Web Services——Amazon云服务)。为此Elastic公司的CEO,Shay Banon甚至曾经发文怒斥过AWS的一些行为。

如果说Logz.io公司还只算小打小闹,那么就在前几天,1月21号,AWS 官方做出回应,宣布将基于目前仍为开源状态的 Elasticsearch 和 Kibana( 7.10 版本)创建分支,开源许可证也会继续使用 Apache License 2.0。(和Logz.io公司发文中的意图不谋而合)

为了确保这个分支能够健康的持续发展使用,AWS 也宣称会负责后续的维护工作。

微信图片_20210203173028.png当然,和Logz.io公司发文中直接开怼Elastic不同,AWS更多的采用了隐晦的嘲讽模式(大公司的公关团队就是不一样!)。例如,AWS 声称自己将要创建的这个分支才是真正开源的 Elasticsearch,显然是在暗喻 Elastic 公司即将采用的双许可证方案(SSPL + Elastic License)算不是真正的开源,因为上述两个协议都不是 OSI (Open Source Initiative,开源促进会,批准开源协议的机构) 批准的开源许可证。微信图片_20210203173031.png

不过,AWS类似的事情并不是没有过。早在2019 年AWS就推出一个 Elasticsearch 的发行版——Open Distro for Elasticsearch,当时他们就对外标榜这款采用了 Apache License 2.0协议的产品,是 100% 开源。

AWS做这个申明的时候似乎忘了Amazon 靠着 Elastic 开发出来的东西赚到的钱就比他们自身赚到的还要多,因为这些内容可以跟 Amazon 的其他产品结合得更紧密,让别人使用更方便。

也为了这个Open Distro for Elasticsearch,Elastic 就在当年在加州联邦法院起诉Amazon 侵犯了自己的商标,一次次的矛盾升级之后最终才导致了Elastic痛下决心,进行开源协议改变。

不知道这一次,之前习惯了白嫖的AWS,是否能做出一个更好的开源Elasticsearch,让我们拭目以待!


开源模式反击之后,白嫖服务商竟然大叫“好自为之!”

科技创新徐凤年 发表了文章 • 0 个评论 • 95 次浏览 • 2021-02-04 10:11 • 来自相关话题

来源于公众号-程序猿DD还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。这一举动自然引起一些用惯了白嫖的云服务商的不满,这不... ...查看全部

来源于公众号-程序猿DD

还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这一举动自然引起一些用惯了白嫖的云服务商的不满,这不Logz.io公司官网就发布了一篇,简单总结就是:Elastic,你不讲武德!

微信图片_20210203173353.png

Logz.io公司描述到,Elastic的举动,已经在开源社区引起了轩然大波,无数依赖于Elasticsearch的组织都开始混乱无比。(潜台词:用惯了别人的东西一下子没得用了不知道该咋办)

而Logz.io声称已经联系了很多类似的组织,这些组织的共同点,就是认为Elasticsearch和Kibana应该保持开源而不是使用SSPL。Logz.io正在和这些组织商量一起打造一个真正的开源的Elasticsearch和Kibana版本。

所谓的真正开源,是Logz.io似乎准备自己搭建一个永远用Apache 2.0协议的Elasticsearch和Kibana项目,而维护整个项目的将是他们与多个志同道合的组织。(潜台词:以后没有白嫖的东西了,不自己做还能怎么办呢)

Logz.io公司同时还重申了自己公司的立场:

作为一个客户至上的组织,Logz.io公司最关注的是客户和社区用户的成功。Logz.io公司致力于用最好的平台来支持社区,以满足社区成员的可观察性需求。Logz.io公司将继续致力于在未来支持Kibana和Elasticsearch,并为客户提供最好的观测平台。

这里稍微介绍下,Logz.io公司主要基于AI的日志分析平台致力于帮助用户公司跟踪网站、应用及软件的情况,以避免发生代价高昂的停机故障。这些基本都依赖于Elasticsearch、Logstash和Kibana(ELK)堆栈的云服务分析日志。 所以说,Elastic的这次改变对他们是毁灭性的打击。

说够了远大前景,自然要吐槽下不满,文中,Logz.io公司对于Elastic团队的不满溢于言表:

Logz.io公司自从2014年来一直很敬佩Elastic,钦佩他们的公司文化、领导及业务(潜台词:先夸夸你再摔你),但是在最近几年,Elastic对于开源项目的投入已经江郎才尽,所有的心思都花在了商业上。同时认为Elastic决定关闭源代码以阻止竞争是一种背叛,背叛了他们的初衷:

微信图片_20210203173359.png

同时Logz.io公司认为一家价值数十亿美元的公司试图残酷地阻止竞争迫使社区用户为Elasticsearch付费,是不讲武德的!(潜台词:你家大业大,你给我白嫖下咋的了,你就应该继续免费,然后再战胜我们这些白嫖的人,这才是厉害啊)

最后,Logz.io公司相信,在Apache2下合作提供Elasticsearch和Kibana开源,对Logz.io公司的客户来说是正确的。对于任何依赖这些开源项目的人来说,这是正确的做法。最重要的是,Logz.io公司认为这对开源软件的未来是正确的。(潜台词:白嫖用户来关心开源软件的未来了!)


拒绝白嫖!开源模式的反击:向不要脸的云服务商收费!

科技创新王叫兽 发表了文章 • 0 个评论 • 77 次浏览 • 2021-02-04 10:11 • 来自相关话题

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给... ...查看全部

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给他一样。

遇到这种人,气不气?

其实这种人不在少数,也正是有这样的人,才会有拿来主义,才会有做事毫无底线的云服务商,才导致了开源商业模式一再萎靡。

当然,老实人并不代表着一定要被欺负!就在1月15号,Elastic 公司 官方宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这次变更的主要针对目的,就是那些毫无底线的云服务商!

微信图片_20210203172125 (1).jpgElastic 公司 的CEO Shay Banon在他的博文中解释到:

虽然,从Apache 2.0 变更为 SSPL 与 Elastic License会改变一部分源代码,但是对于绝大多数的使用免费版本的用户及Elastic 公司的云客户以及自主管理软件客户也不会受到影响。唯一会受影响的,就是云服务商。

SSPL 允许用户以自由且不受限制的方式使用并修改代码成果,但是SSPL也有自己的要求:那就是如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

由此将限制云服务商在不对项目做出任何贡献的前提下,发布云服务商自己的 Elasticsearch 与 Kibana 服务,从而达到保护Elastic 公司的权益,亦可以让公司在开发免费产品方面持续投入的热情和资源,避免恶性循环。

微信图片_20210203172149.png

对于为什么会这么做,Shay Banon也给出了自己的解释:

长久以来,云服务商不断地肆意的将免费的开源软件集成到自己的云产品中,同时将其作为自己的云服务解决方案给予客户使用,俗称白嫖~造成了许多客户越来越多的放弃这些开源厂商的付费版本,直接断绝了开源厂商的经济来源!

早在Elastic之前,就有不少开源公司进行了变更:

Redis、MongDB、OpenCV、Google,Elastic绝不会是最后一个。

此次Elastic主要是借鉴了MongoDB的类似经验。

微信图片_20210203172152.png早在2018 年 10 月,MongoDB 就已经宣布将开源协议从 GNU AGPLv3切换到 SSPL,无论当时如何引起部分用户的不满,MongoDB 至少目前还很健康的继续经营,股价也从 2018 年的不足 100 美元 / 股涨到现在的 361 美元 / 股。可以说是开源公司学习的楷模。微信图片_20210203172155.jpg

SSPL 就是由 MongoDB 最初创建的可提供源代码的许可证,旨在体现开放源码理想的许可证,允许自由和不受限制地使用,修改和重新分发。

SSPL最简单也是最核心的一点就是前文提过的:如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

SSPL 是基于GPLv3 的 copyleft 许可证。并没有经过 OSI(Open Source Initiative,开源促进会,批准开源协议的机构) 批准,因此官方还特意声明:为了避免混淆,我们暂时不将两个产品称为开源,而使用“免费和开放” 进行描述。

有时候甚至会觉得,SSPL纯粹就是被那些习惯了白嫖的云服务商逼出来的产物,就像当每个人做事都只顾着看别人的成效数字,又有几个人能真正做好事呢?


开源商业模式正在被云服务商杀死!

科技创新柠檬^ 发表了文章 • 0 个评论 • 66 次浏览 • 2021-02-03 17:20 • 来自相关话题

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是... ...查看全部

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是开源的,也是让众多程序员喜欢他们的原因之一。

但是昨天看到了一个让我震惊的新闻:最新版本的Mapbox GL JS将不再是开源的!!!

作为个人来说,我并非是一个完美的热衷于开源的粉丝,因为我知道,创建和维护开源代码是多么一件吃力不讨好的事情,真的是非常累人,所以我一直很尊敬那些愿意开源的程序员,并且哪怕是开源,哪怕是对方过去已经丢弃不用的想法,我都觉得自己没有权力肆意使用对方的想法和知识产物。

但是同样的,直到昨天看到那个新闻之前,我仍然对商业开源软件抱着些许的客观、浪漫、自欺欺人的想法。在我的想法中,这是一个在当下重名利的世界中,保持着那颗开源的心,一直以开源做为自己的商业模式,持续走下去的童话故事,而Mapbox就是故事的主角,

去年的时候我也写过关于Mapbox商业模式的文章,就是他即提供了一种免费开源的版本,也提供了一种收费的版本,这些收费版本当然有一些独到的免费版本没有的功能。 听起来,有点像王者荣耀中有皮肤和没皮肤的概念。

如果对开源的商业模式有进一步了解兴趣的,建议可以看下Joseph Jacks的博文,链接地址如下:https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c044da7c

在最初的时候,没有人相信这种模式管用,但是随后发生的一切让人大跌眼睛,像Elastic、D2iQ(以前的Mesosphere)、MongoDB和Cloudera这样的几十家公司,都通过这种过往没出现过的方式,成功赚取了数十亿美元的投资。当然和现在相比,那个时候他们开放的开源版本可是开放好多。

直到今天,看了那个新闻之后,我们不由得感慨,开源模式即将死去!

那是什么让他从一时兴旺到如今的一命呜呼呢?

云服务商!

我们先回到Mapbox的例子,在Mapbox GL JS使用的案例中,Mapbox最早的决定是,开源其基于浏览器的地图渲染器的最早的两个版本(像我们熟知的Snap-Maps、纽约时报和CNN都用过)。自2014年首次发布以来,它在web开发人员中一直非常流行。一旦你知道你在找什么,你就会开始到处看到它。

微信图片_20210120152742.png

而对于我自己来说,当我的团队开始构建一个标记卫星图像的项目时,我才亲身体验了Mapbox GL JS的功能是有多么强大。使用Mapbox GL JS的功能,支持复杂几何图形的自由形式绘图,最终的成品是可以在地图上形成形状,也就是说是我的标记是被投影到地球上的一个真实位置,而不是简单的仅仅是悬浮在想象中的二维空间。这种效果让人感觉明显和直截了当,非常好用。

但事实上如果我不用Mapbox GL JS,从零开始设计就会非常非常困难。因为即使是用徒手画的简单形状也可以包含数千个单独的点。这样的话很快,我的屏幕上就会被数十万个顶点的形状填满,然后很显然,我的浏览器就会崩溃。而Mapbox GL JS是通过调用计算机上图形卡来帮助解决这个问题,如果不依靠Mapbox那几万小时的艰苦的工程工作,我们不可能在预算和时间有限的情况下完成该功能。Image for post

而这周Mapbox决定公布一个Mapbox GL JS的新版本,这个新版本不再开源瞬间震撼到了我!不仅仅是因为之前的V1版本是一个广受欢迎的开源版本,而是因为Mapbox作为一个开源代码的代名词给予我的那种崇高的敬意。在我的看法里,如果你要描述Mapbox是一家怎么样的公司而不提到开源,就像你和一个从未喝过的人谈到巧克力牛奶时不说这是一种液体一样!

Mapbox迄今为止,仍拥有超过800个开源项目,并在Github公共存储库活动方面一直名列全球前40名。并且Mapbox一直在给世界上知名度最高的开源软件贡献者提供各种工作机会,不仅仅是地图行业。

所以说,到底突然发生了什么?

其实,一切都源头还都是因为开源不再是一个在当下这个时代能站得住脚的商业模式!

Mapbox选择保持Mapbox GL JS的V2版本的专有权而不再开源就是一个强烈的信号。虽然这信号背后到底代表着什么还不是很清楚,但是已经让我咬牙切齿。。。

在我看来,这已经意味着我们要迎接一个时代的结束,这预示着代表着开源这种商业模式的寿命的终结!

其实我的潜意识里一直有着这个想法,早在Mapbox的新闻之前,但是Mapbox的新闻是真正为我心中猜想敲上实锤的那最后一击。

为了了解即使像Mapbox这样的公司也决定从开源转变的原因,我觉得可以先看下Mongo DB和Redis Labs这两个行业同行之前已经发生过的故事。

就在两年前,知名科技博主Ben Thompson写过一份文章,文章中阐述了一份总结关于AWS(Amazon Web Services——Amazon云服务), MongoDB和开源代码的经济回报。按他的说法就是:如果你提供了你的独家代码作为开源代码,并且让它变得流行起来,那么那些云服务商必然将用这些代码来为他们自己所用,为他们制造一些竞争性的服务,就好比用你制作的武器来攻击你一般,并且他们的心中没有丝毫歉意和犹豫,他们的眼中只有利益,对于这种行为,你的律师最后只会对你说一句无能为力,因为你曾经自己将这些内容开源了!

Ben在文中提到AWS推出了一项与MongoDB和Redis的付费产品直接竞争的对手服务,但也没有完全击败对手。事实上,自从那个时候起,MongoDB的股价从那时起已经上涨了275%,Redis在几个月前刚刚筹集了1亿美元,正式跨过了10亿美元的神奇估值门槛。

微信图片_20210120152751.png

但我想表述的更重要的不仅仅是Mongo和Redis在受到AWS的攻击后依旧蓬勃发展,而是他们是如何做到的?

这两家公司都以公司一贯的方式反击:一支知识产权的律师大军。

Redis采取了一种策略,在现有开源工具的更新版本中加入了一个有着严格限制性条件的commons条款,不过这让一些著名的开源代码的支持者非常不满:

微信图片_20210120152753.png

鉴于此,Redis后来用了另外一种方法,申请了一个完全新颖和独特的许可证,虽然这不会比commons条款更糟,但几乎可以肯定的是也不会更好。

另一家公司MongoDB呢?它也采取了俗称poison pill(毒丸) 的法律策略,在AWS推出竞争性的服务后不久,它就为自己的软件申请了一个新的、同样是虚构的许可证Server-Side Public License (SSPL)。

这些动作都是为了对抗云服务商的一系列举措。

更准确的说,他们的开源产品对任何有规模的公司都会起到使用时是否合规这个问题。

当然,这么做的代价就是Redis和Mongo从根本上减少了开源的开放性。从结果看,他们做的很好,虽然这是以牺牲了它们最初的理想为代价的,但毕竟活着是最重要的。

但是很多开源作者觉得自己被出卖了一样,我能理解他们的感受,但是我也理解Redis或MongoDB这么做是理性的生意行为。

回到Mapbox上,至少已经有一家云服务商公开的将Mapbox的代码复制并粘贴到他们的收费服务中: Azure,微软的云服务

去年,Azure发布了由Mapbox GL JS支持的地图样式,它是Azure地图服务的一个关键特性。为此,Mapbox甚至在他们公司的博客上写了一个声明。

虽然我们可以理解为Mapbox写这个声明是件好事,但我严重怀疑这是导致了Mapbox GL JS不再开源的开始。毕竟,在竞争无比激烈的公共云世界里,一旦一个云服务商开始提供服务,其他服务商肯定很快就照猫画虎一样开始提供类似服务。Mapbox终于发现自己的处境与MongoDB和Redis是如此的相似:它们在为那些万亿美元的科技巨头免费提供研发基础!

与Mongo和Redis不同,Mapbox最终还是抵抗了一些冲动。他们没有改变产品开源部分的基本许可证,而是彻底打破了这一局面。旧版本仍然是一个成熟且非常有用的版本,将保留其原始的许可证。同时Mapbox召集社区成员无限期地维护这个版本,我希望这会有用。

而新版本将保持一定程度的公开(例如代码都发布在Github上)。但是它不再是开源那样的了。对我来说,这感觉是一个更诚实的方法,而不是试图用一个没见过的、完全未经证实的许可证或一些“看似明白”的条款来穿针引线制造一种假象。

有些人可能会觉得这是一场悲剧,因为这意味着社区捐献可能会减少。诚然,尽管贡献者名单很长,但Mapbox的现任和前任员工还是贡献了最大的份额。但是这个项目已经吸引了一个庞大的、全球性的工程师群体,他们用它来建造东西,对它进行技术讲座。毫无疑问,昨天对于那些充满创作热情的用户来说的确是一个悲伤的日子。他们会继续过下去,但肯定有一种莫名的失落感。

至于这么做是否偏离了Mapbox最初的使命或公司文化?我想这条来自一位自公司成立以来一直在公司工作的现任员工的微博很好的总结了这一点:

微信图片_20210120152756.png

现实中很多事情都是很无奈的,毕竟我们要吃饭要生存下去。

很久以前我天真的以为围绕开源建立一家公司是很容易的,并且其他人都会很道德的使用这些开源的信息,但是现在我不再敢肯定这些。

我仍然相信开源是世界上一股强大的向善力量。我仍然认为,有的公司可以战略性地、认真地为开源做出贡献,不仅为自己的使命服务,也为集体利益服务。

但是,相对的,我再也不相信那些靠着风投存活下去的公司能够负责任地推行这种策略,将软件作为其价值主张的核心。我不再认为这是一个可行的模式,因为或快或慢,他们都会被他们的野心所吞噬,因为如果不这么做,他们最终只能在被自己的武器干掉和背叛最初的理念中间二选一。

昨天真是令人难过的一天。不仅仅因为Mapbox的宣布令人失望,而且就在昨天,我终于不得不向自己承认一点:

云服务商真的杀死了开源!

(来源于公众号:程序猿DD)


开发者真的喜欢开源吗?

IM即时通讯大兴 发表了文章 • 0 个评论 • 74 次浏览 • 2020-09-07 10:03 • 来自相关话题

作者 | Matt Asay译者 | 风车云马,责编 | 屠敏出品 | CSDN(ID:CSDNnews)FaunaDB创始人埃文·韦弗(Evan Weaver)有一个疯狂的想法:只要给开发者一个开放的API和一个适合他们开发的模型,那么云是最好的选... ...查看全部
作者 | Matt Asay

译者 | 风车云马,责编 | 屠敏
出品 | CSDN(ID:CSDNnews)

timg.jpg

FaunaDB创始人埃文·韦弗(Evan Weaver)有一个疯狂的想法:只要给开发者一个开放的API和一个适合他们开发的模型,那么云是最好的选择,即便是Linux和Kubernetes这样的开源平台。也许他们不想为任何代码做“手术”。那么,他们感兴趣的是云,而不是代码?

这是一个大胆的想法,倒也存在合理的地方。然而,当我向业界的重量级人物提出这个想法时,他们却因为各种不同的原因否定了。根据Lightspeed的投资者瓜拉夫•古普塔(Guarav Gupta)的说法,“开发人员对开源有着深深的喜爱和欣赏,几乎像是上瘾了”,而这是开发人员对API所没有的感觉。

有没有一种方法既能方便地使用API,又不会失去开发人员对开源社区的归属感?答案似乎是肯定的,但实现起来有点复杂。

不要忘记数据

StrAPI提供一种开源headless CMS,它的联合创始人兼CPO Aurélien Georget认为,开源的持久魅力不仅在于代码。例如,StrAPI的许多客户都想要定制他们的CMS。在这种情况下,云服务不能满足他们的需求。

即使他们不想修改代码,数据也会驱使他们这样做:“我们的用户对他们的代码的所有权不感兴趣,而是对他们的数据感兴趣。出于数据隐私的原因,或者从法律的角度出发(例如银行、保险、公共管理等部门),他们需要在自己的数据中心运行他们的代码——并保存他们的数据。”当然,这并不是说Weaver坚持以API为中心的方法是错误的,“每个解决方案都应该是面向API的,”Georget赞同道,“因为它让开发人员富有创造力,想象新的用例,并进行创新。”

Georget表示,使用云服务或许会更方便,但对于某些类别的应用程序或客户来说,这并不总是可行的。

DataStax为ApacheCassandra数据库社区提供代码和操作技巧,其首席宣传官PatrickMcFadin认为,API可能会成为一扇单向的门,过去开放的API随着时间的推移会被锁起来,或者被挡在付费墙后面。未来数据之争只会带来严重的专利化。相比之下,代码可以免费提供,因为它不是大多数企业(包括软件供应商)的核心“业务”。

Instaclustr的首席技术官本•布罗姆海德(BenBromhead)有一个理想的折中方案。Instaclustr将ApacheKafka等开源软件作为托管服务运行。只要建立的云服务严格遵守开源标准,他们就不会真正失去代码或数据的独立性。

开源数据层技术保证公司完全控制自己的数据和流程。通过选择100%的开源技术,公司可以拥有自己的代码,并保持不受供应商或技术的限制。比代码本身更重要的是,真正的开源技术确保了公司的关键信息流程不会被提供专有解决方案的供应商所破坏,也不会在任何情况下干扰公司充分利用自己数据的能力。

核心在于信任

这让我们回到了古普塔的观点,即开源有一些不同的,也许更好的东西。尽管“人们最终还是想以云服务的形式消费”,但是他认为,代码对于营造真正的技术亲和力——甚至对技术的喜爱和欣赏——是至关重要的。

您能通过API实现这种“亲密”(cosmic closeness)吗?古普塔认为不会。他说,“如果你是开源的,那么很容易构建社区,而不是带API的黑箱云服务”。因为,“作为一名开发者,你想通过自己的感觉和理解来开发它,并成为团队的一部分。”

这种开源运动的核心是信任:开放代码、开放路线图、开放交流、开放决策。这就是像Instaclustr这样的云供应商的成功之处:云的易用性以及对开源的信任和控制,可以为客户提供他们想要的东西。好的开源公司会建立起令人不可思议的信任。明智的云计算公司不甘示弱,一定不会让开发人员缺失在开源社区中的那种信任和喜爱。

原文:https://www.infoworld.com/article/3572324/do-developers-really-care-about-open-source.html