Skip to main content

区块链将会如何影响开源

中本聪[1]十年前创立比特币伊始,就引来来众多的追随者,并慢慢演变为去中心化的一场运动。甚至于,对于某一些人来说,区块链技术就像互联网那样深刻影响着人类社会的技术,当然,也有很大一部分人认为,区块链不过是另外一场庞氏骗局罢了,就在这众说纷纭之中,区块链也在进化并不断的尝试寻找自己的位置。无论怎样,有一件事是确定的,那就是区块链是一项颠覆性的技术,将从根本上改变一些行业。我深信开源就是其中之一。
开源的模式
开源是一种软件协作开发方法,也是软件分发的模式,开源允许拥有共同兴趣的人们一起协作,进而生产出他们中间任何个体都无法独立完成的事情,它让整体所创建的价值远远大于部分的总和。开源通过分布式的协作工具(IRC、email、git、wiki、issue 跟踪等)、以及开源许可证模式下的分发和保护,当然还有诸如 Apache 软件基金会[2]云原生基金会[3]这样的非盈利基金会的治理。
说来已久,最让人们好奇的莫过于开源的模式本质上是缺乏金钱上的激励的。在开源界,像人类社会的其它方面一样,分很多的派系,如其中一些人就认为谈开源就不要谈钱,开源本应该就是由内在的激励的自由和资源的行为(诸如“共同理想”、“为了伟大的事情”);也有另外一些人认为开源需要获得外部的尤其是金钱上的激励。虽然开源项目仅仅通过世上的志愿者来完成是富有理想的浪漫主义色彩的,就目前的现状来看,事实上主要的开源完成的贡献均是在有支付的情形下搞定的。当然,毋庸置疑的是我们拥有大量的无偿贡献者,但是这些贡献都是来来回回的临时性的,或者是某些受追捧的项目备受世人关注。建立和维系开源项目是需要企业倾注大量心血和精力来进行开发、文档化、测试、修复缺陷,而且是持续性的一如既往的,绝不是一时心血来潮。要知道,开发软件产品是需要克服大量困难的事情,这类事情最好是有金钱上的激励方能持久。
开源的商业化
众所周知,Apache 软件基金会是通过捐助而生存的,当然还有其它的一些收入:赞助、会议费用等等。但是要知道这些资金主要是用于运营基金会本身,如为项目提供法律保护,以及确保有足够的服务器来运行构建程序、缺陷追踪、邮件列表等等。
同样的,云原生基金会 CNCF 会收取会员费,以及更多的会议费用,这些费用同样是用来运营基金会以及为项目提供资源。如今的年头,绝大多数的软件已经不能在自己的笔记本电脑里构建了,它们都的运行和测试都是在云平台中上百台服务器当中。这些都属于基金会的日常开销。其它如开展营销活动,品牌设计、分发一些小的宣传物品,也是基金会份内的事情。基金会的核心任务是实施正确的流程,与用户,开发人员和控制机制进行交互,并确保将可用财务资源分配给开源项目以实现共同利益。
看起来是一切都运行良好,不是吗?开源项目可以募捐到钱,基金会也可以公正的进行分发,那么哪里有问题了呢?
这里没有说明的是:用于在开源生产者和开源消费者之间进行价值转移,直接,透明,可信,分散,自动的双向链接。就目前而言,所有的链接都是单向或间接的:
◈ 单向:一名开发者(广义上的开发者,可以是软件生产中的任何角色:码农、维护者、分发者),利用自己的聪明才智,绞尽脑汁,并花费无数时间来开发开源项目,且提交贡献为所有的开源用户分享这一价值。但是基本上都是一厢情愿的。
◈ 间接:如果软件出现了 bug,影响到了特定的用户/公司的话,有下列几种情形出现:
◈ 让内部开发人员修复 bug,然后提交一个拉取请求(PR),这是比较理想的状态,这些公司并不总是能够聘请到特定的开源项目的开发人员,因为一般公司都会使用成百上千个开源项目。
◈ 聘请专门从事该特定开源项目的自由职业者并支付服务费用。理想情况下,自由职业者也是开源项目的提交者,可以直接快速更改项目代码。否则,修复程序可能永远不会进入上游项目。
◈ 接近围绕开源项目提供服务的公司。这些公司通常雇用开源提交者来影响和获得社区的可信度,并提供产品、专业知识和专业服务。
第三种选择是维持许多开源项目的成功模式[4]。无论这些公司提供服务(培训、咨询、workshop)、技术支持、打包、开放核心,还是 SaaS 服务,不可否认的是他们都需要雇佣上百个全职的员工来为开源做出努力,我们可以看到这样的公司有一大把[5],他们成功的建立了有效的开源商业模式,而且正在有更多的公司加入这个阵营。
支持开源项目的公司在这个生态系统中发挥着重要的作用:它们介于开源项目和用户之间,起着重要的催化剂作用。那些能够真正为用户创造价值的公司,不仅仅是能够打包出很棒的软件;而是他们能够识别用户的真实需求,且能够洞察技术趋势,有能力创建出一个完整的堆栈甚至是开源项目的生态系统来满足这些需求。 他们可以全身心的扑在一个有些寂寥和无聊的项目上,而且会一直支持很多年,只为坚守其中的价值。还有如果在某个软件堆栈中缺少了某一部分,他们随时可以从头开始一个开源项目,并围绕它来构建一个社区。他们甚至可以收购一家闭源的公司,然后将项目再整个的开源了(没错,可能很多读者看到这里已经猜到了说的是哪家公司了,没错,这里的特性红帽[6]公司都拥有。)
简单总结一下,基于商业化的开源模式就是这样,项目由少数个人或公司正式或非正式的管理和控制着,这些个人或公司确保了项目的成功发布,而且有着商品化的能力,并有效的在回馈给开源的生态。对于开源开发人员,管理公司和最终用户来说,这是一个没有输家的美好格局。这可以很好的替代那些日薄西山且昂贵的闭源软件!
自我供给,去中心化的开源
毫无疑问,想要让项目赢得好口碑,就得满足一些人们的期望。举例来说,Apache 软件基金会和云原生计算基金会均需要孵化和毕业的过程,除了所有技术和形式要求之外,项目还必须拥有健康数量的活跃提交者和用户。这些都是形成可持续发展开源项目的关键。在 GitHub 上拥有源代码与拥有一个活跃的开源项目是有着本质上的不同。一个活跃的开源项目意指编写代码的提交者和使用代码的用户,两个组通过交换价值并形成一个每个人都受益的生态系统来不断的螺旋式成长。一些项目生态系统可能很小而且寿命很短,有些可能包含多个项目和竞争服务提供商,其中非常复杂的交互持续多年。但只要有价值交换,每个人都从中受益,项目就会得到发展、维护和可持续。
我们来看下 Apache 软件基金会的项目 Attic[7],该项目已经完成了它的历史使命,正在走入其生命周期中最后的阶段。这是非常正常的现象:当一个项目在技术上不再适合它的当初的开发目的时,它通常会自然结束。同样,在 ASF 的孵化基地[8],你会发现很多项目从未毕业但却已经退出了历史舞台,通常情况下,这些项目无法构建足够大的社区,要么因为它们过于偏门,要么是被更好的方案所替代。
但更多的情况是,具有高潜力和卓越技术的项目无法维系自身,因为它们无法形成或维持一个有效的生态系统来进行价值交换。目前的开源模式以及基金会并没有为开发者提供一个获得报酬或让用户获知他们的请求的框架或机制,这样的话,就没有任何一方拥有共同的价值承诺。这样的话,结果就是一些项目只能在商业的开源环境中维持自身,在商业化的开源中,公司充当中间人的角色,并在开发者和用户之间进行价值获取。这还增加了另外一个局限且要求服务提供商的公司来维持一些开源项目。这似乎离我们理想中的情况很是遥远:用户可以完整而直接的表达他们对项目的期望,开发人员能够以透明、可量化的方式来兑现他们对项目的承诺,这是一个具有共同利益和意图进行价值交换的社区。
现在各位看官可以想象一下,有这样一个模式,它的工作机制和工具可以实现开源用户和开发人员直接打交道。这不仅仅体现在诸如通过拉取请求来贡献代码、使用邮件列表发送问题、GitHub 的星星数量、以及笔记本电脑上的贴纸,而且还体现在用户有更多的方式、更加自控的、透明的行为来影响项目的走向。
该模型可包括对以下行为的激励:
◈ 直接为开源项目提供资金,而不是通过软件基金会
◈ 通过投票影响项目方向(通过代币持有人)
◈ 由用户需求驱动的功能需求
◈ 及时的合并拉取请求
◈ 为提交缺陷者给予奖励
◈ 为更好的测试覆盖率进行奖励
◈ 奖励及时更新文档者
◈ 及时的安全修复
◈ 专家协助、支持和服务
◈ 为项目的布道师和推广者进行最佳预算
◈ 定期活动的预算
◈ 更加快速的电子邮件和在线聊天帮助系统
◈ 全面了解整体项目的状态,等
聪明的看官可能已经猜到了,没错,以上所谈就是使用区块链和智能合约[9],进而实现最终用户和开发者之间的积极互动。 智能合约可以让代币持有者拥有真实的权力来影响项目的走向。
上图所示:在开源生态系统中区块链的应用
目前现有的开源生态系统中,采用非正常手段来影响项目的走向是可能做得到的,如服务提供商的财务承诺、通过基金会的较为有限的方式等。但是在开源生态系统上增加基于区块链的技术会为用户和开发者之间打开一条新的通道,这么做并不是说会取代商业的开源模式;因为大多数使用开源的公司做了许多智能合约无法完成的事情。但是智能合约可以引发一种新型的开源项目,为那些不堪重负的项目提供二次生命的机会。它可以激励开发者去认领那些无聊的拉取请求、撰写文档、测试程序代码等等,在用户和开源开发人员之间提供直接的价值交换渠道。即使公司支持不可行,区块链也可以增加新渠道,帮助开源项目增长,并在长期内实现自我维持。它可以为自我维持的开源项目创建一个新的互补模型 —— 一种双赢的模式。
通证开源
其实已经有许多旨在将开源通证化的实现了,它们其中有一些是仅仅聚焦于开源模式的,也有一些是更加通用的(也适用于开源模式),以下是我收集的列表:
◈ GitCoin[10],在开源成长起来的,这是该领域最有前途的开源项目之一。
◈ oscoin[11],针对开源的加密货币。
◈ 开放协作[12],一款支持开源项目的平台。
◈ FundYourselfNow[13],针对项目的众筹和 ICO 平台。
◈ Kauri[14],支持开源项目文档。
◈ Liberapay[15],经常性的捐赠平台。
◈ FundRequest[16],针对开源协作的去中心化市场。
◈ CanYa[17],最近被 Bountysource [18]收购,Bountysource 是目前世界上最大的开源 P2P 赏金平台。
◈ OpenGift[19],开源套现的新模式。
◈ Hacken[20],为 Hacker 们提供的白帽令牌。
◈ CoinLancer[21],一个去中心化的人力市场。
◈ CodeFund[22],一款开源的广告平台。
◈ IssueHunt[23],为开源维护者和贡献者提供的募捐平台。
◈ District0x 1Hive[24],众包和策展平台。
◈ District0x Fixit [25],GitHub 缺陷悬赏系统。
这个列表在本文撰写之时仍然在增长着,而且是蛮快速的那种,它们其中一些肯定会消失,也有一些会转移目标,但是总有一些会融入到诸如 SourceForge[26]、Apache 软件基金会、以及 GitHub。这些平台不会也没有必要去取代这些平台,但是令牌模型是对这些平台的很好补充,它可以让开源生态系统更加的丰富。每个项目都可以选择其分发模型(许可证)、管理模型(基金会)和激励模型(令牌)。无论哪种,都会为开源的世界诸如新鲜的血液!
开放和去中心化的未来
◈ 软件正在吞噬世界
◈ 每家公司都是软件公司
◈ 开源是创新的良田
事实就在眼前,开源已经发展到如此巨大的产业,是不会轻易失败的,而且开源对于这个世界实在是太重要了。它是不可能被少数人所操纵,或者被世人所遗弃而自生自灭。开源是一个对所有人都有价值的共享资源系统,而且更要重要的是,它只能以这样的方式来被管理,这个世界上所有的公司都希望自身在开源拥有筹码和发言权,然而,颇为不幸的是,我们并没有一种工具或者习惯来这么去做,我们对工具的期望是:这些工具将允许任何人表达他们对软件项目的欣赏或忽视;它将在生产者和消费者之间,开发者和用户之间创建直接而且更快的反馈循环;它将促进由用户需求驱动的双创新模式,而且是通过令牌来进行追踪和衡量的。
关于作者
Bilgin Ibryam (@bibryam[27]) 是开源的铁杆粉丝,博主、演讲者,《Camel 设计模式》和《Kubernetes 模式》等的书作者。他也是红帽的架构师,同时也是 Apache 软件基金会的贡献者,涉及的项目有 Camel、OFBiz、Isis 等,在日常工作中,Bilgin 非常热衷于指导、训练、带领团队搞一些正如应用程序集成、分布式系统、云原生的应用等。在闲暇时刻,他为开源项目做贡献,并撰写博客:ofbizian.com[28]

Comments

Popular posts from this blog

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into ...

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checkin...