First!
Its been almost a year since I started working on the CoRD Project. In that time we’ve released 0.5, which was in “beta” for almost 18 months when I started tinkering with it in March of 2009. We’ve also released two minor updates that fixed major issues and added features, and are getting ready to release a third release (0.5.3) that will hopefully fix a few problems. Work on a 0.6 release has started, and rudimentary code has been put in place to allow groups. Going completely off of the amount of releases and code changes, it may seem like we’ve been resting on our laurels, but I wanted to point out the massive changes we’ve made on the backend in the past year that will help us accelerate releases and hopefully prevent another 18 month drought of updates and information.
Trac & Forums
Prior to the summer of 2009, CoRD used SourceForge’s own native Tracker for bugs, features, etc., as well as their Forums for user interaction and support. In the middle of last year, I convinced Dorian, our esteemed (and awesome) project lead, that we should migrate CoRD’s “infrastructure” (for lack of a better word) to the newly christened SourceForge Apps, including Trac and phpBB. This has proven an awesome change, which has allowed us to do so much more and be much more productive. We added menu items into CoRD giving users a direct line into the forums and Trac. We (I) started using the Trac’s wiki to document features and options (something I wish we had more of).
This wasn’t an easy change though, as SourceForge could provide no migration of data from their Tracker to Trac. So I spent the better part of a month moving tickets by hand as I came across them, to the new system. We lost a lot of historical stuff in the forums, which sucks, but was a necessary evil. It was a ton of work to move this stuff, but in the end it turned out awesome and Dorian and I have been incredibly happy with it.
Crash Reporting
Prior to 0.5.2, Dorian had employed SmartCrashReports to some extent, but gathering and collating that data was incredibly difficult. Most crash reports we received either came in when a kind user attached them to a bug report they filed, or via email to one of us (mostly Dorian since his name and email are on the website 
) In 0.5.2 we replaced SCR with UKCrashReporter and backended it with Dorian’s own CrashPool system. CrashPool, which will be going live soon for any interested developers, serves as a crash report aggregator, it handles sorting and grouping, searching, etc. Prior to 0.5.2, we both thought we were putting out a relatively stable app. Boy were we wrong!
We have a huge devoted group of awesome guys who are running the Nightly Builds (see CoRD’s preferences or this article) and reporting a ton of data back to us. And since 0.5.2 has been out we’ve gotten thousands of crash reports that we’re sorting through (it is really easy to spot trends; we know that guys who use Fullscreen heavily are seeing a metric shit load of crashes; and for some reason the inspector is causing some crashes that we haven’t been able to chase down (yet)). We definitely appreciate the guys (and gals) running the nightlies and providing us feedback and crash reports. Thanks!
Build & Deployment Infrastructure
This was all Dorian. He completely revamped his nightly build script and modified it to the point where we can release stuff practically on demand. The script will update the build the app, package it, upload it to the right places, update the appcasts, everything. He has a nightly task that runs and builds our nightlies, and by simply changing up the parameters we can dump out a release, either a beta or a full release, on demand. It is a truly awesome piece of code. Thus far he’s keeping is close-hold and not releasing it into the wild. But I think the eventual plan was to make it available, but it is his baby, a separate project in and of itself, so I can promise nothing, just give him credit where it is due.
VNC Requests
For those following CoRD on Twitter, I have wanted to make a tweet about this for some time now, but it is just too long of a thought for 140 characters. We see a lot of chatter, and the occasional feature request, about adding support for VNC connections into CoRD, theoretically making it a universal, kick ass, remote console tool. I share these thoughts. I would love to flip the magic switch, and allow CoRD to answer VNC requests. But I can’t, and even if I could, we’re not at a place where I would. There are many, many, many things I want to see in CoRD (including fixes for the aforementioned stability problems) before I see VNC support:
- Groups
- Better management of credentials
- Stable printer forwarding
- SSL/TLS support
- Smart Card support
- Autoreconnect support (rdesktop has this now, we have some code in place but no implementation yet)
- A complete rework of our drawing code to fix all the screen glitches people run into.
With just Dorian and I working on CoRD in our free time, we have to apply our time to where it makes the most sense and can do the most good. So just to put an end to any nonsense before it gets started, we’re not against being a good RDP/VNC app. But we want to be a robust, kickass RDP app first. In the mean time, there are plenty of really decent VNC apps out there.