[Ground-station] Open Source CubeSat Workshop - Working Group 1 Draft Report

[Michelle Thompson]

Workgroup 1
20181001 draft by Abraxas3d
One of the activities at the Open Source CubeSat Workshop 2018 was a set of
working groups. These small groups met after the presentation sessions on
both of the two days of the conference. The working groups lasted between
60 and 90 minutes. Each working group had a topic or question. Discussion
was free ranging, encouraged, and productive.

The concern in this working group was one of process within community.
Wisdom is communicated through the accumulation of best practices within a
group. Any particular community, facing any particular challenge or threat,
must provide members with a set of policies, procedures, goals, and rewards
that give individuals the best chance of individual success. That success
must also be in alignment with group goals. Community success is when the
individual achievements result in collective achievement with minimal loss.

A useful analogy for understanding this balance between individual and
society is impedance matching. A particular community must provide
impedance matching between the center-of-mass-of-current-membership to the
particular problem space those members live within and encounter and are
organized to address. This gives that community the best possible chance to
survive and succeed in the larger ensemble of civilization. This is dynamic
over time, so goals and strategies do shift and change.

The question of this particular work group was relevant and interesting,
since it directly confronted some growing pains resulting from recent
community success.
There have been large steps forward. UPSat in particular has succeeded as
an open source satellite. Documentation, while not completely perfect,
exists and is extremely useful. The documentation is of more than
sufficient quality for other teams to not have to start from scratch.

The central question is Why aren’t more new teams taking better advantage
of the lessons that Libre Space has to offer?

Why does it seem that cubesat teams generally seem to start over from
scratch at the beginning, wasting time and failing to take advantage of the
substantial leverage that existing open source work can provide?

The perception of the host and the clear majority of the workgroup
participants was indeed that too many teams were showing up, starting from
scratch, and wasting time. The lessons learned and documented from UPSat
should be more widely adopted. The starting point for open source space
efforts no longer needs to be proprietary secret tribal lore, nor does it
need to be re-learned every time by every open source team, painfully, from
the beginning. Progress has been made and progress should be taken
advantage of.

The group identified some potential reasons for why new open source teams
start from scratch.

1. They are unaware of existing open source work.
2. They are aware of existing open source work, but lack confidence in
using it or feel they don’t have permission to use it. Sometimes there is
the perception that the team has to prove their worth in some way in order
to access the work.
3. The team is prevented from using the open source work by an authority
figure. The authority figure (e.g. a professor at a university) views using
open source work as anti-pedagogical or cheating or unethical. Starting
from scratch is virtuous. Starting from scratch confers credentials through
an arbitrary educational process where objective achievement may be
secondary.
4. The team cannot comply with the open source license. They want to
commercialize the work or benefit from the work in some way that is in
conflict with the open source license or culture or constraints.
The group discussed the particular challenges from a pedagogical point of
view.
There is and should be a balance between legitimately learning the ropes
through valuable personal experience and getting a boost past very boring
basics.
When the goal of an educational endeavor is to learn something, anything,
then there is no special advantage from open source work. Open source work
allows the starting point to be substantially further along in the
complexity curve in any given field. The further along in the starting
point along the complexity curve, the harder the educational professional
has to work in order to take full advantage of the material.

The educational professional either has to abstract things down, or work
harder to make sure that the students understand enough prerequisites that
they can handle the material. Either one of these endeavors substantially
increases the educational workload. Increased workload is not to the
benefit of the educational professional; they are unlikely to engage in
anything that results in an increased workload, regardless of how much it
may benefit a critical technology.

When the end result of an educational endeavor is given more weight than
the learning-the-hard-way experience, then the head start that quality open
source work provides becomes much more valuable. Open source
non-differentiating technologies are enormous force multipliers to measured
end results. The lessons learned being further along the complexity curve
are also valuable. It is the choice of the educational professional as to
where on the complexity curve they choose to start their students or team
or class.

This appeared to be the crux of the discussion. The host posited that the
scientific and mission success of a particular CubeSat team is of higher
importance than a stereotypical learning something, anything, it doesn’t
matter if the mission fails pedagogical approach. The administrative and
educational leaders of many new cubesat teams may not value the success of
the mission above the “pay your dues” cubesat team experience.

This dichotomy is important to Libre Space and was addressed in discussion.

This is a marketing and cultural challenge to Libre Space. Libre Space can
provide a higher baseline to those teams that want to take better advantage
of it. Not all teams will want to take advantage of it. Libre Space should
not spend inordinate amounts of effort attempting to change minds that do
not value the results higher than the pedagogical journey. The success of
teams that do take advantage of the open source work will be more than
proof enough, and the energy should probably be expended there.

Industry groups often provide similar functions. The central function of an
industry group is how to best communicate something that is often described
as “tribal lore”, to the benefit of the group members.

Documentation is not sufficient in and of itself. The best possible
documentation cannot alone give enough support to new teams to start from a
higher level. There are a lot of things that need to be communicated that
cannot be simply written down in a table or paragraph.

Reinforcement through encouragement, repercussion, exclusion, and reward
are hallmarks of industry groups.

Some of the institutional methods proposed to address the shortcomings in
onboarding new teams were discussed. Most prominent was the establishment
of weekly conference calls. These calls would be with any new teams that
Libre Space found out about or that found out about Libre Space.

An open invitation to weekly conference calls was discussed at length. The
existence of weekly conference calls to coordinate any new teams was
considered to be success criteria by the host. The group valued the
existence of a culture where new teams would feel willing and able to
participate in regular conference calls with the open source space
community. The new team would rapidly accrue the knowledge and tools and
advice and support in order to get much further ahead than if they did not
have this community resource. They would then be expected to contribute
back in some way.

Publicizing the many successful projects of Libre Space and the wider
community was discussed. The great value of the viral ideas of open source
space projects was emphasized, and the need for better marketing was
highlighted.
The host collected names and contact information for the attendees.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20181001/55bfddfd/attachment.html>