分类 观点 下的文章

开源代码可能是当今大多数公司最可行的选择,但它也伴随着自己的问题。

许多人支持使用 开源软件 open source software (OSS)。毕竟,我们为什么要不断地尝试构建代码来解决别人已经解决过的问题?为什么不分享信息并逐步和迭代地增强当前的开源解决方案呢?这些 平等主义价值观 egalitarian values ,可能是整个文明的根本,更不用说软件了,但还是包含了几千年来一直存在的冲突。

开源软件安全的问题在于,尽管任何人都可以查看源代码,但这并不意味着他们会这么做。有一些广泛使用的开源项目仅由数量有限的工程师维护。这些工程师无法完全自愿地提供时间和精力,因为他们也需要支付他们的账单。

即使对于更复杂的开源项目,这也是一个问题。举个例子,Linux 内核项目由 3000 多万行代码组成,包含数百个需要解决的缺陷,并有近 2000 名活跃的开发者。每个活跃的开发者都写了超过 15000 行的代码。

根据 Linux 基金会最近的一项研究,一个应用程序平均有 5.1 个重大漏洞仍未解决,41% 的企业对其开源软件的安全性缺乏信心。而更糟糕的是,只有 49% 的企业拥有开源安全策略。

即使开源软件有安全漏洞,这也不能保证它能被修复。调查显示,目前修复一个漏洞平均需要 97.8 天,使使用该软件的企业在几个月内容易受到攻击。这就是开源软件安全有时被忽视的地方:就像好人可以寻找代码中的错误和漏洞来修复它们一样,坏人也可以寻找同样的漏洞来利用它们。

仅仅依靠志愿者社区来发现漏洞、报告漏洞和修复漏洞是一个漫长的过程。在你继续受益于开源的广泛优势的同时,花钱请人检查你的开源解决方案的安全性可以帮助弥补这个问题。

由于必须部署开源软件的更新和补丁以保证系统的安全,这一要求会带来独特的困难。如果你的解决方案依赖于某个软件版本,更新你的关键任务软件可能会导致功能损失和/或计划外的停机。当情况对业务至关重要时,聘请专家来回传补丁并维护一个时间更长的版本可能比让大型社区愿意去做更加优雅。

开源社区经常使用的一句话是:“这是开源的,去改变它吧!”它强调了一个关键点:当别人在项目中投入时间、精力或金钱的时候,期望白白得到良好的安全水平是不合理的,也是不可持续的。

要么按原定计划为开源做出贡献,改进代码并为他人发布,要么聘请专业人士管理开源代码并在必要时进行调试,这些都是选择。然而,这个行业无法承担完全不做贡献。


via: https://www.opensourceforu.com/2022/10/security-issues-with-open-source-in-todays-world/

作者:Laveesh Kocher 选题:lkxed 译者:KevinZonda 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

微软、谷歌、亚马逊、IBM 和甲骨文如今都在关注云上的 DevOps。这些大公司正在给企业提供 IT 自动化的服务。然而,DevOps 仍然在持续的演进中。DevSecOps、AIOps 和 NoOps 正在成为下一个流行词。

随着开发和管理人员看到及时交付高质量软件的商业价值, 敏捷 Agile 方法论和 DevOps 也变得流行起来。拥有灵活的发布周期,并且交付具有 可扩展 scalable 可定制 customizable 的软件,是世界上每个企业的目标。通过将 CI/CD 工具和 管道 pipeline 部署到云端,DevOps 使发布过程变得更加流畅。融合了 DevOps 的 Polyglot 微服务架构正在帮助企业降低总拥有成本(TCO)。他们现在有能力用渐进式网络应用程序和最新的 UI 框架升级他们的技术栈。总的来说,团队正在以更好的效率执行任务,并且正在开发高质量的软件模块。

自治 DevOps

容器和 DevOps 与云原生应用走到了一起。Kubernetes 和 Docker 正在被用作容器,一个新的名词 NoOps 现在正在流行。对于不同的容器, 编排 Orchestration 都是一个重要的功能。为了扩展应用,开发环境中要创建容器集群。有一些新的容器正在进入云原生应用这个领域,比如 Mesos、Swarm、Openshift Rancher 和 Nomad。NoOps 有助于缩短编码周期,从而监控和管理应用程序。缺陷修复和热修复是不同的活动,它们都是 NoOps 的一部分。NoOps 有助于提高技术团队和业务运营人员之间的协同作用。它也有助于更好的监控、管理和流程自动化。NoOps 基础设施能够控制应用程序在云上的部署。企业从中获得的好处包括更好的交付、弹性的服务、更快的发布、良好的质量和 CI/CD 自动化。

DevSecOps

DevSecOps 算是另一个流行趋势,它与在开发操作中的安全问题有关。最近与 漏洞 vulnerabilities (log4j), 安全泄露 security breach (谷歌、脸书、微软),和安全攻击相关的问题增加了 DevSecOps 在企业中的重要性。 左移 shift left 方法强调了在软件生命周期的早期处理安全性和质量的重要性。在架构阶段就需要考虑隐私和 遵从性 compliances (如 GDPR)。这有助于降低成本,并且提升软件交付的速度。审计工具和安全检查列表是 DevOps 工具和系统的一部分,现在我们称为 DevSecOps。

AIOps

AI DevOps 现在被称为 AIOps。据预测,将来 AI 应用会由 AIOps 来管理。与 AIOps 相关的工具和软件正在开发中,并且将很快发布首个版本。AI/ML 应用部署和模型更新可以由 AIOps 来处理。这将在 工业 4.0 Industry 4.0 以及数据科学中扮演重要角色。有一种观点认为,NoOps 将会是 AIOps 的最终形态。AIOps 包括数据集管理、模型训练、模型服务、元数据管理、模型更新和服务更新。分布式训练将由 AIOps 来完成,这会提供 超参数 hyper parameter 优化,工作流程管理和“ 假设 what if ”的分析能力。

微服务配置管理

当前,DevOps 和微服务正在成为标准部署和 架构蓝图 architectural blueprints 来实施。应用可以在模块级别上就进行扩展。微服务可以在简化缺陷修复和问题区域隔离上提供帮助。经过设计,微服务可以通过添加更多 计算能力 computing power 实例 instances 来进行扩展。但是当它们没有被正确实现的时候,数据安全和管理的问题就会突然出现。

平台即产品

云上的 软件即服务 Software as a Service 平台即产品 Platform as a Product 最近非常流行。通过加速向平台部署和功能交付,DevOps 使这些变成现实。从编码到上线阶段,CI/CD 管道有助于可视化应用的部署。持续交付、集成和部署都是 DevOps 的一部分。DevOps 生产线模拟工业生产线是未来要关注的。

