I’ve been watching Battlestar Galactica again, and I was struck by something that seems to be a very common plot device in space-based stories: Starships of all shapes and sizes are able to be reconfigured in seemingly infinite ways on the fly by the crew. In BSG, the crew networks disparate systems together to create a large compute cluster and implement a multi-layered firewall to protect against the Cylon virus. In Star Trek, the crew must constantly adjust the phasers by rerouting it through the main sensor dish or change the frequency of the shields to defeat some advanced enemy. In Star Wars, Han can easily reroute power to strengthen the shields.
Starships must be large and very complex systems. They have thousands of subsystems. Computer programs controlling doors, weapons, replicators, power, life support, sensors, water recycling, artificial gravity, and many other systems need to be written and tested before being put in to use in an operating starship. Designing and implementing this much code that is responsible for the life and death of all aboard is an impossible task for one company.
Now, for all these starships to be constantly reconfigured on the fly, either the requirement specs given to the developers describe all possible scenarios that the crew of the ship may face or must detail a standard API that all subsystems should adhere to.
There is no way one can predict all situations in which a piece of software may be used. All of these subsystems must have a standard interface that allows them to all interact with one another. Because you never know–you may need to reroute the water filtration through the warp core to kill the trans-dimentional virus that is infecting the crew.
But simply having a standard API isn’t enough. Starship crews need to be able to write programs themselves in order to tell these separate systems to work together in some custom way. Sure, their may be some large patch panel of sorts to redirect some output to some other input, but at some point, Wesley will need to do something that the system wasn’t designed to do. And, of course, bug fixes and patches will need to be applied periodically.
Given these realities, I’ve come to the conclusion that starships must run open-source software. The crew needs access to the source code to make changes as necessary. Disparate systems need to be modified to work together. Crew members (and captains, apparently) need to know exactly how these systems work. Proprietary software would probably not include the source code in the installation. Even if the code were included, it would most likely have so many disclaimers and warranty-voiding clauses in the EULA (or worse, DRM) to make any such modifications useless or impossible for the end-user.
Imagine Galactica docking and being told, “I’m sorry. You have modified your installation of the software, and we can’t upgrade you to the Cylon-proof Weapons Pro v12 unless you revert your changes.”
Or maybe Han is getting pulled in by a tractor beam (as he is wont to do). He engages the auxiliary power, and, “Thank you for using Power Systems 3.0. A new patch is available for this software. Would you like to download it now? Answering ‘No’ will disable the auxiliary power systems.”
The only way for all the complicated interconnected systems of a starship to be useful, reliable, and developed in an efficient manner is for it to be open source.
When building a starship, use open source software.
Use open source software–it’s the future.
Use open source software–don’t let the Borg/Cylons/Empire win.
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
The thoughts expressed here are my own and do not necessarily represent those of my employer.