> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20200910-gong-xian-yu-ru-men/we-get-letters.md).

# 读者来信

* 原文链接：[We Get Letters](https://freebsdfoundation.org/wp-content/uploads/2020/11/We-Get-Letters.pdf)
* 作者：**Michael W Lucas**

> 噢，勇猛无畏、一无是处的来信专栏君：
>
> 我用 FreeBSD 之类的开源软件好多年了。它改善了我的生活，我想回馈。但我怎么都找不到切入项目的入口。要么我的贡献被无视，要么我的技能对不上号，要么我的工作被驳回。我彻底卡在了门外。我怎样才能帮到我钟爱的项目？
>
> ——渴望却迷茫

亲爱的渴望却迷茫：

我都拿不准你是觉得我连“feckless”（一无是处）这个词都不认识，还是觉得我会认出这话的真理而欣然接受。说明一下，是后者。

我猜你中了系统管理员铁律第 17 条：你在解决错误的问题。

看着一个大型开源项目说“哇，噢，我也想干这个”很容易。看着职业滑板手、橄榄球员、笼斗士说同样的话也容易。你想成为某种特定的大人物。你把自己想象成数字版的 Samuel L. Jackson 或 Jason Statham，这幻想或许让你愉悦，但幻象遗漏了一个微小、次要、细若游丝的细节。

成为大人物要付出大量努力。

滑板手得脸朝下摔好几年，才能玩出那些花哨动作。笼斗士得连续多年挨拳、挨踢、挨内裤勒裆，才能赢下比赛。橄榄球的事我们就别提了。

技术界的大人物之所以达到那个技艺水平，是因为花了数十年被编译器错误打脸，被穿着钉靴的 bug 踹，被任性、无效、彻头彻尾胡扯的技术变更淹没。许多站在开源金字塔尖的人，名字后面还缀着额外的头衔，比如“博士”、“Snobby McSnooty 计算奖”或“不知名的黑客”之类。

你是瘫在沙发上看橄榄球，巴望着自己也能上场？还是每天都在举铁、跑马拉松、每顿饭前拿圆头锤狠敲自己最娇嫩的部位，好为加入酒吧球队、一步步往上爬做准备？

扪心自问。然后从三条路里挑一条。

第一条，“放弃”，不值得浪费我的时间和注意力。你完全够格在无人指导下自行实施。

第二条路是改变自己。想成为下一个 FreeBSD 大人物，就付出成为大人物的努力。你会用 C 写程序吗？不会就去学。是的，Perl、Smalltalk、Fortran 这些花哨语言尽享荣光，小屁孩还喜欢某种以蛇命名的怪玩意儿，但这个项目的语言是 C，他们不会为了迁就你的偏见而改弦更张。想开发 Haskell 内核，去加入别的项目。我保证你会有大把选择。

学一门编程语言最好的办法，是想用这门语言去完成某个任务。

聪明人会从 bug 数据库入手。找你能用自己的系统复现的 bug。复现它们，联系报告者获取更多信息，开始深挖。开发解决问题的补丁。你会赢得社区的尊重。

也许你不想收拾别人的 bug。你想干点惊天动地的大事。大型开源项目不在于从零开始写令人兴奋的新组件，而在于缓慢演进。大项目确实会发生，但它们落到社区里受尊重的人手里。你当然可以试试。

回到上世纪，我系统管理员生涯早期，发现自己需要一个能递归抓取的 FTP 客户端。虽然当时已有三四个 FTP 客户端——其中一半还算能跑——但要是 FreeBSD 2.x 自带的客户端有这功能，我的日子会好过得多。我想磨砺自己的 C 功底。我已经读完了 Kernighan 和 Ritchie 的《The C Programming Language》第一版，还写过几个伪装成软件的小型缓冲区溢出。当时的陈词滥调是开源就是抓痒——好，我有痒，那就该自己来挠。

我开始读源代码。

再读源代码。

然后我把 **ftp(1)** 的源代码打印出来，钉在家里的办公室墙上，用几种颜色的荧光笔、红笔、绿笔上阵，标注我那点不够用的脑仁认为重要或相关的代码段，把零散的函数串联起来。那场面活像阴谋论者的软木板，上面全是线绳相连——只不过它确凿无疑地真实存在，而且每次我一碰其中任何一处，整个结构就轰然坍塌。

要是当时我肯花时间就这小项目问问任何一位 FreeBSD committer，他们大概会把我引向更现实点的事，比如杂耍剑齿豪猪。或者至少劝我穿上防护装备，挡一挡那无可避免的圆头锤。我学到了海量的 C 知识。我学会了处理内核转储。我也真切体会到自己的编程水平有多不够看。

我本可以成为一名程序员。我要做的就是继续砸这个问题。

几个月绞尽脑汁之后，我把除打印件之外的所有东西都搬出了办公室，搬出了那栋房子，只盼新房客比我聪明，从此与互联网绝缘。

我选了第三条路。

你大概在某方面有点技能。在你活过的这些年里，你一直在呼吸，维持着基本的消化功能。考虑到人类历史上大多数人如今都已不在人世，你这成绩已经相当不错。

拿你会做的事，去为你的项目做。

也许你喜欢帮别人解决你已经踩过的坑。每个项目都有正式或非正式的支持渠道、邮件列表、论坛之类的。泡在那些论坛上，帮人解答。

你知道谁会得到开发者的赞许和喝彩吗？测试者。

发布日之前，下载发行候选的安装介质。列一张所有安装程序选项的清单，按部就班全部测一遍。报告错误。

要是你出于某种精神错乱想干点更程序员的活，那就学学怎么写和用软件测试。

如果你的工作涉及软件某个奇怪的边缘地带，写写博客讲讲你在这个边缘的经历。或者给 wiki 涂几笔笔记。也许你属于那种真正不幸的人——会写字。眼下你无需采取任何进一步行动，但别担心。秘密小分队马上就会带着电击枪和网兜上门。别挣扎。挣扎也没用。

要点是：做你会做的事。但为 FreeBSD 做。

改变你做的事也无妨。花时间帮其他用户让他们的日子更好过。花时间记录如何调优文件系统、却不能 tuna fish（tune a fish 谐音梗）也同样如此。我花时间系统研读源代码，提升了我读代码的能力，今天我依然靠这本事吃饭。社区层面上，人们会记得你。

确切地说，他们会记得你工作的质量。他们会以你过往工作的质量所配得的严肃态度对待你。

你没法硬挤进一个社区。开源不是这么运作的。它不是街区派对，住对门就放你进去。进入开源社区的唯一途径是完成高质量的工作。你要是能做到这点，就不必为挤破门而争斗。越来越多的社区成员会朝你系上一根根社交绳，直到你发现自己已被判处这个社区的终身监禁。有人会贿赂你接下社区里最烂的活，就因为你把那类任务做成功有口碑。

什么样的烂活？你知道的，比如给社区期刊写读者来信专栏。

有问题想问 Michael？ 请发送至 <letters@freebsdjournal.org>

**MICHAEL W LUCAS**（<https://mwl.io>）最新出版的图书是《SNMP Mastery》和《Terrapin Sky Tango》。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20200910-gong-xian-yu-ru-men/we-get-letters.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.