分类 观点 下的文章

WordPress 和 ReactJS 分道扬镳了,WordPress 的共同创始人 Matt Mullenweg 在其博客中宣布了这一消息。

关于 WordPress 之后将采用何种 JavaScript 框架,Matt 并未宣布,目前几个选择:

  1. VueJS
  2. Preact
  3. 其它框架(AngularEmberPolymerAurelia 等等)

其中, VueJS 和 Preact 的呼声最高。关于它们的优劣势分析如下:

VueJS

  • 优势:易于学习
  • 优势:与 Laravel 一贯协作良好
  • 优势:比 Preact 更流行,支持的社区更多
  • 优势:贡献者比 Preact 更多
  • 劣势依赖于关键人物
  • 状态:Github 上有 133 个核心贡献者,67152 个星标,做了 209 次发布
  • 资金支持:截止至本文写作, 在社区的支持下,VueJS 在 OpenCollective 得到了每年 $9,895 的捐助,作者尤雨溪在 [Patreon](https://www.patreon.com/evanyou) 得到了每月 $8,815 的捐助。

我确信 WordPress 使用 VueJS 能够更好。VueJS 有大量的拥护者,而且初学者易于上手。如果采用 VueJS,这对于 WordPress 是极好的。我自己也在几个项目中使用 VueJS,我喜欢它。

此外,这个框架也可以用在 WordPress 之外的项目(比如 Vue 与 Laravel 的集成),这可以让开发者在 WordPress 项目和非 WordPress 项目中发挥其经验。 有很多开发者都同时参与 Laravel 和 WordPress 项目,所以如果使用同一个框架,有助于同时推动 Laravel、 VueJS 和 WordPress 的发展。

PreactJS

  • 优势:易于过渡
  • 优势:与 VueJS 大致相同的资金支持,不断推进的社区
  • 优势:基于 React 的子集库仍然被 Preact 和 compat 支持
  • 劣势:过渡也许导致代码混乱和困扰(针对初学者)
  • 劣势:依赖于关键人物
  • 状态:在 GitHub 上有 100 个核心贡献者, 14319 个星标,做了 114 次发布
  • 资金支持:截止至本文写作,在社区的支持下, Preact 在 OpenCollective 得到了 $16,087 的捐助

PreactJS 有其优势,但我找不到合适的人咨询(我仅在两个项目中稍微使用过它)。不过看起来从 React 过渡到 Preact 非常容易。这也许会促使开发者选择 Preact,但是我认为这不是选择它的理由。这只会让开发者在采用这个新的 JavaScript 框架生态、node 模块、Webpack 时发生混淆,Preact 又不是 React 的别名!这会让代码味道难闻。

本文作者在几个平台上做了投票,欢迎参与你的意见:

那么你的意见呢?

(题图:maxprog.net.pl)

Facebook 公司的 BSD+专利许可证失败的原因不是因为许可证本身,而是因为它忽略了开源软件更深层次的本质。

2017 年 7 月,Facebook 公司应用于 react 等项目的许可证组合被 Apache 软件基金会禁止使用。该许可证组合曾被 Facebook 应用于其所有作为开源软件发布的项目,它使用了被 OSI 批准的广泛使用的非互惠许可证 BSD 3-Clause,并且加入了宽泛的、非互惠的专利授权条款,但为了应对挑衅者,该许可证组合的终止规则同样宽泛。这种组合代表了一种新的开源许可证,我称之为“Facebook BSD+专利许可证”(FB + PL),在我看来,该许可证试图与 GPL v2 和 Apache v2 许可证保持兼容,以规避这些许可证所指称的不兼容性。

使用 FB + PL 许可证的 Apache 项目仍在发挥作用,但是我认为 Facebook 所犯错误的原因可能不会立即被一贯秉持实用主义态度的软件开发人员们所注意到。例如,由律师转行做程序员的 Dennis Walsh 针对这个问题表示:“它没有什么实质意义”。他的观点是,FB + PL 许可证仅对你所使用的适用该许可证的特定软件项目产生影响,专利授权撤回的后果对另一个专利持有者来说并不严重。他得出结论说:

“Facebook 想要推广开源软件同时不被起诉——这是一个崇高的目标。为此,它可以使用一些苛刻的条款。但在这种情况下,由于上述实践和法律方面的原因,很难在被攻击之后发现是谁干的。”

Dennis 也许是对的,但这并不重要。Facebook 自出机杼地发明自己的开源许可证是一个坏主意。有一系列非直接风险或具体情境的重要因素需要考虑,Facebook 的许可证几乎将它们完全忽略了。

  1. 许可证审批很重要
    使用非 OSI 批准的许可证意味着,就像任何专有许可证一样,将其应用于企业用途时总是需要法律审查。OSI 许可证审批之所以重要,是因为它为开发人员提供了一种指示,即社区评估已经认可了该许可证,并认为它以不会产生不可接受风险的方式提供了软件自由。如果 Facebook 采取了寻求 OSI 批准的路线,那么很有可能一开始就会发现并且回避了他造成的问题。实际上有一种 OSI 批准的许可证能够实现 Facebook 的明确目标(BSD + 专利许可证)。该许可证最近刚被提交和批准,这看起来是 Facebook 可以考虑采用的合理替代方案。
  2. 较少的提前许可
    不仅仅是许可证批准很重要。任何有关创新自由的不确定性都会阻碍开发人员使用代码。与使用相关的含糊条款在使用前需要消除歧义——该步骤相当于为了继续推进而寻求许可。出于同样的原因,公共领域对于软件开发者来说是不利的,因为使用条款规定了在采用之前需要寻求许可。由于需要向项目添加一个与 Facebook 相关的法律文件,每个企业开发人员现在都需要与法律顾问联系,才能继续推进。即使答案是“是的,可以”,他们仍然不得不停下来寻求许可。正如 Aaron Williamson 指出的那样,这可能不是他们的反应。
  3. 不公平的比赛场
    Facebook 使用的专利授权条款为其提供了特殊权利和保护,而项目中的其他人并不享有。这使得开源开发人员感到紧张,原因与 贡献者协议 contributor agreements 一样。开源项目的软件自由的全部价值在于它创造了一个安全的空间,在其中每个人都是平等的,它保护每个人免受他人动机的影响。刻意为自己设置额外权利是反社会的行为,可悲的是,开源社区有很多不平等权利最终被滥用的例子。
  4. 隐含的授权无效
    许多开源法律机构认为,通过对用于任何目的的软件使用授予许可,即使没有提及专利的许可证也隐含授予专利许可。通过添加任意形式的外部专利授权,Facebook 表示它不认为隐含授权足够(最好的情形)或存在(最差的情形)。专注于开源软件的律师们认为,这是 Facebook 毫无根据的扩大化解释。这也是为什么 OSI 放弃了对 CC0 许可协议批准的原因
  5. Apache 基金会的规则
    虽然我没有找到清晰和完整的理由,但 Apache 基金会似乎已经对 Facebook 的许可证组合做出了裁定,因为 Apache 基金会认为,Facebook 的专利授权比 Apache v2 许可证中的专利条款限制性更强。Apache 基金会希望自身是一个中立的软件来源——一个“万能供血者”,而对此产生妨害的条款很有可能违背其规则。对于旨在成为 Apache 生态系统一部分的组件,与 Apache 的许可证产生混乱的做法看起来不太明智。

所以争论这个问题没有什么意义,因为风险很小,问题微不足道。以一种忽视我上面列出的五个社区规范的方式行动无益于任何人,甚至也帮不了 Facebook。虽然 Facebook 目前正在坚持己见,但我希望它能够改正,我愿意提供帮助。


作者简介:Simon Phipps 是 “公开软件” Public Software 开源项目的发起人,以志愿者身份担任 OSI 和 文档基金会 The Document Foundation 的理事。

译者简介:薛亮,集慧智佳知识产权咨询公司高级咨询师,擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

引子:开源软件作者发出求救

约一个月前,笔者撰写了“开源情怀遭遇专利咸猪手”。现在我们回一下锅:看看事情的进展,分析可能的结果,以期开源人再碰到类似状况时,对可能的发展能多一点预期和准备,少一点盲目性和不确定性。

事情是这样开始的:按照开源中国博客文章,一名开源软件作者发出求救的呼声,指出知名公司将他的开源软件 XXL-JOB 申请成了专利。

XXL-JOB 作者于 2017 年 6 月在他人提醒之后,发现他的作品 XXL-JOB 被他人申请了中国专利(CN201610843823.X)。

依照开源中国的另一篇博客文章,XXL-JOB 作者委托开源中国与专利申请人进行交涉,作者的基本诉求包括:申请人撤回专利申请并发布声明加以澄清。开源中国与作者进一步希望,如,申请人从事实和技术角度加以澄清,并提出如果专利授权,应声明其与有关开源项目的关系,并“无偿开源”等。

如笔者在前文中指出的,此事件很典型,无论在国内还是国外都不是孤立性事件。事情的根本在于:开源软件的开发者仅对自己智力劳动成果的知识产权做了很少的保留,将软件基本开放、贡献给公众无偿使用。而开发者的无私奉献却被一些人窃取或搭便车谋利:包括但不限于通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

从此事开始以及开源中国与专利申请人进行交涉的进展报告发出到现在,3 个多月过去了,没有进一步的实质性进展。笔者并不认为奇怪。为什么呢?

如何发展?我们来抽丝剥茧……

没有进展,就是双方谈不拢。开源作者及开源中国一方的要求总结如下:

作者的诉求包括:

  • 专利申请人向专利局申请撤销专利。
  • 以公司名义发布正面声明,客观的描述此事。

开源中国与作者对声明内容的要求是:

  1. 详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。
  2. 在声明中表明将公开宣布主动申请撤销专利。
  3. 如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

从法律角度讲,双方对话行为属于民事行为,是基于双方自愿而进行的,任何一方都没有义务必须要进行对话协商。而如果对话不能进行,且当任何一方认为自己的正当权益受到对方损害时,可以向法院针对对方提起民事诉讼,也就是让法院做主。

专利申请人那头先按下不表,让我们看看作者一方的正当权益是否受到了损害。很遗憾,看来现在的主动权在专利申请人一边。

开源作者的要求:专利申请人向专利局申请撤销专利。

解读:如果专利申请是不正当的,上述要求是合理的。反之,则不合理。所以问题的关键是专利申请人所提出的专利申请是否正当。该问题随后再进行分析。

开源作者的要求:(专利申请人)以公司名义发布正面声明,客观的描述此事。

解读:公司就这个问题做出声明和澄清,从法律角度讲,公司可以自主做出决定,通常出于礼貌和善意的沟通,尤其不会产生负面影响时,公司会比较愿意进行。但法律方面没有强制要求,也就是说,专利申请人没有沟通或发出声明的义务,即使公司方面存在问题。而实际上,公司方面是否存在问题,即专利申请人所提出的专利申请是否正当,尚没有确定。

开源中国与作者对声明内容的要求 1:详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。

解读:“管理不善”应当是指专利申请人如果进行了不正当的专利申请,则是一个管理不善的问题。这就又转回到了那个关键问题:专利申请是否正当。

这句话是比较有意思的:“如果是在开源软件上做改进,那么应该详细描述改进的内容”。这句话字面之下似乎淡淡的有一层意思:如果专利申请针对的是在开源软件基础上做出的改进,那么专利申请可以是正当的。是否如此呢?答案基本上是肯定的。

如笔者前文中提到过的,按照专利制度的本意,任何人可以在现有的公知技术的基础上做出创新性的改进,然后就改进的内容去申请专利。这是正当的,也是受到鼓励和法律保护的。

关键问题的答案

所以,“专利申请是否正当”这个关键问题的答案就依赖于专利申请人是否做出了创新性的改进并就该改进来申请的专利,如果是,则专利申请是正当的;如果不是,就不正当。

接下来,就更加微妙了。开源方要求“细描述改进的内容”,仅就此要求而言,站在专利申请人立场上,是绝对不可以加以说明的。原因是:专利申请人就此内容的任何技术性说明都可能对申请人的专利构成不良影响。专利正在经受国家知识产权局的审查,审查的重点内容就是专利的新创性,也就是其对现有技术到底做出了什么样的改进,改进是否有新创性。专利申请人就此内容发表的任何意见,专利审查员都可以从中摘出对专利申请的新创性不利的内容,利用其来缩小专利的保护范围甚至驳回专利申请。

这种情形之下,申请人不针对“改进的内容”发表任何意见是明智、正当的。而开源方如果坚持要求申请人“细描述改进的内容”就显得强人所难,就不那么正当了。这时,开源方正确的做法是自己来完成开源软件作品与专利申请的比对,如果认为专利申请并未做出实质性的创新,可以将技术分析意见及相关支持性的技术文件按照第三方意见的形式通过正当程序提交给专利审查员。如果审查员认为开源方提出的意见是正确的,当然会加以采纳,相应会对专利申请加以合理限制或予以驳回。如果开源方对审查员的认定结果并不满意,后续还有行政和司法救济程序可以利用。

三点提示

这里提示的第一点是:不能简单因为专利申请当中涉及到的开源软件中采用的技术就直接认为专利申请中不存在新创性的技术改进。对新创性改进而得来的技术方案,在加以描述时要涉及到现有技术,这是正常的,不可避免的。

第二点:真正完成专利申请是否有实质性创新,专业性很强,成本很高;走行政和司法救济程序,成本就更高了。

第三点暂且不表。为什么事情还没有进展其实已经清楚了:专利申请人方面不表态是正当和必然的。至少要等到专利审查员做出授权或驳回的决定才有初步分晓。

开源中国与作者对声明内容的要求:

2、在声明中表明将公开宣布主动申请撤销专利。

3、如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

解读:如果专利审查员做出授权决定,表明专利针对开源软件在内的现有技术做出了新创性改进,相应专利申请也就是正当的。既然是正当的,专利申请人想来不会撤销或放弃专利申请,也不会将辛苦得来的专利“开源”或开放给公众。如果专利审查员做出驳回决定,也就不存在专利申请人撤销或放弃专利申请的问题了。当然,如果有人发起后续行政、司法救济程序,则可能带来变数。

完整地讨论好问题,就要说到第三点:如果专利最终被行政或司法认定成没有新创性从而被驳回,是否就足以证明专利申请人恶意窃取开源软件的技术成果呢?如果没有充分的相关理由和证据,还真不好这么下结论。因为很可能专利申请人出于善意想做出发明,并认为自己已经做出了具有新创性的改进,而最终做出认定的国家知识产权局或法院对新创性的理解和要求与专利申请人不同,才得出了不具有新创性的结论。如果是这种情况,专利申请人只是犯了一个诚实的错误而并不具有恶意。

收尾,旧话重提

我看到,投身开源软件的有情怀的理想主义者,有一些在黑暗和不公的打击之下,愤而退出了开源事业。笔者非常理解他们。我还看到,更多的人无视这些打击,以不变的情怀和理想,在这条道路上继续栉风沐雨,砥砺前行。笔者非常敬佩他们。人间正道是沧桑。


作者:李可,江湖人称“可哥”,老牌专利代理人,集慧智佳知识产权咨询公司的知识产权高级咨询师。70 后文艺理工男,属牛,性子慢但踏实稳妥。

负载均衡器如何帮助你解决分布式系统的复杂性。

Ship with tug

原生云应用旨在利用分布式系统的性能、可扩展性和可靠性优势。不幸的是,分布式系统往往以额外的复杂性为代价。由于你程序的各个组件跨网络分布,并且这些网络有通信障碍或者性能降级,因此你的分布式程序组件需要能够继续独立运行。

为了避免程序状态的不一致,分布式系统设计应该有一个共识,即组件会失效。没有什么比在网络中更突出了。因此,在其核心,分布式系统在很大程度上依赖于负载平衡——请求分布于两个或多个系统,以便在面临网络中断时具有弹性,并在系统负载波动时水平缩放时。

随着分布式系统在原生云程序的设计和交付中越来越普及,负载平衡器在现代应用程序体系结构的各个层次都影响了基础设施设计。在大多数常见配置中,负载平衡器部署在应用程序前端,处理来自外部世界的请求。然而,微服务的出现意味着负载平衡器可以在幕后发挥关键作用:即管理服务之间的流。

因此,当你使用原生云程序和分布式系统时,负载均衡器将承担其他角色:

  • 作为提供缓存和增加安全性的反向代理,因为它成为外部客户端的中间人。
  • 作为通过提供协议转换(例如 REST 到 AMQP)的 API 网关
  • 它可以处理安全性(即运行 Web 应用程序防火墙)。
  • 它可能承担应用程序管理任务,如速率限制和 HTTP/2 支持。

鉴于它们的扩展能力远大于平衡流量, 负载平衡器 load balancer 可以更广泛地称为 应用交付控制器 Application Delivery Controller (ADC)。

开发人员定义基础设施

从历史上看,ADC 是由 IT 专业人员购买、部署和管理的,最常见运行企业级架构的应用程序。对于物理负载平衡器设备(如 F5、Citrix、Brocade等),这种情况在很大程度上仍然存在。具有分布式系统设计和临时基础设施的云原生应用要求负载平衡器与它们运行时的基础设施 (如容器) 一样具有动态特性。这些通常是软件负载均衡器(例如来自公共云提供商的 NGINX 和负载平衡器)。云原生应用通常是开发人员主导的计划,这意味着开发人员正在创建应用程序(例如微服务器)和基础设施(Kubernetes 和 NGINX)。开发人员越来越多地对负载平衡 (和其他) 基础设施的决策做出或产生重大影响。

作为决策者,云原生应用的开发人员通常不会意识到企业基础设施需求或现有部署的影响,同时要考虑到这些部署通常是新的,并且经常在公共或私有云环境中进行部署。云技术将基础设施抽象为可编程 API,开发人员正在定义应用程序在该基础设施的每一层的构建方式。在有负载平衡器的情况下,开发人员会选择要使用的类型、部署方式以及启用哪些功能。它们以编程的方式对负载平衡器的行为进行编码 —— 随着程序在部署的生存期内增长、收缩和功能上进化时,它如何动态响应应用程序的需要。开发人员将基础设施定义为代码 —— 包括基础设施配置及其运维。

开发者为什么定义基础设施?

编写如何构建和部署应用程序的代码实践已经发生了根本性的转变,它体现在很多方面。简而言之,这种根本性的转变是由两个因素推动的:将新的应用功能推向市场所需的时间(上市时间)以及应用用户从产品中获得价值所需的时间(获益时间)。因此,新的程序写出来就被持续地交付(作为服务),无需下载和安装。

上市时间和获益时间的压力并不是新的,但由于其他因素的加剧,这些因素正在加强开发者的决策权力:

  • 云:通过 API 将基础设施定义为代码的能力。
  • 伸缩:需要在大型环境中高效运维。
  • 速度:马上需要交付应用功能,为企业争取竞争力。
  • 微服务:抽象框架和工具选择,进一步赋予开发人员基础设施决策权力。

除了上述因素外,值得注意的是开源的影响。随着开源软件的普及和发展,开发人员手中掌握了许多应用程序基础设施 - 语言、运行时环境、框架、数据库、负载均衡器、托管服务等。微服务的兴起使应用程序基础设施的选择民主化,允许开发人员选择最佳的工具。在选择负载平衡器的情况下,那些与云原生应用的动态特质紧密集成并响应的那些人将超人一等。

总结

当你在仔细考虑你的云原生应用设计时,请与我一起讨论“在云中使用 NGINX 和 Kubernetes 进行负载平衡”。我们将检测不同公共云和容器平台的负载平衡功能,并通过一个宏应用的案例研究。我们将看看它是如何被变成较小的、独立的服务,以及 NGINX 和 Kubernetes 的能力是如何拯救它的。


作者简介:

Lee Calcote 是一位创新思想领袖,对开发者平台和云、容器、基础设施和应用的管理软件充满热情。先进的和新兴的技术一直是 Calcote 在 SolarWinds、Seagate、Cisco 和 Pelco 时的关注重点。他是技术会议和聚会的组织者、写作者、作家、演讲者,经常活跃在技术社区。


via: https://www.oreilly.com/learning/developer-defined-application-delivery

作者:Lee Calcote 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我们最近探讨了那些世界银行定义为高收入的富裕国家是如何倾向于使用与世界上其它地区不同的技术。这其中我们看到的最大的差异在于 Python 编程语言。就高收入国家而言,Python 的增长甚至要比 Stack Overflow Trends 等工具展现的或其他针对全球的软件开发的排名更高。

在本文中,我们将探讨在过去五年中 Python 编程语言的非凡增长,就如在高收入国家的 Stack Overflow 流量所示那样。“增长最快”一词很难准确定义,但是我们认为 Python 确实可以称得上增长最快的主流编程语言。

这篇文章中讨论的所有数字都是针对高收入国家的。它们一般指的是美国、英国、德国、加拿大等国家的趋势,他们加起来占了 Stack Overflow 大约 64% 的流量。许多其他国家,如印度、巴西、俄罗斯和中国,也为全球软件开发生态系统做出了巨大贡献,尽管我们也将看到 Python 在这方面有所增长,但本文对这些经济体的描述较少。

值得强调的是,一种语言的用户数量并不能衡量语言的品质:我们是在描述开发人员使用的语言,但没有规定任何东西。(完全披露:我曾经主要使用 Python 编程,尽管我已经完全切换到 R 了)。

Python 在高收入国家的增长

你可以在 Stack Overflow Trends 中看到,Python 在过去几年中一直在快速增长。但是对于本文,我们将重点关注高收入国家,考虑的是问题的浏览量而不是提出的问题数量(这基本上结果是类似的,但是每个月都有所波动,特别是对于较小的标签分类)。

我们有关于 Stack Overflow 问题的查看数据可以追溯到 2011 年底,在这段时间内,我们可以研究下 Python 相对于其他五种主要编程语言的增长。(请注意,这比 Stack Overflow Trends 的时间范围更短,它可追溯到 2008 年)。这些目前是高收入国家里十大访问最高的 Stack Overflow 标签中的六个。我们没有包括的四个是 CSS、HTML、Android 和 JQuery。

2017 年 6 月,Python 是成为高收入国家里 Stack Overflow 访问量最高的标签的第一个月。这也是美国和英国最受欢迎的标签,以及几乎所有其他高收入国家的前两名(接着就是 Java 或 JavaScript)。这是特别令人印象深刻的,因为在 2012 年,它比其他 5 种语言的访问量小,比当时增长了 2.5 倍。

部分原因是因为 Java 流量的季节性。由于它在本科课程中有很多课程,Java 流量在秋季和春季会上升,夏季则下降。到年底,它会再次赶上 Python 吗?我们可以尝试用一个叫做 “STL” 的模型来预测未来两年的增长, 它将增长与季节性趋势结合起来,来预测将来的变化。

根据这个模型,Python 可能会在秋季保持领先地位或被 Java 取代(大致在模型预测的变化范围之内),但是 Python 显然会在 2018 年成为浏览最多的标签。STL 还表明,与过去两年一样,JavaScript 和 Java 在高收入国家中的流量水平将保持相似水平。

什么标签整体上增长最快?

上面只看了六个最受欢迎的编程语言。在其他重大技术中,哪些是目前在高收入国家中增长最快的技术?

我们以 2017 年至 2016 年流量的比例来定义增长率。在此分析中,我们决定仅考虑编程语言(如 Java 和 Python)和平台(如 iOS、Android、Windows 和 Linux),而不考虑像 AngularTensorFlow 这样的框架(虽然其中许多有显著的增长,可能在未来的文章中分析)。

xkcd - Fastest-Growing

由于上面这个漫画中所描述的“最快增长”定义的激励,我们将增长与平均差异图中的整体平均值进行比较。

Python 以 27% 的年增长率成为了规模大、增长快的标签。下一个类似增长的最大标签是 R。我们看到,大多数其他大型标签的流量在高收入国家中保持稳定,浏览 Android、iOS 和 PHP 则略有下降。我们以前在 Flash 之死这篇文章中审查过一些正在衰减的标签,如 Objective-C、Perl 和 Ruby。我们还注意到,在函数式编程语言中,Scala 是最大的并且不断增长的,而 F# 和 Clojure 较小并且正在衰减,Haskell 则保持稳定。

上面的图表中有一个重要的遗漏:去年,有关 TypeScript 的问题流量增长了惊人的 142%,这使得我们需要去除它以避免压扁比例尺。你还可以看到,其他一些较小的语言的增长速度与 Python 类似或更快(例如 R、Go 和 Rust),而且还有许多标签,如 Swift 和 Scala,这些标签也显示出惊人的增长。它们随着时间的流量相比 Python 如何?

像 R 和 Swift 这样的语言的发展确实令人印象深刻,而 TypeScript 在更短的时间内显示出特别快速的扩张。这些较小的语言中,有许多从很少的流量成为软件生态系统中引人注目的存在。但是如图所示,当标签开始相对较小时,显示出快速增长更容易。

请注意,我们并不是说这些语言与 Python “竞争”。相反,这只是解释了为什么我们要把它们的增长分成一个单独的类别,这些是始于较低流量的标签。Python 是一个不寻常的案例,既是 Stack Overflow 中最受欢迎的标签之一,也是增长最快的其中之一。(顺便说一下,它也在加速!自 2013 年以来,每年的增长速度都会更快)。

世界其他地区

在这篇文章中,我们一直在分析高收入国家的趋势。Python 在世界其他地区,如印度、巴西、俄罗斯和中国等国家的增长情况是否类似?

确实如此。

在高收入国家之外,Python 仍旧是增长最快的主要编程语言。它从较低的水平开始,两年后才开始增长(2014 年而不是 2012 年)。事实上,非高收入国家的 Python 同比增长率高于高收入国家。我们不会在这里研究它,但是 R (其它语言的使用与 GDP 正相关) 在这些国家也在增长。

在这篇文章中,许多关于高收入国家标签 (相对于绝对排名) 的增长和下降的结论,对世界其他地区都是正确的。两个部分增长率之间有一个 0.979 Spearman 相关性。在某些情况下,你可以看到类似于 Python 上发生的 “滞后” 现象,其中一个技术在高收入国家被广泛采用,一年或两年才能在世界其他地区扩大。(这是一个有趣的现象,这可能是未来文章的主题!)

下一次

我们不打算为任何“语言战争”提供弹药。一种语言的用户数量并不意味着它的质量,而且肯定不会让你知道哪种语言更适合某种特定情况。不过,考虑到这点,我们认为值得了解什么语言构成了开发者生态系统,以及生态系统会如何变化。

本文表明 Python 在过去五年中,特别是在高收入国家,显示出惊人的增长。在我们的下一篇文章中,我们将开始研究“为什么”。我们将按国家和行业划分增长情况,并研究有哪些其他技术与 Python 一起使用(例如,估计多少增长是由于 Python 用于 Web 开发而不是数据科学)。

在此期间,如果你使用 Python 工作,并希望你的职业生涯中进入下一阶段,那么在 Stack Overflow Jobs 上有些公司正在招聘 Python 开发


via: https://stackoverflow.blog/2017/09/06/incredible-growth-python/

作者:David Robinson 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

使用开源的方式有利于你的盈亏底线以及开源生态系统。

 title=

合规性工业联合体 The Compliance Industrial Complex ” 是一个术语,它会唤起那些组织参与精心设计并且花费昂贵流程的以遵守开源许可条款的反乌托邦想象。由于“生活经常模仿艺术”,许多组织采用了这种做法,可惜的是它们剥夺了许多开源模型的好处。本文介绍了一种经济高效的开源软件许可证合规性方法。

开源许可证通常对从第三方授权的代码分发者有三个要求:

  1. 提供开源许可证的副本
  2. 包括版权声明
  3. 对于 copyleft 许可证(如 GPL),将相应的源代码提供给接受者。

(与任何一般性声明一样,可能会有例外情况,因此始终建议审查许可条款,如有需要,请咨询律师的意见。)

因为源代码(以及任何相关的文件,例如:许可证、README)通常都包含所有这些信息,所以最简单的遵循方法就是随着二进制/可执行程序一起提供源代码。

替代方案更加困难并且昂贵,因为在大多数情况下,你仍然需要提供开源许可证的副本并保留版权声明。提取这些信息来结合你的二进制/可执行版本并不简单。你需要流程、系统和人员来从源代码和相关文件中复制此信息,并将其插入到单独的文本文件或文档中。

不要低估创建此文件的时间和费用。虽然有工具也许可以自动化部分流程,但这些工具通常需要人力资源(例如工程师、质量经理、发布经理)来准备代码来扫描并对结果进行评估(没有完美的工具,几乎总是需要审查)。你的组织资源有限,将其转移到此活动会增加机会成本。考虑到这笔费用,每个后续版本(主要或次要)的成本将需要进行新的分析和修订。

也有因不选择发布不能被很好识别的源码而导致增加的其他成本。这些根源在于不向开源项目的原始作者和/或维护者发布源代码, 这一活动称为上游化。独自上游化一般不满足大多数开源许可证的要求,这就是为什么这篇文章主张与你的二进制/可执行文件一起发布源代码。然而,上游化和提供源代码以及二进制/可执行文件都能提供额外的经济效益。这是因为你的组织不再需要保留随着每次发布合并开源代码修改而产生的私有分支 - 由于你的内部代码库与社区项目不同,这将是越来越消耗和凌乱的工作。上游化还增强了开源生态系统,它会鼓励社区创新,从中你的组织或许也会得到收益。

那么为什么大量的组织不会为其产品发布源代码来简化其合规性工作?在许多情况下,这是因为他们认为这可能会暴露他们竞争优势的信息。考虑到这些专有产品中的大量代码可能是开源代码的直接副本,以支持诸如 WiFi 或云服务这些当代产品的基础功能,这种信念可能是错误的。

即使对这些开源作品进行了修改来适配其专有产品,这些更改也往往是微不足道的,并包含了很少的新的版权部分或可用来专利的内容。因此,任何组织都应该通过这种方式来查看其代码,因为它可能会发现其代码库中绝大部分是开源的,只有一小部分是真正专有的、与竞争对手区分开来的部分。那么为什么不分发和向上游提交这些没有差别的代码呢?

考虑一下拒绝遵从工业联合体的思维方式, 以降低成本并大大简化合规性。使用开源的方式,并体验发布你的源代码的乐趣,以造福于你的盈亏底线和开源生态系统,从中你将继续收获更多的利益。


作者简介

Jeffrey Robert Kaufman - Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商红帽公司的开源知识产权律师。Jeffrey 还担任着 Thomas Jefferson 法学院的兼职教授。 在加入红帽前,Jeffrey 在高通担任专利法律顾问,为首席科学家办公室提供开源顾问。 Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。更多关于我

(题图: opensource.com)


via: https://opensource.com/article/17/9/economically-efficient-model

作者:Jeffrey Robert Kaufman 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出