LibreOffice 的起源故事，它是一个开源的办公解决方案，确保你总是能够访问你的数据并控制你的创造力。

在 2009 年初，OpenOffice.org（OOo）还是微软 Office 在个人办公生产力套件市场的主要竞争对手。这个流行的开源办公套件的社区，期待着 11 月在意大利奥尔维耶托举行的研讨会。事情进展顺利，未来看起来很光明。

可这之后，同年 4 月， 甲骨文公司 Oracle 宣布了对 太阳计算机系统公司 Sun Microsystems 的收购计划。

就个人而言，我觉得这对 OpenOffice.org 来说是个坏消息。甲骨文对开源套件没有兴趣，我料想它会放弃这个项目。当然，我更希望在研讨会上被证明是我想错了。但到最后，甲骨文只派了一名代表来到奥尔维耶托，乏善可陈，含糊其辞地谈论了货币化和品牌重塑。我和其他社区成员们都觉得，最担心的事情成真了。

那一年，社区成员从奥尔维耶托返程之后决定采取行动。是时候兑现 OpenOffice.org 项目的承诺了。我们决心创建一个独立的基金会来管理项目的资产，在社区的保护下促进套件的开发。OpenOffice.org 将不再隶属于哪一家公司，而是属于它的用户和个人贡献者们。

建立基金会

当时，OpenOffice.org 项目分布在世界各地，在语言社区帮助下进行本地化和推广，其中最主要的四个是：

• 德国：该软件诞生于德国，而且 Star Division（负责 OpenOffice.org 的部门）的总部也在汉堡，因此开发者群体和德语支持者之间沟通顺畅。
• 法国：政府支持这个开源软件。
• 意大利：我所在的小组。
• 巴西。

2010 年初，在法国和德国语言社区的倡议下，最活跃的志愿者 —— 连同一些独立开发者和 SUSE 的开发者们 —— 着手建立了一个复刻项目，旨在作为一个额外的选择，让全球社区和投资 OpenOffice.org 的企业能够同时参与进来。

我在国际商业咨询机构已有超过 30 年的工作经验了。在这个项目中负责市场营销和战略沟通。

随后的几个月里，活动越发忙碌。由于从 Star Division 传来的消息越来越负面，每周都得召开一次电话会议。

即使 OpenOffice.org 的解散似乎迫在眉睫，我们还是通过发布文章征稿（CFP）的方式，确认了位于布达佩斯的研讨会仍将举办。当然，复刻项目的成员在做的也和往年别无二致。他们提交了演讲提案并制定了旅行计划。

一个安全的文件存放处

夏初，复刻项目几乎要完成了。我们的小组在布达佩斯开会评估 OpenOffice.org 方面的境况，并召开了第一次面对面的组织会议。

布达佩斯的研讨会进行得很顺利，为期三天日程中举行了会议、主题演讲和技术研讨。一切似乎还算平常。

可其实并不平常。

当几位领头人没去参加会议的主要社交活动 —— 多瑙河上过夜巡游的时候，一些与会者开始有些疑虑了。其实我们没参加这次活动，是因为我们在餐厅开会敲定新基金会的最终细节，有太多事情要确保万无一失。我们必须定下公告日期，并且，为了协调基金会落地的各项任务，需要确定指导委员会的人员组成。

LibreOffice

从这次会议到 LibreOffice 发布间隔了三周，我们紧锣密鼓地准备。我拟好了发布策略和新闻稿，开发者们为软件做准备。应用的名字甚至是在发布的前几天的一次电话会议上敲定的，那时我在格罗塞托，正在参加意大利开源软件社区会议。

2010 年 9 月 28 日，我把宣布“ 文档基金会 The Document Foundation ”和 LibreOffice 的新闻稿分发到一个包含约 250 名记者的全球邮件列表中，这列表可是我根据供职过的公共关系机构的来信，花了很大力气整理的。

新闻稿是这样的：

开发和推广 OpenOffice.org 的志愿者社区宣布将成立一个独立的基金会，推动项目的进一步发展。基金会将成为一个新的生态系统的基石，在这里，个人和组织都可以为一个真正免费的办公套件做出贡献，并从中受益。从用户的利益出发，这将带来更多的竞争和选择，并推动办公套件市场的创新。从现在开始，OpenOffice.org 社区将被称为“ 文档基金会 The Document Foundation ”。

我们邀请过 Oracle 成为基金会的成员，并捐赠社区在过去十年中发展起来的品牌。而在他们做出决定之前，我们选择了 LibreOffice 作为即将到来的软件的品牌。

媒体界对这一公告的反应非常积极。但另一方面，企业和分析师则倾向于对由社区管理的办公套件表示质疑，这是他们从未完全理解的实体，因为这个组织很扁平、任人唯贤。

公告发布后的两周内，就有 80 位新开发者加入这个项目，推翻了那些认为“仅凭 SUSE 和 Red Hat 的开发者来启动复刻项目并不现实”的预测。不出所料，大多数语言社区都转向了 LibreOffice。

LibreOffice 是基于 OpenOffice.org 的源代码构建的。但新的功能被集成在 Go-OO Go-Open Office 的源代码中，而不是在 OpenOffice.org（OOo）上。

出于这个原因，LibreOffice 的第一个版本（于 2011 年 1 月 25 日发布）为 3.3，以保持与 OpenOffice.org 的一致性。我们认为这对于从第一个版本迁移到新套件的用户很有帮助。由于还有必须解决的明显技术债务，该软件仍有点不成熟，这导致了一些问题和不稳定。这些问题预计将基本上通过 3.x 和 4.x 版本的代码清理和重构得到纠正。到了 5.x 和 6.x 版本，源代码应该已经稳定，并有条件改进用户界面，以及开发移动和云版本。

