本文由 SpiderFoot 开放源码工程项目作者编写，撷取了他从这一工程项目中汲取的 10 个实战经验。InfoQ 英文站译者并撷取。

在往后二十年中，我合作开发了这款开放源码情报部门（Open Source Intelligence，OSINT）工具，名叫 SpiderFoot。这是一类能手动地对达维季夫卡管理和严重威胁情报部门进行搜集和分析的 OSINT 工具，由 Python 编写，适用于于 Linux、*BSD 和 Windows 系统。机能方面，通过 SpiderFoot 我们能获取有关目标的各式各样信息，比如中文网站并集、电子邮件地址、Web 服务器版之类。除此之外，它还为用户提供了两个更易采用的 GUI 介面。

在这二十年中，SpiderFoot 在我的心灵中占有了非常大的占比。我基本上每晚傍晚和半夜都在“工作”，我也经常和丈夫、小孩和朋友们探讨 SpiderFoot。它给我增添了很多欢笑，但有时也会增添不安全感。

因此，我真的是这时候回过头来回去深思，并把自己多年来学以致用和汲取的经验教训都概括出来。我之因此那么做，再者是所致我对个人的利益，另再者也是希望能对那些在自己的开放源码工程项目上有相似历经的人略有帮助。

迄今的旅途

在 2005 年，我编写了两个 SpiderFoot 的如上所述同时实现，并将其作为一类自学 C# 的方式。在我发售了第一个软件包后，它在 SourceForge 的“0.1b 版”逗留了 7 年，直至 2011 月底，我开始采用 Python 再次编写 SpiderFoot。因此，如果你要考虑到这段时间，SpiderFoot（最少是两个中文名称和概念）已经有整整 20 年的发展史了。

上面是 C# 版时的模样：

上面是 SpiderFoot 的新一代版，它是这款如前所述 Web 的 CLI 工具，由 Python 编写：

那么，为何首次发布的版与 Python 重写版之间会有七年的鸿沟呢？

原因在于，我的初衷是要学会用 C# 合作开发两个实用的工具，并将其推广出去，我做到了。但当时我并没有长远的规划或者扩张的打算，只是“完成了”。这对当时的我来说是能理解的。因为那这时候，我还在工作中做了一堆有趣的工程工程项目，因此我也不真的有必要在业余时间合作开发什么东西。

在那些年里，我没有意识到的是，这款小小的一次性工具其实非常受欢迎。SpiderFoot 在图书和培训课程中都有涉及，它的下载数量大约为每周 500 次，虽然不算多，但也算不上微不足道——尽管由于数据源的消失，这款工具的某些机能已经不再工作了。

我在正式工作中担任了几年不同的管理角色后，终于回忆起当时刚做 SpiderFoot 的感觉，甚至真的还缺点什么。现在回忆起来，我错失了用创造的方式来自学的机会，直至我的全部工作都被会议、PPT 和电子邮件吞噬。

这让我开始思考，我在闲暇之余能做点什么。我知道我想学 Python，从事数据搜集和分析，我希望能在安全方面略有建树，因为我已经在这个领域工作了 20 多年。

这样来看，SpiderFoot 依然满足以上所有的要求。因此在 2011 月底，我又另起炉灶，学了很多 Python 的技术，然后继续向 GitHub 仓库推送两个又两个提交，一直至 2013 年 5 月，我发布了 SpiderFoot 2.0 版。

是的，我用了一年左右的时间来提交，直至我感觉足够舒适了，能发布两个新的版，然后对外公布。这是我学到的两个实战经验。

在第一次提交后的二十年中，我一直在摸索，并且逐渐熟悉了 Python，把 SpiderFoot 从几个模块（用 SpiderFoot 的行话来说，是指搜集或分析 OSINT 数据的组件）发展到 200 多个，吸纳了很多社区的重大贡献（尤其是 _bcoles），并最终同时实现了以 SpiderFoot 为基础，创立一家成功的企业。

以下是我积累到的 10 个实战经验，希望能对你略有帮助。

实战经验一：编写开放源码软件能在你无法预测的情况下获得巨大的回报

编写开放源码软件并不仅仅是把代码放在那里供别人采用。当然，从本质上讲，这就是它背后的过程，采用该软件的人免费获得了某些东西（但愿能有用）。以下是我从 SpiderFoot 工程项目获得的回报清单：

听到用户说那么多年来，SpiderFoot 确实为他们提供了帮助，并向我表达出感激之情。这也许是最有对个人价值的，也是最有动力的。 我现在是一名程序员和总工程师，比起刚起步的这时候要好很多，因为一路上有很多来自像 _bcoles 这样的人的反馈。这能帮助我在日常工作中，以管理者的身份与工程师共同工作，并且把从 SpiderFoot 那里学到的技能和知识融入到我的日常工作中。 SpiderFoot 工程项目对我的工作和演讲起到了非常大的推进作用。 这是两个非常好的平台，能让我认识并接触到那些真正有才华的人，在很多场合下，我能立刻获得信誉，即便人们并不知道我是谁，但是他们知道 SpiderFoot。 它让我看到了 SpiderFoot HX 增添的商机，并埋下了这个机会的种子。 长期的持续投入，提高了产品质量，并使上述的积极作用得到增强。

