Okay, let’s lay it on the line right up front: if you’re still building and managing your own open source programming languages, you’re doing open source WRONG. You’re adding drag to your software development cycle, AND multiplying that drag every time your developers add a new language to their development environment.
Let’s take it from the top. ActiveState has been in the open source languages business for more than 20 years. We find that most organizations take one of two approaches when it comes to building and managing their own open source: i) either a centralized, dedicated build team, or else ii) a distributed approach that makes every project team responsible for their own language builds. In either case, what we’ve learned is that developers spend far more time than expected managing their language instead of coding with their language.
DIY Overhead
When your team builds their initial Python development environment, they need to:
- Download the core Python language
- Research and install (and sometimes get corporate approval to use) appropriate third-party packages, along with their dependencies
- Resolve dependency conflicts
- Research and resolve vulnerabilities
- Check all package licenses to ensure against GPL, LGPL or other undesirable license
- Compile and debug the build
- Deploy, install and verify the environment
For more information on the overhead associated with DIY open source, download our infographic
Any step skipped (and many of them routinely are) just push the work downstream to your:
- DevOps teams trying to implement the language in their build and test environments;
- Ops teams who need to resolve security issues in production;
- Audit teams who spend months performing open source license audits to ensure against litigation risk.
And when it comes to Python development environments, we’ve also encountered instances where the data science team is responsible for building their own language. Your data scientists are extremely expensive resources that should be focused on data modelling, not managing Python. Data scientists are not developers, and often wrestle with application tooling, or can feel blocked waiting for key machine learning packages to be approved for use before they can start working with them.
All of this adds up to a huge opportunity cost: expensive resources that could be better spent addressing your ever-growing backlog, rather than focusing efforts on commoditized programming languages.
The Modern Software Factory
Software is more assembled from third party open source components than coded by hand nowadays. Vertical integration in the manufacturing industry went out of fashion more than 50 years ago for good reason, allowing manufacturers to focus on assembling third-party components into finished products.
The lessons learned send a clear message: you should be sourcing your third party components from a trusted supplier and focusing on the finished product, not the raw materials.
ActiveState provides a number of open source language distributions that often meet enterprise needs out of the box. However, we also build, verify, secure and maintain custom versions of languages for clients that require special builds.
For more information on ActiveState’s open source programming languages, view our language distros
