版权声明：
以下内容来自微信公共帐号“EOS技术爱好者”，搜索“EOSTechLover”即可订阅，译者Fred。转载必须保留以上声明。仅授权原文转载。
本文原文链接为https://forums.eosgo.io/discussion/604/of-governance-and-source-code，由本号“EOS技术爱好者”翻译。
Of Governance and Source Code
治理和源代码
lan Grigg
As we move forward to the governed blockchain, we are creating an environment where governance for the first time is far reaching and comprehensive. The participants agree to the Constitution, expose themselves to formal dispute resolution, and work in the knowledge that all others have the same skin in the game - to be called before the Arbitrator.
The shared expectation is that we all are in: BPs, coin holders, Dapps, etc. But what of the developer?
随着我们向治理区块链的方向发展，我们正在首创一个如此深远和全面的治理环境。参与者认同宪法，接受正式的纠纷解决，并且学习相关知识，当被仲裁员呼叫到跟前时，意识到和其他人有相同的利益攸关。
我们共同把期望都放在BP、代币持有者以及Dapp这些上面，那开发者呢？
Bounty in Open source
As the developer provides new code under an open source licence, it is somewhat customary for the developer to be firewalled from any issues arising out of usage. This custom has emerged for several reasons:
- There is typically no bilateral contract between the developer and a known party, so there can be no effective liability described in the EULA that is tuned to the precise use case of the individual user.
- The economics are in balance: the gift of code matches the reciprocal gift of zero liability across many users.
- The re-use of free source code is a gift to society that keeps on giving, making it attractive even if economically one-sided.
Therefore, the open source community would typically agree that open source has to be liability free. If for example, we estimated that there were a million users for a software download and the expected value of the liability were to be found to be $1 per user, the developer would immediately be broke as soon as her efforts found success. Hardly an inspiring thought.
But all this changes when (a) the developer is paid, and (b) when a specific user is known.
开源的赏金
由于开发人员使用开源许可证提供新代码，对于开发人员来说，在使用中任何问题会引发防火墙是比较习惯的了。出现这种习惯可能是有以下几个原因：
典型例子是开发人员和已知方之间没有双边合同，因此EULA中描述的任何有效责任都不会根据用户的具体使用情况进行调整。
经济是平衡的：对于很多用户来说，代码与相对应的零负债的礼物是对等的。
重复使用免费的源代码是对社会来说是受惠的，就算在经济上是片面的，这一点也会引人注目。
因此，开源社区通常会认为开源应该是免责的。例如，如果我们估计有一百万用户下载软件，预计每增加一个用户，就负债1美元，那么只要取得成功，开发人员就会立即破产。这一点都不能鼓舞人心。
但是，当（a）开发者付款时，以及（b）特定用户知道时，所有这些都会发生变化。
Bugs in Open Source
We want the developer to be paid. As an example of this, consider the problem of a large critical project which is open source but has two users in it - let’s call them client-side and server-side for sake of example. And assume that the server-side sells to the client-side.
Over a period, the server-side is incentivised to hire the developers to maintain and improve the software product to increase sales. Inevitably, the product behavior and features becomes driven by the sales, and the goal of the project becomes the preservation and growth of sales. Other goals are degraded or forgotten.
Such a phenomena was seen in the market for secure browsing (PKI certificates, SSL and all that jazz). It was the case during the 2000s that many of the programmers were directly employed with the goal of preserving the sales channel, and the industry cartelised so as to share the bounty. Witless browser projects allowed this to happen because they simply didn’t understand the interests. Meanwhile, the lot of users went from bad to worse as the industry ignored the real threat - the application-layer MITM known as phishing.
开源中的Bug
我们希望开发者得到报酬。举个例子，考虑一个开源的大型关键项目的问题，它有两个用户 —— 为了举例，让我们称它们为客户端和服务器端。并假设服务器端销售给客户端。
在一段时间内，服务器端会激励开发人员维护和改进软件产品以增加销售额。不可避免的是，产品的行为和特征受到销售的驱动，项目的目标成为销售的保存和增长。其他目标已经被削弱或遗忘。
市场上出现了这种安全浏览（PKI证书，SSL和爵士乐）的现象。在21世纪的时候，许多程序员直接被聘用，目的是保持销售渠道和行业卡特尔化，以分享奖励。毫无疑问的浏览器项目允许这样做，因为他们根本不理解利益。与此同时，由于行业忽视了真正的威胁 —— 应用层MITM被称为网络钓鱼，很多用户的情况越来越糟糕。
Enter the Blockchain
This phenomena is also seen in the blockchain. We want the developers to be paid, and we want the alignment to be to the benefit of the users. As noble as it may have sounded at the start, bitcoin quickly slipped into a battle royale between corporations. On one side, exchanges wanted growing sales to users with bigger blocks, and on the other side, developer corporations wanted smaller blocks to generate software sales opportunities. Or something - the point here is that the service to the user was not as high on the list as the security of the corporation’s bottom line.
We really do want to pay the blockchain developer, and we equally really want to align the developer’s interests to the community.
And, given the amount of money involved, it is pretty clear that the developer will be paid somehow, someway. We won’t be seeing many starving geniuses surviving for a year on ramen & borrowed garages. By some mechanism or other, the rewards in the community or the profits made will make their way into salaries for good developers. In blockchain, as novel as it is in the world of open source.
进入区块链
这种现象也在区块链中看到（http://hackingdistributed.com/2017/08/26/whos-your-crypto-buddy/）。我们希望开发者能够得到报酬，并且我们希望这种协调一致对用户有利。尽管一开始可能听起来那么高尚，但比特币很快陷入了公司之间的争斗之中。一方面，交易所希望向更大块的用户销售产品，另一方面，开发商公司希望更小的块产生软件销售机会。或者说 —— 这里的要点是，对用户的服务并没有公司底线的安全性那么高。
我们确实希望支付区块链开发者的费用，同样我们也希望将开发者的利益与社区相匹配。
而且，考虑到涉及的金钱数量，很显然开发者会以某种方式支付。我们不会看到许多饥肠辘辘的天才在拉面和借用的车库上存活了一年。通过某种机制或其他方式，社区中的回报或所赚取的利润将成为优秀开发者的薪水。在区块链中，就像在开源世界里一样新颖。
I, Community
The second assumption was the absence of a clear party for whom this work is done.
The governed blockchain now resolves that: it’s the community. Within a governed community, this is precise - the community is defined accurately as the group of people who have agreed to the constitution. Or, for more fiscal weight, the group of people who’ve got value on the chain. Either way, an Arbitrator can find a defined party, a defined interest.
The specific channel for the delivery of new code is the proposal for a code update. The community votes on a code update, which is technically a repository branch, in which said repository tracks the names of the contributors.
我、社区
第二个假设是没有明确的一方来完成这项工作。
受管理的区块链现在可以解决这个问题：它是社区。在一个被治理的社区内，这是精确的——社区被准确定义为同意宪法的人群。或者，为了获得更多的财政收益，那些对这个链条有价值的人群。无论哪种方式，仲裁员都可以找到一个确定的方，一个确定的兴趣。
提供新代码的具体渠道是提供代码更新。社区对代码更新进行投票，该代码更新在技术上是一个存储库分支，其中所述存储库跟踪贡献者的名称。
Developer, Fiduciary
In the governed blockchain, we can assume that the developer is paid by blockchain-related revenues, and provides source code (still free and open) to a single entity, the community.
This likely flips the above open source convention upside down. Liability can be found because the developer is paid, is known and the community can be clearly identified - as a contractual party.
Thus, the governed blockchain has a surprising effect - the developer becomes a fiduciary - someone trusted to do the right thing (my emphasis):
https://en.wikipedia.org/wiki/Fiduciary
A fiduciary is a person who holds a legal or ethical relationship of trust with one or more other parties (person or group of persons). Typically, a fiduciary prudently takes care of money or other assets for another person. One party, for example, a corporate trust company or the trust department of a bank, acts in a fiduciary capacity to another party, who, for example, has entrusted funds to the fiduciary for safekeeping or investment. Likewise, asset managers, including managers of pension plans, endowments, and other tax-exempt assets, are considered fiduciaries under applicable statutes and laws.[1] In a fiduciary relationship, one person, in a position of vulnerability, justifiably vests confidence, good faith, reliance, and trust in another whose aid, advice, or protection is sought in some matter.[2]:at p. 68[3] In such a relation good conscience requires the fiduciary to act at all times for the sole benefit and interest of the one who trusts.
A fiduciary is someone who has undertaken to act for and on behalf of another in a particular matter in circumstances which give rise to a relationship of trust and confidence.
— Lord Millett, Bristol and West Building Society v Mothew[4]
The developer is a fiduciary because the user of the code trusts them to write with the user interests foremost and at all times. This is actually how the open source world functions - there is nothing new in the statement that the developer is a fiduciary: no developer will stand up and deny that they write good code for users.
开发人员、受托人
在受管理的区块链中，我们可以假设开发人员是通过区块链相关收入支付的，并向单个实体社区提供源代码（仍然是免费和开放的）。
这可能会颠覆上述开源惯例。因为开发者被支付，知道并且社区可以被清楚地识别——作为合同方，可以找到责任。
因此，受管理的区块链具有令人惊讶的效果 —— 开发者成为受托人 —— 某人信任做正确的事情（我强调）：
*https://en.wikipedia.org/wiki/Fiduciary *
受托人是与一个或多个其他方（个人或团体）持有法律或道德信任关系的人。通常情况下，受托人会谨慎地为其他人处理金钱或其他资产。例如，一方如公司信托公司或银行的信托部门以另一方的受托人身份行事，例如，该受托方已委托资金托管受托人以进行保管或投资。同样，包括养老金计划，捐赠基金和其他免税资产的管理人员在内的资产管理人员根据适用的法律和法律被视为受托人[1]。在受托关系中，处于弱势地位的一个人理所当然地有信心，诚信，依赖和信任另一个人，他们在某些事情上寻求帮助，建议或保护。[2]：在68页 [3]在这种关系中，良心要求受托人始终为受托人的唯一利益而采取行动。
受托人是在承担信任和信任的情况下承诺为特定事宜代表他人行事的人。
- Lord Millett, Bristol 和 West Building Society v Mothew [4]
开发人员是受托人，因为代码的使用者相信他们始终以最重要的方式与用户的兴趣一起写作。这实际上是开源世界的功能 —— 开发人员是受托人的声明中并没有什么新东西：没有开发人员会站出来否认他们为用户编写了好的代码。
Before the Community
What is new is that within the context of the governed blockchain, the developer is now someone to whom our internal resolution of disputes applies: because they are known and paid to provide software to the community or members within the community.
Is this bad? Scary - yes. But actually it is good, for two reasons. Firstly, in exchange for the liability to appear before the Arbitrator and the various responsibilities imposed by the doctrine of fiduciary care, the developer is now protected from civil claims in all courts that accept the doctrine of the Arbitration. Instead of random attacks in courts, the developer can now be protected by an Arbitrator who knows already the value of the developer’s work, and how and why this blockchain thing happens.
Try explaining blockchain, git pull requests, adverse requests, bugs, obsolete code and open source tradition to a conventional judge!
Secondly, within this community environment, the developer is encouraged to stand up and declare it so: that his code is built with the best interest of the user as a primary motivation. Indeed, by stipulation and covenant in a contract, and with full forethought that violation is actionable via arbitration.
This raises the stake of development and separates out the developers who are confident they are doing a good job from those who are not. For the first time, perhaps, we have an actionable mark of differentiation that allows the better developers to charge more: “I and my code are ready to stand before the Arbitrator.”
在社区之前
最新情况是，在受管理区块链的背景下，开发者现在是我们内部解决争议的适用对象：因为他们知道并付费向社区或社区内的成员提供软件。
这不好吗？可怕 —— 是的。但实际上这很好，有两个原因。首先，作为对在仲裁员面前出现的责任和受托人的责任所规定的各种责任的交换，开发商现在在接受仲裁原则的所有法院都受到保护，不受民事诉讼的影响。与在法庭上随机攻击不同，开发人员现在可以由一个知道开发人员工作价值的仲裁员来保护，以及这个区块链事件是如何发生的以及为什么会发生。
尝试解释区块链，git pull请求，不良请求，BUG，过时的代码和开源传统给传统的法官！
其次，在这个社区环境中，开发者被鼓励站起来并声明：他的代码是建立在用户的最佳利益基础上的，作为主要的动机。事实上，通过合同中的规定和约定，并充分预见到违约行为可以通过仲裁行事。
这提高了发展的利益，并将那些有信心他们做得好的开发者与那些没有做好的开发者区分开来。也许第一次，我们可以有一个可分辨的行动标记，允许更好的开发人员收取更多费用：“我和我的代码准备好站在仲裁者面前。”
Our Developers, Our Community
Would the community now attack its developers? No, not without cause - because the community as a whole knows that any attack against a developer in court will be watched by all developers. Costs will go up! Good developers will go elsewhere. Developers are a resource to be built up, not knocked down. The community isn’t going to eat its own children, and any small disruptive minority of dev-haters has to get through the Arbitrator, the BPs and potentially the local courts. Checks and balances are built in.
Does it have to be that way? Do developers have to take on real liability? No - a specific exemption could be carved out. For example, we could set a developer’s liability to zero for freely donated code. Such a clause will exist in the Constitution for Arbitrators, as experience shows that they have to be protected in their judgement.
But one thing we should not do is exclude developers entirely, nor should we overthink the problem. We will be trusting the developers - by the nature of programming, only they can protect our value at chain by their careful work, so they are in effect fiduciaries. They should be elevated to that status, which carries risks and cost. And professionalism.
It is better that developers are fiduciaries before our forum, which can balance the needs of the individual and the community, and define the very word and scope of the term fiduciary. Better than the alternate, which is to try the question of culpability in a random court of a very random world.
It is better to set the reality. It is better to recognise that payment begets liabilities, and code demands trust. Let’s bring all that out into the open, in a transparent, caring way. Else, if we don’t, the corporations will battle again and they’ll eat our children because they know no better.
我们的开发者，我们的社区
社区现在是否会攻击其开发者？不，并非没有原因 - 因为整个社区都知道所有开发者都会监视任何针对开发者的攻击。成本会上升！好的开发人员会去别处。开发人员是一种需要建立起来的资源，而不是被推倒。社区不会吃自己的孩子，任何有破坏性的少数人都必须通过仲裁者、BP和潜在的地方法院。检查和平衡是内置的。
它必须这样吗？开发者是否必须承担真正的责任？不 —— 可以划出特定的豁免。例如，我们可以将开发者的责任设置为零，以供自由捐赠的代码使用。“仲裁员宪法”中将存在这样一项条款，因为经验表明，他们必须在判决中得到保护。
但我们不应该做的一件事就是完全排除开发者，也不应该过问这个问题。我们会相信开发者 —— 通过编程的性质，只有他们能够通过仔细的工作来保护我们区块链的价值，所以他们实际上是受托人。它们应该被提升到这种状态，这带来了风险、成本和专业精神。
在我们的法庭之前，开发人员是受托人，这可以平衡个人和社区的需求，并定义“受托人”这个词的词和范围。比另一种更好，那就是在一个随机的世界里，尝试一个随机的法庭的罪责问题。
最好是设定现实。最好是认识到付款会产生负债，而代码需要信任。让我们以一种透明、关爱的方式，把所有这些都带进开放的大门。否则，如果我们不这样做，公司就会再次开战，他们会吃掉我们的孩子，因为他们知道更好的了。
本文内容不代表本号任何立场
本文图片来源于网络
本文原文链接为https://forums.eosgo.io/discussion/604/of-governance-and-source-code，作者lan Grigg，译者Fred。转载请参照本文文首说明。
更多内容，加入我们的知识星球吧～
关于我们 更多联系：
Website：https://eoshenzhen.io
Steem：https://steemit.com/@eoshenzhen
Buzy：https://busy.org/@eoshenzhen
Telegram：https://t.me/eoshenzhen
Twitter：https://twitter.com/eostechlover
：EOS技术爱好者
新浪微博：EOSTechLover