prev next

Attending the hackerSPACE Workshop

by .
1 Comment

This weekend Josh (a member of Dayton Diode) and I had the great pleasure to attend Kentucky Space‘s hackerSPACE Workshop.  The hackerSPACE workshop, led by Bob Twiggs co-creator of the CubeSat standard, was an introduction to CubeSats for hackerspaces, entrepreneurs, and educators.  In addition to the formal presentations, there were a number of group suggested breakout sessions including ones on educational outreach, open source CubeSats (of course, I suggested this topic), working with Amateur Radio operators, and operating high altitude balloons.  I am very happy to report the open source CubeSat topic generated quite a bit of additional conversation and opened the door to several partnership opportunities.

One such opportunity involves designing, building, and operating high altitude balloons.  During Mach 30’s strategic planning for 2011, the Mach 30 board decided to start its CubeSat development efforts by first building high altitude balloons.  High altitude balloons offer many of the same design, fabrication, and operation challenges as CubeSats, at a fraction of the cost, making them ideal “kites“.  And, it turns out, there are several high altitude balloon programs near Ohio to partner with, as we learned from the high altitude balloon breakout session at the workshop.  These programs include:

It turns out Josh and I sat next to Adler Planetarium’s Ken Walczak.  Ken and I talked at length about the Far Horizons program and launching high altitude balloons.  It turns out Adler Planetarium has been looking for a way to share the designs and procedures for their high altitude balloons in support of their educational mission.  It just so happens, Mach 30 has a website for sharing open source hardware projects, and as mentioned earlier, a desire to build its own high altitude balloons.  There has also been talk at Dayton Diode about building a high altitude balloon as a group project just because it would be cool.

Sounds like a great partnership opportunity to me.  Here’s how I see it working.  Mach 30 would provide project coordination, funding, and hosting (on Open Design Engine).  Dayton Diode members who are interested in a high altitude balloon project would volunteer their time to build and operate the balloon.  And Adler Planetarium would provide the experience (in the form of plans, procedures, and training).  Ken from Adler has already expressed an interest in this proposal, and believes he can arrange for a live training opportunity for Dayton Diode members at one of the upcoming Far Horizons launches (the next one is in December).  And Mach 30 has funds allocated for a high altitude balloon project.  And, I am cross-posting this blog post on Dayton Diode’s blog to gauge their interest.  More details to follow as things move forward.

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!