 |
||
 |
 |
 |
 |
 |
| how to evaluate open source software by sfg 06/14/2003, 6:11pm PDT | ||||
 |
 |
|||
| i hope this guide will save you a lot of time in picking out which 'open source software' you might have the misfortune to have to choose between.
step 1: how enthusiastic are the promoters? the more enthusiastic they are about the product, the crappier it probably is. step 2: does eric s. raymond have anything to do with it? are his quotes on the front page? watch out. you might enter the 'libertarian' version of life, where nobody is obligated to do anything for anybody, like , say, tell the truth about what a function does. step 3: are there a lot of flamewars about this product vs another product? chances are, both products are shit. if there is a huge war on usenet or some other place about the 'advantages/disadvantages' just try to imagine that these people are two drunken men trying to convince you that they are better at sex. step 4: is there an instruction manual online? chances are, if they hide the instruction manual in some kind of tar.gz file, pdf, obscure 'presentation' program, or even powerpoint, it means they were too embarassed to put it on the web. step 5: are there scant instructions on the web, and the product is kind of under development, but somehow there is still a 400 page book about it? this is called 'scamming you'. this book is a waste of money, because it is 400 pages of clearly written examples and screenshots of something that doesnt work. wait until the program actually does something, then maybe instructions will be useful. tragically, many nerds, especially open source ones, have a really really screwed up idea about what 'understandable' and 'legible' means. they seem to have bits and pieces of the proper idea going, but cant quite grasp how irrelevant that makes their efforts. like a housecleaner who scrubs the floor but not the toilets. example, you might find instructions that are in 5 different formats, automatically generated from some kind of proto-language like xml or rdf. thus there is html, html.tgz, pdf, postscript, etc, of the manual. but the manual itself has no index, table of contents, or page numbers, and is 25% screenshots and 25% 'yet to be written'. you might on the other hand find extensive and detailed descriptions of every option in the program, down to the minutest detail.... but no overall description of how to use the program or what the point of it is. you might find a 5 page philosophical diatribe on the design decisions that go into the product, and then find that a bunch of the commonly used functions have no instructions. you might find that there are no examples, or that the examples are wrong and do not work. all of these things are warning signs that the product is crap and you should avoid it. |
||||
 |
 |
|||
|
how to evaluate open source software by 06/14/2003, 6:11pm PDT  Re: how to evaluate open source software by 06/14/2003, 9:45pm PDT These aren't bad, but there are some major exceptions by 06/15/2003, 12:18am PDT Re: These aren't bad, but there are some major exceptions by 06/15/2003, 4:26am PDT Re: These aren't bad, but there are some major exceptions by 06/15/2003, 9:01am PDT SSH version incompatibility by 06/16/2003, 5:47pm PDT and then by 06/19/2003, 6:05pm PDT Re: These aren't bad, but there are some major exceptions by 06/19/2003, 6:08pm PDT play well with by 06/19/2003, 6:09pm PDT oops by 06/15/2003, 4:27am PDT |
