1. Making Software Executable by Others Varun Ratnakar USC/ISI varunr@isi.edu April 17, 2015 http://www.flickr.com/photos/gemmerich/6365692623/in/photostream

2. 1. Sharing your software  So you created an awesome tool ? Share ! No share, no reward (cred or $)  What to share ?  Executable  Harder to maintain as you have to build for various systems  Faster for people to use.  Source code  Open source provides transparency and community help to make your software better & more re-usable!  Version control with repositories like GitHub, BitBucket etc  Dependencies ! *Important*  Also share the dependencies (libraries and other software required both for building the software from source & for running the software). Tip: Share the source code, and share executable if possible

3. Software Repositories (yum, apt, maven) Source code Build (libraries & dependencies) Executabl e Dependencie s Share Executable { Developer } { User } { Community usage }

4. Source code Repositories ( github, sourceforge, google code) Source code (java, C,..) Build Libraries & dependencies (README.txt, pom.xml,..) Source code (java, C,..) Build Libraries & dependencies (README.txt, pom.xml,..) Executable Share Source Code { Developer } { User } { Community feedback }

5. 1.a Creating executable from Source  Ok so we shared the source code. Now what ?  How to create executable from source ?  Provide Instructions: README, INSTALL file  List dependencies (libraries, and third party software that the software depends upon)  Use “build automation software” (like make, maven, etc) to compile the code  Tools like “maven” (for java) automatically fetch dependencies from internet repositories in order to build the code

6. 1.b Make your software run elsewhere  Portability: If your software runs on machine A, will it run on machine B too ?  List required dependencies (software and libraries that are needed to be installed on a machine to get your software to run)  No Hard-Coded machine specific details in the source code  Machine specific details such as file location, server name, etc.. should either go in a configuration file, or be provided as a parameter to the software

7. 2. Test, Conduct Experiments  Now that the software is running, can we test it out ?  Provide test input data, and test results, and instructions on how to run the tests  Share real input data if possible, and explain data formats  Provide information about how to create input data, and what to do with the result data

8. 3. Modularity  Split your code into multiple parts, where each part can be invoked separately if so desired.  Provides finer grained functionality that someone might want to re-use in a workflow (or a pipeline of executions)

9. 4. Configurability  Expose important parameters in the software in the form of configuration files or parameter values  Helps to make your software more useful to people working in slightly different domains but with similar problem scenarios

10. 5. Error Handling  Do NOT fail silently if something goes wrong.  Show an expressive error for users.  Return a failure exit code for automated workflow managers to indicate that the software failed