开源软件总体拥有成本指南

Guide to the Total Cost of Ownership of Open-Source Software

开源软件总体拥有成本指南

Tuesday May 10, 2022 by Peter Schneider | Comments

​2022年5月10日星期二 彼得·施耐德 评论

Using ready-made software speeds up development. The use of open-source software (OSS) however is not free of costs. Using open source comes with obligations and risks, which carry a cost.

使用现成的软件可以加快开发速度。然而，开源软件（OSS）的使用并不是免费的。使用开源会带来义务和风险，这会带来成本。

This guide summarizes the costs of using open-source software for professional software development based on public information and my 15 years of experience.

本指南根据公共信息和我15年的经验总结了使用开源软件进行专业软件开发的成本。

My background: I’ve worked with a lot of software based on open-source principles in my career: I switched from Solaris OS to JBoss OS (before Red Hat acquired it) for carrier-grade blade servers at Nokia Networks. At Nokia, I promoted and contributed to maemo.org, the open-source operating system for mobile devices. I’ve used many open-source libraries such as Angular, Docker, Log4J, and Fullcalendar.io when heading the product management for an enterprise service management platform.

我的背景：在我的职业生涯中，我使用过很多基于开源原则的软件：我在诺基亚网络的运营商级刀片服务器上从Solaris操作系统切换到JBoss操作系统（在Red Hat收购之前）。在诺基亚，我为maemo.org的移动设备开源操作系统做了宣传和贡献。我使用过很多开源库，比如Angular、Docker、Log4J和Fullcalendar.io。在为企业服务管理平台领导产品管理时。

Authors Note: I am a firm believer in the value of open-source software. Analyzing the cost of using open source is not intended as means to promote or disregard the value of open-source software. I have always believed that sharing intellectual property when there is a common interest is the future of software development. Nevertheless, I was always willing to pay the price for the use of open source: whether it was the support fee for JBoss, the sponsorship of the Maemo community, paying for multiple years of open-source management in the service management platform, or the acquisition of premium features linked to an open-source product (fullcalendar.io). I have always valued open-source software, especially in commercial product development. The purpose of this guide is to provide transparency for better decisions.

​作者注：我坚信开源软件的价值。分析使用开源软件的成本并不是为了宣传或忽视开源软件的价值。我一直认为，在有共同利益的情况下共享知识产权是软件开发的未来。尽管如此，我始终愿意为使用开源付出代价：无论是JBoss的支持费、Maemo社区的赞助费、在服务管理平台上多年的开源管理费，还是购买与开源产品（fullcalendar.io）相关的高级功能。我一直重视开源软件，尤其是在商业产品开发方面。本指南的目的是为更好的决策提供透明度。

The Myth of Open Source is Free

开源的神话是免费的

 The acquisition cost of open-source software is close to zero. However, open-source software comes with management costs and risks. The figure below illustrates the common misperception of the total ownership cost related to open-source software-based development.

开源软件的收购成本接近于零。然而，开源软件带来了管理成本和风险。下图说明了对基于开源软件开发的总拥有成本的常见误解。

At first impression, when using open-source software libraries, the total cost of software development consists only of the direct development costs for staff and development tooling. Commercially supported software libraries come with an additional charge of software licenses and potentially distribution royalties. Looking at this comparison, deciding what approach to choose seems straightforward. The whole truth, however, lies below the surface.

在第一印象中，当使用开源软件库时，软件开发的总成本只包括员工和开发工具的直接开发成本。商业支持的软件库会额外收取软件许可证和潜在的发行版税。看看这个比较，决定选择什么方法似乎很简单。然而，整个真相都隐藏在表面之下。

While the use of commercial software includes little hidden costs over the product's lifetime, several additional costs must be considered when using open-source libraries. These include:

虽然商业软件的使用在产品的生命周期中几乎没有隐藏成本，但在使用开源库时必须考虑一些额外的成本。这些措施包括：