DevOps 正在慢慢地向 DevSecOps 和 AIOps 转变。对于企业,NoOps 才是未来。现在需要的是减少与安全相关的攻击、事故和破坏发生。对于企业来说,数据安全和隐私的优先级更高,并且这些新技术都将在这方面有所帮助。


via: https://www.opensourceforu.com/2022/09/where-is-devops-headed/

作者:Bhagvan Kommadi 选题:lkxed 译者:Yufei-Yan 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽(Red Hat)精心制作的原创音频播客,讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客《代码英雄》第五季(2):程序员写代码的地方音频 脚本。

导语:家庭办公室、企业园区、联合办公空间、有趣的校园。程序员们希望在工作场所方面有所选择。将普通的工作空间从办公室转移到家里,揭示了在家里工作的好处,但也突出了它的权衡。

Saron Yitbarek 和 Clive Thompson 通过考虑工作场所继续他们对编码职业的讨论。Mary Allen Wilkes 分享了她作为第一个在家工作的开发者的经验。David Heinemeier Hansson 认为远程工作使他的同事有时间进行深入思考。Dave West 解释了为什么他认为面对面的工作仍然能产生最好的结果。Maude Mensah Simpson 权衡了家庭办公室的自由与失去面对面交流的机会。

00:00:02 - Saron Yitbarek

你们好,欢迎来到《 代码英雄 Command Line Heroes 》,一档 红帽 Red Hat 的原创播客节目。这是我们有关程序员,无论是开发人员到系统管理员,以及架构师、工程师、程序员,工作生活的迷你特别季的第 2 集。我是你们的主持人 Saron Yitbarek,和我一起参与到这一季的是 Clive Thompson,他是记者、技术向作家以及《 码农:新部落的建立和世界的重塑 Coders: The Making of a New Tribe and the Remaking of the World 》一书的作者。你好, Clive。

00:00:30 - Clive Thompson

你好 Saron。很感谢你能再次邀请我来。

00:00:31 - Saron Yitbarek

感谢你加入我们,Clive。在这一集里,让我们谈谈到目前为止,我们当中很多人(不仅仅是技术人员)非常熟悉的一些东西,因为我们大多数人自从 2020 年 3 月以来就不得不这么做 —— 远程工作。现在,你可能认为远程工作在我们的行业里是相对较新的现象。随着技术的进步,在家中工作变得更为容易。先再想一下,让我们来听听这位开发人员的故事。

00:01:00 - Mary Allen Wilkes

嗯,我的名字叫 Mary Allen Wilkes。1959 年到 1972 年间,我做了十二三年的计算机程序员。

00:01:14 - Saron Yitbarek

Mary Allen 已经 82 岁了。在她青少年时期,她迷上了法律,想当一名律师,但是在 50 年代这对一名女性而言并不是一个明智的职业选择。她的导师劝阻了她,并告诉她这将会十分困难。偶然的一次机会,她的一位老师为她描绘了另一条路线。

00:01:36 - Mary Allen Wilkes

我在读八年级时的某天,在上一个地理老师的课时被这位老师指引了那条路线。当时我应该是给他讲述了自己对某件事情的论点,而他停了下来并看着我说:“Mary Allen,你长大以后应该成为一名计算机程序员。” 好吧,我那时并不知道他在说什么。多年以后,我很想知道他是否清楚他当时正在说的是什么。他教授地理和法语,而没有人教计算机编程。但是我永远都忘不了他的话。而且我认为让我多年难以忘怀这个目标的一个原因是,这是一个成年人告诉我长大以后可以做一件积极的事情。

00:02:22 - Saron Yitbarek

当 Mary Allen 从大学毕业并且开始求职时,唯一有计算机程序员职位的地方是 MIT。没有人接受过计算机编程方面的任何训练。她的主要资格条件是她在大学里上过的两门逻辑学课程,但这已经比她在 MIT 的同事多了。

00:02:41 - Mary Allen Wilkes

我开始在 马萨诸塞州 Massachusetts 列克星敦市 Lexington 林肯实验室 Lincoln Laboratory 工作,这是由美国国防部资助的一个大型的 MIT 研究机构。那时候是 1959 年,我第一次知道他们正在使用这些非常巨大的计算机,能占据整个房间的那种。这是我最初学习编程的机器。它们是 IBM 计算机。你用汇编语言逐行编写好你的程序,然后把这些纸片交给打孔卡操作员,她们会把你的程序打在 打孔卡 punch card 上。然后你将其带到计算机室,交给计算机操作员。

00:03:29 - Saron Yitbarek

1961 年, Mary Allen 被分配到一个小组,在 Link 计算机上工作,这是一款实验室仪器式微型计算机。它是第一批真正的交互式计算机之一,与当今的台式计算机有些相似。

00:03:44 - Mary Allen Wilkes

Link 有一块显示屏。我们称之为“ 视窗 the scope ”,因为它事实上就是一个实验室示波器。它有四个可以放在桌面上的盒子,一个装着这台示波器的盒子、一个装有两个袖珍大小的小型磁带装置的盒子。基本上你可以把它想象成你的永久存储器、硬盘驱动器。那是你存储和读入你的程序的地方。另一个盒子被称为控制台盒子。你可以用开关来加载某些代码(比如某些引导代码)到 Link 的内存里。它也有个键盘。因此,你拥有你现如今会有的基本交互式配置,键盘、屏幕以及某种形式的永久存储器。然后当然还有所有的电子元器件,它们都被装载一个大约和一台冰箱差不多大小的大箱子里。

00:04:43 - Saron Yitbarek

1964 年, Link 小组做了一个艰难的决定,从 MIT 迁至 密苏里州 Missouri 圣路易斯 St. Louis 的华盛顿大学,但是 Mary Allen 不想去。

00:04:54 - Mary Allen Wilkes

我不想立马就搬到圣路易斯。我一点都没有想搬去那里的想法。我想要做的是为 Link 写一个合适的操作系统,因为到那时为止,我们所拥有的只是我在 1962 和 1963 年所编写的相当基础的小汇编程序。我说:“我可以写它。我可以在家里写它。”

00:05:20 - Saron Yitbarek

Link 小组的负责人 Wesley Clark 认为这个想法不错。

00:05:25 - Mary Allen Wilkes

我对他说:“我想要写操作系统。”我可能是当时唯一一个能够写这个操作系统的人。因此,Wesley 只是说:“好吧,没问题。为们会给你送来一台 Link。你可以在家里使用它。”这就是它的经过。一天,我们实验室的几个人开着一辆小货车来了,并带来了四个箱子,四个模块和冰箱大小的东西,装着电子设备与存储器等等。他们把这些东西运到了我父母在 巴尔的摩 Baltimore 的客厅。除了他们不得不为此拉了一条 20 安培的电路,只需要将其插入墙上的插座即可。

00:06:10 - Saron Yitbarek

你的父母对家里这个硕大的新入侵者作何看法?

00:06:15 - Mary Allen Wilkes