除此之外，SpiderFoot 还增添了一些私人或间接的好处：让自己更加自律，改进时间管理，寻找增强精力和身体健康的途径，之类。

实战经验二：要长期坚持下去

两个工程项目之因此成功，是因为它能经得起时间的检验，并且比其他工程项目要好。如果你一直在努力改进工程项目，那么它就会得到关注和利用，而不会像那些只是昙花一现的应用一样，最后被淘汰。

没有人会要求你每晚、每周或每月都要提交，但是你要努力保证当你的依赖性改变时，你的软件仍然能正常工作。还要留意所报告的问题，如果这些问题涉及的范围很广，那么就需要重视。

实战经验三：交付，并定期交付

这二十年来我一直都有很多遗憾。比如，我应该一开始就在单元测试、代码文档和代码品质方面投入更多的精力。但是我也明白，如果我在把 SpiderFoot 投放到公众之前，就花费大量的时间去自学和同时实现，把它变成两个好的产品。那么，成千上万的人就不会采用到 SpiderFoot，也就不能获得他们所拥有的价值。因为在这期间，我也许会因为情绪低落或者心烦，而完全放弃交付。

记住实战经验二，放心吧，你会有更多的时间去完善它。只要每周留出几天的时间，你就能静下心来，去打造一些伟大的东西，并且保证你的产品能正常运行。你必须时不时地做出选择，以保证交付，不要陷入追求完美的境地。

实战经验四：制定广泛的、开放的目标

我的目标是熟练掌握 Python，而这仅仅是我在 SpiderFoot 工作的两个动机。我对于 SpiderFoot 的更广泛和更长期的目标是：

制作这款让我引以为傲的产品，以我想要的方式，把我的创意集中到我认为对的地方。 由于我的职业生涯越来越多地进入管理领域，我会发展并保持我的技能活跃。 有创建成功的开放源码工程项目的实战经验，这个工程项目被普遍视为我所在行业中 OSINT 的首选工具。 以此为基础，打造一家有特色的成功企业。

注意，这些目标并非一成不变，但范围很广泛，而且很开放。我永远不会完成其中的任何两个目标，因为它们中的每两个目标都没有结束的状态，它们每年都能被继续延伸。

比如，我可能会在今年用 React重写前端，或是实施两个新的测试框架来合作开发我的技能，然后在明年迁移到不同的后端数据库。另外，或许我希望 SpiderFoot HX 的 MTT（月度经常性收入）翻番，或是在今年同时实现其他类型的商业突破。

这些都是指导原则，并非一成不变的目标，因此我要继续往前走，激励我日复一日地在 SpiderFoot 上工作。

实战经验五：只要你足够关心，就会挤出时间

当人们知道我有两个丈夫，三个小孩，有一份全职工作，并把 SpiderFoot HX 作为副业经营时，第两个问题总是“你是是不是挤出时间的？”当然，我愿意认为我有某种超级专注的能力（然而并没有），或者是两个令人难以置信的工程师（但我确实不是），但我想我能将其概括成以下几个关键问题：

我经常把我的时间安排到我不会被打扰的那一段。比如在早晨或者晚上，这要看我一岁小孩所选择的睡眠模式。 我很少看电视（每周可能就几个小时），只通过社交媒体来宣传 SpiderFoot（见实战经验七）。在 Hacker News 上随意浏览是我最大的拖沓方式，但是除了我自己写的帖子，我不会对帖子进行任何评论，这样做会减少我浪费的时间。 当我因为身边没有笔记本而无法编程时，我就会研究新的数据源，或者查找一些新的 Python 技巧，查看这个领域中的其他工具现状，或是回复邮件之类。 投入了大量的时间后，现在在 SpiderFoot 上工作已经成为我的一类习惯。这是我“只做不说”的事情，并且不能长时间避开它，否则我会开始感觉好像有什么事情不对劲了。

实战经验六：没人关心你的单元测试覆盖率

换句话说，人们真正关心的是你的软件是否能做到它所说的一样，而且做得非常好。

不过现实情况是，没有人（或者是少数人）会因为你的代码缺乏单元测试或代码混乱而避开你的工程项目。人们关心的是，这些东西是否能正常工作，是否能顺利进行，是否有文档记录，是否能长期保持工作状态（回想一下实战经验二和实战经验三）。而如何同时实现这一点，真的取决于你。

