Guide to the Total Cost of Ownership of Open-Source Software
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.
This guide summarizes the costs of using open-source software for professional software development based on public information and my 15 years of experience.
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.
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.
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)
- 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.
1) The Cost of Fixing Open-Source Code Yourself
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.
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.
It takes a developer between 0,5 to 2 days to fix a software bug.
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.
Open-source software has an average of 20 bugs per 1000 lines of code.
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.
Qt Framework Essentials libraries include some 3 million lines of code
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:
/ 10 YEARS
x 20 BUGS
/ 1.000 LOC
x 0,5 DAYS
x 688 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.
2) Implementing Open Source Obligations
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:
- 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.
Image: UI listing all open source components and their license terms in Nokia X20 smartphone
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.
- 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.
Image: UI displaying guideline on how to get open source code in Nokia X20 smartphone
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.
- 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).
- 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.
If we sum up the cost of the mandatory responsibilities, then we get the following costs:
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)
x 688 USD (DEVELOPER DAILY RATE)
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)
'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.
3) Legal Checks for Open-Source Software
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*
* 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
4) Compliance Management for Open-Source SoftwareCompliancy 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.
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.
5 CONTRIBUTING SOFTWARE DEVELOPERS
x 25 USD / Month
x 12 Months
The cost for Compliance Checking Tools should be allocated partially in accordance to the different OSS components in the product.
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.
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.
OPEN-SOURCE OBLIGATIONS: (16 DEV DAYS * 688 USD) = 11.008 USD
FIXING BUGS (3M LOC / 20 BUG / LOC / 10 YEARS x 0,5 DEV DAYS x 688 USD x OWN 1%) = 20.640 USD
OPEN-SOURCE OBLIGATIONS: (2,5 DEV DAYS x 688 USD) = 1.720 USD
LEGAL CHECKS: (1 ATTORNEY DAY x 1.038 USD) = 1.038 USD
COMPLIANCY SCANNING (5 DEVS x 25 USD / MONTH X 12 MONTHS): 1.500 USD
x 5 YEARS
+ 11.008 USD
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.
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. In addition, providing software also under open-source license ensures that students and research projects contribute to a healthy developer ecosystem. Hence, my recommendation is to be active in the community, which helps everybody ultimately.
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.
Subscribe to our newsletter
Try Qt 6.6 Now!
Download the latest release here: www.qt.io/download.
Qt 6.6. is a feature release with focus on improving UX capabilities including responsive UI technology and the Qt Graph module.
Check out all our open positions here and follow us on Instagram to see what it's like to be #QtPeople.