OSS Watch : Walking into the Sunset - Elliot Smith
Elliot Smith is going to explain to us how to choose open source software. This sounds like it could be useful...
Lecture Notes follow
Lecture Notes
-----------------
Installing Drupal took about 15 minutes. Result was a 'gleaming machine', which he then filled with stuff. Upgrades occurred, which he didn't use. Result was that within a year the software was 'a pile of rust and junk'. This was a problem of the user not keeping things up to date...
So, how do you create a productive relationship with a piece of software?
Won't be talking about skills or policies. Will be talking about resources - what will I need and how can I tell? You will need to upgrade, extend and fix the software. But that goes for anything. Suggests that it's easier to estimate this stuff if you're using Open Source software because you can see it happening in the open.
Open Source does mitigate the risk that software might break and your vendor won't fix it. You always have the option to do it yourself.
If you're evaluating Open Source you have to engage with the community / content. So read SourceForge, Freshmeat etc. and track projects around the area. You have to get engaged to understand this stuff.
How do you tell the prospects of Open Source - in basic terms, is it being used and is it still being developed? The latter is more important, because Open Source tends to die if it's not being actively developed. Remember that this has to be balanced against what you're planning on doing with the software - dead projects have their uses.
Scalability - not the most important thing in the world. Worry about it once it becomes a problem [hmm. Not too sure about that one]
Numbers to look for : Bug reports - how many and how quickly are they fixed; Code check in - how often does this happen and what proportion are bug fixes; How many people are submitting patches; How many downloads has it had; How much traffic does it get.
Other things - look up the developers, what else do they work on, do they blog? Do they say the project is stable and do they ever expect it to be? Does it ship with anything out of the box?
Formal models for software evaluation : Open Source Maturity Model, Business Readiness Rating, Woods and Guliani (book), JISC QA Focus... [All seem to work. Might want to look into these in more details.]
Examining code quality : Is there an API, is the code modular, is there a set of coding standards in use, consistency of naming files / variables, is it documented, comments in the code, presence of a test suite (and coverage / quality of this).
Before patching anything see if anyone has done it already. Then log a bug report / feature request. Then start work on patching this, and once you've done it encourage the community to use it.