我的父亲是一位 圣公会 Episcopal 牧师。他看到每个人都会说:“我敢打赌,你的客厅里没有计算机。”这至少可以说是相当新颖的事情,相当的新奇。

00:06:30 - Saron Yitbarek

Mary Allen 的父母整天都不在家,因此她能够集中注意力。她直接在 Link 上写操作系统,不需要打孔卡,所以她可以更快地进行调试。她通过电话或老式的 蜗牛邮件 snail mail 和她的团队交流,并在必要的时候前往圣路易斯。仅仅在不到一年的时间里,她就完成了这个操作系统并编写了编程手册。

00:06:55 - Mary Allen Wilkes

我从未感到被孤立,也从未感到过沮丧。我感到充满了挑战。我认为编程基本上是一项适合内向的人、与世隔绝工作的人、独立工作的人、不需要大量支持或是与他人互动的人的工作。

00:07:15 - Saron Yitbarek

多年以来,Mary Allen 从事过其他需要在办公室的工作。但是她更喜欢的是在家工作。

00:07:23 - Mary Allen Wilkes

自从我在 2001 年辞去最后一份全日制工作以来,我如今已经在家里工作了好几年。因此,我是一个家庭工作者。而且事实上,在我离职那天,我对自己说,我会继续工作,但我不想去办公室,也不想坐在办公桌前。但是到了那会,我们已经有了笔记本电脑,所以我能够坐在舒服的椅子上工作。

00:07:53 - Saron Yitbarek

因此,Clive,Mary Allen 的故事如此精彩,你该为《码农》一书去采访她。她不仅仅是计算机编程的先驱,而且还是远程工作的先驱,对吧?

00:08:03 - Clive Thompson

是的。我的意思是,据我所知,她是第一个有一台能让她在家工作的个人计算机的人。网上有一张她的令人惊叹的照片,照片上她正坐在她父母的楼梯脚下。他们把所有这些部件放在顶层的楼下,这是她放一张小桌子坐着工作的地方。而且这是对未来的一瞥,对吗?我是说,那时候她正在做的事情要花费 30、40 年时间才能够整体实现,因为她完全领先于自己所处的时代。

00:08:36 - Saron Yitbarek

编程是一项很理想的远程工作。甚至我自己的自我封闭经历也使我意识到,我已经这样做很多年了。因此当你和程序员们交谈的时候,有多少人喜欢这种工作方式?它变得有多流行?

00:08:52 - Clive Thompson

好吧,这很流行,而这是因为程序员们喜欢在家工作。绝大多数的程序员如果能够选择的话,他们会说,是的,我会一直在家工作。之所以会这样,是因为这提供了他们一个安静而又能够专注的地方,而且不会因为在隔间里有人拍他们的肩膀而被打扰。如果你要对他们说:“嘿,伙计们,各位,你们更愿意在哪里工作?”他们全都会更倾向于在家里工作。

00:09:26 - Saron Yitbarek

Basecamp 是一家大力提倡远程工作的技术公司。他们已经有 20 年历史了,而他们从最初就进行远程工作,甚至在远程工作流行之前。他们的员工在世界各地的家中工作。让我们来听听 David Heinemeier Hansson 怎么说。他和 Jason Fried 共同创立了 Basecamp。他也是 Ruby on Rails 的创造者。

00:09:49 - David Heinemeier Hansson

事实上,在我开始和 Jason 共事的前六个月,我们只是通过电子邮件和 IM 进行联系。我们甚至都没有打过电话。因此我想是过了六个月时间我们才通了第一次电话,并且花了一年多时间我们才见面。所以很长的一段时间里,这都不是传统观点。我们接触到了庞大的人才库,这些人意识到自己不想住在 旧金山 San Francisco 。他们不想去纽约生活,他们也不想去西雅图生活。他们不想在这些大型技术中心里的任何一个地方生活,然而他们确实是精通而且合格的人才。因此,Basecamp 允许他们这么远程工作,对于我们的招聘策略和维系策略都至关重要。

00:10:31

2012 年,我与其他企业家进行了一系列对话,向他们询问他们的工作实践,我们谈到了远程工作。而对于为什么远程工作行不通,他们只给了我这些老套的辩驳,“哦,你们没法合作。魔法只会发生在白板周围。”而我想,什么,人们还是这样想的?这怎么可能?白板在 Basecamp 基本上不存在。我们拥有的第一工具是写作。它是异步的,你自己书写并发布,然后等着就行。当富有创造力的人们有时间和空间去进行深度思考,并且将深度思考编辑成深度写作时,就会产生良好的协作。深度写作的并不是一行行的聊天组成的,而是完整的句子,形成段落,进而形成完整的论点。

00:11:29

然后,你可以利用时间的优势和平静来考虑这些观点。90% 时间拿来写作,然后 5% 拿来聊天,最后 5%,可能是随便什么,是用 Zoom 还是 Tubal 或者一些其他的视频连接屏幕共享之类的协作。

00:11:49 - Saron Yitbarek

Clive,David 在这里提出了一些非常有趣的观点。有些我从来都没想过。还有程序员正在使用的能使远程工作成功的其他工作方式吗?

00:12:00 - Clive Thompson

是的,当然有了。在他们知道需要和人进行联络,甚至可能是面对面接触时,他们会做一些时间安排。因此,确实有一些我交谈过的公司会说:“好吧,我们知道我们的开发人员不在这儿的时候能把他们的工作做到最好,但是我们希望他们有时能够在这里,我们想开一些面对面的会议。”他们仍然相信这一点。因此,他们会有比如像是这样的日程安排:好吧,在周二和周四的下午 1 点到 5 点,我们需要所有人都在办公室里,以便我们能够有时间进行交谈。剩下的时间,你可以去你想去的任何地方。如果你想的话,你可以在办公室里工作,你可以在任何你喜欢的地方工作。可以是在星巴克,也可以是在家里。因此,这种有趣的新安排是一件行之有效的事情。

00:12:44

我认为另外一件相当有效的事情是,弄清楚所有人都最喜欢的聊天或者交流模式是什么样的。就 David 而言,他喜欢的,以及他的团队所喜欢的,是长长的电子邮件会话。我肯定已经和喜欢这种交流模式的人交谈过了,但是其他人,他们实际上真的很喜欢 Slack,或者他们特别喜欢老式的 IRC,对吧?就是在黑色背景的绿色文字那种。但是他们弄清楚了它们的共存形式是什么,因为有过这样的现象,被谈论在线交流的心理学家们描述为 环境感知 ambient awareness ,这是一种当你没有和他们在一起时,知道其他人正在思考什么或是做些什么的能力。有很多技术可以使我们做到这一点。而最好的远程团队仔细考虑了他们的环境感知方法是什么,然后锁定并使用它。

00:13:39 - Saron Yitbarek