• Fixing bugs yourself instead of having a commercial maintainer doing it on your behalf (or hope that somebody in the community will do it quickly free of charge)
• 自己修复bug，而不是让商业维护人员代表您（或希望社区中的某个人能免费快速修复）
• Implementing the open-source obligations such as documenting the used open-source components for audits, managing a repository where people can download your source code, and creating a user interface displaying the open-source libraries used in your product
• 实现开源义务，例如记录用于审核的已使用开源组件、管理人们可以下载源代码的存储库，以及创建显示产品中使用的开源库的用户界面
• Implementing legal checks and risk assessments when introducing a new open-source element or when the open-source licensing terms have changed
• 在引入新的开源元素或开源许可条款发生变化时实施法律检查和风险评估
• Performing regular license compliance checks in line with the corporate information security, corporate open-source policy, and the open-source license terms
• 根据公司信息安全、公司开源政策和开源许可条款定期执行许可证合规性检查

I have excluded other direct costs such as annual security audits and indirect, one-time costs for this guide. Security audits, including penetration testing, need to be done in either case. Potential one-time expenses related to incompliance with open-source terms and conditions, such as the loss of product distribution rights, patent litigation, or brand damage due to public defamation are of such magnitude that I excluded them. These need to be considered as risks.

本指南不包括年度安全成本和其他间接成本。在这两种情况下都需要进行安全审计，包括渗透测试。与不遵守开源条款和条件有关的潜在一次性费用，如产品分销权的丧失、专利诉讼或因公开诽谤而造成的品牌损害，其数额之大，我将其排除在外。这些都需要被视为风险。

The guide is written in such a format that it demonstrates the total cost of open-source based on examples. It’s easy to adjust the TCO calculation with your input values. The focus of this guide is on explaining the cost components and not on any individual results.

该指南以这样一种格式编写，它基于示例演示了开源的总成本。使用输入值调整TCO计算很容易。本指南的重点是解释成本构成，而不是任何单独的结果。

1) The Cost of Fixing Open-Source Code Yourself

1） 自己修复开源代码的成本

Fixing bugs takes time. Every software has bugs, whether it uses open source or not. The question is only who fixes the bug. If one buys commercially supported software libraries, the code maintainer does the bug fixing. If one uses open-source, then one can hope that the bug is fixed in the open-source community by somebody else. But there are no Service Level Agreements (SLA) in the open-source community. Alternatively, one can fix the bug in open source oneself and ask the open-source maintainer to merge the bug fix in the upstream code library, i.e., the master of the code. Those logistics are also an additional effort, and there are no guarantees the open-source project maintainer will approve it. If the open-source project does not accept the self-made bug fix, one must manually patch the open-source library with every new version.

修复bug需要时间。无论是否使用开源软件，每个软件都有漏洞。问题只是谁修复了这个bug。如果你购买了商业上支持的软件库，代码维护人员会进行错误修复。如果一个人使用开源软件，那么他可以希望其他人在开源社区中修复这个bug。但开源社区中没有服务级别协议（SLA）。或者，你可以自己修复开源中的错误，并要求开源维护人员将错误修复合并到上游代码库中，即代码的主人。这些后勤工作也是一项额外的工作，不保证开源项目维护人员会批准它。如果开源项目不接受自制的bug修复程序，则必须用每个新版本手动修补开源库。

To calculate the effort of fixing a bug, one can estimate the average time it takes to fix a bug with the average amount of bugs one would expect to find in any software code. If one searches the Internet, one will find several statements that fixing a bug in a commercial product takes on average half to one day of a software developer. Based on my experience running an R&D team of 20 developers, I have to say that I never saw a bug fixed in a single day. I agree that the actual correction of the code sometimes takes not more than 30 minutes, but that's only a fraction of what it takes to fix a bug. I would set the range of developer days it takes to fix a bug from 0,5 to 2 days.

