EarlyThoughts

30 November 2005, Paul Wooster

It is difficult to know a priori what the DevelopSpace system will be used for and how it will be used. Many possible applications exist, each with some unique aspects to how the system would be developed if it were focused on that particular application. As such, is there a way to create the DevelopSpace system such that it can be flexible and useful across a wide range of applications, some of them currently not even envisioned? In other words, can the system be created to enable a base level of functionality while also allowing additional new functionality to emerge over time?

One of the difficulties in achieving this goal will be in providing sufficient functionality to achieve these varying objectives, without providing so generic a set of tools that using them is very cumbersome or people do not find the site to be useful beyond already existing entities. At the same time however, some benefit can be derived simply through having a single portal for a community to gather around and focus their minds towards a particular objective. Along such lines, however, content of sufficient quantity, quality, and dynamism must exist for a community to actually coalesce.

A number of online communities already exist in the space realm, and they may offer some indication of potential models for development. My impression of many of these communities, however, is that they tend to be focused more on discussion than on action, and as such may not entirely suited to the intent of creating a community that takes action in the technical realm towards developing space.

From an organizational stand-point, it is probably worth investigating how other online development communities organize themselves and how the members in such organizations proceed through various levels of responsibility and authority. Some organizations that come to mind as potential models include SlashDot, Wikipedia, Apache Software Foundation, Linux, SourceForge, and the Free Software Foundation. Some of these may be appropriate for this endeavor, others may not. Many additional examples likely exist as well that are worthy of analysis.

Sometime in the fall of 2005, Paul Wooster

Just spoke with Wilfried very briefly about the concept of enabling distributed groups of people to contribute to space exploration. The question he asked, which is quite reasonable, was “What would they do, and how would it be different from what NASA could do?” Part of the question was if they would just come up with ideas, or if they would do something different.

In order to be effective, it would be important that they not simply “come up with ideas”, but instead make a meaningful contribution that will make it easier and less expensive to do things in the future. It’s important to not simply be a group that talks about things, but a group that does things. That being said, the question still exists as to what is a meaningful contribution.

One of the biggest difficulties is in the degree of subjectivity which pervades space exploration system design work. One person’s reasonable estimate is overly optimistic to a different person and overly conservative to yet another. Data can be used to validate estimates, however unfortunately there is frequently a lack of relevant data and extrapolations are required.

A possible avenue to address this is through careful, detailed, and well documented analysis of specific topics that both cover a wide space of options and present detail sensitivities to relevant parameters. As parameters become better understood, the results of the analysis within the range of parameters can then be applied to the engineering design. It is important, however, that this analysis be based upon basic principles, accepted safety factors, and be carried out with rigor, such that the results can be trusted in future work. Lacking the appropriate background, it is very easy for an argument to emerge along the lines of “I think that number should be XXX” and “No, I think that number should be YYY”, without any rational means of resolving the conflict.

It should be possible to create tools to structure analyses such that both documentation and sensitivity evaluation become easier. Strict documentation of every parameter along with specification of a range for sensitivity of that parameter could be required. The system could then iteratively investigate the parameter space to represent the sensitivities. The difficulty with this, though, would that the system may tend to constrain the capabilities of experienced engineers who can more intuitively address the questions at hand and quickly narrow the space of options. In addition, a new need to analyze and represent a much larger dataset would result.

If this approach were undertaken, a form of continuous peer review and parameter linking could be possible.