专有解决方案很难满足开放解决方案自然提供的功能和支持范围。而基于社区的软件通常在演进速度上很难被单一供应商超越。
译自 Thinking about an Internal Developer Portal? Think Open Source，作者 Helen Greul 是一位工程领导者、演讲者，也是一个致力于打造能够使团队茁壮成长的开发者生态系统的坚定倡导者。她的经历使她从亲自编码逐渐过渡到引导工程和平台团队，为她提供了一种全面的视角...
作为现代软件架构变得愈发复杂，平台工程已经成为一种有价值的实践，以支持软件开发人员的需求并提供他们管理不断发展的基础设施所需的工具。
平台工程团队将技术复杂性防患于未然，释放潜力，并充当粘合剂，为团队之间创建清晰的接口和契约。
与此同时，内部开发者门户（IDPs）也逐渐崭露头角，作为服务于平台工程的前台的工具之一。
IDPs是集中式系统，为开发人员提供构建、部署和管理软件的工具和资源。它们通常充当组织中所有元数据和每个软件项目的项目所有权的真实信息的单一来源，有助于发现并实现团队间无缝协作。
IDPs还可以通过标准化开发工作流程和简化团队以不损害自主性的方式发布高质量代码的能力，为重复性任务提供自动化解决方案。
如今，随着公司规模的扩大和处理不断增加的不同基础设施组件和分散的资源，开发者门户已经成为一项至关重要的策略，使公司能够保持产品开发的速度。
组织在启动其开发者门户时有两个主要选择 — 他们可以自行组装和配置，利用云原生开源领域提供的构建模块（在需要时添加更多价值和功能的潜力），或者他们可以使用专有解决方案。
与任何决策一样，都有利弊，所以让我们深入了解一下为什么我们在 Spotify 认为在启动团队内部开发者门户计划时，采用开源基础是最佳选择。以下是您可能需要考虑的一些因素：
当公司开始增长和扩展时，它们借助内部开发者门户（IDPs）来帮助规范组织中软件的构建方式。预先构建的IDP软件似乎是一个简单的选择，因为它为他们迅速解决不断增加的复杂性提供了一个即时的解决方案。
但是采用这些解决方案可能会在长远内带来挑战，因为它们提供有限的定制性和可扩展性。专有软件依赖于一个供应商来构建和推进其背后的技术，并对您可以推动解决方案的程度设置了限制。
另一方面，开源模型避免了供应商锁定，并且可以在不超出仅解决眼前需求的解决方案的情况下持续扩展。虽然现成的模型可能提供更多的初始指导，但开源模型提供了一个基础框架，具有公司和团队需要进行扩展的灵活性。
此外，利用开源的内部开发者门户（IDP）模板，能为平台工程团队提供丰富的插件组合 — 这些插件是可以集成到开放平台中的独立软件功能，以满足公司在基础设施和软件开发方面的各种需求。由充满热情的工程专家构建和维护，插件允许在组织演进时进行无与伦比的定制和功能扩展。
最好的利用这种灵活性的方式是首先确定你的团队面临的最大问题或拖慢速度的障碍。
一旦确定了最初的挑战，围绕解决方案构建你的IDP就变得更加容易，将其扩展以适应相关和连续的问题的路线图变得更为清晰。这还提供了更清晰的投资回报率（ROI）洞察，并确保你的团队能够有效地推出它。
当你采用开源解决方案时，你不仅可以利用内部开发团队的贡献，还能够访问整个开源生态系统的贡献。这意味着你可以获取到公司之外存在的广泛专业知识和经验。
与开源技术互动使你能够深入了解你所依赖的技术如何运作以及如何为其改进做出贡献。
例如，Backstage，Spotify于2020年捐赠给云原生计算基金会的IDP，拥有全球超过1,200位贡献者。这些贡献者定期提交错误，添加新功能，并构建有价值的插件，使每个采用者受益。
专有解决方案很难与开源解决方案自然提供的功能和支持范围相媲美。而基于社区的软件的演进速度通常难以被单一供应商超越。
开源贡献者投入他们的时间来构建和维护许多组织所依赖的技术，因此向开源社区回馈也同样重要。培养一个支持和维护开源项目的环境，确保开源社区的资源和健康能够持续繁荣。这不仅有助于更好的产品，而且促进了多样性。每位新的贡献者都为改进开发者体验和效能所面临的挑战带来了独特的观点和经验。
在一天结束时，所有的内部开发者门户（IDPs）都需要文化转变来实现技术对齐，因此重要的是你以同理心的态度与开发者合作，共同创造对他们有意义的解决方案。开源门户鼓励这一点，因为它们允许灵活地构建和调整平台以适应开发者的需求，而不是相反。