Mach 30's 2016 Annual Plan

Mach 30’s 2016 Annual Plan

Most of your New Year’s resolutions have probably faded into fond memory by now, so why not pick up a new one? We’re excited to share Mach 30’s 2016 Annual Plan because we’re constantly on the lookout for volunteers to help us make our dream of open source spaceflight come true. We may not have cookies (we’re not the Dark Side, and we don’t have the budget for it — yet), but we do have very cool plans ahead.

This year’s project list is divided into three categories: rocks, pebbles, and sand. Dr. Stephen R. Covey, entrepreneur and author of The Seven Habits of Highly Effective People, tells a parable to explain this principle. Rocks are top priority, pebbles next, and sand last, the moral being that, “If you don’t put the big rocks in first, you’ll never get them in at all.”

The biggest priority on our list is developing Ground Sphere. This is a small, portable satellite receiver that you can use to eavesd— erm, listen to voice communications from the International Space Station. We also want to look into the viability of developing Ground Sphere as a product that we could possibly sell, which is why after building the prototype, we want to demo it so we can gauge interest.

Other rocks include the board’s annual strategic planning retreat during Apogee 3 (Mach 30’s annual outreach event), and recruiting both board-level and non-technical volunteers. We’ve realized that the organization would be served well by having a diversity of talent.

Onto pebbles: we’re continuing marketing activities because we want to at least double our reach this year. You may have noticed that we’re publishing more content than before and that we’ve restarted our newsletter.

Also in the pebbles category are the actual Apogee 3 Public Outreach Event, plus acquiring D&O insurance by January 2017.

Lastly, we move on to our sand activities. We’re supporting the Open Source Hardware Association by either becoming a corp member or being a sponsor at the Open Hardware Summit this year. Also, we’re publishing the Mach 30 Annual Report for 2015.

We’ve also categorized the projects into large, medium, and small, depending on how much time, money, and manpower we need to complete them. Looking at it in this way helps us determine if we’re doing too much or not enough. More importantly, it helps us assess if we can do the things that we really need to do, what with our (current) lack of resources.

Ground Sphere development and planning for Apogee 3 are considered large, while recruiting, the Apogee 3 event itself, and publishing the annual report are medium. Lastly, marketing activities and the OSHWA sponsorship are small.

Another way that we’re grouping the projects is according to whether they’re administrative or mission. Administrative tasks involve taking care of and growing the organization (recruiting non-technical volunteers), while mission tasks are those that fall in line directly with our mission statement (developing Ground Sphere).

You’ll notice that two-thirds of our tasks this year are admin. That’s because we want to focus on growth right now so we can do more mission work in the future.

We’ve figured out some time ago that Mach 30 is relevant to three communities: makers, space enthusiasts, and open source hardware enthusiasts. The numbers on the chart are the product of a quick calculation of how activities would impact these communities. As you can see, we’re trying to make sure that our activities are equally interesting to all three groups.

Projects also fall into three major areas based on Mach 30’s IRS-approved non-profit mission. As explained by Mach 30 president J. Simmons, “OSHW means supporting the OSHW community (because a rising tide helps all ships, think things like open source cad software and Open Design Engine). Ed is for education and outreach (because more people need to understand about space), and OSSHW is open source spaceflight hardware (that being our main thing of course).”

Last but not the least, in keeping with our efforts to recruit more non-technical volunteers, we’re putting more effort into visiting incubators and idea places. We want artists, writers, photographers, marketers, and business-minded individuals to join and help our cause.

Part of why we’re doing this is so we have a document to guide us through the year. It also helps keep us accountable as a team. The other part of why we’re sharing this with you is because we hope some of you will get excited enough to want to join us!

Check out Mach 30’s 2016 Annual Plan in infographic form below. Click here if you’re interested in volunteering, or email us at outreach@mach30.org.

Mach 30's 2016 Annual Plan

Mach 30's 2016 Annual Plan Mach 30's 2016 Annual Plan Mach 30's 2016 Annual Plan

[mc4wp-form id="2814"]

