As published in The AMSAT Journal, Volume 43, Number 5

[Published under the US doctrine of fair use. This is an excerpt of a publication, used for commentary to advance public discourse regarding a subject of great interest and importance to the amateur radio satellite community.]

September/October 2020

Engineering Update

Jerry Buxton, N0JY

Vice President, Engineering

Open source, Open mind

“Open-Source” is a hot topic for many in discussions about AMSAT, as you may well know. While my go-to, good old fat Webster’s Third New International Dictionary does not have an entry for “open-source,” it does have an entry for “open-mind.” You can find any number of definitions for open-source in an online search. I will go with what turned up first on my search, annotated “Definitions from Oxford Languages”:

adjective [COMPUTING] “denoting software for which the original source code is made freely available and may be redistributed and modified.

A handful of others I looked at to be somewhat certain in what I say here were all essentially the same, and specified software as part of the definition of open-source. That is interesting in that some comments directed at me in the argument for open-source seemed to use the term to include not just software, but hardware as well.

“You cannot reason someone out of something he or she was not reasoned into” (Jonathan Swift, 1721). The quote of Jonathan Swift seems to apply to the current situation because of discussions calling for AMSAT to adopt “open-source” as our means of doing business with satellite projects, lest AMSAT die off as an ineffective organization. Hence, the subtitle refers to what seems to be rare in the age of polarized tweets and blogs and unfortunately, amateur radio email lists, having an “open mind.”

My trusty old Webster’s says about “open mind” (actual entry is “open-minded”):

adjective: “receptive of arguments or ideas: free from rigidly fixed preconceptions: UNPREJUDICED (an open-minded curiosity that made him receptive to new ideas – V.L.Parrington)

To me, being open-minded is a natural part of the general fraternity of amateur radio, and it takes place every day in everything from tower parties to satellite QSOs. I’m baffled that the concept seems to be left behind as you look at leadership levels of amateur radio affinity groups where one might think being open-minded is a required “skill.” Yet here we have some of the most highly polarized and divided groups of hams who are the functioning antithesis of the openminded definition, especially “free from rigidly fixed preconceptions.” There appears to be no reasoning behind the highly polarized championing of a dire need for AMSAT to “be” open-source. On the flip side, there is no apparent reasoning by anyone who summarily says “no.”

Fear not. My subject here is not who said what or how AMSAT is run. My director hat is on the tree, and I wear my “VPE MAGA” hat (Moving AMSAT GOLF Ahead) for this. With the scenario set, I will look at how open-source may already exist in AMSAT Engineering, and share some open-minded questions and curiosity in how open-source fits what we do.

There are surely high levels of disagreement already with what I have written this far. Whatever your opinion on my being openminded, please do the same, and perhaps we can think beyond the existing “must” and “no,” which don’t really facilitate any discussion.

To my knowledge, which only goes back just shy of a decade as far as being in a position to know, AMSAT Engineering has never had a policy that specifically ruled out open-source. Obviously, some things would need to be carefully considered before a change is made. I cannot speak for my predecessor as far as the choice to handle documents the way we do right now. It was in place and would make no sense to have tried to change it in the middle of the Fox program.

When I “went to work” for AMSAT in August (or so) 2011 as Systems Engineer, I was tasked with putting together all of the Fox-1 engineering documents that we had at that point for publication in the 2011 Proceedings of the AMSAT Space Symposium. That was the first AMSAT Space Symposium I attended in my then 37 years of fun using amateur radio satellites. I believe, from looking at the 2010 Proceedings, book that 2011 was the first year that Fox-1 was fully documented in that way. In writing the introduction used in those Proceedings, Tony Monteiro (AA2TX), who was VPE at the time, wanted to include the following:

We would also like to be able to discuss our satellite projects with our own members, [emphasis added] some of whom are not “US-persons” per ITAR. These AMSAT Space Symposium proceedings provide a convenient mechanism for the needed publication to make this information public domain and allow us to communicate with our members. The engineering documents published in these proceedings are what was available at the time needed for inclusion, and we hope you find them interesting and informative. AMSAT intends to continue to make the majority of the final technical documents, exclusive of satellite control information, available in future publications.