​要计算修复bug的工作量，可以用任何软件代码中预期的平均bug数量来估计修复bug所需的平均时间。如果你在互联网上搜索，你会发现一些说法，即修复商业产品中的漏洞平均需要软件开发人员半天到一天的时间。根据我管理一个由20名开发人员组成的研发团队的经验，我不得不说，我从来没有在一天内看到一个bug被修复。我同意，代码的实际更正有时不超过30分钟，但这只是修复错误所需时间的一小部分。我会将修复bug所需的开发人员天数从0,5天设置为2天。

 It takes a developer between 0,5 to 2 days to fix a software bug.

开发人员需要0,5到2天的时间来修复软件缺陷。

The second parameter for the cost calculation is the number of bugs in the open-source software. Suppose we assume that open-source software has as many bugs over its lifetime as any software. In that case, we use a widely-used assumption: Commercial software typically has 20 to 30 bugs for every 1000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. Let’s assume further that open-source software has fewer bugs than individually developed software (due to more participants contributing and using the same software), then we might take a value at the lower end of that spectrum.

​成本计算的第二个参数是开源软件中的bug数量。假设我们假设开源软件在其生命周期中有和其他软件一样多的bug。在这种情况下，我们使用了一个广泛使用的假设：根据卡内基梅隆大学CyLab可持续计算联盟的数据，商业软件通常每1000行代码就有20到30个bug。让我们进一步假设，与单独开发的软件相比，开源软件的bug更少（因为有更多的参与者参与并使用相同的软件），那么我们可能会在该范围的低端取一个值。

Open-source software has an average of 20 bugs per 1000 lines of code.

开源软件平均每1000行代码有20个bug。

That leaves the question of how many lines of code an application has and how much of that is open source. There is a wide variety of lines of code in an app. While the average iPhone app might have 50.000 lines, the Über app has some 428.000 lines, and TikTok has 15 million lines of code. To simplify this complexity, and since I work at Qt, I assume that our model application uses the Qt Framework Essential open-source libraries available in dual-licensing (commercially supported and open-source). The Qt Framework Essentials software libraries are often used in high-performance mobile apps, desktop applications, and embedded devices. The Qt Framework Essentials (qtbase and qtdeclarative repositories) of the Qt 6.3 release include 2.936.523 lines of code (LOC) according to a measure with SLOCCount.

​这就留下了一个问题：一个应用程序有多少行代码，其中有多少是开源的。一个应用程序中有各种各样的代码行。iPhone应用程序的平均行数可能为5万行，而Über应用程序的行数约为428.000行，TikTok的代码为1500万行。为了简化这种复杂性，而且由于我在Qt工作，我假设我们的模型应用程序使用双授权（商业支持和开源）中可用的Qt框架基本开源库。Qt Framework Essentials软件库通常用于高性能移动应用程序、桌面应用程序和嵌入式设备。Qt 6.3版本的Qt框架要素（qtbase和qtdeclarative repositories）包括2.936.523行代码（LOC），根据SLOCCount的衡量标准。

Qt Framework Essentials libraries include some 3 million lines of code

Qt Framework Essentials库包含大约300万行代码

Finally, we need to estimate of average cost of a software developer day. I will use the average salary of a Software Developer in the US in 2022 based on glassdoor.com, which is 555 USD / Day. Adding a 1.25 multiplier for indirect employee costs (using the same ratio used for EU funding programs), we get 688 USD costs for an average software developer day. I’ll spread the number of expected bugs over a 10-year period, which is a typical time for the software to be refactored or redone. So, if one would maintain the Qt Framework Essentials open-source libraries oneself, that would mean:

最后，我们需要估算软件开发人员一天的平均成本。我将使用基于glassdoor.com的2022年美国软件开发人员的平均工资，即555美元/天。将间接员工成本乘以1.25（使用与欧盟资助项目相同的比率），我们平均软件开发日的成本为688美元。我将在10年内传播预期的bug数量，这是软件重构或重做的典型时间。因此，如果要自己维护Qt Framework Essentials开源库，这意味着：

    3.000.000 LOC

