合适吗?4 个开源项目评估

目前还没有读者喜欢这个。
open here

Opensource.com

您如何找到合适的开源项目来参与? 这是一份指南,基于我寻找合适项目的旅程。

在该指南中,我写到了通过撒网式研究来做功课,然后评估你自己(你的技能、你的目标和你的时间)。在这个寻找合适项目的评估中,我审视了自己的动机和技能,列出了目标清单,并列出了一些目标项目。因为这不是我的第一次尝试,所以我认真审视了自己的过往记录。我可以从那些没有坚持下来的项目中吸取什么教训,从而找到一个能够坚持下来的项目?我注意到我可以避免的模式,并了解它们如何与我的新目标和技能清单相符。然后,我评估了四个开源项目及其社区,看看它们是否适合我。在最后查看获胜者!

我的过往记录

Fedora 基础设施

几年前,我加入了 Fedora 项目,成为一名贡献者,但没有做这次评估工作。结果显而易见。我加入的理由是正确的,我想回馈我使用的项目,但我没有先弄清楚我能提供什么。我最终试图找到一个突破口,但不是很成功。在四处打探后,我加入了基础设施团队,但虽然我在工作中有一些时间可以使用,但很难应用它们。

问题:没有获得进展,因为我没有找到合适的定位;因此,我没有管理好我的时间和期望。

Spaceclone

我花了很多时间使用 Red Hat Satellite,并在开发者和用户列表中查看上游 Spacewalk 项目。有一次,列表上发布了一个关于管理通道和生命周期的新工具的公告。这是一个我遇到过,我的客户也遇到的问题,所以我认为它很有趣,并看了一下。我用 Python 编写了代码,托管在 GitHub 上,并且很容易深入研究并编写一个新的用于缓存身份验证令牌的功能。这对我来说有些挑战,早期版本中存在一些糟糕的列表推导式,但进展顺利。直到我们都忙于日常工作。你看,我们只有两个人。两个忙碌的人无法成就一个成功的项目。

问题:贡献时间和项目健康问题导致项目停滞。

Liquidprompt

在我的日常工作中,我今年花了很大一部分时间与 OpenShift 打交道。我遇到的其中一件事是在开发应用程序时保持 Python virtualenvs 和软件集合的整洁。为了解决这个问题,我在 GitHub 上查看了未解决的问题。那里有相当多的活动,他们有贡献策略,主要的维护者很快就处理了我的拉取请求,所以这看起来是一个健康的项目。因此,我为问题列表上的一个增强功能提交了另一个拉取请求,但没有其他东西真正引起我的兴趣。

问题:进展仍然来自参与;如果你对问题领域不感兴趣,你可能不会继续回来。

Netflix OSS

在 OSCON 大会上,我参加了 Netflix 的好心人关于他们的一些 OSS 工具的教程。我的配置与预期的设置略有不同,所以我做了一些额外的工作来使示例正常工作,并在 GitHub 上提交了一个拉取请求。该拉取请求仍在等待审查。

问题:虽然“欢迎补丁”,但这可能真的不是像我这样的人的项目。我们可能会在内部使用它来研究一些东西,但它实际上只对 OSCON 有意义,我错过了目标。

从这份历史清单中得出的主要结论:为了获得进展并继续贡献,我需要对项目领域感兴趣,找到时间,并确保我选择的项目积极接受公众的意见。我已经通过我的公司解决了时间问题,所以现在的问题是兴趣和项目健康状况。

何去何从?

好的,你已经看到了我的开源软件 (OSS) 历史中的好、坏和丑陋。到目前为止,已勾选的框是
    •    时间 = 与 $DAYJOB 对齐,处理了公司知识产权问题
    •    技能 = BASH、Python、架构、文档
    •    目标 = 磨练技能,真正的信徒

现在是时候用我构建的新视角来看待一些项目了。我检查了四个项目的健康状况和良好运行,它们可能非常适合我。

投入新项目

OpenStack

这个项目绝对符合目标。OpenStack 的大部分是用 Python 编写的,肯定会促使我扩展我的技能。我在各种会议上见过一些社区人士,并且知道有很多种贡献方式。潜在的问题之一是这是一个非常庞大的项目,因此,以较低的技能水平找到突破口可能很困难。此外,我协商的时间量可能不足以做出有意义的贡献。但是,它还是被列入清单。

评估: 我对 OpenStack 的最初印象得到了证实。有很多项目让我更容易尝试找到突破口。该项目有一个非常全面且易于查找的新贡献者指南,无论他们是开发人员、测试人员、编写人员、UX 人员、安全专家等等。他们使用 launchpad 中的标签来标记简单的错误,以帮助编码人员找到入口点。邮件列表和我找不到可以尝试突破的入口点。考虑到我拥有的可用时间以及即使是简单的修复工单也相互关联的性质,我认为我无法在这里取得任何进展。因此,尽管说“我在 OpenStack 上工作”很酷,但我现在要把它放在一边。

OpenShift Origin

对于我来说,这个项目绝对是一个真正的信徒项目,并且由于使用过这些工具,我可以看到一些我可以解决的功能。查看问题列表,我的功能不在那里,因此这可能是一项艰苦的“提交”,并且该项目主要使用 Ruby,因此存在相当陡峭的学习曲线。

