我已经看到很多关于构建与购买的问题和讨论，但大多数人都坚持简单的方法，你可以简单地做一个或另一个。大多数时候，您必须购买和集成或自行构建。无论哪种方式，你都在做一些工作。
在接下来的 30-60 天里，我需要实施几个管理项目，以防止每个人都扯掉头发并互相残杀。其中最大的是票务系统（电子邮件、支持请求、自助服务等）。
不乏选择，但最终我们将不得不购买我们决定使用的任何东西，添加我们所有的客户及其用户，并确保我们随着时间的推移保持同步。我们还必须提供单点登录并进行一些设计工作，以使其看起来像是我们从头开始构建的。
如果我们构建我们可以跳过集成痛点，尽管具有有限（但集中）的功能集。
在做出这样的决定时，您通常会分析什么？如果有 4 到 5 个系统能够很好地完成一项非常具体的工作，还是有一个可以完成所有工作的单一系统更好？
一个系统更适合以下情况：
一个数据存储库（即数据库）
将每个系统链接在一起的简单方法，进行交叉引用。无需构建中间导入器/导出器/同步器
允许单次登录。这在企业中非常有用，可以确保每个人都知道在哪里可以找到正确的信息。所以更多“什么是错误跟踪的站点......”并不是每个人都会在大部分时间使用所有工具，他们会忘记如何访问甚至使用。
一切都具有相同的外观和感觉
节省培训费用
维护更便宜。一切都是一样的更新。管理员不必专门研究单独的系统。
但是……显然你被你买的东西困住了。如果可以的话，请确保获得一个可以构建自己的插件的系统，以使其与您的业务模型相匹配。
显然“这取决于”。我的一般规则是，如果它是内部的，我们会购买它并在需要时进行集成。如果她有问题，我们的公司系统管理员有一个支持热线给我们组织外部的人，而且这不是一个给我们的开发人员带来负担的巨大项目。
如果它是我要交付的产品的一部分，我会根据需要构建它或从开源库中获取一些源代码。没有什么比别人的黑盒代码破坏你的产品更糟糕的了。恕我直言，运输产品中的依赖项越少越好。
我倾向于购买您提到的支持产品。好的那些为共享身份验证系统、面向用户的主题以及可能您的客户服务团队尚未意识到他们想要/需要的大量功能提供了很好的集成点。
但是，要分析什么。对于像这样的“管理”项目，对我来说最重要的是机会成本。我的团队还能做些什么来让我们的公司赚更多的钱，让我们获得更多的客户，等等？当然，这些项目对底线有一些积极的影响，但与新产品、改进产品等相比没有什么。随着时间的推移，包括维护在内，开发人员/产品经理/测试人员会在这个管理项目上花费多长时间？如果您购买，集成点不会经常更改，但如果您构建，您的客户（内部人员）将不断要求新功能，您将能够在您的剩余任期内维护该项目。
您已经确定了一个关键问题——当您购买时，您仍有工作要做，而且可能还有很多工作要做。话虽如此，我每次的总体倾向都是购买。编写代码很难，调试代码更难——当你购买时，你购买的不仅仅是代码/应用程序，你购买的是它可以工作的事实——后者是 90% 的收益。
但是，由于您的需求非常普遍，为什么不使用开源。这有两个突出的好处。
1）由于您可以访问源代码，因此您可以根据自己的意愿对其进行修改——即无需在现有系统的顶部进行单点登录。定制登录模块以使用您现有的基础设施，因此无需保持同步、节省时间、干净的方法等。许多开源通过组件化（？）那些无论如何都是特定于环境的方面来承认现实世界。它们通常与 DB/身份无关。
2）如果您明智地选择，您将拥有一支已经了解系统的顶尖技术人员随时准备提供帮助 - 唯一的问题是他们不为您工作（还没有！）。
我的建议是选择一个您的简单目标 - 票务系统似乎是一个，分析在开源世界中满足您大部分/所有需求的内容。评估并在Rent A Coder上提出任何所需更改的请求。坐下来等待结果，希望结果很好。你失去了一点时间，并获得了很多经验。
开源不等于 Linux/Unix——.Net 也有很多好东西。
买？你说的这个买的是什么，陌生人？
说真的，很长一段时间以来，我都不必为自己的项目购买软件。我所有的开发工具都是免费的，我所有的第三方库都是免费的（不是 GPL）。甚至我的操作系统也是免费的。出于测试目的，我必须为 Windows 付费，但大多数工作都使用跨平台的工具。
任何需要从免费工具或库中无法立即获得的代码的东西，我要么从头开始编写（所有算法都可以在网络上免费获得），要么使用我一直在添加的（因为我太老了所以很大）片段库源代码多年。
购买（“获得”）几乎总是比构建更快，除非购买的东西是如此糟糕以至于集成是一场噩梦。这可以通过避免来自几乎没有记录的供应商的最新奇闻异事来缓解。
您的要求越“标准”，购买就越合适（或者换句话说，不要重新发明轮子）。相反，您的要求越独特，您可能考虑构建的越多。
您非常正确地指出，即使在购买时也往往会有一些定制。请记住，任何自定义都会在每次升级/修补时花费您。我建议，如果您的需求接近您可能购买的工具之一所支持的业务模型，那么您认真考虑将业务流程重新调整到供应商标准。如果这不可能，请询问您是否购买了正确的工具。
我建议，如果有人出于成本原因建议建造它，那就尖叫吧。以我的经验，购买成本是众所周知的，而建造成本却很隐蔽。请记住，您将决定在应用程序的整个生命周期内（商业应用程序平均为 7 年）继续编码，但在决定购买和构建时可能只考虑初始开发成本。
我非常喜欢单一的单体数据库，但有时这是行不通的。更重要的是拥有“单一的真相来源”；如果您有多个数据库保存类似的数据，请选择一个作为给定数据的权威来源，并有一个流程来维护与该来源一致的所有其他数据库。最好这将是自动的。