/                 10 YEARS

x                 20 BUGS

/           1.000 LOC

x                0,5 DAYS

x               688 USD
-------------------
     2.064.000 USD

One could expect the open-source community to fix most bugs, but even if one assumes that one would need to fix only 1% of all those bugs, that would still mean a cost of 20.640 USD each year.

我们可以期待开源社区修复大多数bug，但即使我们假设只需要修复所有bug的1%，这仍然意味着每年的成本为20.640美元。

2) Implementing Open Source Obligations

2） 履行开源义务

The use of open-source software comes with both mandatory and voluntary obligations. The range of mandatory responsibilities depends on which type of license terms and conditions has been attributed to the code. While there is a multitude of open-source license types hiding behind abbreviations such as GPL, MIT, and BSD, typical responsibilities of the open-source software user are:

开源软件的使用既有强制性义务，也有自愿义务。强制性责任的范围取决于属于该准则的许可条款和条件的类型。虽然GPL、MIT和BSD等缩写背后隐藏着大量开源许可证类型，但开源软件用户的典型职责是：

• You need to develop a user interface (UI) in your product that displays which open-source software has been utilized. If you create software with multiple pieces of open-source software, then the effort of developing this UI is shared among each open-source component.
• 您需要在产品中开发一个用户界面（UI），显示使用了哪些开源软件。如果您使用多个开源软件创建软件，那么开发此UI的工作将在每个开源组件之间共享。
   

  

  Image: UI listing all open source components and their license terms in Nokia X20 smartphone
• 图：列出诺基亚X20智能手机中所有开源组件及其许可条款的用户界面
  
  As a rule of thumb, the more open source you use, the more time you need to put all the content together. The initial development of this UI in a software product takes between 5 to 10 developer days based on two backlog refinement meetings I’ve been part of. I would estimate the maintenance of the content to take one developer day per year.
• 根据经验，你使用的开源软件越多，你需要的时间就越多。基于我参加过的两次积压优化会议，在软件产品中初步开发这个UI需要5到10天的开发时间。我估计内容的维护每年需要开发者一天的时间。
• 2) You need to make the source code available either with the product or separately, which means you need to manage a repository where people can inspect and download the open-source code, depending on the open-source license sometimes even your own code. It would be best to create a workflow allowing people to request the open-source software, create and maintain a software repository where the relevant source code is available, and assign somebody responsible for this.
• 2） 您需要将源代码与产品一起提供或单独提供，这意味着您需要管理一个存储库，人们可以在其中检查和下载开放源代码，这取决于开放源代码许可证，有时甚至是您自己的代码。最好是创建一个工作流，允许人们请求开源软件，创建并维护一个软件存储库，其中包含相关的源代码，并指定负责人。

  

  
  Image: UI displaying guideline on how to get open source code in Nokia X20 smartphone
• 图：关于如何在诺基亚X20智能手机中获取开放源代码的UI显示指南
  The development of the corresponding UI takes some 2 to 3 developer days. Setting up the workflow takes another two developer days. Creating and maintaining the software repository maybe requires one-day using existing infrastructures such as Github.
• 开发相应的UI需要大约2到3天的开发时间。设置工作流需要另外两天的时间。创建和维护软件存储库可能需要一天时间使用现有的基础设施，如Github。
• You want to manage an internal document listing all open-source software licenses and their license terms for potential requests by customers or prospects, especially if you are building business software. Maintaining this document is not rocket science, but I would put aside one developer day for creating it initially and another per year to manage this list (which might be in the raw format the same as the one posted in the UI).
• 您需要管理一个内部文档，列出所有开源软件许可证及其许可条款，以满足客户或潜在客户的潜在请求，尤其是在您正在构建业务软件的情况下。维护这个文档不是火箭科学，但我会留出一天的时间来创建它，每年留出一天时间来管理这个列表（可能是原始格式，与UI中发布的格式相同）。
• Users of your product need to be able to modify an open-source library on the device. If you are building a hardware product, then this means that you need to provide means to flash the device software. You probably need anyway a flashing interface for service purposes but providing the toolchain for users including the documentation can take quite some effort. I’ll allocate 5 developer days for creating and maintaining the toolchain, but that number is probably way too little to get the job done, at least initially.
• 产品的用户需要能够修改设备上的开源库。如果您正在构建硬件产品，那么这意味着您需要提供闪存设备软件的方法。无论如何，出于服务目的，您可能需要一个弹出的界面，但为用户提供包括文档在内的工具链可能需要相当多的努力。我将为创建和维护工具链分配5个开发人员工作日，但这个数字可能太少，无法完成工作，至少在最初是这样。

