Running a Research Lab on Free Software?

Neurotensor asks: "My lab is researching quantum computing, and I don't like the fact that Windows / Visual Basic [seems to be] the preferred solution for controlling the experiments. It's not just a pride thing, unlike many colleagues I know what I'm missing out on, in the free software world. I've wasted a *lot* of time and effort trying to implement some very simple stuff with free (and better) alternatives, simply because certain hardware manufacturers utterly refuse to support anything other than Windows." There were older articles that touched on this subject, 2 years ago, but are others still finding themselves in the same situation as the submitter?

"[Hardware Manufacturers] seem to get very upset when somebody asks them what the register-level interface to their card is. Who could blame them? Their Windows DLL is the perfect solution under [most] circumstances.

I'm not the only one around here getting frustrated, but all before me have been defeated. It seems I am to be as well, for today I have started to learn Visual Basic.

Has anyone had any *positive* experiences trying to move a lab from proprietary to free software? Surely the government-funded researchers of the world have a responsibility to ensure that their work is free, as in freedom. However, I have found out the hard way that it's usually just not worth the effort, following such ideals. You just get frustrated by apathetic colleagues, useless product support, and the conventional wisdom that it's OK to ignore your ideals, so long as you get the experiment working. Additionally, my ordeals convince my peers that free software isn't worth the trouble."

Comments

Linux in Research

[Linthos]

For almost any government project i have seen, Windows is the choice by the government. Getting them to switch over makes no sense to them, because why switch when you have something that works? Cost benefits don't really seem to do anything, but they seem afraid of switching and trying something new because Windows is just the way it has been, and will continue to be for them. Research might be the same way. UNlesss their research IS software like this, they may just want to stick with what has already beenw orking for them.

Do it on a project-by-project basis

[TheConfusedOne]

I work in a Corporate R&D lab and we're pushing open source technologies here, but you have to be patient and strategic.

First off, are you trying to make programmers convert? If so then you're in a losing battle. People will almost always stick with what they're comfortable with. You'll only get them to look at something else if it is 1 or 2 orders of magnitude simpler to use.

Set an example with your work. If you can do your work using OS tools and you can do it quicker, cheaper, and easier then that's how you convince people. Comments like, "But VB is lame. MS is the anti-christ. etc..." do NOT a good case for conversion make.

Finally, if you can't do it in OS then don't. If you're stuck because of specific hardware/OS issues then don't try to fight the beast on those for now. Pick projects and things that you can migrate and move those instead. (Move the intranet site to JSP or PHP or whatnot on Linux/BSD/Apache. Throw out some NT/2000 Domain boxes and use SAMBA instead.) If you can show the advantages of OS tools for certain tasks then you can get people thinking about it. If you can't do it because of the hardware you're using then you're just going to appear as a stubborn zealot to your colleagues.

Re:Labview

[DirtyJ]

Labview is indeed very nice. Once you get used to the graphical programming, you can work very quickly. Interfacing with hardware usually goes quickly and smoothly - especially if you buy National Instruments hardware; of course Labview is set up to interface with NI hardware with minimal pain. And it runs on several OS's, I think. Certainly it runs in Linux.

However, if part of the motivation is moving to free or cheap software alternatives, Labview is not the answer. NI charges one metric shitload for their products. But... for people running and working in a research lab, time is extremely valuable - perhaps moreso than money. You'll probably make up for the money cost of Labview with the time saved easily interfacing software/hardware. Time saved = salary saved, after all...

Re:Obviously...

[MourningBlade]

Yes and no.

A research lab, especially a public one, is first and foremost obligated to do science. To clarify what I mean by this, let me say what I mean:

The experiment must

• Have a clear question in mind, and a method for discerning success from failure (not as easy at it sounds, when your result is not binary).
• Be repeatable by your lab.
• Be repeatable by other labs.

In a physical experiment, it is perfectly acceptable to use a proprietary kit, provided that you can:

• Show that the results are replicable
• Give other labs access to said kit (for a price) and have the ability to produce more
• Show that the results have relevance to what it is that you are trying to achieve

That is true for physical experiments. For manipulation of the data of an experiment, however, the procedure must follow a published or publication-pending method of analysis if you intend to have your research be considered legitimate.

It is coming to pass that algorithms are becoming complex enough and analysists savvy enough, that it is often more practical to produce clear, well-documented source code in addition to your paper than it is to go over and over again the fine points of your method with every interested party.

This leads me to my point: in physical interaction, proprietary and closed methods will most likely remain prevalent for many years to come.

In information manipulation, however, open methods are becoming a dominating trend, if only for the clarity they afford.

In my lab we do bioinformatics research, and we could not do research on the scale we are doing at the pace we are doing it if we were depending upon proprietary software: the proprietary companies cannot compete on customization, new development (after all, we're the ones creating the method), user interface (we're improving all the time, most proprietary packages have ancient user interfaces that are clunky and just plain awful, read: GeneSpring and friends), and cross-lab communication and auditing.

These proprietary solutions are forcing many theoreticians to use software that is "open" in another way: Excel. Yes, I kid you not. Quite a bit of bioinformatic analysis development is done in Excel because the proprietary solutions are just too closed.

The only proprietary companies that are on the right track, in my opinion, are the ones that allow you to use the app as a hub for many other componentized programs.

A couple great alternatives

[ZxCv]

My first choice is Delphi. I don't think I'd ever say Delphi is better at creating quick`n`dirty apps than VB, but I would most certainly say that it is completely on par in that area, with the added benefit of being much more powerful. (My opinions here are based on VB6 and Delphi5, which are the last two I used heavily before being liberated from Windows GUI work.)

The other alternative I can think of is RealBASIC. Their development environment used to only run on Mac OS, even though it could compile apps for either Mac OS or Windows. Nowadays, the environment itself as well as the apps it creates all run on both Mac OS 9/X and Windows, although I've never used the Windows development environment. I've only had limited exposure to RealBASIC, but based just on those few hours, I would highly recommend any fan of VB at least give it a shot--I know if I ever have to go back to Windows GUI work, I certainly will. (It seems it would especially shine for quick`n`dirty apps because it seems to focus more on simplicity and cross-platform rather than feature bloat.)