没有维护者的开源 已翻译 100%

oschina 投递于 2018/11/27 10:26 (共 10 段, 翻译完成于 12-10)
阅读 2440
收藏 5
1
加载中

为什么在许多开源项目中维护是一个很大的障碍? 维护者倦怠是最主要原因。

我最近意识到,如果社区中有正确的文化,许多开源项目都有机会独立于原作者。 但是,并非所有项目都能做到这一点。 我在这里描述的主要适用于小型开源库,而不是大型库和终端用户软件。

 

溪边九节
溪边九节
翻译于 2018/11/27 17:20
0

分叉发布

所以。一年前,我偶然发现了David Sheldrick的这个名为patch-package的JavaScript项目工具。它允许我创建小补丁以应用依赖关系,这些补丁在整个npm安装和删除过程中持续存在。我用它来定制一些我的依赖项的小方面,以便与我的软件项目一起更要的运行。这允许我没有打扰原始作者的情况下“维护”一个第三方的资源库。

然而,这个工具仅仅对一些小的或临时的分支是方便的。我工程中的一些其他分支正在变大,所以我做了一个第三方库的分支。然而,有趣的是,我没有费心去做拉取请求。我的理由主要是懒惰,但其次,我不想打扰原作者。我想,也许他们处于倦怠的边缘。另外,我不认为我的补丁重要。我本来希望创建一个可以忽略和友好的“拉取建议”,而不是一个要求严格的“拉取请求”。

下次我做了一个另一个包的分支,jsondown,我采取了一个稍微不同的方法。像以前一样,我在npm上发布了自己的分支,但后来我也创建了一个拉取请求。我没有要求,我只是把PR留在那里,并没有费心去看它是否会被合并。令我惊讶的是,几天之后,有用户合并了它并在npm上发布了一个新版本。从@ staltz / jsondown到jsondown这个版本没有以任何方式改变我的项目,除了我能够重命名我的一个依赖项。任何感知的好处都只是美学。

这个经历让我好奇。一方面这就像一个典型的拉取请求经验。另一方面,在意图和互动方面完全不同。我注意到拉取请求的要求可能要低得多,合并可能不那么重要,并且关闭拉取请求可以在没有任何一方的强烈感受的情况下发生。我觉得或许开源项目会在没有责任压力的情况下取得进展。所以我将这种方式的贡献应用于其他几个包,像leveldown,medeadown,react-native-os,react-native-workers(顺便说一下,这些是一个分支的分支)。

硅谷课堂
硅谷课堂
翻译于 2018/12/05 13:53
0

Githubness

我想在这里引起关注的是“责任”。 保持开源软件包最新的感知责任往往是由于“githubness”,而不是由于开放性。 许多开源消费者通常不利用源是开放的这一事实。 他们提交问题,功能请求和错误报告,然后等待发布新版本。 对他们来说,无论项目是开源还是专有,都没什么区别。 源代码通常是一个可怕的访问地点,所以避免它更安全。

可能有几个原因导致 GitHub 驱动的社区使人们对于开源变得苛刻和害怕。 我想强调的原因是由于用户层面的微妙之处,我们把注意力集中在了错误的事情上。 问题和自述文件通常是我们关注的目标。不过,也不都是那样。 在网络的另一个角落,人们在 unsplash 上分享“开源”摄影,而且这是一个具有馈赠文化的低调地点。 在一个不太遥远的网络社区,在 GitHub Gist上,代码也是开放的,也没有问题,没有拉取请求,并且代码立即可见。 因此,通过 gists 共享代码与 GitHub 公共存储库一样是“开源”,但它是一个不太可能导致倦怠的空间,因为它给予需要的代码,而不是代码本身。

溪边九节
溪边九节
翻译于 2018/11/28 13:56
0

礼物不是责任。开源作者通过简单的开源已经给世界做“贡献”了。以前,这听起来像是我在作者和消费者之前拉起分歧,这些是情景角色,而不是永久性头衔。程序员可以全天改变角色,但是要不断维护开源软件,需要关键的技能:愿意阅读第三方开源代码。从根本上来说,这不需要开源作者或官方维护人员。仅仅是需要有人愿意阅读并且能够理解代码以便可以修复代码。一但修复准备好了,可以发布一个分叉,这个分叉并不是官方或原创的。理想情况下,一个开源工程可以按如下顺序展开:

  • Alice分享代码

  • Alice愿意对代码做一些更新

  • Bob对X特性或维护X感兴趣

  • Bob阅读源代码,打了一个补丁,发布了他自己的分叉。

  • Charles对Y特性或维护Y感兴趣

  • Charles想Bob使用Alice的代码一样使用了Bob的代码

  • Alice他自己对X和Y感兴趣,所以Alice主动整合了这两个特性。

但是,有两项重要的注意事项和理想化方法。第一,假定程序员愿意并且并允许花时间阅读了理解第三方代码。第二,不适用于大项目。发布我们自己的调整分支意义不大(比如TypeScript或者React Native),因为大的项目比较难定制,但特别是因为分叉它们会破坏“代码”的基础以及破坏我们通过这个得到广泛认可的基础分享想法的能力。

硅谷课堂
硅谷课堂
翻译于 2018/12/04 11:01
0

阅读小型库,编写小型库

另一方面,这两个注意事项指出了我们作为一个程序员社区可以提升的部分:

  • 练习阅读和理解第三方代码

  • 成为较小开源库的作者

