Category Archives: Open Source Spaceflight Revolution
by Jeremy Wright, Innovations Technology Solutions, LLC
[Editors Note: I’ve been asking you to be patient on the hardware front for years now, so believe me when I say words cannot capture how excited I am to introduce you to Jeremy Wright--a new Mach 30 volunteer and major contributor to our very first open source spaceflight hardware project. Thank you Jeremy for taking us over the breach--and thank you, patient reader, for sticking with us through the “boring” parts.]
Mach 30’s Shepard Test Stand project has contributors spread over 4 U.S. states and 2 different time zones, so making sure that everyone gets a chance to leave their mark on the project can be a real challenge. Add to that the fact that we’ll not only be exchanging ideas, but also things like drawings and source code, and the challenge gets even more interesting. This kind of collaboration is possible because of what Mach 30 is doing through the Open Design Engine.
On Shepard, we’ve started this collaborative process in the project’s forums and wiki by working on the why, who, and how questions that will guide us through the rest of the design process. These are seemingly simple questions like:
- “Why are we building this?”
- “Who’s going to use this?”
- “What features does it need to have?”
However, without solid answers to these questions we run the risk, as contributors, of not all pulling in the same direction. As we head deeper into the project, these answers are being turned into a list of requirements that will keep us grounded and focused throughout the life of the project. That way we’re all on the same page, and when we get to the more exciting tasks of building and using the test stand, we’ll have our best shot at hitting the target. These requirements will start to pay off right away by informing the creation of the system block diagram, which is our next step.
If you haven’t yet, swing by opendesignengine.net and look over the Shepard Test Stand project. ODE will be moving into public beta soon, and we’d love to have the help of anyone who’s interested in moving humanity toward a space-faring future.
In short, “ad astra per civitatem” – to the stars through community
No worries! We recorded the live event. You can watch it below:
Executive Director, School Factory
Twitter played an important part of the party, with guests posting questions for the panelists, answering trivia questions, and sharing great links. Take a look below for highlights, or follow this link for the full history of the conversation.
Party Sketch Notes
In addition to serving as a panelist, James Carlson “doodled” the party. Click the image below to see the whole set!
Thanks again to our panelists, volunteers, and everyone who was able to join us on Twitter. We had a blast!
One of the first questions people ask when I talk about open source spaceflight is “What about ITAR?” It’s no wonder. Nearly everything to do with spaceflight technology is export controlled, making it illegal for US citizens and permanent residents to openly share spaceflight hardware and its supporting documentation. Needless to say, ITAR is a significant challenge for Mach 30 and other open source spaceflight groups.
I’ve spent a lot of time thinking about how Mach 30 might approach these challenges. The short answer is obvious. We work within the boundaries of ITAR. That doesn’t mean, however, we are abandoning are open source values.
The long answer is we need to develop a combination of approaches to openly publish as many of our projects as we can, while ensuring we are fully compliant with the requirements of ITAR. To that end, I’ve come up with four potential paths that might allow Mach 30 to develop spaceflight hardware in a (mostly) open way, while still staying in full compliance with the restrictions placed upon US based persons under ITAR.
Develop quasi-open source spaceflight projects
The first approach to dealing with ITAR, and in the early days the most noticeable approach, is running quasi-open source spaceflight projects. Mach 30 could host all of its spaceflight projects on a private copy of Open Design Engine, access to which will be limited to individuals who we have verified are US persons and who have received appropriate ITAR training in order to comply with ITAR. If you look at the formal definition of open source hardware, one of the requirements to be open source hardware is providing unrestricted access to the design documentation. Our space projects will fail to meet this requirement due to our insisting people agree to follow ITAR in order to gain access to our designs, hence calling them quasi-open source.
Create a catalog of published spaceflight technology
The second approach is crowd sourcing a catalog of the large body of published spaceflight technology. Why is this important? Simply put, any technology which is already published in public literature is exempt from ITAR. Let me repeat, if you can find a public article, book, or other source which fully documents a piece of spaceflight technology, then that technology cannot be withheld by ITAR. And, it turns out there is a large body of scholarly articles, textbooks, and government reports, especially from NASA, covering spaceflight technologies. Mach 30 could launch a new wiki to catalog, tag, and for openly licensed materials, archive publicly available materials concerning spaceflight technologies. This new wiki will be a public resource to help identify which projects need to be quasi-open source, and which can be fully open source.
Develop core technologies in non-space disciplines
The third approach is developing technologies as part of fully open source projects in non-space disciplines. Many core systems which are important for spaceflight are also applicable to non-space applications. Examples include power management, sensing, and command and control. By developing these systems in non-space applications, we could avoid the ITAR triggers and still develop the systems in full compliance with the definition of open source hardware. Projects could include solar powered robots to develop power management systems, autonomous Remotely Operated Vehicles (ROVs – remote controlled submarines for underwater exploration) to develop sensors and their related systems, and high altitude balloons to develop command and control systems. Once the technologies have been developed in these fully open projects, they can be ported into the quasi-open projects for use in space applications, but the core development will still be available in the non-space projects.
Partner with non-US groups for technology transfers
The fourth and final approach is to establish partnerships with non-US groups and to develop approved technology transfers. One such group Mach 30 is already discussing this approach with is CSTART. CSTART is an open source space organization which started during an online discussion at reddit.com. Its membership includes people from all over the world. At a recent joint meeting on ITAR, CSTART and Mach 30 discussed CSTART becoming a non-US group and its US members joining Mach 30. Both groups could then work within ITAR and other export control regimes, while they investigated the processes required to transfer technology into or out of the US. We imagine it will be easier to transfer technology into the US, but we will work diligently to find opportunities to legally transfer technology both ways.
So,where once there was the big scary ITAR, we now have a potential path forward for open source spaceflight. Please share your ideas for additional paths, as well as potential pitfalls of these suggested paths, in the comments!
ad astra per civitatem