Category Archives: OSHW

What about ITAR?

by .
3 Comments
Restricted Area

Image by Jeremy Brooks via Flickr

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

Ask a silly question…

by .
4 Comments

Well, I’m back at ISPCS again, one of my favorite conferences about spaceflight.  And this year I am joined by Greg Moran, Mach 30’s vice president.  One of the first day’s panels concerned intellectual property as business assets.  Just as the panel was about to start, Greg asked me if I was going to ask the panel a question about open source hardware.  My response was “of course not, I learned a long ago bringing up open source in large sessions like this doesn’t work.”  Well, this panel showed me I hadn’t learned that lesson as well as I thought.  😉

The first panelist was from the Patent and Trademark Office and she presented a number of changes which are in the works concerning how patents and patent applications work.  Given that our mission involves open sourcing our designs instead of patenting them, her material did not really concern Mach 30.  The second speaker was the CEO of a computer peripheral company which derives a great deal of its income from its patent portfolio, so much so that he described his business as an intellectual property business instead of a hardware business.  At some point he went as far as to suggest the new space companies should consider a similar model.  Well, that was the proverbial straw for me, so I posted the following (somewhat snarky tweet) to vent my frustration over his message.

http://twitter.com/#!/Mach_30/status/126779828094513152

Now, I knew in the back of my mind that the ISPCS staff were going to draw some audience questions from tweets tagged with “#ISPCS“, but that hadn’t happened yet, so I figured nothing else would come of it.  Imagine my surprise when one of the first questions was preceded with the caveat that it came from twitter, and then heard my tweet read out loud, followed by the sound of crickets.  No one on the stage understood what the question was even asking, so I raised my hand, claimed ownership of the question, and elaborated on it.  So, how did the panelists respond?  I think the twitterverse said it best.

http://twitter.com/#!/Marimikel/status/126783090721964032

Ouch! Well, the second panelist did say something about liking his monopolies. But wait, there’s more.

http://twitter.com/#!/ad_astra2/status/126783332691349504

Maybe we need to do some outreach on the benefits software companies large and small have gotten from open source software?

And do you want to know the best part? Greg and I got several “oh that was you” comments when we introduced ourselves at dinner and the reception afterwards. Let’s hear it for stirring the pot.

An Urgent Need in Open Source Hardware

by .
Comment

I have just gotten back from the second annual Open Hardware Summit.  The organizers did a fabulous job, adding breakout sessions and project demos while handling a growing audience (in person and over the internet).  Kudos to the entire team.

As I flip through my notes from the summit, I find there are several themes which stand out.  First was the wider variety of projects from last year.  Second was the social impact of open source hardware from projects such as EyeWriter (a project to help people communicate using only eye movements) and Protei (a project to build autonomous boats to help with research and ocean clean up).  And third was the urgent need to fully document open source hardware projects.

This last theme seemed to permeate the summit, from the opening keynote to Mach 30’s demo booth at the end of the summit.  The Arduino Team expressed it as one of their lessons learned: “Document what you make.”  It is direct and simple, and it rolls off the tongue.  So much so, that I immediately thought, “there’s the tag line for Open Design Engine.”

http://twitter.com/#!/Mach_30/status/114346797945733120

Engineering Design Process, credit Amanda Wozniak

It didn’t stop there.  Bre Pettis of MakerBot went on to say “Publishing ideas is an urgent community responsibility.”  For Bre, this was partly as an inoculation against having someone else patent your idea and make it impossible for you to act on it.  I think it also speaks to the more fundamental idea that hardware only becomes open source when we publish it.  Of course, this begs the question, what does it mean to publish an open source hardware project.  At Mach 30, we believe it means opening up the entire design process, from identifying a need, to developing a concept, all the way to fabrication and test.  And, it turns out we are not alone.  Amanda Wozniak gave a brilliant presentation on how to start opening up the engineering design process as a means of documenting open source hardware projects.

To round out the day, Mach 30’s exhibit during the Cocktail and Demo Hour was a demonstration of Open Design Engine, a web portal developed specifically to address the urgent need to publish not only the final plans but the entire design process for open source hardware projects.  We like to think of it as the Source Forge for hardware.  And while sites like Source Forge and LaunchPad are focusing on features to support software projects (such as demo web and database servers for web site projects), Open Design Engine is focused on the needs of hardware projects.  The private alpha version is built on Redmine, and has support for common features such as source code repositories, wikis, forums, and issue tracking.  Open Design Engine also has full sub-projects so teams can breakout their work along functional lines (such as software, electronics, and mechanical engineering) all under the heading of the main project.  And Open Design Engine has a desktop like file management system for storing non-source files in a way that is more familiar to developers who come from disciplines beyond software development.  Check out the full list of features and the road map to see where Open Design Engine is headed.

So, the alpha version of Open Design Engine has the core project hosting features.  What’s next?  We want to open up access to any user who wants to host open source hardware projects.  Unfortunately, there are still a few features we need to make this practical, things like a strong terms of service workflow to make sure users have seen and agree to the terms of service, and a consistent way of identifying a project’s license.  And, we are rocket scientists, not web developers, so we have had to hire a development shop to help us implement these features.  Luckily, we found a great shop here in Dayton, Littlelines, and they have given us a discount since we are a 501(c)3.  But they still have to eat, so we still have to pay them.  We are currently raising the funds we need for the development of the public beta.  If you give $25 or more, we will give you an early access account on the private alpha so you can host your projects today, and help provide valuable feedback.  So, please donate $25 today and help us spread the word about the urgent need to publish open source hardware designs and the role Open Design Engine can play in filling that need.

Click Here to Kickstart ODE and start documenting your own Open Source Hardware!

The Role of Open Methods in the Development of the First Airplane

