As discussed in a previous blog post, all of the costs of build engineering are rarely taken into consideration when determining overall project costs. But unless you’re just standardizing on a Commercial Off the Shelf (COTS) language distribution from your Cloud provider, Operating System vendor, or other commercial entity, your devs are either:
- Building the language distribution they require for their project themselves, or
- Using a language distribution your centralized build team has prepared for them
While these two approaches allow developers the greatest flexibility when it comes to creating language distributions specific to their project’s needs, it’s important to understand the ramifications, such as:
- More “works on my machine” incidents due to non-standard dev environments
- More dev/test/deploy cycles due to poorly updated/maintained runtime environments
- Legal and security reviews that delay time to market
ActiveState has created a “Cost of Open Source” calculator to help managers understand the costs that come with building, updating and maintaining their own open source language distributions on a per project – or even just a per language – basis.
Calculating the True Cost of Open Source
As shown in the screenshot above, ActiveState’s “Cost of Open Source” calculator distills the costs of building open source into a few recognizable categories. But there are still a number of sliders and assumptions you should be aware of before calculating your burn rate:
- FTE – An annual Full Time Equivalent (FTE) cost is used, based on India employee rates.
- Linear Scaling – The calculator scales linearly with each new language and operating system you add. While it’s true that every language has its own quirks, inconsistencies and gotchas that can trip up the uninitiated (and will therefore require its own build engineering expertise), general build knowledge is still broadly applicable to any language. As a result, adding a second language doesn’t truly mean double the costs. The same can be said for adding another operating system.
- Build Complexity – This is a “catch all” category intended to cover multiple situations that might increase the difficulty of a build. For example, a package you need may never have been built for your target platform. Or the package may require C libraries to be compiled in to speed up compute-intensive routines. Or you may be forced to use an older version of a package that requires a security patch to be backported. Or perhaps it’s a debug build that’s required. Any of these factors can significantly increase complexity, and therefore the time/resources required.
- License Audits – Audits are typically a yearly event, driven internally by dedicated personnel, or else externally by a consulting service. Given a list of all applications and their open source components, the auditor(s) identify how they’re licensed, as well as how all embedded routines/libraries/code are licensed. They can then determine whether the licenses are compatible; whether the developers have complied with the requirements of the license, and whether the licenses adhere to corporate policy.
- Regulatory Compliance – Depending on your industry, you may have strict regulatory rules with which you need to comply. For example, if you’re in the eCommerce business, you might require that any third party packages you use must be able to be support PCI-DSS.
- Security Review – Software organizations have multiple systems, as well as checks and balances to ensure the open source code they deploy to production is free of vulnerabilities. The same should be true about the open source languages you deploy in your dev environments.
- Curating Costs – Many industries have strict controls around which third party packages can be brought into the organization. The costs associated with curating a set of packages that have been approved by a technical lead, reviewed by legal, and verified by InfoSec before a developer can even begin working with them can be significant, but are not included in the calculator.
Build Burn Rate then is the yearly cost of building, updating and maintaining all of your DIY languages.
Open Source Language Build Costs for SMBs
As an example, if you’re a Small or Mid-sized Business (SMB), chances are each of the developers in your teams are building their own development environment themselves, including the language distribution they require. In some cases, 1 or 2 members of a team may be tasked with building, updating and maintaining a standard language distribution that all team members can incorporate in their dev environments.
If your SMB has standardized on 2 languages, develops on Windows and deploys on Linux, your annual build burn rate might look like:
Open Source Language Build Costs for Large Enterprises
If you’re a Large Enterprise (LE), it’s likely that the task of building, updating and maintaining the languages all your projects use has been centralized in a team of 4-6 build engineers. Where the LE has standardized on a core technology stack, this can mean the build team is dealing with only 2 or 3 languages at most. In other cases, where the business is committed to using the best language for the job (e.g., building out a set of APIs), the team may be dealing with as many as half a dozen or more different languages.
If your LE has standardized on 4 languages, has developers that work on Windows, Mac & Linux machines, and also deploys to Linux, your annual build burn rate might look like:
Try it out yourself to see what your burn rate might be:
[cesis_roi_calculator]
Of course, the “Cost of Open Source” calculator results in a monetary cost to your business of taking a DIY approach to building your own languages. But there’s also the opportunity costs, as well, which is discussed at length in another blog post.
How to Decrease the Cost of Build Engineering
If you’re concerned about the monetary and/or opportunity costs of building your own languages, the ActiveState Platform can help. Using it, a single technical resource can build, update and maintain multiple languages at a cost of only a few days per year because the ActiveState Platform:
- Automates language builds
- Rebuilds languages on demand with the latest versions of the packages and dependencies required
- Can identify poorly licensed and vulnerable packages*
Interested? Want a personalized demo or looking for specific packages or support? Schedule a call to learn more.
* currently only available for Python
1These options have other costs, as discussed in our One Size Fits All blog post