7 thoughts on “Mach 30’s 2016 Annual Plan

  1. Benjamin Brink

    When you divide your problems, and then burn (spend) resources, you’re weakening your play.

    You don’t need a separate space to operate. It isolates you and you burn resources unnecessarily. What happens if Mach30/OpenDesignEngine has to shutdown for a perod? All your valued OSHW resources are gone.. maybe forever.

    Use github.com instead of Open Design Engine as a respository. You network with more OSHW developers because you are in their environment.

    Make Open Design Engine a standard template of how you want OSHW designers to contribute. You become a thought leader for space OSHW projects.

    Instead of marketing etc, operate barcamps for Space OSHW projects, until you can create or network hackerspaces. See barcamp.org or https://en.wikipedia.org/wiki/BarCamp

    Instead of focusing on the boulders, focus on things that block development by more people. Some of your Mach30 engineers already know this and are working to make open source CAD software work for OSHW space projects.

    Also, NASA has lots of software you can use. Catalog and use things, make simulator software for things to test. Some important NASA software depends on IDL. IDL is not open source and is very expensive. GNU is already working on a replacement called GNU Data Language. Highlight it and/or help them. These are the kinds of things you need to focus on to get to space using OSHW.

    Instead of the boulder / pebble paradigm, think of farming. Many early space pioneers were from small farms. Small farms with limited resources is closer to a paradigm that Mach30 should model –not a military industrial complex company. Seek to harvest crops and realize that you might be eating anything you have grown and canned from over the last few years if your current crop fails. You might have to plug an oil leak in your tracker engine with oatmeal, or rebuild a tiller from a fender. Avoid the glamour of industrial production.

    Best wishes.

    Reply
  2. Chris Sigman

    Thanks for the comments Ben. There’s definitely some things we’re going to think about in this. Of particular interest to me is BarCamp. I hadn’t heard of it before, and I can see how it might work out for us. If you don’t mind, I’m going to give a shorter reply, but I plan on addressing some of these in more detail in an upcoming blog post.

    When it comes to ODE, the reason it was created was because a number of the components that we feel are needed to really effectively open source a piece of hardware weren’t present in other existing free offerings. GitHub for example lacks several of the features that we feel are essential to provide the ability to properly document hardware so that someone else can easily reproduce it. That being said, we’ve also been discussing at the very least adding git hosting to ODE, which would allow someone to mirror the repo on GitHub. More on ODE though in the post to come shortly.

    As for NASA, yes, they have a lot of open source software that we believe will be of great use for us later down the road. One problem though is that there’s actually so much of it, that digging through to find things that might change our course that aren’t things we need immediately is a challenge. Thus far though, nothing that we’ve been doing to my mind has had a good open source alternative available that we weren’t already trying to use or involve ourselves with, and open source CAD software is a great example of that. We’ve also been working on MTK, which is built on top of a ton of other open source components.

    Thanks again for the comment, we really appreciate the feedback. I’ll post a link here to the post when it’s up, for convenience.

    Reply
      1. Benjamin Brink

        Hi Chris,
        I saw the post soon after you posted it; I subscribe to blog’s email notifications. Am hoping someone else will respond to it. Here’s some more comments.

        Github is not git. Github can handle large media files ( https://github.com/blog/2079-managing-large-files-with-git-lfs ), although a significant part of the community uses youtube, vevo and other services to augment their projects with video.

        I’d argue that instead of a “more advanced environment”, OSHW projects related to a space program need to have a checklist, for each component regardless of the medium used. Development environments will evolve without Mach30 spearheading it. I see the Mach30 need as an administrative issue more than a technical one. This isn’t meant to undermine the importance of core open source technology, such as revisioning environment, CAD, multimedia etc. Having witnessed a mechancial engineer that didn’t depend on computers for any aspect of designing custom and series issued elevators, I see the benefit in having requirements/standards that are not dependent on any particular media.

        I agree that github isn’t the greatest of all choices, but it meets a certain minimum:

        It doesn’t cost any funds. This value should not be overlooked –for the organization and the OSHW community at large. Many leading OSHW initiatives have folded and their years of man-hours lost because they didn’t use an environment that persists beyond their footprint. Other’s couldn’t pick up where they left off.. Anyone wanting to carry the torch has to start from scratch..

        You might ask, what would be on an OSHW space program checklist? Good question. The OSHW license for starters. There are engineering sign-offs too, for performance characteristics, safety etc. Someone submitting a component may not be aware of the dimensions of requirements; A checklist helps.

        Also, any component that may have innovative characteristics should include material to help establish documentation to prove it under a legal challenge. To this extent, I took inspiration from a NASA form used when inventors submit innovative projects to NASA. Here is a blank form: https://github.com/tekbasse/3S-OHL/blob/master/OHL-innovation-release-form-blank.odt Proof-of-concept and other material should be included. A first attempt was made with the 3S-OHL repository ( http://github.com/tekbasse/3S-OHL.git ). I’m sure you can make a more robust template for OSHW space program participants.

        Another aspect of resource resilience is redundancy. I’m not sure how resilient Github is for large disasters. Making repositories available for local duplication goes a long way to helping increase redundancy in case a catastrophic event requires rebuilding from distributed sources.

        Best wishes,
        Ben
        (re-submitting –I forgot to address reCAPTCHA. Hopefully not a duplicate entry)

        Reply
  3. Benjamin Brink

    Hi Chris, Thank you for listening.

    Mach 30’s Mathematics ToolKit ( https://opendesignengine.net/projects/mtk/wiki ) looks promising.

    MTK may be quite a hurdle if contributors are expected to participate exclusively via one environment. One thing learned from the NASA Space Shuttle program is that it’s best to not depend on one system exclusively –the birds had at least two independently developed flight control systems. By tracking MTK-added features in MTK’s docs and creating software-independent standards for engineering processes, contributions won’t be limited by or subject to limitations of a single software stack. Contributors will be able to meet various engineering challenges according to their resources and limitations, which may or may not be similar to Mach 30’s.

    cheers,
    Ben

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *