I really regret having to spend the time writing this since in a lot of ways it will be airing dirty laundry. But since Adam is grossly misrepresenting a great deal of what went on during the effort of the CFML Advisory Committee and what led to its eventual demise, I think it's only fair that people don't take Adam's version of the story as gospel. It's far from it.

Preamble

First, I'd like to get some semantics out of the way. I can't bring myself to refer to this now-defunct effort as "Open CFML" because it's such a huge misnomer. Frankly, we never referred to the committee as "Open CFML" so I suspect the use of that term in Adam's blog post is merely FUD/scare tactics that suit his purpose. (Saying Open CFML is dead sure has impact, don't it?)

The CFML Advisory Committee was anything but open. There was no communication with the CFML community as to what was going on with the effort, there was no way for the community at large to participate, and suggestions by myself and others to update the wiki regularly with our progress and have an open mailing list that anyone in the community could at least read were continually shot down. Given all this it's not surprising the effort ultimately failed, because openness always wins in the end.

Now for the timeline of the CFML Advisory Committee and why things went wrong from my perspective.

In the beginning ...

When I was invited to join the CFML Advisory Committee I was excited because I originally thought the effort was important for the future of CFML. The CFML landscape changed dramatically with the introduction of two open source CFML engines, so it seemed logical that the interested parties would want to get together and discuss a certain level of standards for the language. It's also something that the CFML community was clamoring for, at least initially, because of concerns over code portability between the various engines.

After getting up to speed on things and having discussions via the closed mailing list as well as a couple of conference calls, it became quite clear to me that the effort wouldn't be able to survive the politics. Even given my valid pessimism, I decided to continue on in earnest, hoping for the best but expecting the worst.

Here comes a bit of dirty laundry, but I think it's necessary for people to understand what was really going on behind the scenes. Adobe's participation and level of effort during their involvement with the committee was incredibly lackluster. The committee had conference calls monthly in the beginning, but after Adam didn't show up for three calls in a row, it seemed rather pointless to continue to schedule them. The email traffic on the closed mailing list would go in fits and starts, and in many cases months would go by with no traffic at all.

To cite but one example of Adobe's lack of effort, the way the committee was attempting to organize the language was to use a Google spreadsheet, with columns for the CFML tags and functions on the left, and then a column for each engine indicating whether or not it had the tag or function. There were then columns for each member of the committee to indicate if they thought the particular tag or function should be "core," "extended core," or "vendor specific" as far as the eventual language specification was concerned.

As you can imagine simply organizing the spreadsheet took a great deal of time and effort, to which many members of the committee contributed. Each vendor was tasked with entering their engine's tags and functions. OpenBD and Railo provided their information quite promptly, and I think it was Rob who did the Lion's share of getting things organized initially, but Adobe's column was incomplete for weeks. Finally I took a day or so and added/corrected all the Adobe functions and tags. That at least got things to the point where we could vote.

When it came to voting, Adobe failed to complete this effort as well. To put things in perspective voting took about an hour, but Adobe couldn't seem to find that hour to input their votes. First it was the CF 9 release, then it was MAX, then ... who knows. Bottom line is it never got done. Everyone involved with this effort is incredibly busy, yet everyone but Adobe made the time to vote.

Lack of Accountability Means Lack of Commitment

After weeks turned into months and the voting was still waiting on Adobe, I believe it was Peter who made the modest proposal of setting deadlines for votes. If someone didn't meet the deadline then we'd simply indicate the person didn't vote and proceed with the votes we had. Everyone paid lip service to having deadlines, but even while discussing deadlines Adobe reserved the right to ignore the deadlines if they were "busy." Again, we're all busy. Either the effort is worth your time or it isn't.

I also suggested repeatedly that the whole specification and voting process be open to the public. The members of the committee were selected to represent the CFML engines and the CFML community, but we don't necessarily have all the best answers, and at a minimum the community at large should have been able to see the process as it unfolded. But that would have meant both commitment and accountability on the part of everyone involved, and in the case of certain members of the committee the commitment clearly wasn't there. Having accountability--let alone public accountability--wouldn't work in their favor.

In the end the incredible lack of progress led everyone to agree to simply codify what was in Adobe CF 8/9 so we could get past the voting roadblock and move on. (Keep that decision in mind; it backs up an important point I'll make later.)

Conspiracy Theories Debunked

Here's where things get really bizarre, so please don your tin foil hats and try to stay with me.

Adam mentions the CFML Conventional Wisdom group in his post, which is an effort Alan Williamson started in order to foster public discussion of the CFML language. Personally I think an open discussion list should have been an arm of the CFML Advisory Committee from the start.

To quote Adam's post, "At the very least, this explained why Peter so abruptly resigned." I'm not going to speak for Peter, but this is not why he resigned, and his resignation wasn't exactly abrupt. He debated it for a long time, but to call it abrupt reminds me of a scene from "Fletch":

Back to our story. So why didn't I mention the CFML Conventional Wisdom list to the committee? Two reasons.

First, it's a public mailing list, and I found out about it like everyone else did, on a blog post or Twitter or who even remembers where. Alan may have even sent me an email directly to make sure I was aware of it, but it wasn't a big secret. There were no back-room dealings on any of this. Alan saw a need, created the group, and then announced it publicly. Simple as that.

Second, and more importantly, I saw this as a completely separate effort from what the committee was doing. The committee never had a public forum to discuss CFML, and the powers that be on the committee didn't want one. So this provided something the committee didn't, and giving the community a voice in helping to define the language they use is something vitally important in my opinion. Ultimately the Conventional Wisdom list could even serve as a benefit to the committee. Loose ideas could be hashed out, sample code usage could be created, and the results could be submitted to the ivory tower that was the committee.

And a bonus reason: at the time when the Conventional Wisdom list started, the committee was in no way, shape, or form in the business of discussing enhancements to the language. We weren't even able to codify what was already in the language, so for Sean, Peter, or me to bring a CFLOOP enhancement discussion to the committee wouldn't have made sense. The committee wasn't the time (or the place, frankly) to have those sorts of discussions.

The way Adam phrased all of this makes it sound like Alan, Peter, Sean, and I got together and were all conspiring against the committee, and maybe Adam even believes against him personally. Nothing could be further from the truth. Sean, Peter, and I found out about the Conventional Wisdom group when everyone else did, and since people on the committee are supposedly aware of what's going on in the CFML community, I assumed everyone on the committee would have seen it as well. The implication that we were keeping a publicly announced, publicly available list hidden from the committee simply doesn't hold water.

As for my better mouse trap header above, ultimately I think having an open discussion group is the way things should have been from the start. Why not seek input from the community at large? Why not have the discussions out in the open? Seems like a no-brainer to me. If Adobe wants to have enhancement discussions with their customers and among the members of their private programs that's great for Adobe, but that doesn't let the legions of CFML developers in the wild participate in the process.

Again, openness always wins.

Where I Agree

Adam did make a couple of points with which I agree.

"In the end, the community isn't losing much at all with the demise of the OpenCFML board."

I completely agree with this statement. Though I was honored to be a part of it I questioned the effort from the beginning because at the end of the day, Adobe ColdFusion sets the de facto standard for the language. I made that point in my last email to the committee list (which for a very long time was the final email on the committee list), and I don't think anyone would disagree.

I take issue with Adam's follow-up to this statement, but life's too short to nitpick every last detail of what he said. The real beneficiary of this effort was supposed to be CFML developers, but somehow that ideal got lost along the way.

Bottom line here is that CFML developers don't have anything to fear due to the loss of the committee, because the practical value of the end goals were rather dubious from the start. It's in the best interest of the open source engines to be largely compatible with Adobe CF, which they are. We haven't had an official CFML standard before and the world hasn't come to an end, so the cf_apocalypse won't come now.

"Innovation and progress in CFML is driven exclusively by the ColdFusion community."

I suspect Adam and I have very different ideas of what constitutes the "community" and what community really means, but ultimately this is correct. The odd thing here is that before the Conventional Wisdom list was started, there was no single public forum where members of the community at large could discuss what they want to see in the CFML language. So if innovation and progress in CFML is truly driven by the community, they now finally have an outlet.

Setting the Record Straight

Now, for the corrections.

"Matt claimed the OpenBD team was too unorganized to submit tags like CFJAVASCRIPT and CFSTYLESHEET (tags I had hope to include in CF9)."

Pure FUD on multiple levels. I may have said something along the lines of "These tags were added on a whim last week," but that's how open source projects work. If Alan or Andy get an idea, or need something for a project they're working on, they'll create the tags and release them in a nightly build. We then get feedback from people actually using the new features and refine as needed. That in no way means the OpenBD team is disorganized. It differs from proprietary software development, sure, but calling that process "disorganized" would be the equivalent of me calling Adobe "lazy" because they only have a new release every two years. Apples and oranges.

CFJAVASCRIPT and CFSTYLESHEET were added to OpenBD, and Adam's response when he found this out was apparently to take it as an affront because we didn't run the idea by the committee first. Adam seemed to continually and conveniently ignore the fact that OpenBD is an open source project, so Adobe or anyone else can see what we're doing every step of the way.

Furthermore, it was agreed upon by all members of the committee that tags and functions developed in specific engines would be brought to the committee only if their creators wanted the language enhancements to be considered as "core" in the CFML specification. We didn't consider CFJAVASCRIPT, CFSTYLESHEET, and some of the other innovations in OpenBD as "core" CFML, so we didn't officially submit them. But again, the source code is open. If Adobe saw something in OpenBD they thought made sense to be core to CFML or to add to ColdFusion, they could have brought it up and we could have discussed it.

And let's talk about what "submitting a tag" to the committee even means. I'm not sure what exactly I was even supposed to "submit"--the tags were out there in the OpenBD source along with documentation as to how they are used, so wouldn't it make sense that if Adobe was interested in considering those tags for ColdFusion they could read the docs and ask about it on the committee list? If you get the sense from Adam's post that there was some rigorous formal process that OpenBD was somehow subverting, don't. There was no such defined submission process in place.

Finally, the "tags I had hope[sic] to include in CF 9" bit is completely bogus. Yes, Adobe did make some changes to CF 9 (specifically CFSCRIPT if I remember correctly) based on the committee's recommendations, and I applaud them for that, particularly given that CF 9 was nearing the end of development at that point. They ignored plenty of other recommendations, and the reason for that--the real bottom line here--is that CF 9 was largely baked by the time the committee was even having these discussions. So to point a finger and say CFJAVASCRIPT and CFSTYLESHEET didn't make it into CF 9 because I failed to make an official submission to the committee is false on numerous levels. We didn't consider them to be core to the language, the code and spec were available from day one, and adding this new functionality to CF so late in the development process likely wasn't going to happen anyway.

"Sean claimed that Railo wanted to wait a version (or two) to see how new Railo tags were accepted by the community before making a formal recommendation."

Again, this is how open source projects work. Did Adobe expect that the open source engines will stop following the process that is best for their projects and users, and hit the brakes on the rapid pace with which new features are added, to ask the committee's permission before making enhancements to their engines? Does it not make sense--and ultimately benefit Adobe--if the open source projects introduce new features to CFML and let the community kick the tires before finalizing the feature? That saves Adobe time in the future if they decide to implement these features, because a lot of the questions surrounding the new features and how they should work will already have been answered.

I'm at a loss to see what the real issue is here. OpenBD and Railo are both open source, both have nightly releases, both have public roadmaps ... everything's always available for anyone to view. I think ultimately this comes down to a culture clash between open source projects and proprietary products, which was probably partially to blame for the failure of the committee's efforts.

"As a community, we never needed the OpenCFML board to guide or document feedback."

I give this one a "thumbs sideways." We didn't need the CFML Advisory Committee specifically to serve this function, but I don't see Adobe doing anything to foster open language discussions in a public forum either. Perhaps that isn't their job; they focus on finding out what their paying customers want, and no one can fault them for that. In similar fashion the open source projects get continual feedback from their users and make changes accordingly.

I do think it's important that there be some avenue for people to discuss CFML as a language in an engine-agnostic way, however, but that was as simple as creating a Google Group. It's a much better solution and will yield far better results than the committee ever would have.

"I really want to thank Ben, Rob and Ray for the work they put into the OpenCFML."

... but no one else. Not Sean for making valiant efforts to keep things going even when the committee was at its lowest points, and not any of the rest of the people who participated far more than anyone from Adobe, and particularly Adam, ever did. If anyone questioned Adam's real attitude towards the committee that statement pretty much sums it up for me. He was never interested in setting politics aside and working collaboratively to create a CFML language spec, and apparently the only efforts that matter are the ones made by the people in his camp. "You're either with us or you're against us" has been proven to be a very divisive attitude, and it's one that ultimately isn't good for the community as a whole.

"As far as I am concerned, the ColdFusion ACPs will be the CFML Advisory Panel for ColdFusion X and beyond. We'll be asking them to review and sign-off on all of our language enhancements (very soon)."

So this at least defines what "community" means to Adobe, and helps to illustrate that they never had any interest in helping to define CFML as a language outside of their own product. That's fine, and makes perfect sense coming from a proprietary software company, but leads me to the conclusion that the CFML Advisory Committee was a PR stunt to begin with. Adobe's heart was never in it, they were just trying to get out in front of the open source CFML revolution.

In Summary ...

The goal of Adam's post is patently obvious: to blame everyone but himself and Adobe for the failure of the CFML Advisory Committee. His rhetoric sounds almost McCarthy-esque. Get people focused on a common enemy--real or imaginary--and they'll become oblivious to little things like logic and the truth.

Let me be clear: Adobe's lack of participation and paranoia over the supposed malfeasance of Railo and OpenBD are, from my perspective, a massive part of what killed the CFML Advisory Committee. I'd have a lot more respect for everyone involved if we could have collectively decided to end the effort, made a joint statement, and parted ways amicably. But for Adam to post a truth-challenged version of events out of the blue, while not surprising, is in very poor form.

And That's All I Have to Say About That

I've said my peace and then some at this point. Feel free to comment, and if you have any specific questions you think I can answer, I'll be happy to do so. If, however, your comment is of a "he said/she said" nature or intended solely to inflame the situation further, don't be surprised if I don't respond. Adam gave his version of the story, I've given mine in abundant detail, and everyone can continue to speculate on what went on behind the closed doors of the committee. If you care to, anyway. I'd certainly hope you have much, much better ways to spend your time. ;-)

To me, it's not worth dwelling on all of this. The CFML Advisory Committee will go down as an interesting side-note in the annals of CFML history, and people looking back will wonder why we even tried in the first place. I've been asking myself that very question for quite some time.

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.

For example, all the form fields in one of the PDFs I'm working with are
set to font face Times New Roman and "Auto" for the font size. Random
fields here and there show up as Arial instead of Times New Roman and come
out some massive font size, even though other fields with the same amount
(or less) text are a reasonable size and are the correct font face.

Since I only recently figured out how to do mass changes of the font face
on multiple fields (usability fail; and this doesn't work consistently by
any means, but it's faster than doing it one by one), I thought I missed
setting the font face correctly on a field or two. But lo and behold when I
open the PDF form in Acrobat Pro the font is CLEARLY set correctly, yet the
generated PDF still renders the font incorrectly.

All that's bad enough, but the PDF size issue is really starting to kill
me. The particular PDF I'm modifying started out at about 500K in size. I'm
having to experiment with some things to figure out these annoying font
issues, so I changed all the fonts from Times New Roman to Arial, saved the
PDF, and the file size went up to 800K. I then changed the font back from
Arial to Times New Roman (which is what it was originally) and the file
size is now 1MB.

What. The. @$&*.

I'm sure there are stupid subtleties or fancy Acrobat Guru tips and tricks
of which I am woefully unaware but my file size shouldn't grow by 200K
every time I save it, so I'll declare this a "fail" and try to suffer
through. Once I get these god-forsaken things working if I never have to
touch Acrobat the rest of my natural life it'll be too soon.

I posted previously on an odd problem I've run into with PDF forms populated by CFPDFFORM on ColdFusion 8 and the resultant PDF not being searchable via Ctrl-F in a PDF reader. Initially I thought it was a font encoding problem since I found some promising evidence to support that notion, so after spending literally an entire day changing hundreds of font encoding settings in PDF form fields individually in Acrobat (because you can't select them all and change them globally ... nice feature to add to Acrobat 10 maybe? YA THINK?), I thought I had the problem licked. I was able to open the PDF form in Acrobat, fill in the form field, save the PDF, and have the text I typed into the form field come up in searches.

Wrong. Turns out the only reason it was searchable was that I manually typed into the form field. When ColdFusion 8 populates the form fields with CFPDFFORM the form field still isn't searchable. Same problem with ColdFusion 9.

I submitted the issue to Adobe Support Center of Excellence, and a week and a half later they're saying they can reproduce the issue and it's getting escalated.

Since I have no clue when I'll get a response from Adobe and I'm putting my money on a "can't/won't fix" response (based on previous experience), this afternoon I grabbed the latest version of iText which is an open source Java PDF library. Among the numerous open source libraries bundled into ColdFusion, iText is one that's potentially used to power CFPDFFORM. (I'm not saying this is what's used since I can't know that for sure; I'm just saying it's a likely candidate if they didn't roll something themselves.)

Anyway, with iText in hand I wrote a simple little Java application to populate said PDF form. This way I could narrow down further if the problem is with iText (if that is in fact what ColdFusion uses for CFPDFFORM) or if it's something ColdFusion is doing that's causing the issue.

The result? iText by itself works perfectly. So at least now I have it narrowed down to ColdFusion being the culprit. I even replaced the iText instance in ColdFusion with the latest version to make sure that wasn't the issue, and either the version doesn't matter or iText is not in fact what ColdFusion is using to populate PDF forms.

You might be thinking, "But isn't CFPDFFORM so much simpler than Java?" Short answer is absolutely not . Longer answer is absolutely not and holy crap is using iText directly fast as hell.

Here's some simple CFML code that populates a PDF form:

<cfpdfform action="populate" source="mypdfform.pdf" destination="filledpdfform.pdf">
    <cfpdfformparam name="myPDFField" value="Foo" />
    <cfpdfformparam name="myOtherPDFField" value="Bar" />
    ... etc. ...
</cfpdfform>


<cfpdf action="read" source="filledpdfform.pdf" name="myPDFData" />
<cfpdf action="write" source="myPDFData" destination="filledpdfform.pdf" flatten="true" overwrite="true" />

And here's that same thing in Java--all I'm leaving out is some import statements that would be at the top of the class in which this code resides:

PdfReader reader = new PdfReader("mypdfform.pdf");
PdfStamper stamper = new PdfStamper(reader, new FileOutputStream("filledpdfform.pdf"));
AcroFields form = stamper.getAcroFields();

form.setField("myPDFField", "Foo");
form.setField("myOtherPDFField", "Bar");
... etc. ...

stamper.close();

As you can see, the Java code is about the same as the CFML code. You open the PDF form, you set the field values, and you write the file out, although with iText I don't have to write/read/write again to get it flattened, which is one of my earlier "can't/won't fix" responses from Adobe.

What's my next step in all of this? Well, I'm faced with a pretty easy decision really. This is for an application the sole purpose of which is to process mountains of XML and generate flattened PDF forms containing the data extracted from XML. iText lets people actually search the PDFs as they should be able to (which is important since some of these PDFs are hundreds of pages long), iText is incredibly fast at cranking out PDFs in my limited testing thus far (which will be important when I'm re-generating three years of PDFs since none of the existing ones are searchable), and the Java code to achieve a better end result isn't any more complex than the CFML code.

It's an easy decision to use iText for this portion of the application. But as you can glean from the tone of this post I'm annoyed. CF 8 was new when this app was first built and one of the reasons we bought another CF 8 Enterprise license (since this app runs on its own server) was for this very feature because I figured it would be easier than using iText. It might have saved me some time initially, but boy am I paying dearly for it now.

So I'll start by reworking the PDF generation portion of the app to use iText, and then I'm going to start implementing CFPDFFORM in Open BlueDragon. Frankly given that there's literally no user interface for this application CF wasn't a great choice to begin with, but at the point when I was making the decision CFPDFFORM is what sold me on using CF instead of writing the app in Java. But three years later, here I am. My other option I'm pondering is rewriting the entire application in Java or Groovy since that's probably better suited to the no-UI aspects of the app anyway.

Nothing like having an itch to scratch to get motivated I guess, so at least the problems I'm having may lead to a nice new (and fully working!) feature in Open BlueDragon at some point, and maybe I'll dig into Groovy more to rewrite my existing app. Interesting times ahead.

One of my final annoyances as a full-time Linux user is the inability to share my desktop when I'm in Adobe Connect sessions. (Aside: you CAN do screen sharing from Linux quite well with Yugma. Free conference call line too.)

Although this isn't a real solution for screen sharing on Linux, it at least gets you there without having to use a completely different machine. These steps are for Ubuntu 9.04 but I'm assuming most of the other distros have VNC built in as well.

1. Launch a Windows VM and install TightVNC
2. Enable desktop sharing on Ubuntu (System -> Preferences -> Remote Desktop)
3. Using the IP address or hostname that is displayed in the desktop sharing dialog once things are enabled, connect to your Ubuntu host using TightVNC from the Windows VM.
4. From an Adobe Connect room, click "Share My Desktop" and select TightVNC as the application you want to share

I know, I know, people were probably groaning with step 1, but compared to having to switch completely over to my Mac just to share my desktop in a Connect meeting this is a better solution. I figured it would work but didn't get around to trying it until today. You may have some resolution issues to contend with but it gets you there.

I'd love to see Adobe actually enable screen sharing in Connect from Linux, but I'm not holding my breath.

While I'll believe the "Furthering Adobe's commitment to the Linux community" bit when I can share my Linux desktop in Connect (ahem), it's nice that there's a native 64-bit Flash Player for Linux. Since I recently got a 64-bit system76 Serval Professional laptop I figured I'd try it out. The Serval comes with Flash pre-installed but I believe it's the 32-bit plugin running through nswrapper.

Nice that the 64-bit Flash Player is available, but not so nice is the amount of time I spent getting it working, so I hope this helps others.

1. Download Flash Player 10 pre-release from Adobe Labs
2. Unzip the file
3. Copy libflashplayer.so to either /usr/lib/mozilla/plugins or ~/.mozilla/plugins
4. REBOOT YOUR MACHINE

Step 4 is the most important step, since for me anyway simply restarting Firefox didn't do the trick. Every time I'd restart Firefox and hit a URL with Flash content the browser would instantly crash. Rebooting entirely did the trick for me.