game engine design is serious business and there is a LOT of stuff you need to know. I envy that you know all of Austin's secrets!

Keep up the good work.. and needless to say even microsoft has resorted to including nothing more than "windows.h". Just remember to test the network once in awhile.. or at least once win7 is released! I doubt your old compiler will curse at you for using such things as "string.h"..

1) Have a workable backup, or…
2) Delay upgrading until the first user reports are in.

Though the betas can jerk you around a bit, overall I'm pleased with the progress and process, brushing off the problematic ones and enjoying the great intermediate builds I've come across.

All I'd consider asking for is a better explanation of what's changed in the release and how to use the new features in the wiki, where an example or an extra sentence or two could save me a few hours of grief.

I'm currently enjoying rc1 and bypassing rc2, but I'm gratified some attention is being paid to the arrow keys, which are somewhat bizarre in 3D cockpit mode. I expect something good will come out of this, or we'll just have to get used to the changes. Or Laminar will have to put up with incessant complaints.

However, the release and QA process is extremely poor for a commercial consumer product, and it does hurt your users (even those who don't participate in the betas). I understand the desire to avoid having a lot of overhead and process — those things slow development down and generally tend to hamper excellence. But process isn't binary. It isn't as if you either have heavy, bureaucratic process or none at all. It's a continuum. And even a small amount of process would be a huge improvement in X-Plane.

For example, how about a rule stating that no new features go in once you've reached beta? The point of beta testing is to work out bugs in new functionality, not to keep adding features and trying out new things. We're now at Release Candidate stage and you're STILL adding functionality (e.g. "A handful of new gps commands to control the software Garmin-430"). That's a serious misuse of the term "release candidate," IMHO. I'd also suggest a rule that you actually try all of the major functionality of the app before releasing a new beta (or especially a new RC). The breakage of cockpit scrolling between RC1 and RC2 is inexcusable. I don't see how that could have gone out the door if anyone had actually used that version for a significant period of time before sending it out.

I don't think these represent onerous process. They're just about excercising due care to actually provide a solid product to your customers. I have heard the objection that people who want a solid product shouldn't be playing with betas or RCs. That's true, but it doesn't discount the value of the changes I suggest. First, if beta testers are playing with new functionality or struggling with major breakage between betas, they are likely not fully testing the rest of the app (e.g. anyone who uses the 2D cockpit is pretty much unable to use and test RC2). Second, the amount of churn in the supposedly final versions of the app prolongs the time until final release and also increases the likelihood of bad bugs in the final release.

I'd also like to suggest that the willingness to break things is generally good, but it could be done in ways that are less disruptive to users. For example, it seems like every release lately has completely changed some major things about the way aircraft work (e.g. the recent back and forth over how the engines work), making huge numbers of third-party aircraft (and sometimes even the included aircraft) unusable. This is totally unneccessary. First, it's inexcusable to keep going back and forth publicly (in the form of releases) over how such a major part of the software works. If there's a problem, figure out the solution, test it, make sure it's the right choice, and THEN release it. Second, even very lightweight versioning information in the aircraft files would make things a lot easier on users. Obviously from a user's perspective, the best outcome is for X-Plane to fall back to the old functionality if an old aircraft is loaded. However, I understand the desire to avoid keeping all that cruft around in your code. So how about at least giving users a warning like, "this aircraft was based on an old version of Plane Maker. The engine response will not be correct until the aircraft is updated." And give aircraft developers an easy way to upgrade.

The bottom line is, you make your living from your users. It's just a matter of respect to them to try to provide a solid, quality product. That might mean adopting a few development practices you don't like, but you owe it to the people who pay you.

I want to reiterate — I think you guys are doing great work. I do not mean to play that down. But I think it's time for the process to mature a bit. This isn't an open source software project, so it's time to stop acting like one.