If we sum up the cost of the mandatory responsibilities, then we get the following costs:

如果我们将强制性责任的成本加起来，那么我们得到以下成本：

One-Time Expenses:

一次性费用：

               5 DEVELOPER DAYS (OSS LIST UI)

+            2 DEVELOPER DAYS (OSS REQUEST UI)

+            2 DEVELOPER DAYS (OSS REQUEST WORKFLOW)

+            1 DEVELOPER DAY (SOFTWARE REPOSITORY)

+.           1 DEVELOPER DAY (OSS PDF DOCUMENT)

+            5 DEVELOPER DAYS (SOFTWARE FLASHING TOOLCHAIN)
--------------------------------------------------------------

            16 DAYS

x       688 USD (DEVELOPER DAILY RATE)
---------------------------------------

   11.008 USD

Annual Expenses:

年度费用：

              1 DEVELOPER DAY (OSS UI Update)

+        0,5 DEVELOPER DAY (OSS REPOSITORY UPDATING)

+        0,5 DEVELOPER DAY (OSS REQUEST HANDLING)

+        0,5 DEVELOPER DAY (OSS PDF MAINTENANCE)
-------------------------------------------------------

           2,5 DEVELOPER DAYS

x        688 USD (DEVELOPER DAILY RATE)
-------------------------------------------------------

       1.720 USD

'The voluntary activities to the open-source community include the contribution of bug fixes, sharing of feature enhancements to the original code, participation in and sponsorship of open-source community events, and taking a more proactive role such as approver or maintainer of open-source components. I will not include any costs related to voluntary activities in this guide because everybody can choose which of them to take up. However, it’s good to remember that an open-source community is a form of society, and it only works when most benefactors contribute back to the project.

“对开源社区的自愿活动包括贡献bug修复、共享对原始代码的功能增强、参与和赞助开源社区活动，以及扮演更积极的角色，例如批准或维护开源组件。我不会在本指南中包含任何与志愿活动相关的费用，因为每个人都可以选择参加哪项活动。然而，最好记住，开源社区是社会的一种形式，只有在大多数赞助者为项目捐款的情况下，它才会起作用。

3) Legal Checks  for Open-Source Software

3） 开源软件的法律检查

Most companies will run a legal check whenever new open-source software is added to the product. The legal assessment serves mainly to verify that the current open-source policies are adhered to. Since there is only a finite number of open-source license types, such a legal check shouldn't take much time. Should a change of open-source licensing policy be necessary, such a legal check will consume a significant amount of time. Many such lawyers act as gatekeepers, and related costs are mainly incurred only once.

每当新的开源软件被添加到产品中时，大多数公司都会进行法律检查。法律评估主要用于验证当前的开源政策是否得到遵守。由于开放源代码许可证类型的数量有限，这样的法律检查应该不会花费太多时间。如果有必要更改开源许可政策，这样的法律检查将耗费大量时间。许多这样的律师充当看门人，相关费用主要只发生一次。

In my opinion, lawyers should be more active on an ongoing basis in monitoring the use of open-source licenses regarding risk management, compliance downstream towards users, compliance to industry patents and IPR owned by other parties and protection of own IPR. Some of these activities one cannot quantify easily, and some are such that they may create a risk to jeopardize the whole business.