阅读库的源码在开始时是可怕的,因为它看起来与应用程序代码截然不同。如果你仅编写构建终端用户软件的代码,那么你一直在构建一阶特性。库代码之所以不同,是因为它构建了更高阶的特性。你可以认为,库代码更加抽象。为了使它更加可怕,它所使用的代码样式通常与你所熟知的代码样式格格不入。每个库看起来都不同,因为是不同的作者。如果你的雇主不了解开源精神,你甚至可能会直接被劝阻在工作时间里“处理他人的代码”,这是我们行业中常见但令人悲哀的做法。

也就是说,我不能过分强调:作为程序员不断阅读不同代码库是多么正常。你开始查看代码模式而不是代码样式。你学习了一两个技巧。而你实际上最终理解了库,因此修复它将不再困难,甚至从头开始编写自己的库也是小菜一碟。如果你还没有编写过一个库,我建议你试试看,即使它最初并不流行。

Tocy
Tocy
翻译于 2018/11/29 17:05
0

小的库更容易阅读和理解。有许多JavaScript库尽量追求更小的体积,因此阅读它们的源码不会花费你多少的时间和精力。小的库也更容易更换和复刻,因此这种库更适合开源而不是持续维护。

实际上,有许多的大型项目都可以被分割成许多小的库。比如,React Native自己的十几个嵌入式组件和原生API都来自于一个库。但其实每一个都可以作为他们自己的库,并非将所有的所有的模块放在一个主干分支中进行管理,而是放在不同的仓库中进行管理。这仅仅是一个具体的例子,并非是批评React Native,我自己也在使用并且也很欣赏React Native。也有其它项目属于“大型公开项目”,都能够分割为许多小的库。

y
yosora
翻译于 2018/11/28 09:07
0

支持性分歧

分成小型库与最小化共识有关。Sebastian Markbage曾谈及最小化API层面。我将重用此想法并提出:如果我们最小化层面开源项目会如何呢?如果我们仅同意一些事情,那么我们可以在其他方面自由地表达不同意见。当我们必须选择一位优胜者时,分歧是很痛苦的,因为有人会失望。但当我们不得不同意时,分歧意味着自由,因为关于如何构建和构建什么的多样化意见是一件好事。我不喜欢英语中的分歧这个单词,它有负面的含义(参考词典,“失败或拒绝同意”,“冲突或意见不一”)。在芬兰语中,我们仅仅说“有不同的想法”(“ollaerimieltä”)。语言塑造了我们的社交互动,以至于它有时会阻止我们看到传统的消极概念中的积极方面。

这种不同意的自由为创造性和狂野的想法提供了方便,有时这些狂野的想法会带来惊人的发现。也许这一发现最终成为每个人都赞同的属于共识的最小化层面的新基石,因此提升分歧实际上可以加速我们达成共识和进步。在更元的级别上,我会谈及文化,集体智慧的定义,以及切向性的个人智慧。但在我离题之前,让我们回到开源库之上。

Tocy
Tocy
翻译于 2018/11/28 12:29
0

我已在pull-stream社区中见到过一小型库的社区,其共识层面很少。已认可的API简单小巧,并且在pull-stream上有数百个的npm软件包,这些软件包是由有时也是pull-stream库的用户的作者所授权的。作为一个示例,我通常仅作为pull-stream库的用户,但我写了至少一个小包,pull-workers

当我发布Callbags时,我决定更加彻底地采用这种方法。共识表面实际上包含零代码,它仅仅是一个规范。这是我唯一希望人们赞同的事情。其余的,这完全取决于社区。

我做了一些初始包只是为了开始并提供示例,及其可用的证据:callbag-basics。但这些实用程序远非“官方”包。它们也非常小,每个部分通常少于30行代码,诚邀人们无所畏惧地阅读之。我特别将其托管在我自己的GitHub帐户下,而不是在官方的callbag org下。

Tocy
Tocy
翻译于 2018/11/28 14:41
0

作为一个目标,我希望callbags成为一个没有维护者的开源项目。如果你发给我一个问题或pull请求,我会试着礼貌地告知......我真的不在乎。这是因为,参考构建two stream库的经验,我们不需要就许多方面达成一致。如果该项目容易产生分歧和分叉,那么社区可以减少引起维护负担的影响。我称之为“支持性分歧”,其中我并不试图破坏你的想法,相反我承认我们不认同你的想法,然后我们会支持并鼓励你表达自己的想法。

令我惊讶的是,在第一周我已经看到了npm上发布的其他callbag包。其中让我最欣慰的是callbag-subscribe。它起初是一个不认同原始包的PR,然后在支持将此分歧作为一个分支,它成为自己的包。结果,一个开源用户在几个小时内成为了一个开源作者。

Tocy
Tocy
翻译于 2018/11/28 14:51
0

没有维护者的开源可能是一个乌托邦目标,现在仅适用于某些类型的库。例如,我无法将它应用于Cycle.js之上,该项目由三名维护人员组成的核心团队负责以使框架保持最新状态。但我希望我已经说明了为何没有维护者的开源可以成为一个健康的目标。总的来说,我们需要减少懈怠,我们需要更多的开源作者,更多对不同意见的支持,更少的协议,更少的需求,更多的馈赠,以及更多的感恩。

Tocy
Tocy
翻译于 2018/11/27 21:09
0
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(2)

bkkkd
bkkkd
以后就是天坑
我没有抓狂
我没有抓狂
这翻译质量不太行
返回顶部
顶部