在我自己的远程工作经历中,有一件我发现确实很有用的事情是,通过 Hangout 或 Zoom 会话来进行协同工作,让流媒体运行着,并一直保持着连接。这确实是一种减少孤独感的绝妙方式,一定意义上有了相互陪伴的感觉,像在一个公司里面,除了每个人仍然还在做着自己的事情,但是这提供了可以拍拍某人肩膀的机会,因为我可以说:“嘿,我被这个功能难住了。你介意我耽搁你接下来的 5 到 10 分钟吗?和我结对帮助我摆脱困境吗?”因此,这成了一种着实很有用的方式,能让你获得某种形式的社交互动,并在需要的时候有机会得到帮助。

00:14:21 - Clive Thompson

这完全有道理。我是说,我认为很多人都试图找到某种方法来与有经验的人这么做,或者甚至坦率地讲,甚至和同龄人这么做,因为你能够得到很多,即使某人并不比你资深,但他们也有与你不同的大脑。

00:14:37 - Saron Yitbarek

是啊,当然了。我认为这是一种不同的交流形式,而不是一种低质量交流。

00:14:44 - Clive Thompson

一点也不。这就像是心理学家所谓的 元认知 metacognition ,有关思考的思考。确实,当前的任务是:今天我想要尝试的是哪一种思维方式?是和某人面对面交流还是与他们在线聊天更有助于思考呢?

00:15:01 - Saron Yitbarek

因此,既然我们所有人都被迫在家工作,各家公司都意识到他们仍然能够完成工作。人们的态度已经倾向于远程工作将成为主流了吗?

00:15:12 - Clive Thompson

这是真的是一个大问题,而我认为我们目前并没有答案。我认为即将要发生的事情是,有很大一部分工人,包括从未在家或者被允许在家工作的开发人员,我估计超过 50 %,他们将会要求将远程工作成为半永久性的。他们将发现自己的工作效率要高得多,并且希望更频繁地这样做,而且有一些会议中是不必要的,打断了他们在工作区中的工作流程。

00:15:47 - Saron Yitbarek

因此,如果远程工作是提高生产效率的好方法,随着时间的推移,它变得越来越流行,尤其是对于码农们来说,这是一种很好的完成工作的方式,它可以更方便,而我们这种工作形式确实意味着在家里工作,那么为什么这些大型科技公司要继续建造如此大的工场供其员工工作呢?

00:16:06 - Clive Thompson

有一部分是基于他们的想法或者担忧,即人们只有在面对面,并且彼此有着意想不到的联系的时候,才会有创造性思维产生。而这有一些实际上是基于科学的。我的意思是,有大量研究表明,当公司中的可能互相根本不认识的人们相遇时,会产生某种特定类型的交流和松散的协作与念头。我是说,这是典型的 饮水机效应 water cooler effect 。 3M 是一家大型的纸业公司,以发明了 便利贴 Post-it Notes 而闻名,这是一项价值数十亿美元的发明,只是因为发明了这种粘性物质的一个人遇到了另一个正在找寻一种能把纸张固定在适当位置的方法的一个人。而正是因为这个遇见彼此的机会,他们创造了该公司最具标志性的产品之一。

00:17:05

史蒂夫·乔布斯 Steve Jobs 打造了苹果公司总部,不仅仅最大程度地提升了人们在一起工作的机会,而且让他们在一些地方聚集,以迸发出创意的火花。

00:17:20 - Saron Yitbarek

我进行远程工作已经很多年了,不过只是我自己一个人工作。然后当我有了一个团队后,就和几个人一起工作,但是我在远程工作方面的经历里最多是和四个人共事。而且他们来自各个地方。我们中有人在洛杉矶,有人在布鲁克林,也有人在芝加哥,但是我想知道的是 —— 远程工作真的只有对于像这样的小型团队以及像 Basecamp 那样的小型公司才能取得成功吗?

00:17:44 - Clive Thompson

这是个很棒的问题。我看到的最成功的情况是,在开发团队很小的时候,在初创阶段,有 5 到 6 个人,而且事实上,他们之所以能够获得所需的人才,是因为他们说:“好的,你在俄罗斯,我在多伦多,我们其他人在田纳西,而我们将一起工作。”因此,你在某种类型的创业公司中经常看到这种情况,他们拥有他们所需的特定技能,并且需要得到他们认为最好的人才,但他们不会要求这些人搬家。这是都是小型团队。

00:18:22

我觉得管理通信要更加容易一些,因为你基本上可以将这视为一组节点之间的通信,并且随着节点的整张,需要通信的人数急剧增长。因此,只有 4 个或 5 个人的时候团队运转良好,到了比如 50 个人,这变得着实很困难,再到 150 个人,哦,我的天哪。对于一家有着 10000 个人的公司而言,弄清楚他们将如何做到这一点变得更为困难。

00:18:47 - Saron Yitbarek

让我们来听听有关远程工作的另一种观点。Dave West 是 scrum.org 的首席执行官。这家公司工作的基础是《 敏捷宣言 Agile Manifesto 》的第一条规则:个人和交流高于流程与工具。有请 Dave。

00:19:05 - Dave West

我认为现实是,如果你真的想要以极快的速度构建一个项目,以一种真正有效的方式协同工作,面对面可能仍然是最好的形式。这并不意味着它是唯一的方法,也不意味着你以其他的形式交流和分配就不能像从前那样行之有效。但是,最好和最容易的形式是面对面交流。时至今日,我仍然相信我曾经从事过的最令人愉快的软件项目,以及我曾经参与过的开发项目和团队都位于同一地点,位于同一个办公室里。而这是有许多原因的。这是因为周五晚上出去喝点儿啤酒,能够在发生可能影响他们工作的问题时,比如他们的狗死了或类似的事情,能够真正得到额外的理解。

00:20:04

你会得到那种额外的东西,而这是很难从一个分布式团队中得到的。但是另一方面,我认为不是所有最出色的软件工程师都居住在硅谷。所以我感到很矛盾,我觉得位于同一地点的团队有着巨大的价值,但是我也认为,由分散在不同地点,不同能力的人们所带来的好处,也是巨大的。因此,你必须找寻到一个平衡点,而这相当相当困难。我所知道的是如果你打算分散你的团队,那么你必须特别注意促进,并使得环境尽可能实际复制位于同一地点的团队所处的环境。这意味着经常让他们见面。因此,你们要进行大量的屏幕共享,并且花时间在一起,可能需要发起一个谷歌 Hangout,并使之持续运行并进行共享。这些事情变得非常非常重要。

00:21:10 - Saron Yitbarek

因此,Clive,开源项目是建立在协作和团队合作之上的,那么,远程工作会阻碍这一点吗?远程工作对真正的协作能有多大帮助?

00:21:22 - Clive Thompson