在我看来，律师应该在持续的基础上更加积极地监控开源许可证的使用，包括风险管理、对下游用户的合规性、对行业专利和其他方拥有的知识产权的合规性，以及对自身知识产权的保护。其中一些活动无法轻易量化，有些活动可能会产生风险，危及整个业务。

However, the reality in most companies is different, and legal checks are performed only once. A legal check, confirming the license terms and conditions online and doing some research on whether the risk is worthwhile taking, might not take more than a day, I would expect that one of these checks needs to be done each year.

然而，大多数公司的现实情况不同，法律检查只进行一次。法律检查、在线确认许可条款和条件，以及对风险是否值得承担进行一些研究，可能不会超过一天，我预计每年需要进行一次检查。

              1 SENIOR ATTORNEY DAY

x   1.038 USD*
--------------------------------

     1.038 USD

* Average Annual Salary of Senior Attorney in the US according to Glassdoor.com: 148.000 USD. Indirect costs: 207.000 USD, Daily rate: 1.038 USD

*Glassdoor.com的数据显示，美国高级律师的平均年薪148000美元。间接成本：207000美元，日费率：1.038美元

4) Compliance Management for Open-Source Software

4） 开源软件的法规遵从性管理

Compliancy Management includes all activities in the enterprise verifying that

合规管理包括企业内验证以下各项的所有活动：

• the companies’ products contain only open-source software in line with the internal IPR and open-source policies
• 这些公司的产品只包含符合内部知识产权和开源政策的开源软件
• the company complies with the open-source obligations
• 公司遵守开源义务

85% of the audited codebases contained license compliance issues, according to a 2019 whitepaper from Synopsys. Compliancy should be preferably achieved proactively through establishing clarity of the open-source policies and training of the software developers. The previously mentioned legal checks are also a part of achieving compliance. In addition, many companies are applying post-development compliance practices such as automatic software scanning and license management tools.

​Synopsys 2019年发布的白皮书显示，85%的经审计代码库包含许可证合规性问题。最好通过明确开源政策和培训软件开发人员来主动实现合规性。上述法律检查也是实现合规性的一部分。此外，许多公司正在应用开发后的法规遵从性实践，如自动软件扫描和许可证管理工具。

Automated software scanning products such as Snyk or Debricked are often cloud solutions with per-developer pricing. The prices per developer range from 25 USD to 139 USD per month (at least when it comes to publicly visible pricing). I will assume that five software developers need a license for this capability. These products help identifying whether one's product contains open-source software that might not comply with the companies' policies, such as GPL3-licensed code. Since applications nowadays include millions of lines of code, automated scanning might be an effective practice to avoid compliance issues.

Snyk或Debricked等自动化软件扫描产品通常是按开发者定价的云解决方案。每个开发商的价格从每月25美元到139美元不等（至少在公开定价方面）。我假设五名软件开发人员需要一个许可证来实现这一功能。这些产品有助于确定一个人的产品是否包含可能不符合公司政策的开源软件，例如GPL3许可代码。由于如今的应用程序包含数百万行代码，自动扫描可能是避免法规遵从性问题的有效做法。

             5 CONTRIBUTING SOFTWARE DEVELOPERS

x        25 USD / Month

x        12 Months
-------------------------------------------------

    1.500 USD

The cost for Compliance Checking Tools should be allocated partially in accordance to the different OSS components in the product.

合规性检查工具的成本应根据产品中不同的OSS组件进行部分分配。

Total Cost of Ownership of Using Open-Source Software

使用开源软件的总拥有成本

The Total Cost of Ownership (TCO) of open-source software can be compared to getting a car. A car has a specific acquisition cost. However, in addition to the price you pay the car dealership, you will need to account for any additional expenses such as registration, insurance, and support costs. While the acquisition cost of open-source software is zero, there are other costs over the lifetime of a product that one needs to be aware of.

