I just got back from the wonderfully educational and inspiring BFlex/BFusion conference in Bloomington, IN, and I want to thank Bob Flynn for putting on another great conference and for his tremendous hospitality to Team Mach-II while we were in town. Save us a spot for next year!
BFlex is designed to be all hands-on sessions, some 90-minute and some full-day. This is a great idea and one which other conferences could stand to emulate, at least in a small dose. The hands-on sessions allow participants to bring their own laptops and get concrete experience in CFML and Flex as opposed to simply watching slides and hoping they remember how to do everything when they get back home.
This model is not without its dark side, however, and the hell of hands-on sessions can be summarized in one word: installation.
My hands-on session this year was entitled "Building and Deploying CFML on an Open Source Stack," and as I thought through all the bits and pieces attendees would have to install to get any value out of the session, I saw my 90 minutes being completely consumed by installation and configuration issues. Rather than chance it I decided that I would only expect attendees to install VirtualBox (because it's free and runs on Linux, Mac, and Windows), and I would give them a Linux VM with everything pre-configured. That way we could focus on playing with the open source stack instead of dealing with installation issues in the limited time we had in the session.
So I created my VM for the session, put it on a few thumb drives, and as I was doing some intro slides before the hands-on portion people installed the VM on VirtualBox and I hoped for the best. I expected at least a couple of people to have problems with the setup but to my amazement there were literally ZERO problems with the VirtualBox VM. By the time I was done flapping my gums everyone was ready to get their hands dirty.
The next morning I was a TA for one of the all-day Flex classes, and to call the configuration problems a bloodbath would be being kind. Trying to get a room packed full of people to get BlazeDS up and running when they all have different operating systems and hardware is a nightmare of epic proportions. Between the installation and configuration problems, not to mention some problems with the code files for the course, by the time lunch hit the class still couldn't proceed. Half of the full day class was gone, which put a serious dent in the amount of learning that otherwise would have happened.
My experience handing everyone a per-configured VM versus a room full of people trying to do a native install of a bunch of software was a major eye-opener for me. It's a simple idea, and it's the reason when you go to training centers that you use pre-configured workstations. Having people, even technical people, bring their own machines and install everything necessary for a course is a recipe for disaster.
So what does this have to do with Linux?
The VM idea is great and worked better than anyone had hoped. So why not do the same thing for the all-day courses?
Because that would be breaking the law.
Here's the problem. I could hand everyone in my session a VM because it was using Ubuntu and all open source software. Heck, I even made the VM downloadable for people who were attending a different session in my slot or who weren't at the conference.
Adobe software, at least the apps that would be used in training courses, only runs on Windows or Mac. Mac licensing prohibits VMs of OS X to even be created, and while you can create Windows VMs the proprietary license would prohibit a Windows VM from being distributed. Given the platforms on which Adobe software runs Windows would be the only choice for a courseware VM, but because of Windows licensing that isn't a possibility.
Which leads us straight back to installation and configuration hell.
At this point you might be thinking that pointing to training as a reason for Adobe to support Linux is a weak argument. Adobe has to worry about the overall market for sales of their products, after all, not just training scenarios.
I'll address that notion by asking a question: after struggling for several hours to get things up and running, and in some cases still failing, what does this do to course attendee's opinion of Flex? I doubt many people were hurriedly finishing their lunch to return to another installation torture session, and I'd be willing to bet it left a seriously bad taste in the mouths of beginners in the room (and this was a beginner class after all) who will see Flex as well beyond their reach after such a hugely negative experience.
Being able to run trial versions of Adobe software on a free operating system opens up a huge number of doors in my opinion. I truly hope that Bob and crew will find a way to do everything with VMs for BFlex next year; perhaps there are "lab" licenses available from Microsoft for just this purpose that expire after 30 days or something along those lines. Not ideal compared to a VM students could refer to long after the course is over, but at least it's something.
Using a free OS, however, would eliminate all the license issues that render trainers helpless and people can focus on learning instead of slamming their heads against installers and Java environment settings and all the rest of the nonsense that gets in the way of what they're trying to do.
I realize this is wishful thinking, but after having such a positive experience with free software and seeing the abysmal experience people had due solely to operating system licensing issues, all it did was convince me even more that free software is the way to go. Maybe Adobe will see the light someday as well.