This post summarizes a lot of what I have learned about using OSS in the projects I have had.
Do what is usually done – avoid unusual setups
Open source software, whether it is an MVC framework (like Ruby on Rails, CakePHP or Codeigniter), backend software (such as Apache or a particular library) or end-user software (like Gimp or OpenOffice) is generally built scratch an itch felt by the author. There is nothing bad about this. However, expect to run into problems if your intended use is different from whatever the software is usually used for – despite whatever “counterpoints” offered by enthusiasts of that particular software.
As long as you use OSS for things that are commonly done, you will generally save time and money using it. However, if you step outside the common use, you will probably run into issues that are a pain to solve. As someone said, Linux is free if your time is free. I love having Linux on my netbook as a cheap and lightweight server, but I have quit searching for solutions to anything that doesn’t work out of the box (such as in my case, the WLAN drivers). It just isn’t worth the time when one can dual-boot Windows with little effort.
Now if anyone were to actually read what I write in this backwater blog, they would blame me for being a lazy moron, or tell me that this issue in particular is due to the hardware vendor not providing adequate support (or only providing proprietary binary drivers). Well, I don’t care whose fault it is. If you want me to use it (you probably don’t), then get the damn problem solved. Knowing that I could muck around for 2-3 days trying different solutions doesn’t really solve the problem. I appreciate the work (I really do!), but I will only use it if it works for me. (There is no law saying that just because you can do something with OSS, you must do it using OSS.)
This applies to MVC and other development frameworks (and libraries) as well. They are built to match whatever their authors have been doing the most. A lot of web development involves simple CMS-or-blog-or-event-site type websites where having conventions and backend support such as ORM (object-relational mapping) is really useful.
The problem is that when evaluating different MVC frameworks, you will generally find someone who will insist that it can solve whatever key problems you need to solve in your project. They are lying.
As John McCarthy (Stanford) said: “Personal dishonesty is not needed to produce a dishonest business plan or research proposal. Wishful thinking suffices.”
GIMP really is not the same as Photoshop and OpenOffice isn’t Microsoft Office, despite arguments to the contrary. Enthusiasts aren’t really lying, but they are blinded by their enthusiasm for whatever technology they are using to the extent that they cannot imagine why someone might have completely different needs. It works for them, which says nothing about whether it will work for you in your particular situation.
The smart and conservative approach to evaluating the alternatives is to give a lot more weight to perceived concerns (such as technology performance, platform support and maturity) than to whatever optimistic assurances the enthusiasts of any community offer you. If you see a number of side-mentions of concerns such as “X does not scale very well”, or “X is hard to deploy”, or “X is very unstable”, or “X is not commonly used for Y”, take note. More likely than not, it is true to some (significant enough) extent.
Someone (can’t find quote) said that you can judge an organization by the problems people concern themselves with. Non-problems are generally not discussed nor are they debunked by passionate enthusiasts. Think about Java performance, or the usability of Linux-based OS installation. They were talked about a few years back, now they are essentially non-problems.