src/future/software.tex

   1 \section{Software}
   2 \label{sec:future:software}
   3
   4 Open source experiment control is possible!  Even for a small lab,
   5 with a single novice developer\footnote{
   6   I started this project with a bit of LabVIEW and Matlab experience,
   7   but only a few days of Python from the physics department's
   8   ``Welcome to Drexel'' boot camp.  I stumbled across version control
   9   on my own, after a year of maintaining a directory full of
  10   version-stampted tarballs.
  11 },
  12 building reasonable software on top of existing pieces is possible.
  13 After a significant investment in developing
  14 \sawsim\ (\cref{sec:sawsim}), the \pyafm\ stack
  15 (\cref{sec:pyafm,sec:calibcant}), and \Hooke\ (\cref{sec:hooke}), we
  16 have a complete experiment control and analysis suite for single
  17 molecule force spectroscopy.  All of the software in the
  18 stack---including the existing libraries and systems layer
  19 dependencies---is open source, so other labs are free to use, improve,
  20 and republish it as they see fit.
  21 %
  22 \nomenclature{tarball}{A single file containing a collection of files
  23   and directories.  Created by
  24   \href{http://www.gnu.org/software/tar/}{Tar}, tarballs were
  25   originally used for tape archives (hence the name), but they are now
  26   often used for distributing project source code.}
  27
  28 As the body of existing science increases, new researchers must become
  29 at the same time more specialized and more interdisciplinary than
  30 their fore-bearers.  With a relatively fixed undergraduate curriculum,
  31 new researchers cannot afford to spend time becoming experts in every
  32 field that bears on their research project.  By pooling resources
  33 between labs, individual researchers can reduce time spent on generic
  34 tooling and increase time spent on their particular project.
  35 Experiment control, analysis, and simulation software is particularly
  36 amenable to community development, because the cost of sharing
  37 software between labs is minimal.
  38
  39 Besides the low cost of transferring the data itself, the rise of
  40 distributed version control systems such as \citetalias{git} have
  41 reduced the administrative overhead of maintaining a project with many
  42 far-flung contributors.  Researchers can automatically fetch and merge
  43 changes made by other groups, incorperating remote improvements.  They
  44 can also commit and push local improvements, which are then available
  45 for remote researchers to incorperate.  The version control systems
  46 and workflows that facilitate this cooperation scale well, from small
  47 projects with a single user, to huge projects like the Linux kernel
  48 with thousands of developers contributing to each release.
  49
  50 Once the software used in a lab has been published, it is also easier
  51 to audit by others who may be skeptical of the summary published in a
  52 journal article.  For example, resolving the confusion about the
  53 ``Lorentzian'' (\cref{sec:calibcant:lorentzian}) would be trivial if
  54 \citet{florin95} had also published their explicit procudure for
  55 generating their figure.  Do you think I'm not calibrating my
  56 cantilevers correctly?  Feel free to dig through my code.  Let me know
  57 if you find something wrong (or fix it and send me a patch!).  Science
  58 is built on reproducible experiments and analysis, and open source
  59 software allows you to explicitly specify your methods.  With well
  60 organized code, the specification should be clear from high-level,
  61 experiment-design choices down through low-level bit manipulation.
  62
  63 Many researchers have not received formal training in software
  64 development best practices, so how do we bootstrap this transition to
  65 open source science?  There is a wealth of documentation available
  66 online for self-teaching, and scientists have lots of experience
  67 reading technical writing in their own field.  For those who are
  68 overwhelmed by the amount of available resources, organizations such
  69 as \href{http://http://software-carpentry.org/}{Software Carpentry}
  70 are actively reaching out to scientists with short boot camps to lay
  71 the ground work.  Mastery of any subject takes a significant
  72 investment, but gaining a working level of knowledge in distributed
  73 version control should only take a few days\footnote{
  74   Software Carpentry allocates half a day to take students from ``What
  75   is version control?'' to being functioning \citetalias{git} users.
  76 }.  The difficulty for the uninitiated is often not mastering the new
  77 tool or workflow, but learning that it exists at all.  There are a
  78 number of papers highlighting best practices and tools that are good
  79 surveys for guiding future
  80 learning\citep{wilson06a,wilson06b,vandewalle09,aruliah12}.