openNET: 构建基于开源项目的网络与对应的可编程智能分配开源协议

—— 让这个星球上所有的开源贡献者都能因为利他行为而获益。

作为全球性的开源协作系统,Git/Github 已然具备全球化的、无准入门槛的、多方异步参与的大规模协作能力,然而,Git/Github 上的激励层尚未建立,Git/Github 上的大多数开源贡献者 尚未因为其贡献而获得应有的收益与被充分看见

因资金短缺,全职开发者自述:这款开源软件可能没有未来了

因此,我们需要给现有的 Github 叠加激励层:

   +-----------------+          +--------- openNET
  /  Economic Layer /-----------+ 
 +-----------------+            +--------- Programmable Open Source Protocol
  +-------------------+
 / Github System Now /
+-------------------+

激励层包含两个部分,一是「可编程的开源协议」;二是 openNET,在「可编程的开源协议」的基础上的,由开源项目组成的有机网络。

一个开源项目组成的有机网络的简单例子:

Web3_Aptos_Ex 是 SDK,在原有的开源模型下,即使使用量巨大,也很难获得除捐赠外的收益。借助「可编程的开源协议」与 openNET,使用到 SDK 的其他项目,在收到资金后,会将其收益智能分配给 Web3_Aptos_Ex 的 Repo Addr 中。

在开源项目组成有机网络之后,在任何一个 Repo 中注入资金,都可以根据有机网络惠及所有相关的开源仓库及其贡献者,从而建立健康、生发的开源生态。

3 Likes

之前 homebrew 的创始人的尝试 https://tea.xyz/ 是通过 package 包管理来做的,根据安装量来实现。

今天给我很有启发的是“可编程的开源协议”这一个,目前的开源协议都是类似 MIT、GPL 之类的代码层面的协议,实际上是没有一套全新的包括利益分配的协议,试想我们可以创造一个这样的协议,之后就可以被识别扫描加入到这个分享网络中,通过一定的手段和规则来实现影响力衡量、依赖上下游的判断,之后借助区块链实现自动化、公开透明的捐赠或者收入分配。

比如创建一个协议 OPS(随便起的,open-source sharing),类比 MIT 会有一个协议声明,大概的内容就是上层依赖的组件需要附带 OPS,然后指定好一个分配比例到当前的项目。之后其他引用的项目,将会需要附加下层组件的 OPS 定义,由我们的扫描器自动构建加入这个协议的开源项目,并且针对每个 OPS 开放捐赠、打钱的入口,相当于某个软件的收入。打入之后,就流入这个网络中对其下层依赖的项目进行自动的计算和分配。

1 Like

可以考虑嵌入这个:https://www.opensource.observer/
Opensource 这一次在 retroPGF 里出了不少力,帮助各位徽章持有者去审核项目 github 的活跃度,并且提供了一些的打分参考,以致于更好的分配 3000 W 个 op 的奖励

3 Likes

目前也有一个类似思路的项目 https://www.drips.network/

1 Like

非常好的想法。我觉得可以详细聊聊~~~可以起一个项目出来

和当前 LXprotocol 的想法非常契合,搞起来,通过 web3 机制重塑开源软件

1 Like

这是来自 Openbuild Ian 和登链 Tiny 的想法,可以一起看看。

更新一张图:

1 Like

发现一个新的案例

Funding.json way from drips.network

https://twitter.com/austingriffith/status/1752140687015920109

The new license should be on the new layer, the incentive layer, rather than the open-source code distribution layer. Therefore, it won’t overlap with the traditional licenses like BSD, MIT, GPL, etc. In short, we are designing a new layer for all open-source projects.

From https://twitter.com/epr510

我设想协议可以开放最宽泛的使用,类似MIT,允许商业使用乃至闭源。仍然保持开源非商业化的可以把自己加入贡献者里发布新版本,但一旦商业使用就需要给这个版本所包含的之前的所有贡献者抽成

1 Like

具体操作层,测量具体每个开发者的贡献,可以考虑结合GPT来分析代码各个维度,再结合fairsharing来纠偏和共识,形成“股份”比例的动态计算,然后自动分配资金到贡献者。

可能有几个点需要确认:
1.商业化时如果保证项目方将所需的抽成放到池子里
2.激励分配:这个指标感觉比较模糊,需要综合的指标, 代码量,PR次数,贡献时长等等

