I am a true Open Source enthusiast, and always advise my customers to use open software whenever alternative to proprietary software exists. It’s link to the way many (Microsoft for instance) software company try to lock customers down by using closed formats, “forgetting” to put an “export all data” option and providing unstable (thus unusable) interoperability.
But I must admit it’s not possible to advise people to use software that I (computer geek type) can’t even install or try. If I’m not able to get the software working, my customer (usually not computer savvy) probably won’t be either. Recently, I gave some Python packages a try: virtualenv, pylons, and trac.
Test bench
I installed virtualenv on a FreeBSD 8.0 box, it installed cleanly, I created my environment, but was unable to use it because the command in the manual (“$ source activate.sh”) is broken and does not give a clean error message, so I was unable to debug the issue by myself. I assume the package is tried and tested on Linux boxes and the source command there works differently than mine.
I also installed Pylons three times, on my Windows dev box, because it looks like an excellent package. Out of three attempts, I managed to make the tutorial work only once. And as soon I modified the tutorial “Hello, World” into something else, I got strange and non-related errors every time I reloaded the page. Too bad, I will use Bottle for now.
Finally, yesterday I tried to install the dev branch of the Trac bug tracker. The instructions say you have to checkout and install the latest version of Genshi before checking out the latest of Trac itself from their SVN server. That’s what I did, and after ten minutes, I got an error message saying my version of Genshi was not high enough to use Trac. Probably someone set version requirements on his computer, tested it could deploy, but forgot to push the modification in the Genshi tree and I was … stuck. Finally I was able to download and install the last stable version, but not able to test the new 0.12 features.
Conclusion
Of course, I know those goofs are just exceptions in the long life of those three excellent packages, I probably came at the wrong time, and those bugs have probably been solved by now, but it shows the real need of automated integration testing inherent to every software development. And that could be a strategic advantage of the Open Source projects compared to the closed source ones, as their reactivity can make them implement those tools faster than it could be in a big corporation, with procedures, forms to fill and so on. Developers should pay extra attention making sure their software installs smoothly on every supported platform (virtualization is wide spread nowadays), so users are not scared away and then completely miss all the shiny features of their package.
Remember that 10 years ago, linux was labeled as “computer guru stuff”, I welcomed you by asking you the size of your hard drive and the number of cylinders. Now look at what Canonical did with Ubuntu: clean, mouse-driven, colorful installer. And then people were suddenly able to install linux, and realized that “damn, it’s even better than my old Windows box, and I don’t have to pay for it anymore !”. So please Open Source developers, fix your installers 😀
Update: I agree that instead of complaining, I could have filed a bug report in each project to report the issue. Although the statement is valid, it misses the point of “ready to use” software.
Eric Gazoni's Blog 