Those same points were included in what became the yearly publication and sharing of the development of the Fox-1 satellites, and I carried that on when I was voted VPE upon Tony’s passing in 2014. Especially as the Fox-1 platform quickly became popular with partners and prospective partners in flying on our “experiment bay” platform, I took a bit different view of the reason for publication in the Proceedings. I reworded the introduction to better reflect the popularity and the intent of making the designs for Fox-1 CubeSats available to any interested parties, including foreign organizations interested in building their first CubeSats. It stated in part:

AMSAT, in consideration of the educational component of our organization, would like to release the majority of our design documentation to the public as a learning tool to anyone interested in satellite development. [emphasis added]

Since hardware and hardware designs are not included in the definitions of open-source that I mentioned, could you still call our publication of documents “open-source?” It is certainly intended to be accessible to all (purchasing a copy of the proceedings book was not a requirement, as I shared directly as well). It allowed changes for your own use without restriction. In fact, it was about as open as you might get as far as giving stuff to the public.

Incidentally, in the open-source sense, we recently entered into an agreement for an educational program in which students will rework the LTM design to require only two PCBs instead of our design of three. We will benefit from that as the re-design is shared back with us to help improve the LTM package.

The point in the Proceedings introduction that “a majority of the final technical documents” was made available refers to the omission of command and control hardware, and includes software functions regarding such. That point in the sense of “open-ness” is just reasonable security in the operation of the satellites because of licensing, certain government authorizations, and to keep from having the whistler and jammer crowd from also maliciously commanding a bird and ruining the fun for the users. In that, I do not include that omitted piece in this discussion. I expect to make it available after the Fox-1 satellites are no longer operational so it is shall we say, “pending open-ness.”

Let’s look at some of the things that I believe would need to be considered and clarified in “taking Engineering open-source.” One of the points would be whether there is any requirement to put everything on GitHub.com. That is consistently stated or implied in the argument for open-source, but I honestly do not know if that is simply because of general usage or there is something about it in the “compliance” with open-source. The answer to that leads to the obvious question of how doing so makes anything more opensource or officially open-source.

Another point of discussion that flows from that would be the control of information that is restricted by export regulations. Whether you believe that there is no need for concern because the fact that something is open-source makes it impossible for it to be a weapon, what really counts is the government and how the corporation sees it best to comply with those regulations. Certain things that are deemed exports cannot be shared with “non-US Persons,” so how might one secure that information yet still allow some to see it, and all to see whatever other bits are not restricted? There is also the issue of certain blacklisted countries that cannot have access to even something that has an export license, and the internet generally makes it difficult to determine where any interested individuals are from if they hit our GitHub.com page.

For a third point, we do have some volunteers who do not wish to share some or all of the details of their work and that is their right, which is addressed in our IP policy. That work is shared with AMSAT to use in any projects we have, but AMSAT cannot share it, and rightfully so. Do we then have to exclude any volunteers, no matter their capability or desire, if they do not wish to make all that they do open-source? That may be easily dismissed as it has been in some arguments I have seen, but it is an interesting contrast to our current policy that lets anyone participate, whether or not you wish your work to be open-source. In the specific terms of that argument, what we do now is certainly inclusive of all volunteers.

My fourth point in this exploration of the suitability of open-source is something that probably comes only from experience as a volunteer in our all-volunteer organization. It is my understanding that the point of opensource is to allow creativity and input from a larger number of volunteers with the ultimate outcome of essentially, “building better satellites, faster.” In that, I see a situation that we encounter all of the time and for all of the 6+ years I have been VPE.

