“Umm…”

Conversations that start that way are never good ones. This was going to be no exception.

“No one can log in. Is something wrong with the server?”

Apparently, there was. It was late 2000, and I was pretty much on my own when it comes to technology in the district. My predecessor had hired a network consultant eighteen months earlier to set up the server. In the intervening time, I was hired, she quit, and my budget was cut to zero after a levy failure. There were no consultants, and no money to hire consultants. We were running Linux, and, as far as I know, we were the only school in the area doing so. I had learned the basics of account management, as well as a few simple diagnostic tools and command line utilities. But I really had no idea what I was doing.

Since it was me (and Google) against the world, there was really nothing else to do but figure out what the problem was and fix it. Basic stuff first. Can I access the server remotely? No. Can I log in locally at the console? Yes. Is it fixed yet? No. Are there any network problems that would affect connectivity? No. Can you tell me how much longer it’s going to be? No. Are there log entries that are out of the ordinary? Yes.  Do I understand them? Umm… no.

So it went. What could the problem be? How could I eliminate possibilities? I narrowed it down, tried things, documented what I was doing, and eventually found the solution. It was my fault (it always is). In hindsight, the problem was predictable and the solution obvious. But those are relative terms, aren’t they?

It was a rough year. I was doing two jobs. Without a budget, I had to beg for ethernet patch cables and power strips. I was responsible for all technology in all six schools. But I learned a lot that year. I learned to prioritize, and to simplify, and to standardize. I learned that sometimes people will fix the simple stuff themselves if you give them enough time. I learned to conserve resources. But mostly, I learned that I have to solve my own problems.

Things are better now. I have a staff. I have a budget. I keep some consultants on call. I have a professional learning network. There are people and resources to help me solve my problems. But the attitude is still there. My first instinct when something goes wrong is to fix it. It’s not to call tech support. When I do have to call support, I try to learn as much about the product and the problem as I can, so I can fix things myself in the future. I’d much rather spend an hour learning about a problem and trying to resolve it than sitting on hold.

This attitude has had some remarkable benefits. I embrace open source technologies. We use WordPress and Moodle and MRBS and Samba and a host of other applications that we don’t pay for. There are support forums and web resources, but there’s not really anyone to call when something goes wrong. I’ve never really seen that as a problem; I’m used to it.

But I’m finding that most schools aren’t like that. Increasingly, it seems like school tech people want out-of-the-box solutions that work all the time, with people to call when something goes wrong. They’re not interested in hosting their own web sites or managing their own servers or troubleshooting compatibility problems. The don’t care that their web-based products don’t authenticate against their existing user database, or that the products they’re using can’t be tailored to their own needs.

There’s nothing wrong with those expectations, but they’re expensive and inflexible. These schools pay many times more for their technology infrastructure than I do. And schools never have enough money to go around, especially in areas like technology. But until the mindset changes in these schools, they’re stuck.

Case in point: Moodle. For the uninitiated, Moodle is a learning management system. It’s intended for teaching online. It’s organized into courses, each of which can contain content, assignments, discussion forums, wikis, glossaries, and a host of other types of resources. Students typically participate by reading or watching or listening to the course content and interacting with the instructor and other participants.

Running a Moodle server is not a big deal. You uncompress the files into a folder on your web server, create an SQL database for it, run the installer, and set some configuration options. But if you’re used to someone doing that for you, it’s impossible. A fellow tech person was having problems with his new Moodle installation a couple days ago and posted about it on the listserv. Several people jumped in to help, and the questions they were asking were enlightening. Is php installed? Did you create an SQL database? These are pretty basic things, and I mentally rolled my eyes when I read them. It’s the equivalent of asking someone if they’ve plugged in their computer AND turned on the power strip. But the answers were equally telling. How do I know?

Though it’s a bit overused, maybe it’s a good time to quote Morpheus from The Matrix:

This is your last chance. After this, there is no going back. You take the blue pill and the story ends. You wake in your bed and you believe whatever you want to believe. You take the red pill and you stay in Wonderland and I show you how deep the rabbit-hole goes. Remember that all I am offering is the truth. Nothing more.

Take the blue pill and call a commercial company that will do everything for you. Stay in the box. Believe what you want to believe about what is possible and available and affordable. Or, take the red pill. But don’t take the red pill and try to set up a Moodle server. Take the red pill, find an old computer, and install Linux on it. See what you can do with it. Do a lot of reading. Do a lot of experimenting. Don’t be afraid to erase the hard drive and start over again. When you get something working, get a few brave souls to try it out. Build your confidence. Then start rolling it out to more people. But stop being so helpless.