从 Gogs vs Gitea 看中外文化差异

本文已被作者标记为“过时的内容”,这意味着其中的信息可能已经不再准确。
本文已被作者设置为“避免搜索引擎收录”,这意味着它不应出现在任何搜索引擎的搜索结果中。

目录


前言

需要声明的是,这篇文章不是对 Gogs 和 Gitea 做技术上分析比较,只是对“为什么会出现 Gogs vs Gitea”进行一些客观地叙述,外加一些我主观的看法。内容上包含太多我个人的想法,不适合参考或引用,仅供消遣。

Gogs 是什么

gogs

参考 Gogs 文档 里描述:

Gogs 是一款极易搭建的自助 Git 服务。

Gogs 的目标是打造一个最简单、最快速和最轻松的方式搭建自助 Git 服务。使用 Go 语言开发使得 Gogs 能够通过独立的二进制分发,并且支持 Go 语言支持的 所有平台,包括 Linux、Mac OS X、Windows 以及 ARM 平台。

如果使用过 Git 和 GitHub 的用户估计读到这儿就明白了,类似于一个可以自行搭建的 GitHub。如果实在不明白影响也没关系,只要知道:Gogs 对于开发者来说是一个很有用甚至很重要的工具,开源的,不要钱,很多人都愿意用——比如我,我在 http://gogs.wolfogre.com(已下线)下就搭建了一个自用的 Gogs。

Gogs 是由 Unknwon (中文昵称:无闻)发起的,目前为止他是 Gogs 主要的代码贡献者和唯一的维护者,换直白一点的话就是,Gogs 的代码不全是他写的,但主要是他写的,且他是唯一一个有权决定别人的代码是否被合并到 Gogs 的人(悄悄告诉你,此处是伏笔)。

无闻,人如其名,网上并不能找到有关他的个人信息,但通过其 GitHub 主页可以看出来:

  • 这是一个很牛逼的人,其主持的多个开源项目的关注度都是过千甚至过万的;
  • 这是一个 Golang 的布道者,其所创建的项目多是由 Golang 编写,也主持开发了多个和 Golang 相关的教学内容;
  • 这是个中国人,从项目了随处可见的中文便可以看出来。其 GitHub 签名是“不要看我,我是个小人物”(“Don’t look at me, I’m nobody.”),透露着中国人的谦虚和内敛。

字里行间似乎透露出对无闻的个人崇拜,但平心而论,但看 Gogs 这一个项目——驾驭着非主流新兴语言 Golang,只身挑战了 GitHub、GitLab、Bitbucket 的垄断地位——说无闻是国人的骄傲也不为过。

Gitea 是什么

gitea

我第一次看到 Gitea 的时候感觉它是一个盗版,无论是页面设计、项目目标、项目理念,和 Gogs 都如出一辙——“完了,我们以前老是盗版人家老外的东西,现在终于要被老外盗版了。”

后来证明是我多虑了,开源者的事,能算盗版么?

我在 Gitea 主页 上看到了明显的说明:“Gitea 是一个开源社区驱动的 Gogs 克隆”,这说明 Gitea 并不是试图欺世盗名,而是在 Gogs 的基础上新开一个发行分支。由于 Gogs 采用的是 MIT 开源证书,这样做是不违反开源协议的。

目前为止,Gitea 和 Gogs 在功能、使用上几乎完全一样,甚至针对已经使用了 Gogs 的用户,提供了无痛切换到 Gitea 的方案

但区别肯定是有的,却不是技术上的区别,而是管理模式上的区别,欲知详情,请君继续。

为什么会有 Gitea

克隆一个现有的项目,然后改头换面、自立门户、重新发行,这在开源的世界上不算什么新鲜事。但这种情况的发生往往事出有因,比如原项目不维护了,原项目拒绝实现某些新特性,新项目针对特定用户群做了优化,等等等等。

但 Gogs 仍在维护,Gitea 也没有实现什么新功能,针对的用户群也是一模一样的,那为什么还会有 Gitea 呢?Gitea 的官方博客里给出了解释,翻译成中文如下:


Gitea 是一个开源社区驱动的 Gogs 克隆,后者是一个备受欢迎的 Git 自托管服务。我们是一个日益增长的群体——之前是 Gogs 的用户和贡献者,但发现了 Gogs 令人沮丧的“单一维护者”管理模式,所以决定作出努力,建立一个更加开放、更加高效的管理模式。

在此之前,我们尝试说服 Unknown 给社区中更多的人“写权限”。他理所当然地认为 Gogs 是自己的生物,不希望它在自己掌控之外生长。所以为了有效地让代码走向自由,重新克隆一份是必须的。

正如卡里‧纪伯伦描写孩子一样(译者注:原文是英文诗,此处采用冰心版译文):

你们的孩子,都不是你们的孩子,

乃是生命为自己所渴望的儿女。

他们是借你们而来,却不是从你们而来,

他们虽和你们同在,却不属于你们。

Gitea 拥有 3 名一年一选的所有者,和公开数量的维护者。维护者通一个简单的投票模式,决定哪些贡献被接收,哪些人扮演所有者的角色。任何人,只要为项目贡献超过 4 次(含),便可申请成为维护者。

