本文由 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 还带来了一些私人或间接的好处:让自己更加自律,改进时间管理,寻找增强精力和身体健康的途径,等等。
一个项目之所以成功,是因为它能经得起时间的检验,并且比其他项目要好。如果你一直在努力改进项目,那么它就会得到关注和利用,而不会像那些只是昙花一现的应用一样,最后被淘汰。
没有人会要求你每天、每周或每月都要提交,但是你要努力保证当你的依赖性改变时,你的软件仍然可以正常工作。还要留意所报告的问题,如果这些问题涉及的范围很广,那么就需要重视。
这十年来我一直都有许多遗憾。比如,我应该一开始就在单元测试、代码文档和代码品质方面投入更多的精力。但是我也明白,如果我在把 SpiderFoot 投放到公众之前,就花费大量的时间去学习和实现,把它变成一个好的产品。那么,成千上万的人就不会使用到 SpiderFoot,也就不能获得他们所拥有的价值。因为在这期间,我也许会因为情绪低落或者心烦,而完全放弃交付。
记住经验二,放心吧,你会有更多的时间去完善它。只要每周留出几天的时间,你就可以静下心来,去打造一些伟大的东西,并且保证你的产品能正常运行。你必须时不时地做出选择,以保证交付,不要陷入追求完美的境地。
我的目标是熟练掌握 Python,而这仅仅是我在 SpiderFoot 工作的一个动机。我对于 SpiderFoot 的更广泛和更长期的目标是:
注意,这些目标并非一成不变,但范围很广泛,而且很开放。我永远不会完成其中的任何一个目标,因为它们中的每一个目标都没有结束的状态,它们每年都可以被继续延伸。
比如,我可能会在今年用 React 重写前端,或是实施一个新的测试框架来开发我的技能,然后在明年迁移到不同的后端数据库。另外,或许我希望 SpiderFoot HX 的 MTT(月度经常性收入)翻番,或是在今年实现其他类型的商业突破。
这些都是指导原则,并非一成不变的目标,所以我要继续往前走,激励我日复一日地在 SpiderFoot 上工作。
当人们知道我有一个妻子,三个孩子,有一份全职工作,并把 SpiderFoot HX 作为副业经营时,第一个问题总是“你是怎么挤出时间的?”当然,我愿意认为我有某种超级专注的能力(然而并没有),或者是一个令人难以置信的工程师(但我确实不是),但我想我可以将其归纳成以下几个关键问题:
换句话说,人们真正关心的是你的软件是否能够做到它所说的一样,而且做得非常好。
不过现实情况是,没有人(或者是少数人)会因为你的代码缺乏单元测试或代码混乱而避开你的项目。人们关心的是,这些东西是否能够正常工作,是否能顺利进行,是否有文档记录,是否能长期保持工作状态(回想一下经验二和经验三)。而如何实现这一点,真的取决于你。
所以,别担心代码质量、测试覆盖率等等。不管怎么说,许多开源项目的开发者并不是专业的软件工程师,而且很多人因为害怕被批评,从而不敢把他们认为可能是“糟糕的代码”发布出来,这实在是太遗憾了。代码可以重构!测试可以添加!你甚至可以用一种完全不同的编程语言来重写代码,只要你想。
你只需拿出一些有用的东西,当别人指出你的错误时,你要谦虚地去接受,并且从中吸取教训。有些 SpiderFoot 的代码写得非常糟糕,但是在过去的十年来,我想我只看到过两次关于这个糟糕代码的评论。谁会在乎呢?
请记住:这是你的项目,你有时间让它变得更好(见经验二)。
在某些时候,当你的软件达到了预期的效果,而且在一段有意义的时期里表现良好,那么别人就会开始为你推广它。话虽如此,但你在早期的时候仍然需要投入精力来做一些营销,并且早期的反馈对你来说非常有帮助。
你需要了解你的用户和他们出没的地方(Twitter、LinkedIn、TikTok),并在那里与他们接触。联系你所在领域的有影响力的人(如通讯和博客作者),他们会发现你的软件很有用,并且让他们尝试一下——你将会惊讶地看到,他们会如此容易地接受开源开发者,因为他们感激你花了那么多的时间去帮助别人。
专业建议:除了要发布消息,还要为你的项目准备一个精美的 README.md,说明其功能、工作方式,并指出相关的信息,甚至还可以搭建一个独立的网站。
保护你在工作时间以外所做工作的知识产权相关的法律法规,在不同的国家、雇主之间会有所不同。如今,大多数科技和技术友好型公司都应该有一套流程来批准副业项目。我不是律师,但是你要确定你在入职前所做的工作和入职后所做的贡献都包括在内。
在你开始为雇主工作之前和在你开始项目之前,把知识产权的问题解决好要容易得多。为了确保在可预见的未来能够得到保障,我甚至宣布了我最终想要工作但尚未存在的项目。
如果你所加入的公司在你的工作时间中对你的开源项目抱有敌意,那么你就应该扪心自问,这样的职位到底值不值得你考虑。在你签合同之前,这是一个更容易作出的决定。
这可能是我积累的最重要的一个经验,因为我认识到了它的重要性,但它确实需要大量的时间投入。事实上,我确实从一开始就创建了文档,但除此之外什么都没有做,我以为这样就足够了。如今,情况可能并非如此。
我这里所说的“培养”,就是为你项目的用户创建论坛和资源,让他们能够深入了解,与他人联系,并在需要时获得/给予帮助。
这里有一些例子:
这也许应该是第一个经验,因为它是一切的基础,但我把它放在最后,因为我希望它是你从这篇文章中得到的最新观点。
当你开始进行任何个人软件开发项目时,你需要立即放弃这样的想法:它有一天会完成。即使你认为它的功能在某一时刻已经完成,但随着依赖关系改变,或是你想重构一些东西,用户碰到一些问题,并提出新的功能要求,甚至是出现“竞争”项目……都会给你带来巨大的压力。
一旦我接受了这个旅程,便永远不会结束,除非我自愿放弃它,我的很多挫折感和紧迫感就会烟消云散。现在,我很少在深夜疯狂地尝试推出新特性,或是因为不断增加的开放问题或请求而感到压力,或是因为测试覆盖率没有得到改善而感到难过。
没有任何规则规定你必须合并每一个拉取请求,回答每一个问题,或者真的做任何你不想做的事情,无论你处于何种原因。强迫自己去做,最终只能让你失去激情,而且有可能彻底地毁掉这个项目,这绝对是一个很大的问题!
所以,要时常扪心自问:你做手头的工作,是出于自己的意愿,还是认为自己非要去做不可?如果是后一种情况,你可以先放一放,然后去做别的事情,或者试着调整一下任务的框架,否则就把它留在积压的任务中,过一个星期再完成,而不必抱有负罪感。
当然,除了上面所说的 10 个经验,我在过去的几年里还学到了很多 Python 和其他技能。当我想开启下一个项目时,我将会用到这些学到的经验,我希望你也能如此。
作者介绍:
Steve Micallef,Spiderfoot 的作者(www.spiderfoot.net),一个开源 OSINT 自动化平台。
原文链接:
https://medium.com/@micallst/lessons-learned-from-my-10-year-open-source-project-4a4c8c2b4f64