by .
2 Comments
First flight of the Wright Flyer I, December 1...

Image via Wikipedia

The open source spaceflight hardware movement has its roots in both the growing open source hardware movement, which is itself based on the open source software movement, and the application of open methods in aerospace engineering which dates back to the earliest days of the field. In fact, this openness led to the success of the Wright brothers.

The Wrights built upon a large body of published works including books, articles, and expired patents, dating back to the beginning of the nineteenth century. George Cayley identified the use of curved airfoils for lift, the need for controls, and the use of propellers as a means of propulsion as the fundamentals of flight in 1799. He also proposed the use of the bi-plane wing, which would later be used in a number of gliders, including those built by the Wrights, and the first airplane. These ideas were not widely known until Alphonse Penaud rediscovered and published Cayleys work. Penaud went on to expand Cayleys work by publishing what he saw as the core challenges to achieving heavy than air flights: resistance of the air, resistance of the machine, and a light weight motor. Even more important to the story of the Wrights was Penauds work in models and his use of rubber bands as a power source for model airplanes and helicopters, some of which were sold as toys. The Wright’s father gave young Wright brothers one of Penauds toy helicopters, which is said to be the catalyst for their interest in aviation as adults.

These principles and challenges identified by Cayley and Penaud were the core of the problems tackled by the Wrights, due in large part to the Wrights beginning their journey into aviation by researching all of the work done to date. But the aviation community’s influence on the Wrights’ work did not end with an understanding of the principles of aviation, it also influenced their approach to tackling the problem. Louis Pierre Mouillard, author of the 1881 book The Empire of the Air, was a proponent of using ailerons for roll control, a challenge that the Wrights solved with the related idea of wing warping. And it was Otto Lilienthal who in the late 1800s publicly promoted the idea that the best approach to developing the first airplane was to start by developing a reliable glider and then adding a motor. This is exactly the approach used by the Wright brothers in the development of the Wright Flyer. Finally, the Wrights knew and were in contact with Octave Chanute who published the most complete summary of nineteenth century aeronautics to date, Progress of Flying Machines, leaving little doubt that the Wrights were influenced by the developments of earlier aviation pioneers.

As can be seen above, the Wrights first airplane is the product of not only their hard work and ingenuity, but also of the culture of openness surrounding the field of aviation during the nineteenth century. In the words of author Courtlandt Canby in his book A History of Flight, “The Wrights were not pioneers. Their work, rather, culminated a century of experience.”

Shared Challenges and Opportunities in Open Source Spaceflight

by .
5 Comments
Desert

Image by Jungle_Boy via Flickr

Yesterday’s discussion of open source spaceflight hardware groups reveals a number of repeated challenges facing this movement. These challenges include licensing open source hardware, the development of web-based project management tools for engineering, overcoming the costs associated with engineering software, and resolving the conflict between open source methods and export restrictions on spaceflight hardware. The good news for the open source spaceflight organizations is that they are not alone in addressing some of these challenges, which provides for important opportunities.

The first challenge is licensing open source hardware. Licensing software is a matter of applying terms of use to copywritten works. This is a process which is well understood in the software industry and does not involve any additional cost to the developers. However, intellectual property rights for hardware are more complex. Hardware is often protected by patents, trade secrets, and non-disclosure agreements. Each of these processes involves different laws and processes, and generally additional costs. These factors make developing open source hardware licenses difficult. This challenge is shared by the open source hardware movement as a whole, and is being addressed by other organizations. For example, the Tuscon Amateur Packet Radio Corp. (TAPR-OHL) and CERN (CERNOHL) have developed  open source hardware licenses similar to the GNU Public License 2.0.  Mach 30’s own licensing approach (Mach 30 Open Design Pledge) is modeled after the Arduino’s use of multiple licenses and is similar to the Apache Software License.

The second challenge is developing web-based project management tools for engineering projects. There are a number of web sites which fill a similar role for open source software projects, including Source Forge.  However, these tools are optimized for managing and sharing software projects, not hardware projects. So, at present, most of the organizations listed above are making due with a collection of disconnected tools. Which explains why a number of them are working to address this challenge.  And these organizations are not alone. DARPA, which is researching open source hardware, is soliciting proposals for the development of their own open source hardware project portal called Vehicle Forge.  And CERN has recently announced its Open Hardware Repository.  DARPA and CERN’s investments validate the efforts to develop such a portal, and may help pave the way for wide-spread availability in the near future.

The third challenge is overcoming the cost of engineering software. The ideal solution for these groups is to identify and adopt open source engineering tools. Using open source engineering tools first ensures the tools will continue to be available and at no cost to volunteers participating in the design process. Second, using open source engineering tools fits in with the over all philosophy of open source hardware. The second best solution is to find software which can be used freely for personal or not-for-profit use. Sites like the Mach 30’s Openeering Wiki and Develop Space’s Open Source Engineering Tools are both intended to catalog the available options as a means of addressing this challenge.

The fourth challenge is resolving the conflict between open source methods and export restrictions on spaceflight hardware. In the United States, there are a number of export restrictions which affect almost every type of spaceflight hardware, regardless of use or intent. Put simply, these export controls forbid United States citizens from sharing any material concerning spaceflight hardware. Failing to comply with these regulations can carry severe penalties, making it essential that anyone working in spaceflight hardware follow them. However, following these kind of restrictions is in direct opposition to the open source philosophy.

While it is true these challenges are significant, most of them are shared by the larger open source hardware community, which means we are not alone in facing them.  The key to overcoming these challenges, and making open source spaceflight successful, is to work together to address these challenges, both within the fledgling open source spaceflight and with the larger open source hardware community.

Want to join Mach 30′s team in the Open Source Spaceflight Revolution?  Learn more here.