2011 年春天，甲骨文将 OpenOffice.org 源代码转让给了 Apache 软件基金会。但该项目仅持续了三年，它的上一个新版本已经是将近十年前的事了。

未来是开放的

文档基金会的组建过程于 2012 年初结束，并于 2012 年 2 月 17 日在柏林有关部门完成注册。因为创始人希望该项目的志愿者成员们也可以根据贡献成为基金会成员，这让注册过程十分漫长。德国的法规并未考虑到基金会的这一细节，因此需要对章程进行多次修订才能满足现有状况。

基金会成立之初的前两项活动都是委员会成员的选举。这是从单纯的志愿者过渡到基于贡献的文档基金会成员所必经的规程。有委员五人，副委员三人。最后，负责在行政和战略方面领导基金会的董事会，由七名成员和三名副手组成。

2012 年底，基金会聘请了第一位雇员 Florian Effenberger，在后来他被提升为执行董事。今天，这个团队有十几个成员，他们负责日常活动，例如协调项目、行政管理、网络基础设施管理、软件发布、指导新的开发人员、协调质量保证、用户界面的演进、以及营销和沟通。

目前，基金会正在寻找开发人员满足企业客户需求，例如 RTL 语言管理和辅助功能。这些功能并不是由 LibreOffice 生态系统中的公司开发的，这些公司为他们提供功能开发服务、三级支持以及为企业需求优化的软件的长期支持版本。

在 LibreOffice 和文档基金会宣布成立已经过去 12 年之后，我们可以说，我们已经实现了开发一个独立的“ 自由和开源软件 free and open source （FOSS）”的项目目标。我们的项目是基于一个由个人志愿者和公司量力而行做出贡献的扩展社区。参与者们帮助创建了无与伦比的免费办公套件，并通过采用和发展现有市场上唯一真正的 标准办公文档格式 Open Document Format （ODF）来支持开放标准。同时，该套件也确保了与专有的 OOXML 格式的出色兼容性。

这种模式的可持续性是一个日常问题。身处于与大型科技公司的激烈竞争下，我们一直在尝试，试图在“希望一切都免费”，和“希望每个用户都能力所能及做出贡献”之间达成一种平衡。不过无论如何，LibreOffice 都会是开源的办公套件，这提供了竞争之上的额外价值。

试试 LibreOffice 吧；捐赠；不论是工作还是业余，支持它；向你的朋友介绍它！LibreOffice 是一个开源的办公解决方案，它确保你总是能够访问你的数据，并掌控你的创造力。

via: https://opensource.com/article/23/2/libreoffice-history

作者：Italo Vignoli 选题：lkxed 译者：onionstalgia 校对：wxy

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

Nilesh Vaghela 是 AWS 的 社区英雄 community hero ，也是一家云计算开源公司 ElectroMech Corporation 的创始人。据 Nilesh 说，为开源做出贡献本身就是一种有意义的事。但是它需要人们的投入和奉献，而这个过程涉及许多步骤，从选择项目到确保你的贡献成果获得关注。在与 OSFY的 Abbinaya Kuzhanthaivel 的对话中，他分享了一些关于开发人员如何帮助提高印度对开源的贡献的技巧。

问：你能告诉我们一下你目前的角色和对开源的贡献吗？

