There are several barriers preventing engineers from sharing their work (that is the underlying analyses, as opposed to just the results). Some are cultural, such as the norm for journal article (publish equations, methods, and tools, not data files), and some are technical (using different tools, or different formulations). I believe the technical barriers reinforce the cultural ones, and are more straight forward to address, so I would propose looking at those first (this is actually a similar approach to the course of open source software, where early efforts focused on developing the tools that enabled people to share their work, including open source compilers and version control).

So, let’s take a look at one of the technical barriers: using different tools. One solution might be to use open source analysis tools (and they do exist for many specialties). Unfortunately, this would involve convincing engineers to use new tools, which at best means requiring the to learn how to use them and interpret their output, and at worst means convincing them that the tools really work (good engineers gave a heavy skepticism of new engineering analysis software). What if we turn the problem on its head? Instead of finding the one set of tools to use, we make it easy to switch between tools. I am thinking of a vendor neutral analysis description language. Engineers develop their analysis in this neutral format and then use translators to write vendor specific input files. Then if the engineers want to share their analysis, they send the neutral format file to someone who then uses a translator for the tool of their choice.

Now, I don’t imagine this would be easy. Their are many disciplines with many tools in each. But, imagine how much easier it would be to share one’s work. If anyone knows of an example of this, please let me know.