Open Source DIY Is Open Source Wrong
If your team is creating their own open-source languages instead of using third-party resources, chances are you're wasting time and money.
Join the DZone community and get the full member experience.Join For Free
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.
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 check against GPL, LGPL or other undesirable licenses
- Compile and debug the build
- Deploy, install and verify the environment
Any step skipped (and many of them routinely are) just pushes 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 modeling, 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.
Published at DZone with permission of Dana Crane, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.