答： 我目前是一名从事自动化工作的架构师。我领导着多个团队，并且同时主要在开源安全服务平台 Invinsense 上作出贡献。我在 1998 年初创建了开源小组，当时已经有大约 1500 名成员。我现在管理的一个小组 (https://groups.google.com/g/vglug) 自 2014-15 年以来一直非常活跃。

问：你是如何开始在开源项目中工作的？

答： 我是一名有着从业资格的机械工程师，当时我在我的公司 ElectroMech Corporation 负责调制解调器和 UPS 系统。我慢慢地被拖入负责 PC、网络和 Linux 等等。1996 年，我在核科学中心看到超过 150 台计算机服务器在 Linux 上运行时广受启发，之后便开始尝试。自此我将我的公司完全转变为专注于培训和支持的开源公司。

我可以自豪地说，我是最早一批使用开源的人 —— 帮助客户了解什么是开源、它有什么好处、什么是免费的、安全或代码问题等等。我们在 Vadodara 得到了至少四五个客户，并且最终通过黄页上的广告宣传自己。我们与 Red Hat 合作并且关系一直持续到现在。

问：自那以来你认为开源发展如何？

答： 我可以说，早些时候，开源是一种令人着迷的强烈爱好，吸引人们参与其中。当一些来自西伯利亚的贡献者致力于改善水资源短缺问题时，世界各地的用户都说他们的产品有多么简单易用，这给我留下了特别深刻的印象。它更像是一项企业社会责任（CSR）活动。人们和专家创建一个委员会来管理和推进项目。人们会因为对技术的热爱而加入进来，没有任何期望。

那时我并不相信开源可以商业化，但它是当今大多数创新和技术的驱动力，而且越来越多的企业正在采用它。我们期待在贡献和使用开源方面取得很好的平衡，因为我们有个人、社区和大公司参与进来。这才是开源真正的未来和力量。

问：你可以分享一些自己遇到的困难吗？

答： 最初我是单枪匹马干，但一旦人们知道我的意图是好的，他们就会加入我。我在没有任何期望的情况下创建了很多社区，但确实在声誉或名望方面间接地获得了回报；有人理解我是技术达人，并长期给我项目。在早期，人们刚开始加入社区并且不需要付出很多精力就可以做出贡献。因为我的目标不是做生意，因此可以说我没有真正面临什么障碍。

问：作为社区领袖，你的领导格言和经验教训是什么？

答： 首先，如果你想建立一个社区，那就保持中立，不要抱有偏见。虽然看起来好像是你作为领导者正在管理一个社区，但请记住，加入社区的人都是平等地做出贡献的。永远不要让成员失去动力。在发表评论和回答问题时要有礼貌。不管是什么问题，如果你不想回答，那就选择沉默。但别让人们停止提问，而是帮助他们建立专业知识。

第二，不要让社区掺杂商业。不要让社区的目标和你个人企业的目标产生混淆和互相匹配。将它们严格区分开来。

始终尝试鼓励人们参与，而不是作为专家提供指导。如果你发现人们有兴趣领导项目并采取主动，请给出舞台让他们发挥。邀请他们参与社区活动。这将帮助你培养更多的社区领袖。此外，让你的社区保持简单，不要在初始阶段让赞助商参与进来。

问：你从谁那里得到了灵感？

答： 开源运动之父 Richard Stallman 是我的灵感来源，我一直很钦佩他的项目。

除了他之外，我还有一个有趣的事要分享，它激励着我从事开源工作。在我开始从事开源工作的时候，核科学中心的大部分软件都是基于 Windows 操作系统的。然而，许多科学家希望使用基于 Linux 的软件。在两三个月内，他们实际上创建了 Linux 驱动程序。这就是让我着迷的地方——用户可以创建这些驱动程序，这在专有软件中是不太可能发生的。我真的很喜欢开源赋权用户这一点。

问：你对印度开源格局以及改进空间有什么看法？

答： 印度是使用开源的人最多的国家（LCTT 校注：或应加上“之一”），我们正致力于成为贡献者。有这么多开发者，印度却仍然没有软件巨头。我们拥有的主要是服务提供者，而不是创新者。更多的人应该成为开源的贡献者，去开发具有国际标签的东西。

为开源做贡献的想法应该从学校和大学抓起。幸运的是，古吉拉特邦政府已经在 8 年级到 10 年级里推出基于 Linux 的课程。教育年轻一代并让他们了解开源模型很重要。

其次，我们要培养好的导师。当人们开始贡献时，找到一位在这个项目中工作的开源导师很重要。导师给出了一个小任务，尝试代码然后提交。如果一切顺利，成员的贡献会逐渐增加。不幸的是，在印度导师很少。我们需要有很多导师，或者可以与世界各地的导师建立联系。

第三是要鼓励那些踊跃贡献的人。让人们发现，一旦你成为了一位广受认可的开发人员或为开源开发做出贡献的人，你在职业发展和业务上也会有所突破。

通过遵循这些简单的方法，印度可以成为开源的主要贡献者。

问：你如何看待为开源做出贡献时编程方面的要求？

答： 根据我的经验，如果你知道计算机内部的知识，如何开发应用程序，你应该维护什么样的代码标准，以及如何管理团队和其他最佳做法，你可能不必担心编程专业知识。

在设计、安全维护和整合方面还有其他角色可以担任。看看你合适什么。通过做你喜欢的事情来不断提升加强自己的技能。如果你仍然对编码感兴趣，那么你就在其他开发人员的支持下去学习。

问：你如何确定一个你想参与的项目？

答： 你需要了解你最感兴趣的几个领域，然后对围绕这些领域发生的项目进行研究。你需要弄清楚哪些领域有招募更多志愿者的需求或职位空缺。 你可以从小处着手练习，然后积累专业知识。

避免随大流；重要的是你的个人兴趣。例如，因为现在 DevOps（开发运维一体化）的需求量很大，你便可能更倾向于选择 DevOps 项目。不要犯这个错误。

你可以在云原生基金会（CNCF）、Apache、Fedora、Red Hat 等平台上找到开源项目。通过这种方式，你还可以找到已经在从事项目并可以给出适当指导的导师。

问：每个项目有自己的目的和目标受众，有时它们甚至与开源目标不一致。那么，在开始做出贡献之前要核实什么？

答： 我同意，当有人开始一个开源项目但随后又将其商业化时，你会感到为开源作出贡献也变得颇有难度。但这样的风险总是会有的，不应让你对此感到挫败。

首先试着去了解该小组 —— 小组中的贡献者有多受欢迎，他们贡献了多长时间，以及他们的声誉如何。一旦你加入，观察每一个人和每一件事是关键。尝试至少学习三到六个月，并了解一切是如何运作的。如果你发现他们的意图不对，你可以随时离开这个项目。但如果你觉得没问题，那就继续做贡献吧。

你可以看看他们是否有某些许可证，例如 GPLv3。你还可以查看未修改的许可证版本，例如 Apache 开源许可证。

问：你觉得大公司会接受应届生投稿吗？

答： 是的，当然。公司也喜欢指导新人。他们通常不允许你直接贡献，但可能先会给你一个小任务。导师会首先尝试了解你拥有什么技能以及你的能力如何。一旦他们认可你具备所需的技能，他们将继续指导你或根据你的技能将你分配给其他导师。初始阶段非常关键。很多公司都会做一些筛选，只有在你证明了自己的能力之后，你才会被允许做出贡献。

问：贡献者在接手项目时必须克服的最初挑战是什么？

答： 首先，你应该非常认真地对待你的贡献。没有书面承诺，贡献者可能倾向于对工作掉以轻心。这种想法是完全错误的。尝试每天投入 8-10 小时或任何可行的时间。如果你因为觉得没有立竿见影的回报而不愿投入其中，那么你就不是一个好的贡献者。

在最初阶段始终严格遵守导师的指导。这对于健康的贡献非常重要。有时你可能会认为自己擅长某事，而你的导师可能不会根据该技能给你分配项目。在这种情况下只需找你的导师，问他你应该做什么，你的角色是什么，以及你可以如何贡献。

问：许多开发人员在提交项目贡献后没有得到回复。如何让自己提交的东西被人注意到呢？

答： 写一篇关于你计划作出贡献的项目的小博客，包括你喜欢的方面，你不喜欢的地方，以及可以改进的地方。这种积极的推广方式可以帮到你很多。

成为小组的一员并参与与该项目相关的活动。作为贡献的替代，首先尝试参与到团队中去，这将增加你被采纳为贡献者的机会。

一旦你对项目有了更好的了解，你的工作不仅会被接受，而且你将能够更好地适应该项目。

问：你如何克服你的贡献不被接受的情况？

答： 就是理解发生这种情况的原因有很多 —— 也许你没有在合适的项目中，或者你没有做出正确的贡献。如果项目是国家驱动的，你的请求可能不会被接受。因此，如前所述，请记得列个清单。如果你的贡献没有被接受，请不要担心，因为要么你不适合该项目，要么该项目不适合你。

我会建议尝试找四到五个项目，并且至少有一个项目会接受你所做的工作。

问：你对我们的读者有何想说的？

答： 开源是当今大多数创新背后的驱动力。让我们根据自己的能力和技能试着做出贡献，而不是仅仅使用开源。贡献可以是代码、文档、测试、博客、金钱等。是时候做出贡献了。

问：ElectroMech 公司有招人的计划吗？

答： 我们在云计算 DevOps（开发运维一体化）方面有需求，正在招聘云架构师、Python 开发人员、Linux 架构师和安全专业人员。

via: https://www.opensourceforu.com/2022/06/its-time-to-contributing-to-open-source/

作者：Abbinaya Kuzhanthaivel 选题：lkxed 译者：XiaotingHuang22 校对：校对者ID

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

平台即服务能够快速、轻松地创建网络应用，而无需购买和维护其下的软件和基础设施。本文解释了它为什么有用。

平台即服务 PaaS （以下简称 PaaS）指的是云计算服务，它为客户提供了开发、运行和管理应用程序的平台，而免去了建立和维护与开发和启动应用程序相关的基础设施的复杂工作。这是云原生应用和支持系统所依托的核心平台。

PaaS 通常包括不同的应用基础功能，包括应用平台、集成平台、业务分析平台、事件流服务和移动后端服务。此外，它还包括一套与监控、管理、部署相关的功能。

开发人员希望他们的开发环境不需要等待，而运营团队则更关心性能和稳定性。这经常引起两方间的冲突。PaaS 为这两方创造了和平的环境。一个作为服务交付的应用平台被称作 PaaS，它被用于部署用户代码。Cloud Foundry、Cloudify 和 OpenShift 这些开源环境都可用作 PaaS。

PaaS 的采用模式

云计算必须满足五个基本特征：按需服务、接入网络、资源池化、弹性和可度量的服务。为此，云计算提供了三种服务模式： 软件即服务 Software as a Service （SaaS）、 平台即服务 Platform as a Service （PaaS）、 基础设施即服务 Infrastructure as a Service （IaaS）。

业务选用 PaaS 的关键驱动力：

• 减少提供业务的资本支出和运营费用
• 通过减少应用程序的交付时间和提高开发和交付质量，最大限度地降低 IT 成本
• 增加中间件之间的灵活性和集成度

简单 PaaS：踏入 PaaS 领域的入口。它可以提供应用程序服务，并将它们暴露在自助服务的目录中；自动部署和计量服务使用的资源。

管理 PaaS：管理已配置应用程序的 服务级别协议 SLA 和 服务质量 QoS ，例如弹性、应用程序性能、安全性等。

编程 PaaS：允许应用程序与外部应用程序或公共云集成，并实现自动扩展和云爆发场景。

面向流程 PaaS：允许通过创建持续交付流程来实现 开发运维 DevOps 流程，该流程可以自动构建、测试应用程序并将其交付到云环境中。

除了这些采用模式之外，还有其他的 PaaS 变体如下，这些变化可能与上文的模式有一定重合：

集成平台即服务（iPaaS）：一套能够开发、执行和管理集成流的云服务。集成流可以是个人内部或跨多个组织连接的，可以包含任何企业内部或基于云的流程、服务、应用和数据。这些组合变化可能也符合上述的模式之一，例如 MuleSoft CloudHub 和 BizTalk。

移动平台即服务（mPaaS）：为开发移动应用提供的集成开发环境（IDE），并且支持多种移动平台。

数据库平台即服务（dbPaas）：一种按需的、安全且可扩展的自助式数据库平台，可自动配置和管理数据库。dbPaaS 使扩展数据库变得更加容易，并使它们更加可靠。

物联网平台即服务（IoTPaaS）：提供了实现异构物联网拓扑所需的通信、安全、分析和管理的通用基础架构。它为构建物联网解决方案提供了更简单、更敏捷的模型。

业务流程管理平台即服务（bpmPaaS）：一个完整的预集成业务流程管理平台，托管在云端并作为服务交付。它被用于开发和执行整个企业的业务流程和以工作流程为中心的应用程序。例如 Pega cloud 和 OpenText Cordys cloud。

PaaS 的一些基本特征：

• 在同一集成开发环境中开发、测试、部署、托管和维护应用程序的服务
• 多租户架构，即多个并发用户使用同样的开发程序
• 部署软件的内置可扩展性，包括负载平衡和故障转移
• 与异构平台和系统的集成
• 支持开发团队的协作
• 包含处理帐单和管理订阅的工具

主要的开源 PaaS

在选择 PaaS 之前，企业主要考虑关注以下几点：

• 部署灵活性
• 操作简便性
• 应用堆栈的选择
• 语言、数据库和框架支持
• 规模的可扩展性
• 服务质量（QoS）
• 开发和运营的工具
• 它有多适合你的业务

现在让我们快速浏览下流行的开源 PaaS。

Cloud Foundry：提供了多种云的选择、开发者框架和应用服务。Cloud Foundry 使构建、测试、部署和扩展应用程序变得更快、更容易。

它有不同的发行版本，其中比较流行的是 Pivotal 和 IBM。它包含应用 运行时 runtime 和容器运行时。在 Pivotal 上包含有应用服务和容器服务。

OpenShift：红帽的云计算 PaaS 产品。这是一个云端的应用平台，应用开发者和团队可以在这里构建、测试、部署和运行他们的应用程序。

Cloudify：在开放的原则下开发和设计，用以推动 IT 转型革命。它使组织能够在其上设计、建立和提供各种商业应用和网络服务。Cloudify 的最新版本为 4.3，它包含了先进的安全、控制和 真自服务 true self-service 等增强功能。Cloudify 4.3 还为 Kubernetes 容器编排引入了全新的概念。

表 1 列出了 Cloud Foundry、Cloudify 和 OpenShift 的基本功能及其对应的架构组件。以上完全基于个人观点，所支持的功能的真实需求应与云供应商进行验证。

从行业统计数据中，我们可以清楚地看出 PaaS 的使用率正在迅速上升。PaaS 使企业应用程序可以是 云无关 cloud-agnostic 的，它们可以在任何云平台上运行——无论是公共的还是私有的。这意味着一个在亚马逊的 AWS 上开发的应用可以很容易地移植到微软 Azure、VMWare vSphere、Red Hat RHEV 等等其他平台。

当多个开发人员共同参与一个开发项目，或外部用户需要与开发过程协作时，PaaS 是很有用的。因此，PaaS 尤其适合于敏捷开发，因为它降低了围绕软件快速开发和迭代的难度。

鸣谢

作者感谢 Kiran M.R. 和 Wipro 有限公司的数字架构实践 Raju Alluri 为本文提供的支持。

via: https://www.opensourceforu.com/2022/09/why-enterprises-should-opt-for-platform-as-a-service/

作者：Gopala Krishna Behara 选题：lkxed 译者：onionstalgia 校对：wxy

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

我的团队不再采用标准的算法编程笔试，而是采用一套能够产出更多相关成果的流程。

作为初创安全公司 Profian 的首席执行官和联合创始人，我参与了我们聘请开发人员从事 Enarx 的工作。Enarx 是一个处理机密信息计算的安全项目，几乎完全用 Rust 语言 编写（少部分用汇编语言）。Profian 现在已经在这次招聘找到了所有要找的人，一些开发人员将在接下来的几周内开始工作。然而，Enarx 绝对欢迎新的贡献者，如果事情继续顺利，公司将来肯定会雇用更多的人。

招聘人员并不容易，加上 Profian 还有一系列特别的要求，这让招人变得更加困难。因此我认为分享我们如何解决这个问题应该还蛮有意思的，而且也会对社区有帮助。

我们寻找什么样的人才？

以下就是我前文提到的特别要求：

• 系统编程：Profian 主要需要那些喜欢系统层编程的人。这一层面的编程已经处于栈的底层，有很多直接与硬件或操作系统的交互。例如，要创建客户端-服务器部分，我们必须编写相当多的协议、管理加密等等，而这方面的工具还不是很成熟（请参阅下面的 “Rust” 一节）。
• Rust：项目几乎都是用 Rust 语言编写的，那些不是的则是用汇编语言写的（目前只有 x86 平台，尽管随着我们添加更多平台情况可能会有所改变）。Rust 是一门很新、很酷同时也令人兴奋的编程语言，但它同时也很年轻，并且一些领域没有你想要的所有支持或者没有你希望的那么成熟 —— 这包括从密码学到多线程库到编译器/构建基本架构。
• 分散各地的团队：Profian 正在建立一个能够及时通讯联系的团队。Profian 在德国、芬兰、荷兰、北卡罗来纳州（美国）、马萨诸塞州（美国）、弗吉尼亚州（美国）和乔治亚州（美国）都有开发人员。我在英国，我们的社区经理在巴西，我们有来自印度和尼日利亚的实习生。从一开始我们就知道团队很难聚集在一个地方工作，因此我们需要能够通过视频、聊天和（最不济的情况下）电子邮件与人交流和协作的成员。
• 安全：Enarx 是一个安全项目。虽然我们并不是专门在寻找安全专家，但我们需要能够将安全放在首位去思考和工作，并设计和编写适用于安全环境的代码的人。
• Git：我们所有的代码都存储在 Git 中（主要是 GitHub，还有一些存在 GitLab）。我们围绕代码的大部分交互都是围绕 Git 进行的，因此任何加入我们团队的人都需要能自如使用它作为日常工作中的标准工具。
• 开源：开源不仅仅是许可；更是一种心态，同时，这也是一种合作方式。大量开源软件是由不同地域的人创建的，他们甚至可能不认为彼此身处于一个团队。我们需要知道我们招的人不仅能在公司内部凝聚成一个紧密的团队，同时也能够与组织外部的人员协作，并接受 Profian 的“默认开放”文化，这里的开放不仅仅限于代码，还要有开放的讨论、沟通和文档。

我们是如何找到人才的？

正如我在其他地方提到的，招聘很困难。Profian 使用多种方式寻找候选人，它们取得了不同程度的成功：

• 领英招聘广告
• 领英搜索
• 特定语言的讨论板和招聘板（例如，Reddit）
• 外部招募人员（特别致敬来自 Interstem 公司的 Gerald）
• 口耳相传/个人推荐

虽然很难从质量方面判断这些来源如何，但如果没有外部招聘人员，我们肯定会在数量上苦苦挣扎（我们也有一些来自该途径的优秀候选人）。

我们如何筛选出想要的人才？

我们需要按照上述的所有要求衡量所有候选人，但并非所有要求都是同等重要的。例如，虽然我们热衷于雇用 Rust 程序员，但那些在系统级别具有强大 C/C++ 技能的人也能成为团队里有用的一份子，因为他们能够很快掌握 Rust 语言。另一方面，熟悉使用 Git 是至关重要的，因为我们无法花时间去培养新团队成员，让他们跟上我们的工作方式。

你可能会觉得很惊讶，但强大的开源背景并不是必需的要求，在类似模式中工作的心态是必需的，而任何有开源参与历史的人都可能对 Git 有很好的了解。同理，在一个分散各地的团队中工作的能力这一条件上，我们认为有过任意开源社区的参与经历都会是个积极的指标，因为有如此多的开源项目都是由分散各地的人们完成的。至于安全这一条件，我们则一致决定这只是一个“锦上添花”的条件。

我们想让这个过程简单快捷。 Profian 没有设置专门的人力资源部门或人力职能，因为我们正忙于编写代码。以下是我们最终使用的招聘流程（实际流程中可能略有不同），我们试图在 1-2 周内完成招聘：

1. 初审：个人履历/简历/GitHub/GitLab/领英主页，决定是否面试
2. 我作为 CEO 和候选人进行一场 30-40 分钟的讨论，了解他们是否适合我们团队的文化，同时让他们有机会了解我们，并了解他们是否真的像在初审提交的材料中所说的那样精通技术
3. 由 Nathaniel 领导的有关技术方面的深入讨论，通常我也在场
4. 与团队其他成员谈话
5. 编码笔试
6. 快速决策（通常在 24 小时内）

编码笔试很关键，但我们决定不采用通常的方法。我们的观点是，许多科技公司钟爱的纯“算法编码”笔试对我们想要的几乎毫无用处：考察候选人是否可以快速理解一段代码，解决一些问题，并与团队合作完成以上的工作。我们创建了一个 GitHub 存储库，其中包含一些几乎可以正常运行的 Rust 代码（事实上，我们最终使用了两个，其中一个用于技术栈上层的人），然后让候选人修复它，在上面执行一些与 Git 相关的过程，并稍作改进，在此过程中添加测试。

测试中一个必不可少的部分是让候选人通过我们的聊天室与团队互动。我们安排了 15 分钟的视频通话时间用于设置和初始问题，两个小时用于做笔试（“开卷”——以及与团队交谈，鼓励候选人使用互联网上所有可用的资源），然后是 30 分钟的总结会议，在这个会议上团队可以提出问题，候选人可以思考任务。这个谈话，结合笔试期间的聊天互动，让我们了解了候选人与团队沟通的能力。候选人挂断电话之后我们通常会在 5-10 分钟内决定是否要雇用他们。

这种方法通常效果很好。一些候选人在任务上遇到困难，一些人沟通不畅，一些人在 Git 交互方面做得不好 —— 这些是我们没有雇佣的人。这并不意味着他们不是优秀的程序员或者以后不适合该项目或公司，但他们不符合我们现在需要的标准。在我们聘用的开发人员中，他们的 Rust 经验水平和与团队互动的需求各不相同，但 Git 专业知识水平以及他们在和我们讨论之后的反应始终足以让我们决定接受他们。

感想

总的来说，我不认为我们会对筛选过程进行大的改动 —— 尽管我很确定我们可以在搜寻过程环节做得更好。通过编码笔试，我们可以筛选掉相当多的候选人，而且很好地帮了我们挑选合适的人。希望通过了这次选拔的每个人都很适合这个项目并且产出出色的代码（以及测试和文档等等）。时间会证明一切！

本文最初发布于 Alice、Eve 和 Bob – 安全博客 上，经许可后重新发布。

via: https://opensource.com/article/22/2/how-we-hired-open-source-developer

作者：Mike Bursell 选题：lujun9972 译者：XiaotingHuang22 校对：wxy

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

作为一个开源项目的成员，你可以做很多事情来帮助新手找到为项目作出贡献的方式。

当有人刚开始为开源做贡献时，最好从对新手友好的故障和议题开始。但在他们修复故障之前，他们必须要能够找到这类问题。作为一个开源项目的成员，你可以做很多事情来帮助新手找到为项目贡献的方式。

鉴于此，AnitaB.org 开源社区 优先考虑让我们的社区做到对新手友好。我们提倡包容性，确保不同经验和水平的贡献者都可以参与进来，并且他们的贡献不止限于跟编程有关。

我最近在 Upstream 2021，即 Tidelift 活动中介绍了我们在 AnitaB.org 上所做的一些社区工作，该活动启动了“维护者周”，这是一个为期一周的开源维护者庆祝活动。在活动中我讨论了我们策略的三个主要部分：

• 我们如何沟通
• 项目和议题
• 开源项目

我们如何沟通

透明度是开源的重要组成部分，我们将透明度原则应用于我们的沟通方式。实际上，这意味着我们所有的社区会议都是公开进行的，并且影响我们设置 Zulip 聊天的方式以及我们提供文档的方式。

开放会议

任何人都可以加入我们的会议，并讨论与我们社区相关的话题。他们可以参与讨论或者旁听。会议相关信息在我们的社区日历中都可以找到。在这些通话中我们通常只使用语音聊天，我们发现这可以让人们在参与时感觉更自在。

我们举办以项目为中心的会议和一些分类的会议。会议上，来自不同领域的人们可以讨论同一个项目并帮助改进我们的流程。偶尔，我们会有“ 自由提问 Ask Me Anything （AMA）”会议，任何人都可以来问任何与开源相关的问题。

所有会议我们都会在共享文档中进行记录，并在 我们的 Zulip 中共享摘要和文档链接。

我们的 Zulip 聊天

开源 Zulip 聊天平台是我们的主要社区交流渠道，虽然我们也在 Github 的评论区讨论议题和 拉取请求 Pull Request （PR）。一般来说，我们禁用了私人消息以确保我们尽可能透明。对于这条规则，我们只有少数例外，那些私人聊天是管理员在处理我们运行程序的后勤工作所用的。我们发现这种方法更受欢迎，它还使我们能够更清楚公共聊天中的违规行为。

我们在 Zulip 聊天室分享所有会议摘要，包括讨论的要点、行动项目和文档。这些听起来好像是些显而易见的要求，但我一直惊讶于很多开源项目并不提供会议笔记，所以 Zulip 可以让那些没有参加会议的人也随时了解情况。

在 Zulip上，我们讨论项目路线图，回答社区的问题和疑问，并积极促进人们通过不同的方式方法和在不同的场景下做出自己的贡献。有时我们为贡献者的成就而庆祝 —— 无论是为了突出他们测试或者审查的第一个拉取请求，还是强调我们志愿者所做的出色工作。

文档

我们尽量保持关于我们流程的开放文档，例如常见问题解答，以便这些社区成员可以按照自己的节奏和时间了解社区。这是为了让他们在联系我们之前了解我们的工作方式以及我们从事的工作类型。

项目和议题

关于我们的项目和议题管理，我们鼓励通过多种方式做出贡献，我们为新手专门创建特定的议题，并尝试让项目的设置变得简单。

多种贡献的方式

我们努力创建需要不同贡献的问题，例如文档、测试、设计和外展。这是为了让任何人 —— 无关他们的经验水平和兴趣领域 —— 都能做出贡献。这样能够帮助社区参与进来，而且我们发现它使成员能够从一些省力但有价值的任务开始一步步做出贡献。

我们提倡的贡献类型有：

• 不同复杂性的编程任务。
• 质量保证任务 —— 贡献者可以测试我们的应用程序或拉取请求并报告错误。
• 社区成员可以参与讨论的设计会议。此外，创建模型和重新设计我们应用程序某些部分的机会，并探索改进用户体验。
• 外展任务，我们主要在 Zulip 上推广，我们建议在我们的 Medium 出版物上发表博客，介绍他们的开源经验和他们的贡献。
• 文档任务，可以包括一般社区文档或我们在 Docusaurus 上的项目文档。

仅限新手的问题

我们将一些议题标记为“仅限新手”。这些问题适用于尚未为议题存储库做出贡献的人。为议题做标签还使我们能够让人们在贡献者大量涌入时开始他们的开源之旅，例如，在 谷歌编程之夏（GSoC） 申请期间。

有时，这些可能是“唾手可得的果实”，可以让他们熟悉作出贡献和提交拉取请求的过程。

简单的项目设置

我们也很在意为我们的项目提供新手友好的安装设置。我们注意到最活跃的项目通常是最容易设置的。我们知道，为你不熟悉的项目做出贡献可能需要付出很多努力并且关乎贡献体验的成败。

我们尝试提供有关如何在多个操作系统上运行我们项目的说明。在过去，我们有一些项目有单独的说明，可以在 Unix 环境下运行，我们注意到贡献者在 Windows 上运行这些项目有些困难。自那以后我们不断进行改进，以避免贡献者在 Zulip 上寻求帮助时出现混乱。

我们根据贡献者的经验，一直在改进我们最活跃的项目之一 mentorship-backend 的自述文件。新手在这个项目中遇到的困难之一是设置与配置电子邮件帐户相关的部分环境变量，以使后台功能能够发送电子邮件。但是，由于此功能对于本地开发并不重要，因此默认情况下，我们将电子邮件设置设为可选，以便将电子邮件打印到终端，而不是发送给用户。这种方法仍然使贡献者可以看到这些电子邮件。与此更改类似，我们将 SQLite 数据库 作为本地开发的默认设置，以避免对 Postgres 数据库进行额外设置，虽然我们在部署版本中会使用到 Postgres。

我们注意到，一些贡献者在为我们的 bridge-in-tech-backend 项目做出贡献时觉得很困难，该项目的设置很复杂，并且包含的步骤比 mentorship-backend 多得多。自从我们在一个开源项目中注意到这一点以来，我们一直在探索如何改进其结构。

对于我们的大多数项目，我们还提供应用程序的实时体验版本或打包版本，以便贡献者无需设置即可测试项目。这有助于我们为那些对开发设置不感兴趣或不熟悉的贡献者提供一种方式，来尝试我们应用程序的最新版本，并通过报告发现的任何错误来做出贡献。我们在 质量保证指南 中放了这些应用程序的链接。

开源计划

我们在社区中组织了两个主要计划：开源黑客（OSH）（一个为期一个月的项目）和 Open Source Ambassadors（一个为期六个月的项目）。

开源黑客（OSH）

在此计划中，我们在多个类别的贡献中创建议题 —— 文档、编码、外展、测试和设计（类似于 谷歌的 Code-in 竞赛）。 参与者可以为每个类别至少贡献一次并获得电子证书。一个议题可能包含多个类别，并且无需合并拉取请求也能使贡献有效。

我们为这个计划选取几个项目，请导师们集思广益为参与者创造议题。项目开始后参与者可以认领议题并开始作出贡献。导师们会支持帮助并审查他们的贡献。

这种方法鼓励贡献的多样性，并欢迎任何人，无论他们的编码能力如何，都可以在友好和不怕出错的环境中做出贡献。

开源大使

在此计划中，我们从社区中选择大使，理想情况下他们将涵盖我们旨在促进的每一类贡献。至今该计划已启动了两次。

该计划旨在让成员通过回答社区的议题、协助贡献者参与并为他们指定的类别宣传来帮助管理项目和计划。

第一个计划举行时我们接受了所有的申请者。我们评估了社区成员的兴趣所在，并为那些想要做出贡献但最初不敢踏出第一步的人提供了一个体系。

第一个计划的举办给了我们很多启发。因为我们的活动中既有经验丰富的开源贡献者和社区成员，也有初来乍到缺乏经验的新手，因此项目的执行要求管理员进行大量的管理工作。一些社区大使信心十足准备好进一步采取新措施，而其他大使则需要更多支持。到了第二个，我们决定缩减该计划，只接受那些已经熟悉社区、可以领导倡议和项目并帮助我们培训新人的贡献者。

第二个计划中形成了正反馈循环。那些在第一个计划中还是新手的大使们，通过为上一个项目做出贡献并且从项目经验中学习之后能够做到轻松带领项目。

这种方法的改变使管理员能够更加专注于支持大使团队，帮助他们传播我们的使命，并继续让我们的社区对新手友好，并指导更多人做出贡献。

总结

这些计划帮助我们提高了对开源贡献和回馈的不同方式的认识。通过它们，我们发现志愿者通过管理项目和举办公开会议来提供帮助，这有助于管理社区并为我们的贡献者提供指导。

尽管我们得到了贡献者的良好反响，并帮助人们做出了他们的第一个贡献，但我们仍有很大的改进空间。我们将继续改进我们项目的设置和贡献指南，以改善贡献者的体验。我们还将继续专注于确保我们的组织始终拥有并推动不同类别的问题，促进包容性，以便任何有意愿做出贡献的人都能出自己的一份力。

via: https://opensource.com/article/21/8/beginner-open-source-community

作者：Isabel Costa 选题：lujun9972 译者：XiaotingHuang22 校对：wxy

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

体验为开源做出贡献的快乐。

难以用言语形容我在收到合并通知（如下图）时的喜悦，当然这要归功于现在我上的工程学校 AltSchool Africa。

在此之前，我曾多次接触过开源的概念，了解了它在技术领域的重要性，甚至参加过开源会议（比如 OSCAFest）。我曾多次跃跃欲试，但当打开 GitHub 来想创建些东西时，冒名顶替综合症就会冒出来。

时间来到 2022 年 8 月 8 日星期一，当观看了 Bolaji 为开源做贡献的视频之后，我重新振奋起来。不过，想要把我学到的东西付诸实践，我注意到需要下面几个步骤：

步骤：

1. 我要下定决心，做好为一个开源项目做出贡献的心理建设。
2. 我要根据我的技能水平进行筛选，我从一个站点（Good First Issues）寻找我开始的第一个项目。我不停地往下翻看，直到找到了一个符合心意的项目。
3. 我要确定自己掌握完成项目所需的 Git 和 GitHub 知识。

LCTT 译注：

“Good First Issues” 这个网站主要是针对那些想为开源软件做贡献，但不知道从哪里开始或如何开始的开发者。通过为开发者提供过滤器，该网站使他们能够根据自己熟悉的编程语言来浏览和选择问题和存储库。此外，他们还可以选择他们想要解决的问题的类型。

项目

经过长时间查找，我终于找到了一个名为 确保没有缺失的 alt 属性 的项目。我所要做的，就是为网站上的图片提供描述性的 alt 值。图片的 alt 值有助于提高网站的辅助功能，这样屏幕阅读器就可以向视障人士提供图像的详细描述了。这很简单，对吧？是的，但假如我没有下定决心想要作出贡献，我就不会找到这项目，在我心中开源仍将是个神话。

我心潮澎湃，直到发现这个项目是来自 MDN 的。等等， MDN Mozzila 开发者网络 ？干和 Mozilla 的开发者一样的事儿？他们会合并我这么小儿科的贡献吗？冒名顶替综合症 又开始了。

在检查这个议题时，我看到有人已经在提交贡献了，于是我鼓起勇气开始翻阅项目的内容。阅读和理解这个项目颇花费了我一些时间，而另一个要克服的，就是清楚处理这个议题我要怎么做。

这个项目就像你想的那么简单。

于是，我挑选了两幅图片着手尝试。我给它们的 alt 属性赋值，提交我的更改，然后发出拉取请求。从提交请求到收到批准邮件的这段时间，我充满了自我怀疑。我要不要关闭拉取请求？这可是 MDN 啊。好吧，这甚至都不算编程…… 如果请求没有被合并怎么办？我恐怕再也不会想为开源做出贡献了。不过，所有的疑虑都在我看到审阅者发来的这些邮件时烟消云散：

我喜出望外，这激发了我去检查更多图片的热情，也给了我发请求解决其他议题所需的勇气。

总结

我希望你能从这篇文章中感受到以下几点：

• 开源是面向所有人的。你在刚刚访问的那个网站上看到拼写错误了吗？你帮助订正了拼写错误，这就是为开源做出了贡献。
• 没有任何技能是微不足道的。如你所见，我所做出的贡献，只需要对 HTML 最基本的了解。
• 能阻止你做出贡献的只有你自己。
• 要想让雪球滚起来，需要做的就只是提交第一个贡献。

我衷心希望你能从我的经历中获得什么，并且今天就付诸实践。这也就是我想贡献的另一个领域，那么，我们下一篇文章见，也祝你开源愉快！

这篇文章最初发布于 我的第一个拉取请求被合并，并经许可转载。

via: https://opensource.com/article/22/9/first-pull-request-merged

作者：Oluwaseun 选题：lkxed 译者：onionstalgia 校对：wxy

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