好吧,这个问题有关开源的的第一部分很容易回答,我认为实际上开源领域的大部分巨大成就都是在极端远程的情况下取得的,因为从定义上说,开源项目的魔法是一个开发者说:“嘿,我有一个我正在开发的代码库。有人有什么主意吗?”与其只是询问你公司里的 50 个人,你可以在网上询问数以百万计的人。因为实际上只有 1% 的 1% 的 1% 的 1% 的人会给你提供一个好主意。在你拥有 50 个人的组织里,可能没有人会在意你正在构建的奇怪的小库,而在整个星球的范围内,你就能找到 9 个人以令人难以置信的热情和兴趣帮助你开发这个东西。因此,从某种意义来讲,开源从定义上说通过远程协作大力促进了远程工作。

00:22:18

不过,它也受到了挑战,因为刚才 Dave 所谈及的所有这类事情都是真实的 —— 没有面对面接触的话,所有能够帮助组织运转的社会纽带真的很容易分崩离析。而你会在开源项目中看到这一点。它们真的能够转变成网络上反社会行为的噩梦,因为人们并不擅长去阅读彼此的语气。他们会认为自己只是直截了当,而其他人则会认为他们是在进行令人难以置信的羞辱。在面对面社交互动的情况下能在可能是短短 30 秒的时间内就能够化解的误会,能够撕裂开源社区,并已经撕裂了网络上的一些开源社区。

00:23:07 - Saron Yitbarek

Maude Mensah Simpson 是一名前端开发人员,她在居家工作的同时还是两个年幼孩子的母亲。她解释了在有了她第二个孩子以后,在远程工作方面所遇到的早期挑战之一。

00:23:18 - Maude Mensah Simpson

在我有了第二个孩子的时候,我只做了一年的开发人员。因此,当其他所有人都在办公室而就你不在的时候,你会错过太多太多东西。其中之一是人们对一般工作的小范围谈话。比我资深的开发人员会在我写代码的时候从我身后走过,然后他会看到我正在做的东西,并且会说:“哦,是的,我喜欢你的做法。”或者,“你在做什么呢?”他只是经过我工作区,这让他有机会和我谈论有关写代码以及如何正确地做事情。远程工作可能只依赖于你的个人自信,因为当你不在办公室里工作时,你会错过一些教学与指导。

00:24:10 - Saron Yitbarek

Clive,我想知道一名经验丰富的程序员和一名处于生涯起步阶段的程序员相比,远程工作的经验是不是会有所不同,因为我能够想象一个经验丰富的程序员,已经习惯于在办公室环境中工作,然后不得不转到远程工作。这变化可能并不是太糟糕,也并不是太具有挑战性。但是对一个处于职业生涯初期的程序员而言,我能看到他们真正受益于身边的导师,这些人拥有更多地经验,能够拍拍他们的肩膀然后问他们问题。因此,处于生涯初期的程序员会因为不在其他程序员身边而有所损失吗?

00:24:43 - Clive Thompson

我觉得他们会的。是的。我认为这是一个很合理的担忧,而且我确实从那些通过面对面合作成长起来的老开发者那里听到过,他们知道,通过和一名更资深的程序员进行一次 30 秒的面对面交谈,他们可以学到很多东西,并觉得茅塞顿开。Jeff Dean 是谷歌的一名资深工程经理。我从许多和他共事过的人那里听说,他就是一个非常有用的资深资源,因为人们会带着问题去找他,而他能够通过字面上直接看到解决方向,并且在 20 秒内说,“哦 …… ”虽然他不会直接给出答案,但是他会指出他所认为的问题所在,从而使他们茅塞顿开地回去,并变得令人难以置信得富有生产力。

00:25:36

因此,新人们能够从像那样的交互当中受益匪浅。我不是说你永远不能从远程得到这种交互,只是会更难。然后还有代码审查。因此,在一家管理良好的优秀公司里,你将会需要代码审查,你的同事,最好是有一定经验的资深人士会查看你的代码,坐下来讨论它,并问你是如何实现,以及为什么要这么做。而这个往复的过程会涉及到许多你可能作出的模糊决定,并使其清晰化,这对学习而言相当有价值。能够理解你为什么要做自己所做的事情,将其具象化给其他人,是十分有价值的。

00:26:20 - Saron Yitbarek

我所听说过的有关远程工作的问题之一是这种混合的想法,当你开始工作,然后到了 6 点钟,是时候停止工作了,但是你在工作过程中感到舒适,你会再额外地工作一两个小时,最终会因为远程工作而过度劳累。是这样吗?然后与之相反的是,你会在远程工作的时候摸鱼吗?

00:26:43 - Clive Thompson

你可能会摸鱼,但是在我对开发人员及其经理的所有访谈中,从来都没有听说过这种情况。事实上恰恰相反。我更多听到的是经理们担心人们永远不休息,永远都不离开工作。我也从开发人员那里听说过,难以摆脱工作。对于开发人员而言,总是很难停止去思考问题。当你居家工作的时候,你会花费 8 个小时的沉浸式时间,然后你会完成许多工作,但是由于你实际上并没有去其他地方,你的身体没法帮着欺骗你的思维,进入关闭状态。就像你离开了办公室,坐上了汽车、公交车、踏板车或是步行回家,你实际上就从一个地方到了另一个地方,而这种物理信号会帮助你的大脑自我复位。

00:27:35 - Clive Thompson

这里涉及到了很多很多的科学依据。我是说,从字面上看,实际上从一个地方去到另一个地方能够帮助你的大脑进行自我复位。当你没有能力这么做时,当你居家工作,编码问题的天然象棋式的心理空间就很难告诉你的大脑停止工作。因此,诸多原因导致了居家工作的人们继续以自己明知道不健康的方式去工作,却难以停下来。

00:28:03 - Saron Yitbarek

David Heinemeier Hansson,请。

00:28:05 - David Heinemeier Hansson

随着时间的推移,我们对于 Basecamp 的人们如何处理这一问题有过一些有趣的轶事。我们过去有一位数据分析师,他有两双拖鞋。他会在走进办公室的时候穿上他的工作拖鞋,而换下他的居家拖鞋。它们只是一双拖鞋而已,只不过是将工作与家庭分隔开来。而我认为这一分隔尤为重要。我觉得对许多使用他们的家来工作的人而言,能够分出家里的一个房间用于工作,然后当你离开那间屋子时,你就不再工作了,这也不失为一种健康的行为。

00:28:41 - Saron Yitbarek

我喜欢这个拖鞋的点子,就像 Rogers 先生那样。接下来还是 Maude。经过在家和孩子一起工作了几年后,她想出了自己的方式,使得居家工作行得通。

00:28:53 - Maude Mensah Simpson

