Hi, everyone! This is Melissa Strong reporting today. I bring to you part 5 of my Open Source series. If you haven’t read previous articles from the series and would like to do so, you will find them here: one, two, three, and four.

Without further ado, let’s get to know Docker.

Imagine a data sculpture. Maybe it's a wall of small screens pulsing with live climate readings, or a room-sized installation where visitors walk through a decade of migration data rendered in light. The artist builds it in her studio over months. Every cable is where it should be, every sensor calibrated, every script running cleanly on her laptop. Then the piece gets invited to a gallery across the country, and the real trouble begins.

The screens behave differently under the gallery's lighting. The Python version on the loaner machine is a hair too new for one of the libraries. A font renders wrong. The serial port the sensors expect isn't where the script thinks it is. None of these problems existed in the studio. All of them exist now, three days before opening night.

This is the situation Docker was built for, and it's why the tool belongs in a series about open source visualization even though it never draws a single pixel itself.

A touring exhibition is never only the artwork. It's the mounts, the lighting rigs, the wall text, the climate controls, the specific extension cords that fit the specific plugs. A good touring crew packs all of it into cases designed so that when the show arrives at the next venue, everything unfolds into the same configuration it had before. The art looks the way the artist intended because the environment around it traveled too.

Docker is the equivalent for software. It packages an application together with the operating system pieces, language runtimes, libraries, and configuration files it needs to run, and it bundles all of that into something called an image. When the image opens on another machine, the software finds the same conditions it was built in. The Python version is correct. The libraries are the exact ones that were tested. The fonts are where the code expects them. Nothing depends on what the host machine happens to have lying around.

For a physical data visualization piece, that means the artist can hand the gallery a single image and trust that the thing inside will behave. The show travels, and the studio travels with it.

Reproducibility in visualization is usually discussed in terms of data and methods, but for work that has to actually run, it also means something more practical. Will the piece still render? Will the interactive elements respond? Will someone who opens the project two years from now be able to see what the artist saw?

A Dockerfile is, in a way, the packing list for a crate. It spells out exactly what goes inside and in what order: start with this base layer, add these libraries, copy in this code, run this command when the crate is opened. Anyone with the packing list can rebuild the crate from scratch. And because the list is a plain text file, it can live in the project repository right next to the code and the documentation, where it gets versioned and reviewed like everything else.

That transparency is what makes Docker feel at home in the open source world. The environment stops being a private thing that lives on the artist's machine and becomes part of the work itself, visible to anyone who wants to understand how the piece is built.

The value of a touring exhibition kit shows up most clearly when the show opens somewhere new. A classroom, for example. Students arrive with different laptops, different operating systems, different levels of comfort with the command line. Without something like Docker, the first hour of a workshop on physical data viz can easily be lost to installation errors that have nothing to do with the lesson. With a prepared image, the instructor hands everyone the same crate, everyone opens it, and the actual teaching can start.

Collaborators benefit in the same way. A researcher working on the data pipeline, a designer working on the visual output, and an engineer working on the hardware interface can all develop against the same environment even though their own machines are wildly different. Handoffs between them stop involving long setup documents and start involving a single command.

And then there's the moment the piece moves from studio to public. A physical data visualization often begins as an experiment on a bench and later becomes something that has to run unattended in a gallery, a lobby, or a classroom kiosk for weeks at a time. That transition is where fragile projects tend to break, because production conditions are never quite the same as development conditions. Docker narrows that gap. The crate that ran on the artist's bench is, more or less, the crate that runs on the exhibition floor.

Docker doesn't make anything visible on its own. It draws no charts, designs no layouts, maps no data. What it does is make sure that everything else in the visualization toolkit can travel. The Observable notebook, the Penpot design file, the Bootstrap layout, the Git repository, all of it becomes easier to share, teach, and reinstall when the environment around it is packed up and labeled instead of left behind.

For physical data viz in particular, where the work genuinely has to be trucked across the country and set up by someone who wasn't there when it was built, that kind of portability isn't a convenience. It's what lets the piece exist somewhere other than the studio it was born in. Open source visualization is at its best when the work can keep moving, and Docker is a big part of how it gets to travel.