因此，别担心代码质量、测试覆盖率之类。不管是不是说，很多开放源码工程项目的合作开发者并不是专业的软件工程师，而且很多人因为害怕被批评，从而不敢把他们认为可能是“糟糕的代码”发布出来，这实在是太遗憾了。代码能重构！测试能添加！你甚至能用一类完全不同的编程语言来重写代码，只要你想。

你只需拿出一些有用的东西，当别人指出你的错误时，你要谦虚地去接受，并且从中汲取经验教训。有些 SpiderFoot 的代码写得非常糟糕，但是在往后的二十年来，我想我只看到过两次关于这个糟糕代码的评论。谁会在乎呢？

请记住：这是你的工程项目，你有时间让它变得更好（见实战经验二）。

实战经验七：营销没有什么好丢人的

在某些这时候，当你的软件达到了预期的效果，而且在一段有意义的时期里表现良好，那么别人就会开始为你推广它。话虽如此，但你在早期的这时候仍然需要投入精力来做一些营销，并且早期的反馈对你来说非常有帮助。

你需要了解你的用户和他们出没的地方（Twitter、LinkedIn、TikTok），并在那里与他们接触。联系你所在领域的有影响力的人（如通讯和博客作者），他们会发现你的软件很有用，并且让他们尝试一下——你将会惊讶地看到，他们会如此容易地接受开放源码合作开发者，因为他们感激你花了那么多的时间去帮助别人。

专业建议：除了要发布消息，还要为你的工程项目准备两个精美的 README.md，说明其机能、工作方式，并指出有关的信息，甚至还能搭建两个独立的中文网站。

实战经验八：和雇主说清楚

保护你在工作时间以外所做工作的知识产权有关的法律法规，在不同的国家、雇主之间会略有不同。如今，大多数科技和技术友好型公司都应该有一套流程来批准副业项目。我不是律师，但是你要确定你在入职前所做的工作和入职后所做的贡献都包括在内。

在你开始为雇主工作之前和在你开始工程项目之前，把知识产权的问题解决好要容易得多。为的是确保在可预见的未来能得到保障，我甚至宣布了我最终想要工作但尚未存在的工程项目。

如果你所加入的公司在你的工作时间中对你的开放源码工程项目抱有敌意，那么你就应该扪心自问，这样的职位到底值不值得你考虑。在你签合同之前，这是两个更容易作出的决定。

实战经验九：培养社区

这可能是我积累的最重要的两个实战经验，因为我认识到了它的重要性，但它确实需要大量的时间投入。事实上，我确实从一开始就创建了文档，但除此之外什么都没有做，我以为这样就足够了。如今，情况可能并非如此。

我这里所说的“培养”，就是为你工程项目的用户创建论坛和资源，让他们能深入了解，与他人联系，并在需要时获得/给予帮助。

这里有一些例子：

创建文档、教程视频、博文等。 倾听特性请求并实施它们（前提是与你的目标和愿景相符）。 创建两个 Discord 或 Slack，让人们提出问题并支持他人。 在会议上发表演讲。

实战经验十：保持愉快的心情

这也许应该是第两个实战经验，因为它是一切的基础，但我把它放在最后，因为我希望它是你从这篇文章中得到的新一代观点。

当你开始进行任何对个人软件合作开发工程项目时，你需要立即放弃这样的想法：它有一天会完成。即使你认为它的机能在某一时刻已经完成，但随着依赖关系改变，或是你想重构一些东西，用户碰到一些问题，并提出新的机能要求，甚至是出现“竞争”工程项目……都会给你增添巨大的压力。

一旦我接受了这个旅途，便永远不会结束，除非我自愿放弃它，我的很多不安全感和紧迫感就会烟消云散。现在，我很少在半夜疯狂地尝试推出新特性，或是因为不断增加的开放问题或请求而感到压力，或是因为测试覆盖率没有得到改善而感到难过。

没有任何规则规定你必须合并每两个拉取请求，回答每两个问题，或者真的做任何你不想做的事情，无论你处于何种原因。强迫自己去做，最终只能让你失去激情，而且有可能彻底地毁掉这个工程项目，这绝对是两个非常大的问题！

因此，要时常扪心自问：你做手头的工作，是所致自己的意愿，还是认为自己非要去做不可？如果是后一类情况，你能先放一放，然后去做别的事情，或者试着调整一下任务的框架，否则就把它留在积压的任务中，过两个星期再完成，而不必抱有负罪感。

当然，除了上面所说的 10 个实战经验，我在往后的几年里还学到了很多 Python 和其他技能。当我想开启下两个工程项目时，我将会用到这些学到的实战经验，我希望你也能如此。

作者介绍：

Steve Micallef，Spiderfoot 的作者（www.spiderfoot.net），两个开放源码 OSINT 手动化平台。

原文链接：

https://medium.com/@micallst/lessons-learned-from-my-10-year-open-source-project-4a4c8c2b4f64