Measuring the Costs of Open Source Language Builds
An open source language build can often be a complex, overhead-heavy process. It can take hours and even days for a developer to get their initial build environment set-up completed. And that’s just including building all the components, packages and libraries they’ll need during development. On top of that, there’s the time required to set up their development and test environments. And this wasted time isn’t just a one-off cost. It happens all the time, not just when you start a project but also throughout the project’s life cycle. That includes when languages get upgraded, when components get updated or switched around, when new dependencies get added or even when operating systems get updated.
Most enterprises take environment builds for granted: just another cost of doing business that‘s rarely scrutinized. But from a management perspective, if you’re looking for time and resource savings (and who isn’t?), it’s important to understand all of the costs associated with open source language builds. That’s necessary to be able to fully evaluate a project’s return-on-investment (ROI.)
The Factors and Criteria That Go into the Overall Cost of Open Source Language
The ongoing wasted effort that developers expend on new projects has come to be an accepted inevitability. It’s often considered to be just part of the process of software development, buried within “set-up time” and “environment configuration.” This isn’t just frustrating; it steals budget as well as time.
These costs are “invisible”; your team is racking them up, and you’re losing developer productivity and project velocity. And since you’re not tracking, accounting or understanding the wasted time and associated costs, you’re taking on greater risk. These big, hidden costs are a primary reason why software projects go over time, over budget, or both. For example, if something breaks during a necessary upgrade, it cascades to affect deliverables, budgets and productivity. And, over time, your build requirements will grow. As your project increases in size and scope, so do your “invisible costs.”
Understanding the True Value of These Hidden Costs
Managers need to 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. There are many factors to consider as you begin to calculate your burn rate (the yearly cost of building, updating and maintaining all of your languages), including:
- Linear scaling: 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: A package you need may never have been built for your target platform. Or the package may require C libraries to be compiled to speed up compute-intensive routines. Or a dependency may force you 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 build complexity and, consequently, the time and resources required.
- Security check: There are multiple systems, as well as checks and balances, that software organizations use 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 and test environments to ensure nothing accidentally slips through the cracks.
- License audits: Driven internally by dedicated personnel, or else externally by a consulting service, audits are typically a yearly event. Given a list of all applications and their open source components, the auditor(s) identify how the overall component is 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.
- Costs of curating: Which third-party packages can be brought into the organization is often strictly controlled. 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 begin working with them can be significant, but they are rarely included in any ROI calculation.
- Compliance: You may have strict regulatory rules with which you need to comply, depending on your industry. 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.
How do You Reduce these Hidden Costs?
You need to know what your hidden build engineering costs are before you can lower them. You need to track them and iteratively budget and account for them. They need to be included in your onboarding process (and costs), as well as identified in software estimates. Make sure the time for build engineering is captured in project costs and project velocity estimates. We all need to practice rigor in tracking these processes so we can shine a light on how much time is wasted. But the situation can’t be improved if we — as an industry — don’t elevate its importance and start thinking about real solutions.
Calculate Carefully
Being able to determine the ROI of a project involves understanding where money and time are being wasted. Automating build engineering is the only way to ensure lower costs and increased throughput, but fully automating the build engineering for an open source language hasn’t always seemed worth the cost. The reality, though, is that the hidden costs of having your developers manually building their own languages are costing your organization far more than you think. Carefully calculate the factors that contribute to your build burn rate and then focus on lowering those costs.
Feature image by Gerd Altmann from Pixabay.