I have now racked up some experience,  hosting and conducting workshops and code sprints. The experience has been humbling, exasperating, interesting, and more.  Here are a few things I've learned along the way.

1. Assume the least. Even when conducing a code sprint for developers for a Linux centric product, one thing you cannot assume is that they'll all be using Linux on their laptops! During a code sprint we hosted last year, we had participants showing up with a mix of Linux, Macs and Windows machines, and I'd assumed we'd only be dealing with Linux boxes and possibly a couple of Macs!

2. Internet connectivity is a great leveler. Quality and speed of internet connectivity is a factor that can vary wildly and throw carefully made plans out of whack. If you have to conduct a workshop where participants have to download several gigabytes of components during the installation process, the demo will go for a complete toss, if its going to take several hours to fetch the required files. While bandwidth speeds can be tested using sites like http://www.speedtest.net/, you can only establish the theoretical maximum file transfer speeds from servers located near-by. If the installation process needs to fetch files from other countries,  the speeds may be significantly lower. Benchmark with downloads of actual files that you'll use during your demonstration. It would be a good idea to setup a squid cache, to significantly speed up installations, particularly if all users are going to be downloading the same components repeatedly.

1. The mechanics of getting connected to the internet. Many conference venues/hotels etc require logging into a page prior to being allowed to use the internet. Keep this is mind, if you need to support headless clients etc which need to be connected to the internet. You'd need to be able to separately proxy them onto the internet, or better yet, connect a Linux box to the internet and run routing services on it, to get everybody onto the internet, without the need for separate logging in.

4. Wired vs wireless network connectivity. Many conference venues have a single port which is internet enabled; they typically use a wireless router with or without repeators, in the hall.  Many of these wifi routers are also flaky and may perform suboptimally, particularly since there may be other similar devices in close proximity, filling up the frequency space, potentially causing collisions/disruptions.  If you need to demo something which is network-critical, your chances of success would be better using wired connectivity, than the wireless.  If you connect a dual-homed Linux box to the wired internet port, you can perform routing for your other participants. A couple of 8 port fanless Gigabit switches like the GS608 when cascaded, can connect up to twelve participants with ease.  I put in the bit about fanless switches as I've seen switches kicking up a tremendous din in a small enclosed space, making it hard to be heard over! Communicate your ideas to your participants before-hand, as many laptops don't even have a LAN port nowadays, and require the use of optional adaptors, which your participants may not bring with them, unless asked by you, to do so. Assume the least!

1. Local hardware and networking. I recently conducted a workshop for a partner institute. I'd mentioned that I'd be using prebuilt VirtualBox VMs for the demonstration, and had mentioned the requirements that needed to be communicated to the participants. I was told by the organizer that they'd be providing laptops, for all of the participants to use. I was delighted by this, given that it significantly reduces variable components. I assumed that the laptops would be running some kind of Linux; turns out they were all running Windows! During a key portion of a demonstration, the machine had slowed down to a crawl (typical Windows experience after a few hours of hard use), so I thought I'd give it a quick reboot, to help. Turns out that Windows decided that it was the perfect time to download and install 167 updates. I was told that I couldn't interrupt the download or get it to reschedule it. I had to borrow another participant's machine to continue the demonstration, while the machine I'd been using took over an hour to apply its updates.  Always explain very clearly all your expectations about all local hardware and networking equipment you would expect to be using.  Amount of memory, disk space, operating system, distro, release number.. as specific as you need to be, to avoid nasty surprises at the last minute.

2. More than one screen. While a single large screen is more than sufficient for most corporate presentations etc, live demonstrations are totally different. You will definitely feel the need to have a second or even third screen, where you can have handy snippets of code, instructions, commands etc, rendered in a comfortably large font, for the benefit of users. With a single screen, even if you have all of the instructions in one screen, you'll have to switch to it each time a participant wishes to see it, and you'll have to switch back to your demo screen, to continue. If you try to have both in the same window, the sizes will have to be shrunk to the point where it's not visible to many of the participants. If you need to be able to have multiple screens, you'll definitely need to plan for this/communicate your need well in advance, so that arrangements can be made. This is almost never something that can be organized at short notice.