How can you overcome challenges when using open-source programming languages in control engineering?

Control engineering requires hard or soft real-time management in a highly concurrent fashion, its very hard to beat Erlang/Elixir in the latter capacity as it was designed for Telecom Control Engineering with its Open Telecommunications Platform. It can be paired with more efficient numerical languages like the same libraries that power Python Machine Learning, including as well extremely efficient and defensive systems languages like Rust. Doing so in such a way that simplifies parallel and distributed programming within a functional paradigm. In regards to hard real-time the language may be less critical than the use of an RTOS (Real Time OS). In either case, hierarchically approaching system events through supervision simplifies control

Open-source programming is an exciting and productive environment for those with an open mind. Unfortunately there are only a handful of languages in which the "Framework" or the best practices and standards were crafted by the designers of the open-source language itself. Open Telecommunications Platform provides an extremely elegant approach to managing the complexity of code, it provides an infrastructure which encapsulates the complexity of Java and OOP while maintaining almost the performance of C++. However unlike Java which requires hundreds of refactoring approaches, classes and techniques. OTP requires only 4-5 behaviors, with a supervision layer that can be recursively structured. Robust and manageable systems use verbs not nouns.

Personally, I'm old enough to remember when every question could be found on IRC, today most things have moved over to Slack and Discord, web forums, meetup groups. There is an unspoken rule that to receive help, you should hang out and try to answer questions that you can and in the process people will consider helping you with your own questions. Although you can learn a lot from others, the best way to learn is simply through trial and error trying to solve problems which are of personal interest. In this way you will likely cross most of the problems other people are facing and ultimately you may find your own comprehension of the basics & gotcha's are starting to expand. This is the real power of Open source systems, sharing knowledge

One of the best ways to understand the internals of both the software routines and mathematics involved with a community opensource project is to look in the issues section of it and discover the broken sharp edges of their projects and file them down. This is a practice the industry refers to as dealing with Technical Debt. Being that there are few people in the world capable of reduction, the mere attempt will likely gain you some favors. Running servers or donating equipment for the communities use is an even more powerful way to ingratiate yourself with project stakeholders. Its usually far easier to find something to improve in their software repository than it is your own, and ultimately the point of this is not to reinvent the wheel.

What is the open-source programming alternative to an open-source alternative... Huh?! That would probably be a different open-source solution that offers similar functionality and benefits. In other words, it is a substitute for the original open-source alternative, providing an additional option for users who are looking for a free and flexible solution. The main issue with using anything proprietary is that you have to deal with two very likely issues. You are contributing to their moat and not yours. They will likely increase their prices and decrease their value over time. It is often best not to tie any part of your stack in with proprietary software, unless very trivial. Such as a graph or chart display tool or something very minor.