(在家工作)很容易对时间失去控制。你可能会坐在那里好几个小时,却并不知道自己已经在家写了多久代码,因为你在家里。我的解决方法是,我有一个 Pomodoro 计时器,我会确保大概每小时都会有专门的休息时间。然后就是能够将家和工作分隔开来。我在家里有一个办公室,我不会允许我的家庭生活进入到这间办公室里,以保证将其二者分隔。因此,每当我走出去时,我可以是妈妈或是我不工作时候的任何身份,但是当我走进了办公室以后,这是上班时间,而这使得进入工作流程更为容易。我每天都会进行一次快速的状态更新。早上,我会让他们知道这是我今天要做的工作,然后到了夜晚,我会让他们知道我做到了什么程度。我认为在进行远程工作的时候不存在类似于过度沟通之类的事情。所以是的,只是沟通,沟通。

00:30:02 - Saron Yitbarek

因此,Clive,有没有其他建议或是窍门来远程管理员工,或者甚至是成为一名远程工作者?

00:30:08 - Clive Thompson

当然,如果一家公司想要拥有一种严肃的远程文化,那么重要的一点是,高层管理者也应当远程工作,这样就不会有产生一种远程工作是一种次级状态、重大决定是由重要的人面对面作出的,而远程工作人员并不参与其中的感觉。我在为我的书籍做研究时所遇到的一个问题是,当我与 Postlight 的一些工程师交谈时遇到的,那是纽约市一家很了不起的公司。他们主要为媒体行业开发应用程序。工程负责人进行着远程工作,他在 纳什维尔 Nashville 南部的树林里工作。当我和他交谈时,他说:“这确实是非常重要的一件事情,因为我们有许多远程工作的工程师,他们乐于知道在领导工程师团队的我也是远程工作的。”这意味着公司里的每一个人都非常用心地思考着如何远程工作,因为在这部分中主持工作的人本身就是远程。

00:31:09 - Saron Yitbarek

自从 2020 年 3 月以来,我们大多数人都不得不彻底改变工作方式 —— 居家工作,无论我们过去是否以及是这么做的。而当我们居家工作时,这就取决于我们个人的工作风格,并且确保无论我们从事的是什么项目,无论工作于什么公司,无论在管理什么人或是被什么人管理,我们的个人喜好能够得到尊重,我们可以灵活地以我们擅长的方式工作。以人为本不仅仅是《敏捷宣言》的第一条规则,也是开源的方式,而且它是能够产生最好结果的方式。请访问 redhat.com/commandlineheroes 以获取这一集的更多研究结果。下一次,在我们有关职业生涯的这一迷你季的最后一集中,Clive 将会回来和我们一起解决“你会成为什么样的程序员”这一问题。非常感谢你加入我们, Clive。

00:32:07 - Clive Thompson

谢谢,Saron。

00:32:08 - Saron Yitbarek

你正在收听的是《 代码英雄 Command Line Heroes 》,一档 红帽 Red Hat 的原创播客节目。我是 Saron Yitbarek。

00:32:15 - Clive Thompson

我是 Clive Thompson。

00:32:16 - Saron Yitbarek

好的。然后呢?

00:32:18 - Clive Thompson

哦我的天哪。我们能最后一次说“坚持编程”吗?

00:32:23 - Saron Yitbarek

坚持编程。

00:32:25 - Clive Thompson

坚持编程。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ,LCTT SIG 是针对特定领域、特定内容的翻译小组,翻译组成员将遵循 LCTT 流程和规范,参与翻译,并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽(Red Hat)发起的 SIG,当前专注任务是《代码英雄》系列播客的脚本汉化,已有数十位贡献者加入。

欢迎加入 LCRH SIG 一同参与贡献,并领取红帽(Red Hat)和我们联合颁发的专属贡献者证书。


via: https://www.redhat.com/en/command-line-heroes/season-5/where-coders-code

作者:Red Hat 选题:bestony 译者:JonnieWayy 校对:windgeek, Daniel4078, wxy

本文由 LCRH 原创编译,Linux中国 荣誉推出

使用艾森豪威尔矩阵更好地安排你的待办事项的优先次序。

 title=

在本文中,将研究一种在待办事项上确定任务优先级的策略。想要找到适合你日常工作的开源工具,请查看 此列表

把事情添加到任务或待办事项中很容易。几乎太容易了。而一旦列入清单,挑战就变成了弄清楚先做什么。我们要做清单首位的事情吗?清单首位的事情是最重要的吗?如何弄清楚最重要的事是什么?

 title=