评估: 我对 OpenShift Origin 的最初印象不太准确。向 CLI 添加新功能可能没有那么困难,因为在 OpenShift Online 的支持区域中有一个公开的想法提交页面。找到社区的入口点有点困难。贡献者页面侧重于添加 cartridges(新的框架和语言选项),而不是处理核心代码。我只是根据分配给每种方法的数字空间量来判断的。一旦你深入挖掘,就会有一些很好的资源,其中包含联系团队和使用工具的方法。前面也有编码指南和方法论文档。话虽如此,我拥有的时间和质量就发挥了作用。学习 Ruby、OpenShift 最佳实践以及创建和倡导新功能都需要比我拥有的可用时间更持续的努力。不幸的是,我的新功能可能会被丢弃在公共想法板上,并被孤立。

Fedora 基础设施

自从我第一次尝试参与 Fedora 基础设施以来,那里的团队在让人们更容易参与方面取得了巨大进步。有一个学徒计划和一些“简单修复”工单,所有这些都是为了让新人快速上手。我已经有一些联系人和渠道,并且社区习惯于与贡献时间“不稳定”的人员合作。我可以在这里做很多事情并学习很多东西。

评估: 由于我之前参与过基础设施团队,我已经加入了邮件列表,我已经将 IRC 频道添加为书签,并且我知道如何使用 Trac 并与团队合作。新的学徒计划和简单修复工单为指导系统提供了一个很好的入口点。该团队处理许多不同的事情,从运行镜像和内部云到开发内部应用程序。他们从事的事情在我的能力范围内,我可以找到一些有趣的事情来做。上次我失去了进展是基于我对时间的运用,这是一个常见的主题。根据我的日程安排,我会回到我可以按照自己的节奏工作的事情上,作为基础设施团队的一员,我想成为一名稳定的贡献者。请注意,这是我的感觉,但我确信团队不介意参与中的小差距。

Project Atomic

现在谁没有关注 Docker?而且,Project Atomic 正在构建一个非常有趣的容器托管平台。Project Atomic 有点像 OpenStack,因为有一些不同的上游项目 Atomic 依赖于它们才能成为 Atomic。这些项目中的任何一个都有自己的贡献路径,添加到 Project Atomic 的贡献路径中。这里还有一个小小的个人使命,因为网站上的文档存在一些漏洞。如果项目难以评估,那么它的整体健康状况可能会受到损害。开源项目既需要好的代码,也需要好的文档。对于一个项目的新用户来说,最令人沮丧的事情莫过于听说一个很棒的项目,获取了代码或二进制文件,然后却完全没有用户文档来尝试开始使用它。自我记录的 API 手册页是不够的。

评估: Docker 是新晋的酷孩子,而 Project Atomic 则更新。它还没有完全准备好迎接黄金时段,但很容易成为一个稳固而充满活力的项目。很容易找到社区联系页面,其中包含您开始贡献所需的所有信息。那里有指向他们使用的上游的链接、公共 Bugzilla、IRC、邮件列表等。不幸的是,并非所有文档都很好。其中一个贡献渠道中存在一个循环链接,入门资料也很糟糕。这可能是我开始的地方,而不是尝试贡献代码。像演示和实验室这样的文档是我现在正在做的工作,它是相当异步的,它可以改善项目的形象,以吸引更多的用户和贡献者。

胜者,胜者,今晚吃鸡

开始使用 Project Atomic

首先,我将查看项目页面关于贡献文档的说明。这看起来像最近流行起来的“fork-and-go”贡献风格。我可以从那里开始,并确保我可以设置工具,并且在进一步深入之前了解基本风格。

文档主要采用 Markdown 格式,因此不应该有任何问题。我不懂 HAML 或 Middleman,所以这可能会使事情复杂化,因为我懂 Ruby。HAML 是 ERB 的替代品,因此这可能不是问题。我们将不得不看看事情的进展情况。一种我不熟悉的标记语言的替代标记语言意味着它只是一种新的标记语法。并且 Middleman 服务器有一个 Dockerfile,所以我不需要担心学习服务器。

任何地方都没有大的危险信号,所以我将继续 fork GitHub 上的网站项目,以便我可以开始在本地进行研究。现在,我不想在没有与团队联系并了解当前文档计划的情况下就开始埋头苦干。这是关于社区贡献,而不是我朝着一个方向跑偏,并在真空中展示我对文档的“新的更好的修复”视图。贡献页面上列出了一个开发者邮件列表和一个 IRC 频道,这就是我的起点。

我弄清楚谁拥有文档,向团队发送一封电子邮件,说明我将进行查看,并提交一个简单的更新的拉取请求。然后,一旦该拉取请求获得评论或被接受,我将提交一个更大的图景,说明我认为文档应该是什么样子。

如果您想在我前进的过程中关注我,您可以查看邮件列表和我的 GitHub 存储库。请随时让我保持诚实!

User profile image.
Matt Micene 是 Red Hat Linux 和容器的布道师。他在信息技术领域拥有超过 15 年的经验,范围从架构和系统设计到数据中心设计。他对容器、云计算和虚拟化等关键技术有着深刻的理解。

评论已关闭。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 许可。
© . All rights reserved.