The software you are happily using may be.. unnecessarily brittle. Recently I’ve been developing a little bit of high-level software using open source libraries.  Sometimes it amazes me that open source software works at all.  Here’s an excerpt from the internals I found in the open source library when I looked at why it might not be working properly:

        if (Pipe){
                while(iFlag){
                        vpData = Pipe->Read(&dLen);
                        iFlag = 0;
                                //      If we have more data to read then for God's sake, do it!

                                //      I don't know if this will work ... it would return an
                                //      array. This may not be good. Hmmmm.
                        if(!vpData && GetLastError() == ERROR_MORE_DATA){
                                iFlag = 1;
                        }

                        if(dLen){
                                XPUSHs(sv_2mortal(newSVpv((char *)vpData, dLen)));
                        }else{
                                sv_setsv(ST(0), (SV*) &PL_sv_undef);
                        }
                }

The standard responses from the “open source rah-rah crowd” are something like the following:

• “Yeah, that’s a crazy comment, but at least you can see it!  In proprietary software, there’s the same problems, it’s just hidden!”
• “At least you’re given the source code so you can fix it!  In proprietary software, you’re never given access to the source code so you couldn’t fix it if you wanted to!”

These responses miss the big point that commercial software is often much more fully tested for it’s specific environment, and undergoes a much more rigorous design process.  (Beyond the designed-for environment, things might break.  However, the environment is usually described.)

Having something that works — even if it isn’t “great” software — is better than not having anything at all; so on the whole, we can’t complain too much.  Open source is expected to evolve, over the long term (meaning, decades), into a better system: it’s assumed that eventually, most of the oddities will be ironed out.  The Linux kernel itself contains similar comments (I’ve seen them in debugging the UDP/IP stack) which is astounding considering that non-professionals consider Linux to be “stable”.  Kernel hackers know the truth — it “mostly” works (with “mostly” being better than “nothing”)..   Next time someone offers you “free software” take a moment to think:  how much do I have to trust that software to work in a situation which may be different than the author’s original working environment?  How much of the code’s architecture might have comments such as “Hmm.. This isn’t supposed to work or might not work..”?  How much is it going to cost ($$$) to find the oddities and dig into the internals to fix them?

The connection to Biology here is that these crazy design comments like “Hmm.. It really isn’t proper design to build it this way.. but it seems to be work” in synthetic life will be too small to ever read.  (In the RNA or DNA.)   At least with open source software, there’s a big anti-warrantee statement; don’t use the software if there is liability involved.  As I posted last year, the “Open Biology License” hasn’t touched on liability issues at all — only patent issues.  How much can Open Biology be trusted, how much might it cost ($$$) to dig in to find the strange biological behavior, and attempt to fix them?   Debugging biology is much, much harder than debugging software.