<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><div>Workgroup 1</div><div>20181001 draft by Abraxas3d</div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>The question of this particular work group was relevant and interesting, since it directly confronted some growing pains resulting from recent community success. </div><div>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.</div><div><br></div><div>The central question is Why aren’t more new teams taking better advantage of the lessons that Libre Space has to offer? </div><div><br></div><div>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?</div><div><br></div><div>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. </div><div><br></div><div>The group identified some potential reasons for why new open source teams start from scratch.</div><div><br></div><div>1. They are unaware of existing open source work.</div><div>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.</div><div>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. </div><div>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. </div><div>The group discussed the particular challenges from a pedagogical point of view. </div><div>There is and should be a balance between legitimately learning the ropes through valuable personal experience and getting a boost past very boring basics. </div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>This dichotomy is important to Libre Space and was addressed in discussion. </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Reinforcement through encouragement, repercussion, exclusion, and reward are hallmarks of industry groups. </div><div><br></div><div>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.</div><div> </div><div>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. </div><div><br></div><div>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. </div><div>The host collected names and contact information for the attendees. </div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div>