Software, dying on the journey from academic project to commercial tool. 

by: Anthony Garland
Follow @AnthonyPGarland

When I tell people what I've been doing for the last few weeks, they always look at me in awe as though I had just performed some magic trick. Yes, I'm a Ph.D. candidate in mechanical engineering, but I'm working on a software application. Interestingly, almost everyone in my research group at Clemson is also working on software of some sort. The difference is that I'm trying to take an idea that I've developed while teaching at Clemson and turn it into a commercial application that is helpful for other universities besides Clemson.

Most software developed in academia seems to die on the journey from academic project to a commercial tool.  So, what prevents other applications developed in academia from becoming actual commercial (or open source) software applications that are used? I have a few ideas.  

1. Ignorance of standard software tools. Most mechanical engineering graduate students do not seem to use essential software development tools such as version control (git) and IDEs (like Visual Studio, Eclipse, JetBrains).  Without using these standard tools, the code becomes unnecessarily difficult to manage.  
2. Rush to finish. Graduate students want to finish school as fast as possible, which is understandable if you have been in school for 23 years or more! If making your code understandable by others is not a requirement of your advisor then it will not happen, Period. 
3. Not thinking about how it will be used. Research objectives set out at the beginning of a research effort describe why we should care about this particular research task. However, often these goals fail actually to understand the needs of an engineer. Understanding the actual problem is truly the first problem. If something doesn't add value to a company, then they are not going way out of their way to try your new software tool. 
4. Matlab is a prototyping language. Most code in my research group is written in Matlab. Engineers might be willing to download a Matlab script and try it out on their computer, but sales or management personnel likely won't even know what Matlab is. If a software tool is meant to help make major product planning decisions that involve non-engineers, then it should be simple enough for them to use. 
5. Hoarding of code for future research. Research money is competitive, so if you develop some cool program, likely you won't make it open source which might allow others to build on or improve your code which means they might get the research money. 
6. One off code projects. Rather than use a standard engineering tool and trying to access its API, often researchers like to make their own FEA or CFD. The problem is that custom code projects are hard to use. Someone familiar with COMSOL doesn't want to learn a new multi-physic simulation software with no GUI just because you added one innovative element to your analysis program. 
7. Too complex. Developing commercial software is complex. Graderworks is written in C#, but it makes use of SQL as well. The excel macro used in the demonstration is written in VBA. The website/licensing server is written in PHP, HTML, CSS, JavaScript, MySQL. Many other non-programming tasks must be done to develop a usable application which can also be overwhelming, such as security issues. 

So if software can't be developed into a commercial product then is it bad? NO! Academic research certainly has a place for theoretical research or proof-of-concept type software applications. However, when a project is worked on by multiple sets of graduate students for years, and NO effort is placed on making it into a commercial product then I wonder whether the software/research effort is helpful. 

So, what should be done? I think that research projects that are focused on making a software tool should include a chapter in their thesis or dissertation on how the software would be commercialized or made into a useful open source project. I think this will force students to understand what the engineering community needs by contacting them. If you claim that developing some python library to help with voxelization of .stl files is necessary, then I'm sure the Python community will be willing to tell you if they agree. If you claim that a new decision-making tool is helpful, then make it into a web app and let people try it out. Without people using your tool, you will not be able to identify if it is helpful. Finally, I believe that all research that is not directly funded by industry partner should be made open source. Hoarding code seems to defeat the whole point of academic research and should be eliminated.