With any new project, many wish to contribute their ideas in the design and execution of the project, and that is of course a good thing, to some extent. It does present some challenges in areas such as involving numbers of individuals in discussion and demonstration of ideas through documents or prototypes, even existing widgets. I wonder how that would be structured to play out in a reasonable timeframe without the time creep that inevitably comes with lots of individuals pitching lots of ideas.

Also, a pattern of unbridled enthusiasm appears at the start of something new that tends to die rapidly once ideas are pitched and production of those ideas begins. Many are not quite as willing to spend further time making the idea a reality, properly so in some cases, but unfortunately somewhat easily passed on as “and somebody can build it.” If the originator goes silent as is often the case in terms of percentage (recall that this is said from experience), then whoever might have taken up the reins to start making the idea a reality is often put in a position of finding the need for changes in prototyping or further down with PDR and so forth. If they did not originate the idea, while they have done their part of open-source in making the prototype happen, the widget now relies on input from the originator or others in the open-source world to solve the issues found and advance the project.

This is where things get tougher, and while this exists to an extent in our current process, it is more easily solved because it is likely that the originator of the idea is the one pursuing their dream and therefore has the ability (as well as desire) to see it completed. What might be expected in an open-source execution of a project in this regard, if the ideas and designs come from those other than the “construction crew” (for lack of a better term)? I do not necessarily doubt that people will not jump in on GitHub some of the time but you again have the situation of viable contribution if they are not intimately familiar with the stage of the development and willing to spend time with the team working on that widget to find a solution and move forward. Anything less creates delay, and, believe me, we can create that just fine already — and that is the nature of all volunteer projects.

My last thought for this article is that of who is in charge of such a project. Again, I have not contributed to any open-source projects other than AMSAT’s own, so I do not have any idea how they are organized in terms of responsibility. You have to have a boss and some sub-bosses I would think, else you wind up with chaos? At the very least, the systems engineering of any satellite project on GitHub as open-source would be a must and perhaps, a nightmare. That is one more of the items that would need discussion and clarification in consideration of “going open-source” that has not been touched upon in the “on/off ” arguments.

My point is not to list all of these things I think of, I simply believe that if there is any serious intent in the arguments regarding open-source I do not see a simple turnkey solution. Whether commercial (do they use open-source?) or amateur radio satellites, some processes are similar and some, perhaps many, are different because of the extreme difference between a paid workforce and a team of enthusiasts who share a common interest. I also do not expect that the arguments being made are with a full understanding of how AMSAT does satellites.

In my tenure, we have seen opportunities and ideas come out from our Engineering Team that can be at least related to open-source, such as standardizing on KiCad. This was an idea put forth and convincingly shown through documentation and use as a great idea, and it is, by a couple of kids who designed and built the Fox-1 MPPT as well as keeping me up late at night for “10 PM Pacific Time” meetings about the MPPT. Bryce and Brent Salmi were all in and one would regularly call or we would meet (can’t remember which, they kinda start to look alike on GTM at 1 AM) which led to the suggestion. With some frustration from the variety of a few other “free” versions of schematic software that had been used by whoever liked which best at the start of the Fox-1 project, they made the push for KiCad. They also turned me on to Kerbal Space Program through which I got my not-a-real Aerospace Engineer Degree usually after one of their calls since I was no longer sleepy.

I do not recall any suggestions about doing our work as open-source, perhaps it has been mentioned but there has been no momentum behind it, so one might take that as an indication that the team is happy with what we have now (SVN complaints aside). Nonetheless, I do believe that I am 98.9% open-minded and the team might support that statement although most people usually only remember the 1.1% of the times I told them no. All of our satellites are testament though, since I neither designed nor created any of it (that I recall) and always give credit to our Engineering Team for their hard work. They are also my real teachers and tutors by which I earned my status as a Real Engineer. (Who needs a piece of paper nobody sees anyway.) I appreciate your reading this with an open mind and ask you to consider the points not as a rejection of open-source, but as valid points of discussion in the consideration of implementing open-source in AMSAT Engineering. Next Journal issue: NDAs and open-source. Exciting!