Hi Grigor!
Glad to see you've gotten this far!
In my experience, if everything goes right, .LRN can be set up in a couple of days. In my experience, not everything goes right. I remember Doc Edgertan saying about his experimental strobes and cameras: "You always make three of everything: you lose the first one and you need the second one for parts to keep the third one going." The essential thing is: finding a Linux Wizard, someone who knows Linux real well, and therefore, can figure out how to set up the Linux box and security, and when OpenACS/.LRN troubles begin, can figure out what is going on. If someone knows Linux and Perl, they can figure out Tcl. My Wizard, Manfred, can solve anything. Having such people nearby only encourages fools like myself to dig themselves in deeper. I've got only a couple of years of self-taught computing experience and only one formal computing (Oracle) course: I've taken this project on more or less as Sport. The best programmers I know are also sportsmen: there's something about the technology, especially Linux programmers, that is amenable to minds happy at play. Manfred is an archer. Don and I are photographers. Staff your project with someone who likes to fiddle. Setting up the system: a good week for a Wizard and Fiddler; a day per week thereafter to keep the box in shape. Best to incorporate it in a larger, on-going, professional Linux operation -- I think security issues alone require a full-time employee, as we have here, advising the rest of us.
Implementation, working with the users, is something else, requiring constant care and feeding. It was just great to have the .LRN crowd meet my customers and explain to them how and why OpenACS/.LRN was an unruly beast and how using it required a change in attitude: instead of a consumerist mentality, thinking BMW, throwing temper tantrums because the software was not perfect (Blackboard is being sold as "finished"). My colleagues learned enough about the development process to develop a different relationship to .LRN: to lower their expectations to the minimum of functionality necessary to get the job done, to see themselves as part of a implementation/development team and working cooperatively with them, and to see the advantages of .LRN/OpenACS over the long term: no license fees soaking up resource, investing in the local implementation/development team instead, being part of a larger development project, a sense of experiment and play, etc. That is, if you've got a university administration giving a computer center a pile of money, then I suppose you can see the problem as the technical one of setting up the box. But I'm doing it from the bottom-up, I have to win my customers and grants myself, and I've got only a couple of "true believers" on my side: the rest have to be won over. Choose your woman/man on the ground over there carefully, how many hours they work per week, I think, is secondary to the problem of building a strong customer base, or maybe put better: the problem of building supportive social relations to support the technology.
I should hasten to say that I think the atttude of experiment is is true for ANY system: I've just had the pleasure of reading the forums for a number of classes using Blackboard. I'd seen the forums only from the outside, in a formal presentation, and it all looked very impressive and hunky-dory and I left the room feeling like they had figured everything out and I had not and therefore I was small. But then I got passwords and read the forums in detail and saw how the system was being implemented, and now I have to confess that I have enjoyed a simply perverse satisfaction: the users entered most forums in dribs and drabs, but the forums on using the application were filled, and filled with invective: the interface was much too confusing for many, they didn't like the way it was being dumped on them, they thought the whole business hype and resented it being foisted on them. I don't think I have that problem at all -- even with all sorts of snafus, because of the low-key, voluntary way most of the handful of faculty I've signed on have gotten into it. I learned much of this from Al Essa, by the way, as you will recall from that fine story he gave of the professor who never touched the stuff until the day he wanted to connect to that one URL that had some data he wanted, and having gotten to it, has been a happy camper and supporter of IT at his school ever since: match the technology to real needs, don't push, build strength from the bottom. When I finally get the video conference call with Blesius online, the tapes are now being converted to .mpg, I'll make sure that that anecdote is indexed clearly so you can hear the lesson in all its insight and humor. Since then, I've been struck by the image of .LRN as being as innocuous as a toaster, a kitchen appliance. In my own mind, I've changed my own title, too, from System Adminstrator to Expectations Administrator, and in the spirit of this time of budget cuts, I have joined the "race to the bottom" and gotten mostly there: our overhead is low, the box can be replaced easily, and when things go wrong, like when I mess around with the code and crash the server or some portlet doesn't work, my customers call up and all but apologise for complaining. Plus, I like to tease The Competition by explaining how our original concept was to install .LRN on castaway PentiumII boxes, sticking one in each professors office, and having a half dozen of them standing by: an image that was so terrifying to some that we ended up being given a fast box built to our specifications. I still think the castaway box a good idea.
All the best,
Bruce