更新一个关于「开源」的思考推文。

关于开源的一些个人想法:
最近推上又看到了一些对于开源的错误认知,让我哭笑不得。2024年了,有那么多哪怕是在IT行业的人依然搞不清开源是个什么。

当然,对于现状如何解释,是区分一个人是否有带来进步的意愿的关键。

比如在开源领域中,log4j等项目的漏洞产生的巨大影响表现出了现状是“人类比想象的要贪婪和愚蠢”。使用这些开源项目的大大小小的公司,通过开源项目获得了极大的利润,但却不愿意掏出哪怕一个硬币来捐助这些项目(log4j漏洞事件前一共只收到三笔捐助),导致其缺乏维护,最终给自己带来了极大的损失。

那么:
1,对于此现状,将其解释为“人类就是这样”的想法没什么帮助。上面的大大小小的公司差不多也是这么想的–这些公司自然也知道自己使用的开源项目无人捐助,但想着“没有我捐助总有其他人捐助吧?”“别人也是不捐助就直接使用,我这么做有什么问题?”。
排除掉道德审判,仅仅从“投入->产出”来考察,一个有点规模的公司,对于一个自己严重依赖的项目,每年几百~上千刀的捐助投入,就有可能带来自己使用的组件稳定性的极大提高,以及免去它们不再更新导致需要更换组件实现等工数上的消耗。
(题外话:当然,我觉得能够真正从自己内心完全排除道德审判的,全都是人渣。人类社会的稳定在于法律,良性的发展则在于道德。“如果一直都是土匪赢,那我们应该还活在石器时代” by
@ksintmelody
。)

2,对于此现状,将其解释为“所以我们更要注重对大众认知的宣传,对法律的完善,对贪婪的人加以约束”,则明显表现出对于开源更加关注的态度和愿意改善现状的意愿。
事实上开源领域一直有人在推动如何让这个环境良性运转起来,各种许可证的诞生就是其中最重要的一环。
许可证规范化了各种行为,不光规定了使用者不能对于开源项目为所欲为,同时也让开源软件盈利有了一个坚实的基础–当然,这一切都建立在有法律支持以及严格切实的法律执行的情况下,要是去朝鲜之类的国家给开源维权自然得不到什么好结果。
(题外话2:知识和艺术共享同样有许可证,如著名的CC-BY系列,很多人可能以为这个只适用于图片,不管文字,但实际上两者都管。所以不是任何公开平台上的文字类知识和图片都能被拿来随便用。)

然而在新的时代,开源的现状非常不乐观。
据统计(*2):
自 2011 年以来,代码行数的增长就开始持续放缓;2015 年之后,代码行数则完全停止增长。同时,commit 的数量也在随时间的增长而下降。2015 年之后,commit 量进入自由落体状态,跌回了 2007 年时的水平。这和2015之后开始的云以及AI的欣欣向荣形成强烈反差。

有些人可能会说,这里主要统计的是开源项目,但有很多项目因为不再被需要所以不被更新了,新的项目状况要好很多。
的确有这种可能性,但另一个对于当时流行的开源项目的统计表示(*3):
“超过 50% 的项目是红色的:它们无法让维护者维持在贫困线以上。31% 的项目是橙色的,这些项目的开发者愿意为低薪工作,而这些薪水在我们这个行业内是令人难以接受的。12% 是绿色的,只有 3% 是蓝色的:Webpack 和 Vue.js。”–50%的项目是字面意义上饭都吃不起的。

“对所有的维护者来说,投入到开源上的总资金是不够的。如果我们把数据集中的这些项目的年收入加在一起,就是 250 万美元。工资中位数约为 $9k,低于贫困线。如果将这笔钱平均分配,大约是 $22k,仍然低于行业标准。”–即使平均分配,也只有2w2美刀一年。而这并不是只简单的看github上获得的捐助,同样也尽可能统计了项目在如patreon平台上所获得的资金。

开源趋势整体触目惊心。

对于开源个体,自然可以有很多建议,如不要再进行开源项目,而是直接构建产品。
但对于开源本身呢?

“开源可持续性的斗争是将人类从奴役、殖民和剥削中解放出来的千年斗争。勤劳诚实的人们付出了自己的一切,换来的却是不公平的报酬,这已经不是第一次了。”(*3)

