自2014年以来，Tobias Koppers一直负责维护Instagram网络版的一个重要组件。
Koppers是webpack的创造者，这是一个用于JavaScript的开源代码捆绑工具。webpack实现了代码拆分，允许开发者优化他们的JavaScript代码，并将其拆分成更小的块，这样当你访问一个网络应用时，最重要的代码块会先下载。由于你不必在开始使用之前下载整个应用，因此这使得网络应用更快。
Webpack始于2012年，是一个学术项目的一部分。就像许多其他开源项目一样，它最初是一种解决问题的方式。"我正在为我的计算机科学硕士论文开发一个网络应用，我正在寻找一个代码优化工具，"他在最近一集The ReadME Podcast中解释说。由于对其他工具处理代码分割的方式不满意，他写了自己的工具并在GitHub上发布。"他说："我以前为开源做出过贡献，但我以前从未开放过自己的项目。
不到三年，前Instagram工程经理Pete Hunt在OSCON 2014上解释说，该公司依赖webpack，这使Koppers处于一个奇怪的位置，即维护世界上最受欢迎的应用程序之一的一个重要但不被公众发现的部分。
Webpack在Instagram中默默无闻、不为人知的作用是一个很好的例子，说明我们的软件中的开源程度比普通用户可能意识到的要高得多。专有的应用程序和网络服务也广泛使用了开源，尽管它并不总是那么明显。例如，无数的iOS应用——包括Hulu、Poshmark和TikTok——依靠开源网络库AlamoFire或其前身AFnetworking来下载图片和数据，尽管用户从未与这些库直接互动。
Webpack在Instagram中默默无闻的作用是一个很好的例子，说明我们所有人都在我们的软件中使用了比普通用户可能意识到的更多的开源资源。
开源软件经常被拿来与物理基础设施进行比较。作家和研究员Nadia Eghbal将开源软件描述为数字世界的 "道路和桥梁"。但是，虽然道路和桥梁是高度可见的基础设施形式，但开放源码往往不被其终端用户所见。
像cURL这样的开源库是隐藏的动力源，一部分人认为这是理所当然的。而且，就像它们的物理对应物一样，它们需要被维护以保持运行。cURL包含在大多数Linux发行版中，需要被更新以支持最新的网络标准，就像任何标准的网络浏览器一样。"许多人没有意识到cURL是一个应用程序，而不仅仅是一个操作系统功能，"cURL的创建者David Stenberg说。"甚至那些知道它的人也经常想知道为什么我需要做维护"。
许多开源项目几乎不为人知，这给开源生态系统带来了许多挑战，从为项目提供资金、保证其代码安全到确保其组件之间的兼容性。
试验和磨难
安全是关心开源基础设施的最迫切的理由。无论是开源的还是专有的，没有经过审计和维护的代码对每一个使用它的软件都是一种安全风险。但许多开源项目并不是由提供支持合同和保证的公司创建和维护的。相反，它们是由开发人员建立的，通常是在业余时间工作。这些开发者可能没有人积极修补安全漏洞，更不用说为审计付费了。
理想的情况是，关键的开源项目将有全职的开发人员，不仅修复漏洞，而且在安全方面减少漏洞的出现。今天，大型企业的开发人员可以在签到时扫描他们的代码是否有漏洞，并在部署到生产之前修复问题，而信息安全团队与软件架构师合作，从项目一开始就确保最佳实践。但对于小公司或单个项目来说，同样的资源并不总是可用。
全职的开发人员需要资金。虽然近年来开源的财务模式一直是人们关注的主要话题，但没有一种模式是最有效的。许多开发者找到了初创公司来实现他们工作的货币化。其他人则依靠企业的赞助来资助全职开发。有些人收取额外的咨询和支持费用来资助他们的项目。Stenberg在业余时间研究cURL多年后，去了wolfSSL工作，为cURL提供商业支持。
说服雇主为开源工作付费，作为开发者责任的一部分，是另一种流行的资助模式。对于像Koppers这样的开发者来说，这是个理想的情况。由于企业的赞助，Koppers辞去了工作，从事Webpack的工作，但现在为一家名为Vercel的公司全职从事该项目。一些公司认识到，他们的业务依赖于开源库的可靠性、安全性和完整性，因此，作为回应，雇用维护者全职或兼职从事他们的创作，就像任何其他关键的基础设施。Carolyn Van Slyck利用自己的时间开始了对开源部署自动化系统Porter的工作。现在维护这一系统是她在微软的职责之一。但她指出，这类安排不一定是永久性的。公司可能不会无限期地资助一个项目的开发，特别是如果他们停止使用该软件。
但许多开源项目并不是由提供支持合同和保证的公司创建和维护的。相反，它们是由开发者建立的，通常是在他们的业余时间工作。
有些软件作为自己的初创公司表现得更好，但其他项目并不适合货币化。流行的JavaScript框架Vue的维护者Evan You在GitHub Universe 2020上说："一千个开源项目就像一千个具有不同商业模式的初创公司"。"我主要是在做众筹，因为Vue是一个曝光率相当高的项目，但它可能对某些类型的项目不起作用。"
流行的Python库pydantic的维护者塞缪尔-科尔文（Samuel Colvin）说，他没有看到使其工作货币化的明确方式。 pydantic是一个数据验证库。它帮助开发者确保正确的数据类型被输入到一个应用程序中。例如，它可以检查以确保当一个应用程序正在期待一个整数时，用户不会输入一串字母来代替。
一方面，pydantic是一个广泛使用的软件，是其他流行的Python软件包的核心，如自然语言处理库SpaCy和FastAPI，根据2020年10月对超过28000名Python开发人员的调查，FastAPI是第三大最受欢迎的Python框架。"这对我们在SpaCy的工作至关重要，"维护者Ines Montani说。"围绕着pydantic这样的工具，已经建立了一个完整的生态系统。"另一方面，科尔文说，它还没有大到足以获得大量的赞助或捐款，以帮助资助项目的全职开发人员，也没有一个明显的方法来围绕它建立一个创业公司。
此外，资金并不能解决现代开源所面临的所有问题。开源生态系统越来越复杂，随着这种复杂性，开源维护者要保持他们的项目与其他项目、代码和应用程序兼容的新负担，他们被设计为与之合作。
例如，在2017年，Python核心开发团队提出了对编程语言的改变，这将部分破坏pydantic，并延伸到依赖它的一切，包括FastAPI。科尔文直到2021年4月才意识到这个改变会被实施，当时他收到了一封来自一个相关的Python维护者的电子邮件。"他告诉我，他刚刚听说了FastAPI和pydantic，并意识到这个提议可能会影响到它们，"Colvin解释说。
科尔文在网上发起了反对该提案的运动，最终，Python团队选择推迟这一变化，而他们正在研究一个解决方案。"我也许可以更好地处理这种情况。我可能把鼓敲得比我需要的还要响亮，"科尔文说。"我对Python指导委员会留下了深刻的印象，他们理解我们的顾虑，我们将来会与他们进行更多的合作。"
这一事件阐明了维护软件的挑战。"关注Python开发者邮件列表本身就是一项全职工作，"科尔文说。即使他在pydantic之外没有全职工作，他也不可能跟上Python生态系统中可能影响他的项目的所有情况。同样，期望Python的核心维护者了解每一个Python库的内部运作是不合理的，更不用说边缘案例了。
"Van Slyck说："即使你有资金，总是有更多的工作是你不可能做到的。"而且标准总是在不断提高。过去，只要把一些代码放到网上就足够了。现在，你被要求培养一个社区。你的工作有更高的标准和要求。"
模块化的幸福感
一些开发者通过专注于制作更小的、更容易管理的代码包，以及故意少定制一些标准，在开源中找到了宁静的感觉。"我不喜欢设计需要大量维护的东西，"James Halliday说，他是数百个Node.js模块的创建者。"我试图让我的模块保持最小。我认为，如果人们停止对它们的工作，停止无缘无故地改变东西，很多工具会更好。"更多的功能意味着更多的复杂性，每一次改变都会带来新的错误的可能性。
Halliday--以他的名字substack而闻名--对他的工作采取了一种非同寻常的放手方式。"他说："我把所有的GitHub通知邮件都关掉了。如果有人发现他的代码有问题，或者希望在他不再工作的模块上增加一个功能，他们可以自由地分叉他的代码。这毕竟是开放源码的方式。但他并不为他认为已经完成的软件包的问题或拉动请求投入精力。他说："我的工作不是经常盯着我几年或几十年前写的每一件小事，"他说。"我总是忙于新的项目，如果我总是回顾旧的项目，我就没有足够的时间前进了。"
没有一个完美的开发流程适用于所有的开源开发者。很多人都乐于维护他们的项目或与社区合作进行改进。一种不那么极端的 "少即是多 "的心态正在成为维护大型项目和社区的一种越来越流行的选择。正如Eghbal在她的书《在公共场合工作》中指出的那样。Eghbal在她的《在公共场合工作：开源软件的制作和维护》一书中指出，为一个项目增加更多的贡献者实际上会给维护者带来更多的工作，因为维护者会很快发现自己不仅要审查其他人的代码，还要在这些贡献者最终离开项目时维护新功能。Eghbal指出，开源项目的设计和开发有更加模块化的趋势，维护者创造了更小的软件包，需要更少的维护者和维护工作。即使是较大的项目，如Ruby on Rails，也在采用更加模块化的方法。
同时，GitHub的2020年Octoverse报告发现，开源开发者越来越注重做更小、更多的增量变化，为维护者创造更少的开销。"报告说："所确定的头号最佳实践是保持拉动请求的范围小，因为它使审查更容易，导致更好的审查，并使有问题时更容易恢复。"这也简化了反馈，创造了动力，有助于提高团队的生产力"。
虽然这种更加模块化的方法可能会使开源维护者的生活更加轻松，但它可能会给企业带来新的挑战，因为它增加了他们需要审查和保持更新的不同软件包的总数。"潜在问题的表面积更大了，因为有更多的依赖关系，每一个都由不同的开发人员管理，"Eghbal写道。
在某些方面，这就是使用自由软件的代价。"请记住，开源维护者通常是为了更大的利益而做这项工作，往往没有任何报酬，而且对他们的软件如何被其他人使用或修改没有太多的控制。" GitHub CSO Mike Hanley说。"如果你依赖第三方和开源软件，就有责任对你纳入项目的内容以及你如何使用它做一些尽职调查。考虑将你发现的任何改进、有趣的用例或错误修复与项目分享。"
除此之外，公司和个人有很多机会可以更多地参与到他们所依赖的开源社区中，从资助和维护到培养尚未存在的社区。这一切都始于仔细观察你的代码背后的软件，并看到以前不为人知的基础设施为它提供动力。