开源软件的总体拥有成本（TCO）可以与买辆车相比。汽车有特定的购置成本。但是，除了向汽车经销商支付的价格外，您还需要考虑任何额外费用，如注册、保险和支持成本。虽然开源软件的购买成本为零，但在产品的整个生命周期中还有其他成本需要注意。

For this guide, I will calculate the TCO in a five-year timeframe, probably the minimum of the lifetime of commercial software. I will split the TCO into initial costs and annual recurring expenses. As mentioned before, I will be excluding unlikely or voluntary expenses such as litigation fees or community contribution expenses to keep things simple.

在本指南中，我将计算五年内的总体拥有成本，这可能是商业软件生命周期中的最低值。我将TCO分为初始成本和年度经常性费用。如前所述，为了简单起见，我将排除不太可能或自愿的费用，如诉讼费或社区捐款费用。

One-Time Expenses:

一次性费用：

OPEN-SOURCE OBLIGATIONS: (16 DEV DAYS * 688 USD) = 11.008 USD

开源义务：（16个开发日*688美元）=11.008美元

Annual Expenses:

年度费用：

FIXING BUGS (3M LOC / 20 BUG / LOC / 10 YEARS x 0,5 DEV DAYS x 688 USD x OWN 1%) = 20.640 USD

修复漏洞（3M LOC/20 BUG/LOC/10年x 0.5开发日x 688美元x自有1%）=20.640美元

OPEN-SOURCE OBLIGATIONS: (2,5 DEV DAYS x 688 USD) = 1.720 USD

开源义务：（2.5个开发日×688美元）=1.720美元

LEGAL CHECKS: (1 ATTORNEY DAY x 1.038 USD) = 1.038 USD

法律支票：（1律师日×1.038美元）=1.038美元

COMPLIANCY SCANNING (5 DEVS x 25 USD / MONTH X 12 MONTHS): 1.500 USD

合规性扫描（5个开发者x 25美元/月x 12个月）：1500美元
------------------------------------------------------------------------------

   24.898 USD 

x            5 YEARS

------------------------------------------------------------------------------ 

 124.490 USD

+ 11.008 USD

------------------------------------------------------------------------------

 135.498 USD

Conclusion

结论

In the grand scheme of things, 135.000 USD isn't much when developing your software product. An alternative to the open-source cost is the cost of commercially supported software, which often comes in a SaaS-subscription model.

总体来说，在开发软件产品时，135000美元并不算多。开源成本的另一个替代方案是商业支持软件的成本，它通常以SaaS订阅模式提供。

On purpose, I’ve been cautious about recommending which way to go: open-source or commercial software. The decision always depends on many factors. The TCO is one of them. Personally, and I'm biased since I work for the Qt Company, I would recommend doing both: use commercially supported software based on open-source and contribute upstream to open-source projects. Why? While the acquisition cost of open-source is very attractive and many of the related costs can be shared among several open-source components, it takes a single critical bug escalated by a key customer of yours that you find hard to fix and you would have loved to have somebody to back you up. The benefits of open-source and contributing back to it lie in the better quality of the software. Hence, my recommendation is to be active in the community, which helps everybody ultimately.

我一直在谨慎地建议该走哪条路：开源还是商业软件。决定总是取决于许多因素。TCO就是其中之一。就我个人而言，我有偏见，因为我在Qt公司工作，我建议两者兼而有之：使用基于开源的商业支持软件，并为开源项目的上游贡献力量。为什么？虽然开源的收购成本非常有吸引力，而且许多相关成本可以在几个开源组件之间分摊，但只有一个关键的错误被你的关键客户升级，你发现很难修复，你希望有人支持你。开源的好处和回报在于更好的软件质量。因此，我的建议是积极参与社区，这最终会帮助所有人。

Did you find this guide useful? Check out Qt's guides on software development, such as the Smarter Products Need Smarter Development guide from Forrester commissioned by the Qt Company.

​你觉得这本指南有用吗？查看Qt的软件开发指南，例如由Qt公司委托Forrester提供的《更智能的产品需要更智能的开发指南》。