要做的事。今天?明天?谁知道呢?(Kevin Sonney, CC BY-SA 4.0

与电子邮件一样,我们可以根据一些事情来确定任务的优先级,这可以让我们弄清楚什么事情需要先做,什么可以等到以后再做。

我使用一种被称为“ 艾森豪威尔矩阵 Eisenhower Matrix ” 的方法,它取自美国总统 德怀特·戴维·艾森豪威尔 Dwight D. Eisenhower 的一句话。画一个水平和垂直分割的方框。在列上标明“紧急”和“不紧急”,在行上标明“重要”和“不重要”。

 title=

一个艾森豪威尔矩阵。(Kevin Sonney, CC BY-SA 4.0

你可以把待办事项上的任务放在其中一个框里。但如何知道一个任务应该放在哪里?紧迫性和重要性往往是主观的。因此,第一步就是决定什么对你来说是重要的。我的家庭(包括宠物)、工作和爱好都很重要。如果待办事项上的东西与这三件事无关,我可以立即把它放到 “不重要” 行。

紧迫性是一个比较简单的问题。一件事需要在今天或明天完成吗?那么它可能是 “紧急的”。一件事是否有一个即将到来的最后期限,但离那个时间还有几天/几周/几个月,或者它根本就没有最后期限?当然是 “不急的”。

现在我们可以将这些框转化为优先级。“紧急/重要” 是最高优先级(即第一优先级),需要首先完成。接下来是 “不紧急/重要”(优先级 2),然后是 “紧急/不重要”(优先级 3),最后是 “不紧急/不重要”(优先级 4 或根本没有优先级)。

请注意,“紧急/不重要” 是第三位,而不是第二位。这是因为,人们花了很多时间在那些看似重要的事情上,只是因为它们比较紧急,实际上这些事并不是重要的。当我看到这类事项时,我会问自己一些问题。这些任务需要我具体完成吗?这些任务我可以要求其他人去做吗?它们对其他人来说是否重要和紧急?而这是否改变了它们对我的重要性?也许它们需要重新分类,或者我可以要求别人完成,并将它们从我的清单中删除。

 title=

确定优先级后。(Kevin Sonney, CC BY-SA 4.0

对于“不紧急/不重要”框中的事项,有一个问题要问,那就是 “这些事情到底需不需要放在我的清单上?”说实话,我们经常用那些不紧急或不重要的事情来填满待办事项清单,但其实完全可以将它们从清单上删除。我知道承认 “这事永远不会完成” 是很难的,但在接受这个事实后,把这个事情从清单上删除并且不用再为它担心,是一种解脱。

经过这一切,看着清单很容易说出:“这是我现在需要做的事情。” 然后完成它。这就是待办事项的作用:为一天提供指导和重点。


via: https://opensource.com/article/21/1/prioritize-tasks

作者:Kevin Sonney 选题:lujun9972 译者:Veryzzj 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Rust for Linux 这个项目是希望今后可以使用 Rust 编程语言来编写内核代码,该项目已经进行了几年,有越来越多的开发者认为是时候将这项工作合并到主线中了。在 2022 年的 Linux 内核维护者峰会上,Miguel Ojeda 向大家更新了此项目的最新状况,希望能达成一致来确定何时可以完成合并。

他得到的答案是很清晰的:内核中确实很快会有 Rust 了。

这方面并没有什么悬念。Linus Torvalds 在会议开始时就说,他计划接受(可能在 12 月中旬发布的) 6.1 内核的 Rust 补丁,除非他听到强烈的反对意见。Ojeda 表示,他很期待这一天,并询问这些补丁应该如何进入主线。Torvalds 说,他不愿意直接接受这些补丁,所以看起来很可能需要 Kees Cook 来将这项工作引向上游。

Dave Airlie 说,有一些 MacBook 驱动程序的开发者打算用 Rust 来做他们的工作,所以很可能在不久之后就会有真正的 Rust 驱动程序进入上游了。不过,Torvalds 说他希望最开始只合入尽量少的内容,只是让基础设施先进入内核,让开发者开始使用它。它应该可以完成编译,但应该基本仅限在 “hello, world” 这种水平就好。他说,这将是一个向世界发出的信号:“终于落地了”。

Greg Kroah-Hartman 问道,针对特定子系统的 Rust 绑定实现,该如何进入上游;是应该通过 Rust 树还是通过相关子系统的维护者?Ojeda 回答说,Rust 核心支持应该通过 Rust 树来合入,但其他的应该经过维护者来合入。Alexei Starovoitov 担心,如果子系统维护者不想在他们的子系统中使用 Rust,他们也无法拒绝 Rust 补丁;James Bottomley 补充说,对于长期从事 C 语言开发的人来说,Rust 可能是一种很难理解的语言,把它强加给维护者并不合适。Torvalds 回答说,这应该由维护者决定;目前没有必要制定统一的规则。

Paolo Bonzini 说,对于不熟悉该语言的开发者来说,针对特定子系统实现抽象层的 Rust 代码往往是最难读懂的,“but it's stupid code”,并没有做什么复杂的动作。驱动程序级的 Rust 代码则要简单易懂得多。Torvalds 重申,就目前而言,维护者将可以说他们不想接受 Rust。但 Starovoitov 反驳说,无论他如何决定,BPF 都会受到影响;开发者需要能够对 Rust 代码进行跟踪 来调试问题。他补充说,每个人最终都会需要了解 Rust。Torvalds 回答说,他预计这个过程需要几年时间。

Cook 说,这种变化将类似于内核所经历的许多 C 语言变动。停止使用可变长度数组也是一个类似的过程,开发人员目前已经习惯了这一点。Torvalds 说,这其实更加类似于 BPF 的引入过程;这也是一种新的语言,起初是针对特定使用场景的,但现在已经无处不在了。

Ted Ts'o 指出,内核必须使用不稳定的 Rust 功能,这就导致不好确定应该使用 Rust 的哪个版本了。也许开发者应该宣布一个特定版本的编译器作为内核开发所使用的版本?这将鼓励发行版提供商把这个版本打包发行出来,使其得以更广泛地被采用。Thomas Gleixner 说,在 kernel.org 上提供我们选定的编译器应该就够了,但 Torvalds 回答说,只要有可能,他都希望优先从发行版提供商那里获取编译器。Bottomley 问道,Rust 什么时候会成为内核编译的必备条件;答案是 “当某人需要使用的硬件需要 Rust 的时候”。Torvalds 说,如果这一天到来了,那说明 Rust 在内核开发领域是非常成功的了。

Gleixner 问 Rust 语言现在的规范性如何;Ojeda 回答说,这取决于人们希望用什么。Rust 保证了稳定功能都可以向后兼容,所以这些功能不会意外不能用了。不过,内核正在使用一些不稳定的功能;这些功能出现变动是很有可能的。目前正在做的工作就是把这些功能稳定下来,以便让内核能够稳定地使用它们。

目前正在努力为 Rust 编写一个强调安全的系统的规范,这会最终得到一个类似于标准的文档。不过 Ojeda 说目前基于 GCC 的 gccrs Rust 编译器的开发者发现当前的文档有些地方比较模糊。其中经常把相关行为定义为 “参考 rustc 编译器的实现方式”。他说,这 “不是好事”,但会继续改善。

Gleixner 还询问了生成 Rust 绑定的工具,尤其是有没有自动化工具来确保 Rust 和 C 版本的数据结构是相互匹配的。Ojeda 说,这些工具确实存在,但它们还不能成功地对所有类型完成自动转换。这也是可以解决的。

最后,Gleixner 告诫 Rust 开发者不要改变 C 语言中锁定原语的语义;目前看来大家也没有表现出这样的倾向。Ts'o 补充说,应该从一开始就让 Rust 的锁定抽象能跟 lockdep 这个锁定检查工具配合起来。Chris Mason 插话说,如果 Rust 代码需要 lockdep,这将是该语言成功的另一个标志,是时候 “跳个舞庆祝胜利” 了。

人们经常说,将 Rust 合并到内核代码树中还是一个实验性质的动作;如果不成功就可以删除掉。Ojeda 说,为 Rust for Linux 工作的开发者们想知道试验期可能会有多长。不过,他并没有从这个小组讨论中得到切实的答案。

相反,Bottomley 建议说,与其引入 Rust,不如直接将更多类似 Rust 的功能移入 C 语言。Ojeda 说,他实际上一直在与 C 语言委员会合作来推动这些改进,但这方面的任何变动如果能够落实,也需要很长的时间。Christoph Hellwig 说,除非计划用 Rust 重写整个内核,否则这种改动无论如何都得去做;他对使用一种新的语言来重写已经能正常工作的代码的方案不是很满意。他说,也许 sparse 静态分析工具可以加强一下,从而实现更多 Rust 可以做到的检查。Ojeda 回答说,这种做法最终的效果就像是又获得了一个 Rust 一样——但时间上要晚很多。

Hellwig 继续说,可以随着时间的推移,来逐步采用类似 Rust 的一些功能。这 “必定是不如从 Rust 开始”,但内核社区现在有一个庞大的代码库需要管理。他说,需要有一种方法将类似 Rust 的语言的好处纳入所有的 C 代码中。Cook 说他一直在推动编译器开发人员来创建更安全的 C 语言。

Ts'o 在会议结束时指出,语言设计本身就是一个耗时很长的研究项目;也许我们大家应该在下一年来专注于策略问题。Torvalds 说,他希望看到各位维护者能运行一些持续集成测试并且加入 Rust 相关的测试——这个情况其实已经在进行中了。Laurent Pinchart 说,Rust 开发者需要准备好前期需要给内核社区提供支持;开发者会很快掌握一些技能,在一段时间后应该可以开始相互帮助了。Torvalds 补充说,Rust 其实并不是那么可怕的;“毕竟不是 Perl”。

当被问及文档问题时,Ojeda 说,Rust 的开发者正试图改进一些相应的 C 语言中已经完成了的文档。例如,可以让 Rust 的文档机制能很简单地就确保这些例子是可以被实际测试通过的。他们正在遵守关于应如何解释不安全区块的规则。

时间不够了,Matthew Wilcox 最后问道,内核开发人员是否应该编写地道的 Rust 代码,还是说应该写 “C in Rust”。Ojeda 回答说,这些代码在开始时可能更像 C 语言;采用更高级的功能(如 async)可能会需要更长时间。Gleixner 问,怎样才能防止开发者使用那些不稳定的特性(是说等内核使用的特性已经变成稳定特性之后);答案是指定内核开发时使用的编译器版本。

对开源的信任是一个正反馈循环。

 title=

这是我即将在 Wiley 出版的《 计算和云计算中的信任 Trust in Computing and the Cloud 》一书中经过编辑的节选,也是我之前写的一篇文章 《信任与选择开源》 Trust & choosing open source 的延伸。

在那篇文章中,我提出了一个问题。当我们说 “我相信开放源码软件” 时,我们在做什么?作为回答,我认为,我们正在做的是确定有足够多的编写和测试该软件的人与我有类似的要求,而且他们的专业知识加在一起,使我使用该软件的风险可以接受。我同时也介绍了 “ 分布式信任 distributed trust ” 的概念。

在社区内分布信任的概念是亚里士多德提出的 “ 人群智慧理论 wisdom of the crowd theory ” 的应用,其中的假设是,许多人的意见通常比一个人或少数人的意见更有明智。虽然在某些情况下,最简单的形式显然是错误的 —— 最明显的例子是民众对极权主义政权的支持 —— 但这一原则可以为建立某些信息提供一个非常有效的机制。

我们称这种集体经验的提炼为“分布式信任”,它通过互联网上的许多机制收集。如 TripAdvisor 或 Glassdoor,记录了关于组织或其提供的服务的信息,还有像 UrbanSitter 或 LinkedIn,允许用户添加关于特定人的信息(例如,见 LinkedIn 的推荐和技能与个人档案中的认可部分)。从这些例子中可以获得的利益因网络效应而大大增加,因为随着成员数量的增加,成员之间可能的联系数量也成倍增加。

分布式信任的例子还包括像 Twitter 这样的平台,一个账户的追随者数量可以被视为衡量其声誉,甚至是衡量其可信度的标准,我们应该以强烈的怀疑态度去看待这种计算。事实上,Twitter 认为它必须解决拥有大量追随者的账户的社会力量问题,并建立了一个为 “验证账户” 机制,让人们知道 “一个具有公共利益的账户是真实的”。但是有趣的是,该公司不得不暂停这项服务,因为用户对 “验证” 的确切含义或暗示的期望出现了问题:这就是不同群体之间对内容理解不同的典型案例。

那么,开源的相关性在哪里呢?开源的社区方面实际上就是建立分布式信任的一个驱动力。因为一旦你成为一个开源项目周围社区的一部分,你就会承担一个或多个角色,一旦你说你 “信任” 一个开源项目,你就会开始信任这些角色(见我之前的文章)。例如,架构师、设计师、开发人员、审查人员、技术写作、测试人员、部署人员、错误报告者或错误修复者。你对一个项目的参与越多,你就越是社区的一部分,久而久之,这就可以成为一个 “ 实践社区 community of practice ”。

Jean Lave 和 Etienne Wenger 在 《情境学习:正当的外围参与》 Situated Learning: Legitimate Peripheral Participation 一书中提出了实践社区的概念,团体在成员热情分享和参与共同活动的过程中演变成社区,导致他们的技能和知识共同提高。这里的核心概念是:当参与者围绕实践社区进行学习时,他们同时也成为社区的成员。

“正当的的外围参与既指在实践中知识技能身份的发展,也指实践社区的再生产和转化。”

Wenger 在 《实践社区:学习、意义和身份》 Communities of Practice: Learning, Meaning, and Identity 中进一步探讨了实践社区的概念:它们如何形成、对其健康的要求,以及它们如何鼓励学习。他认为,意义的可协商性(“我们为什么要一起工作,我们要实现什么?”)是实践社区的核心,并指出,如果没有个人的参与、想象力和一致性,实践社区将不会有活力。

我们可以把这一点与我们对分布式信任如何建立和构建的看法结合起来:当你意识到你对开源的影响可以与其他人的影响相同时,你对社区成员的分布式信任关系就变得不那么具有传递性(第二或第三手甚至更遥远),而是更加直接。你明白,你对你所运行的软件的创建、维护、需求和质量所能产生的影响,可以与所有其他以前匿名的贡献者一样,你现在正在与他们形成一个实践社区,或者你正在加入他们的现有实践社区。然后,你就会成为一个信任关系网络的一部分,这个网络是分布式的,但与你购买和操作专利软件时的经历相差不大。

这个过程并不会停止:因为开源项目的一个共同属性是“交叉授粉”,即一个项目的开发者也在其他项目上工作。由于多个开源项目之间的网络效应,使得对其他项目的重用和依赖性上升,导致整个项目的吸收量增加。

这就很容易理解为什么许多开源贡献者会成为开源爱好者或传道者,不仅仅是为单个项目,而是为整个开源项目。事实上,斯坦福大学社会学家 Mark Granovetter 的工作表明,社区内太多的强关系会导致小团体和停滞不前,但弱关系会使思想和趋势在社区内流动。这种对其他项目和围绕它们存在的社区的认识,以及想法在项目间的灵活性,导致分布式信任能够被扩展(尽管保证比较弱),超越贡献者在他们有直接经验的项目中所经历的直接或短链间接关系,并向其他项目扩展,因为外部观察或外围参与显示贡献者之间存在类似关系。

简单地说,参与开源项目并通过参与建立信任关系的行为会导致对类似的开源项目或只是对其他类似的开源项目产生更强的分布式信任。

这对我们每个人来说意味着什么?它意味着我们越是参与开源,我们对开源的信任度就越高,而其他人对开源的参与度也会相应提高,从而对开源的信任度也会提高。对开源的信任不仅仅是一个网络效应:它是一个正反馈循环!


本文最初发表于 Alice, Eve, and Bob,经作者许可转载。


via: https://opensource.com/article/21/1/open-source-distributed-trust

作者:Mike Bursell 选题:lujun9972 译者:MareDevi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出