从 2016 年 11 月被克隆出来开始至今(译者注:原文写于 2016 年 12 月 8 日,即差不过一个月的时间),Gitea 的 193 个合并请求被接受,43 个问题被解决。通过清理问题,11 个 Bug 被修复。此外 26 个合并请求正在等候处理,其中很多将会在 1.0.0 发布之后处理,因为大多数新功能将开始出现在 1.1.0 中。

我们邀请每个人都参与其中,帮助继续构建下一代的 Git 自托管服务。


至此,我相信针对“为什么会有 Gitea”、“Gitea 和 Gogs 的主要区别”等问题,都有了清晰的答案。

本文所有客观叙述已经完结,接下来完全是我个人的想法,请酌情取阅。

值得玩味的点

为什么说值得玩味呢,这位这件事情有几个重要的因素:

  • 一个备受欢迎的好项目;
  • 一个牛逼的项目创始人;
  • 创始人掌控着项目的开发走向;
  • 创始人不愿意放权让他人掌权项目;
  • 一群热爱该项目,为该项目做着贡献的人们;
  • 这群人不满创始人的权利集中;
  • 这群人克隆了该项目,建立了一个由规则驱动的共同掌权的模式;
  • 新项目与旧项目难分伯仲。

很明显,这像极了政治上的两种针锋相对的权力分配模式,我不想提具体的名词,毕竟咱这是技术文章不是?

另一个让这件事值得玩味的事是最近出的一个新闻,什么新闻呢?不好意思我不能在这里说,太敏感了,导致我网站被封都是有可能的。所以我只给两个提示,如果你猜出来的咱们就相视一笑,猜不出来你就当我什么都没说。

  • 提示一:这条新闻和宪法有关,和数字 5 + 5 = 10 有关,如果还没猜出来请看提示二
  • 提示二:echo "fvS3fIG7fY=Agug4fv=4fKg0hh8wfI=Gf1KsfJ4jfKgcfvShfLS3fv4hfZ8PgJWAfIScmQ++" | tr 'a-zA-Z0-9=+' '0-9A-Za-z+=' | base64 --decode

关于这条新闻,可以肯定的是不会是谣言,但也没有坐实。可以看出来,也是一个好项目,也是一个牛逼的拥有者,拥有者也不愿意放权让他人掌权项目。

我可能小题大做了,将开源社区里这点小事类比这样大件儿的事,可能对两方也都不公平的,但我说了,我只是觉得值得玩味,值得思考。

文化差异

不是点评孰优孰劣,我只是对 Gitea vs Gogs 这件事所透露出来的中外文化差异做些阐述,或者只是中外开源者的文化差异。

事实上,面对无闻独家掌权的 Gogs,无论是谁,黑头发的还是黄头发的,都会有一些焦虑的,担心唯一的维护者会导致这个人民迫切需要的好项目走向一个错误的发展方向,或者唯一的维护者精力不足,导致项目发展缓慢。

但差异在于焦虑程度的不同和应对方式的不同。

很明显老外们对于这种单一维护者可能所引发的潜在问题更为担忧,即使告诉他们维护者是怎样怎样的牛逼,会怎样怎样的尽责,仍然无法缓解他们的焦虑。他们更相信被管制的、被分散的权力才是保障,其他都是空谈。有趣的是那些欧美大片里往往充斥着个人英雄主义,但要是真上纲上线,一个手握拯救/毁灭世界的力量的英雄可能会让他们焦灼到崩溃(还别说,电影《美国队长3:内战》里体现了这一点)。

这种焦灼会让他们不原意维持现状而寻找出路,独立出一个 Gitea 便是他们找的出路。哪怕 Gitea 发展越来越差,相信他们也不愿意回归 Gogs,而是仍然对 Gitea 抱有信心——只要有一个科学的规则来调动集体的力量,那力量便是无穷的。

相比较而言,作为黑头发的我们,焦虑感可能很快被当前 Gogs 良好的发展,以及维护者强大的个人能力所打散。我们相信即使 Gogs 是由一个人所管理的,只要这个人够牛逼,那 Gogs 肯定不会越来越差。

我们可能对 Gogs 的执念不会那么重,但只要 Gogs 的发展没有越来越差,我们便会相信——只要有一个牛逼的领导者来调动集体的力量,那力量便是无穷的。

孰是孰非?我怎么可能知道。谁又可能知道?

我只知道差异在这里,原因也容易脑补,但对错优劣就难说了。

我见过由少数人掌权的项目发展得越来越好,因为效率高;

我见过由少数人掌权的项目发展得越来越差,因为各种偏执的错误决定;

我见过由所有人掌权的项目发展得越来越好,因为做决定时有更多的人思考;

我见过由所有人掌权的项目发展得越来越差,因为效率低。

甚至连 Gogs 和 Gitea 哪个更好我都分辨不出来,你指望我这个理工男在这儿指点江山吗?

最后

那究竟该用 Gogs 还是 Gitea 呢?随便喽,你感觉哪个好就用哪个。

——这是我认为最可贵的地方,我们有选择权,能根据客观的事实去做主观地选择。

那么,你选哪一个?

评论加载中……

若长时间无法加载,请刷新页面重试,或直接访问