Shortly after Open MCT was open-sourced, around 2015 to 2016, the JPL, the Jet Propulsion Laboratory, built a distribution on top of it called VISTA, or Visualization for Telemetry Analysis.
It gave mission teams a way to visualize and analyze telemetry, and it has been used across several JPL missions, including the Mars 2020 program. The important part is that VISTA sits on top of Open MCT rather than beside it: it includes all of Open MCT, plus a JPL-specific integration layer.
VISTA is also a good example of the older pattern for connecting Open MCT to the rest of the telemetry infrastructure.
But there is a problem with that pattern: coupling.
Previously, if you wanted to use and customize Open MCT, you would download the software, clone the project directly, configure it, and start your server from there.
This was incredibly practical for me personally. It made Open MCT extremely easy to learn.
But eventually you need portability. You need to be able to maintain different configurations, update versions independently, integrate Open MCT with other systems, and move things around without having to maintain your own modified copy of the entire project.
None of this makes the old process impossibly complicated. It just makes it slightly annoying as the system grows.
And this is where the Open MCT Build Tool (or just mct) comes in.
This is a command-line interface currently being developed to make this process considerably easier, especially when Open MCT needs to work alongside other projects.
The project started roughly a year or a little more ago, and since then it has gradually expanded. There has actually been quite a bit of activity lately, which is why I’ve been spending some time studying how it works.
Now, the old openmct-mcws repository bundled a set of plugins from Open MCT, hardcoded in a loader file, together with the integration required to connect it to the telemetry backend. This meant that if you wanted to move to a newer version of Open MCT, the upgrade wasn’t necessarily isolated. You also had to make sure that all of the integration around it continued working.
As you can imagine, that isn’t particularly convenient.
With mct, that relationship becomes much simpler.
Instead of maintaining everything as one tightly coupled application, you now have a repository structure where the instance can be described through configuration. A YAML file defines how everything fits together, including the Open MCT instance and the components around it.
So changing or maintaining an Open MCT instance becomes much less about modifying Open MCT itself and much more about configuring what should run around it.
It’s a relatively simple architectural change, but I think it makes the entire model considerably cleaner.
As I mentioned, mct still seems to be a relatively small project. It doesn’t have a huge commit history or anywhere near the activity of Open MCT itself.
But from what I’ve been seeing recently, it also seems to be becoming a much more serious project.
And I think it is a pretty interesting direction for how Open MCT can be distributed and integrated going forward.