Kevin Rocap wrote: > You raise an important additional issue, though, around volunteers and > Open Source. I'd say most Open Source solutions do require a bit more > attention to the details of installation than do commercial packages > installed through an Install Shield wizard (or something similar).
This might sound like I am splitting hairs to some - but many Open Source packages are *commercial* packages. Commercial means that it is done for profit, and lots of Open Source software is done for profit. The Free Software/Open Source community does include people who donate their time and energy to software products, and those aren't commercial (yet?!). > It often is not THAT difficult, but you do have to go into PHP files, > or do other customized editing of files. That in itself can feel a > little iffy to the novice ;-), but feels better when it all works > right. But....you also need some memory or record of what changes you > made and to which files if you want to make modifications, upgrades or > fixes in the future. And I think that is also the rub. Proprietary software - where the code is not available for viewing - tends to be much slicker to install because it will only allow one to install it in certain ways. Most Free Software/Open Source solutions instead allow the user more customizability through editing of the files or what have you. And that is actually going away in the commercial Open Source packages because of the same problem - it *is* scarey for a novice. So 'Open Source' has the same problems as Proprietary software (in the context of 'commercial'), and sometimes more so because it's easy to be intimidated by having to edit a file. A task that people do every day, actually, in English or their native language. Documentation is a key issue in any commercial software, and Open Source/Free Software has had a problem with this. It's getting better, but the real strength tends to be the community. The community always amazes me, though since I am bleeding edge I get to be the one who doesn't get answers. But I write them down when I come up with them, and that's how it works. > Volunteers are most likely part-time and what one volunteer starts > another finishes. The only partial solution I can think of at the > moment is to encourage a culture of documentation where volunteers > keep a physical or e-notebook for each piece of software regarding > what they did to which files, as a kind of helpful history and > reference for others. > > Other ideas? The concept of the CVS is good if you use such an idea: https://www.cvshome.org/docs/manual/ However, for dynamic documentation shared amongst volunteers - Wikis are really the best bet. Yes, people may need to learn how to use Wikis - but they aren't very difficult to use (you can get the basics in under an hour) and allow for the sort of documentation you require. Incidentally, something such as Burrokeet (http://www.burrokeet.org ) is also something worth considering for documentation. It can even take OpenOffice documents and convert them to PDF and HTML - unfortunately, it cannot do that with Microsoft Office products, but Microsoft Office may not be the majority office software in the future. -- Taran Rampersad [EMAIL PROTECTED] http://www.linuxgazette.com http://www.a42.com http://www.worldchanging.com http://www.knowprose.com http://www.easylum.net "Criticize by creating." — Michelangelo _______________________________________________ DIGITALDIVIDE mailing list DIGITALDIVIDE@mailman.edc.org http://mailman.edc.org/mailman/listinfo/digitaldivide To unsubscribe, send a message to [EMAIL PROTECTED] with the word UNSUBSCRIBE in the body of the message.