这种开发开源的人连饭都吃不上但利用开源的人赚的很多的循环是没法长期持续下去的,最终开源只能凋零。
而可笑的是,一些用开源吃饭的人还不知道开源都差不多要被饿死了–当然,可能他们知道了也不关心,毕竟人类远比想象的贪婪和愚蠢。

毫无疑问,开源所面对的困境是困难而长期的,解决这些问题也要足够的时间和付出。
“贫困线下的软件”(*3)一文在最后提出了一些措施,如:

  • 只接受那些将很大一部分利润(至少 0.5% )捐赠给开源的公司,或者那些根本不依赖开源的公司的工作
  • 如果你有足够的薪水,捐赠给开源
  • 不要放弃加入工会(我在芬兰写这篇文章,那里 65% 的工人都加入了工会)
  • 不要放弃新项目的替代许可证
  • 向微软施压,要求其向开源项目捐赠数百万美元
  • 通过发布这类数据研究,揭露企业行为的真相

个人觉得可以补充一些:
1,严格审视自己项目的许可证,不要动不动就无脑MIT。
2,对于侵权,勇敢的揭露和维权,善用社交媒体和法律的力量。
3,法律走不通的地方就别讲法,学习一些安全相关,保留对等报复的能力。就算是真菩萨,佛家也讲金刚怒目。


附.对于开源一些典型的认知错误:
例0:开源开源,你源代码都给我了我为啥不能随便用?
典中典。严格来讲,不是把Source给Open了就一定叫做开源。此外,开源是有许可证规定其使用范围的。关于各种许可证的详细,见参考文献。
例1:开源就不应该赚钱,凭什么要捐助?
解析:开源和赚钱不矛盾,从来没有开源项目就不应该赚钱的规定。至于捐助的确是自愿,更多的上文已经讨论过,不再赘述。
例2:真正想开源的不会因为xx原因不开源,所以吧啦吧啦(多半是些不用太守规矩啊之类的言论)。
解析:试图捧杀给自己的行为开脱。开源领域自然多的是菩萨心肠的,但和你不守规矩有什么关系?
例3:我使用了开源项目后还帮它做了宣传,帮助了扩散,所以吧啦吧啦(多半是些不用太守规矩啊之类的言论)。
解析:试图用自己也提供了贡献来给自己的行为开脱。感谢帮忙宣传,但功过不相抵,其他行为请遵守该项目的许可证。
例4:开源捐助要很多钱吧?我又没那么多钱,捐太少被人笑话,不捐了吧。
解析:哪怕捐1cent对于开源项目都是帮助,从来没有笑话捐的少的,捐了钱的都是菩萨,这事情就讲究一个聚沙成塔。而且不少开源作者并不是完全依靠开源项目活命,对于他们来说金额可能是其次,但任何一笔捐助都都是对他们极大的鼓舞。

以此文致敬我所认识的(以及不认识的)中文开源项目作者们,请大家多支持他们。

https://x.com/cryptonerdcn/status/1753697600170299883?s=20

1 Like

这个Idea真的非常赞,我们应该广泛的思考实现路径,如果能得到实现,这将是开源领域最伟大的突破之一!

今日周会纪要:
1/ 名字需要想一个更贴切的(Bruce)
2/ 需要对已有的相关协议进行更充分的调研(Bruce)
3/ 可以解耦成多个轻量级协议的组合(LeeDuckGo)

4/ 可以借助本次 Move 训练营做 MVP 实现(LeeDuckGo)

:bulb: 4 的话需要进一步详细的设计与规划,可以先报名。

MVP 预计需要角色(Roles),每个角色至少 0x1 名:
产品、设计、宣发、前端工程师、合约工程师

1 Like

在 MoveDID 的基础上实现一个轻量协议Github Linker,将 Github Repo 联系在一起。

合约层面功能:

  • 给 Repo 赋予一个数字身份,Repo 和数字身份双向绑定(已实现)
  • 在 Repo 的数字身份中记录 Repo 下游的 Repos
  • 在 Repo 的数字身份中记录一份说明文档,方便查阅

前端功能:

  • 自动生成 Repo 关系网络地图
  • 通过 Moveflow 流支付协议实现简单的利益分配(Optional)
1 Like