Developing add-ons for X-Plane has become a serious business. While airport & scenery development mostly take place in a freeware or donationware environment, particularly the development of aircraft models is currently seeing some kind of arms race. Both ambition and price climbed steeply over the past two years, but I feel to a certain extend, professionalism of developers and distributors didn't keep pace with this development. Through this article, I would like to dedicate some words to observations I made, particularly getting a bit more granular on how I perceive professionalism in development and business behind those aircraft models.
What would X-Plane be without all the add-ons contributed by its community, making terrain meshes, photo overlays and 3D scenery replications of cities and airports, but also contributing aircraft models and a large variety of utilities and plugins enhancing X-Plane's capabilities…? Many of those contributors do sacrifice their spare time for this purpose, but of course, there are also those doing this for earning a living. For lack of a better term, let's simply call them “professionals”, OK? I will apply this designation to all people involved in the development and redistribution of payware addons, regardless whether it's their primary source of income or not.
Yes, you got me right: I don't care whether somebody asking me to pay money for a product or service is a full-time professional or just a hobbyist supplementing his income. I do care though how much money somebody is asking for a product or service. And here we are already, looking at one of the first things I'd ever wanted to rant about. Countless times I encountered the argument
See, developing plugin X has cost us these many hours, that's why we must ask for this sky-high price of $many
With all due respect, I don't want to object to the fact that development of aircraft models and plugins costs a lot of effort. However, if you want this to become your business, I'd expect you to understand market mechanisms first. The view quite frequently transported in a similar manner as the fake quote above does is the one of a cost accountant. As a financial controlling professional, I'm in the trade, so I know what I'm talking about here. But this is not how a market works.
The price one can ask for does not depend on the cost of development, but on the value a product brings to the customer. If you did some careful market research, found an unoccupied niche, developed a product that a lot of people urgently want and are willing to pay for, and if you kept cost (development plus support cost) at bay, you will run a positive business, gaining money. If you failed to do so, you should not blame the customers not paying whatever you consider as adequate, but ask yourself what mistakes you made. This would be a professional attitude, and suit you better than attacking customers on public bulletin boards, as some self-styled “professionals” tend to do.
Speaking of that, this is actually the second point raising my blood pressure: I consider the way some developers or distributors communicate as highly non-professional. To a certain extend this may be systemic to the X-Plane ecosystem and driven by the fact that mostly public bulletin boards are used for communication. The downside of this: As a developer or distributor, you will face negative voices, and probably even to a greater extend than positive ones. This one is not really surprising – customers rather tend to speak up when dissatisfied rather than for leaving positive feedback.
This might be annoying for you, but as a professional, you have to be aware of this mechanism and thus be above such thing, even if some postings are of provoking quality. If you are not, better go looking for a communication professional to handle it for you, or chose other means of communication. Otherwise you will simply ridicule yourself, particularly when losing your composure in a public bulletin board full of (potential) customers. Not convinced yet? Look at it this way: imagine you walking up to a car dealer, asking a few questions, telling you don't like a feature on a model he proposes to you… and this guy just goes ballistic – would you buy a car from him?
So take out a pen and write down:
My customers' opinion can never be wrong.
My customers' opinion can never be wrong.
My customers' opinion can never be wrong.
This doesn't mean your customers can't have some facts wrong, or came to a wrong conclusion due to lack of information or education – but when it comes to personal gusto (liking or not liking a feature, measuring importance of a feature, etc.), nobody can be wrong per se. The best way to deal with opinions is turning them into statistical data. Instead of arguing with customers about the way they feel related to a feature or behaviour of your product, simply count the view they shared. This will give you a solid foundation for future decisions without driving (potential) customers away.
Now let's turn to some more tangible stuff – yes you guessed right, I'm talking about the quality of your product. Before entering this new rant, I would like to elaborate what I consider as (non-)quality when speaking about X-Plane add-ons. In the past two years, we have witnessed a constant rise in complexity and in price for add-on products, particularly when talking about aircraft models. A pricing of ≥60 US-$ has become some state of the art nowadays. That means many add-ons are priced higher than X-Plane itself. In such a price region, a customer is perfectly entitled to expect a mostly bug-free product (I already talked about adding value above, so I keep this one now aside).
There is no such thing as bug-free software.
Truly spoken, but lately it seems this has developed into a standard excuse for developers disregarding any minimum standards when it comes to professional software production. Yes, software is a product, and I prefer speaking of production instead of development. The reason is simple: There are a lot more activities involved than pure development work to get a software product delivered to your customer.
I know something must be wrong when I, a customer of a finally released product, instantly stumble across obvious bugs rendering the product useless (e. g. clearly identifiable crash conditions). I honour the dedication of developers coding their heart out to push a product release to their customers. Yet I question whether this way of working falls under the notion of professionalism – I'd rather say not. In modern software production, having a well-defined release chain is crucial. It starts with appropriate code management; working with a modern SCM and related techniques (e. g. pull requests) is absolutely mandatory. But the tool is not everything; it will only deliver to your expectation if you define a corresponding workflow and stick to it.
And on it goes; continuous integration is a must for complex products. How embarrassing is it if your product fails by a simple, avoidable error (e. g. syntax error, missing variable initialisation, uncaught exception, etc.). That's what unit tests have been invented for. I understand pretty well that testing a full aircraft model is anything but trivial. However, unit-testing every function, class method or whatever component you write should be a matter of course. If your tests get too complex, your code structure is bad, period. This might sound like a harsh statement, particularly in the light of me knowing a lot of people engaged in aircraft model development are not really software engineering professionals, but rather aircraft engineering experts, 3D modellers or graphics designers. Yet again, this is about professionalism. If you want to draw level with other professional software, you have to cope with that.
Also when it comes to release building and distribution, I came across a wide variety of bad, non-professional habits. First thing to get right is a reliable release naming scheme. How hard can it be to adopt the most commonly used scheme in software production, i. e. major.minor.patchlevel for your product? Before going into a test or pre-release phase, make up your mind about the meaning of your release names, and adapt your SCM naming conventions and workflow accordingly. Learn about feature freeze, code slush, code freeze and testing phases. Then build your releases with an automated toolchain – this will guarantee reproducible results and (hopefully) unveil a broken release before delivery to the customers.
I admit however that X-Plane itself does not make it any easier to professionally develop add-on software for it. Yes, there is a plugin API, but the corresponding library (i. e. header files etc.) is not formally maintained by Laminar itself. Many state-of-the art techniques (e. g. such as multi-threading) are not supported out of the box and require a profound understanding of programming concepts. On top of that, X-Plane is a fast moving target; being subject to incremental development, it introduces new features with every minor release, and also deprecates things at nearly the same frequency. Taking this all into account, X-Plane is a hard to control environment from the point of view of a plugin developer.
In consequence that means as a developer, you haven't done with your job even if you delivered a perfect, bug-free plugin. A product that wants to be perceived as professional (and thus justifies a high price) needs to keep pace with X-Plane's development. We already have more than enough products that too obviously aimed at generating some instant revenues and were then abandoned by their developers, coining the term “abandonware”. Remember I am speaking of products priced at or above the level of X-Plane itself – all I do expect is they are supported throughout the same life cycle Laminar supports X-Plane. I do not necessarily expect new features to be developed/integrated (except developers announced they would do so), I just expect them to run also on current versions of X-Plane's major release branch. I think it is fair enough as a customer to apply this assumption when buying an add-on, except developers clearly stated that I'm dealing with a one-shot product. This is also fine; however this information will certainly influence my acceptance or non-acceptance of a price to pay.
The next logical step in the life cycle of a product is the post-release support. I already mentioned that bulletin boards are not necessarily a good platform for communication, and this also holds true to a certain extend for support purposes. While bulletin boards are in general very useful for engaging other customers in helping you answer comprehension questions of new customers (we all have seen them, not knowing what pitch & roll do, but want to fly an airliner), they are rather poorly shaped for systematically collecting bug reports. And then there is an issue with reactivity: customers are in general very impatient. Particularly when an expensive product shows a behaviour that makes it unusable (e. g. crashes or does not load), customers tend to get nervous. Some developers got it right and react quite quickly (apparently they assigned some of their team members policing the respective bulletin board in shifts to ensure reactivity), but others got it woefully wrong, leaving support requests unattended and unanswered for weeks.
Related to that, not every reaction of a developer is a good reaction. Too many times I saw developers outright refusing plausibility of a bug report – another common source of frustration, particularly when talking about high-end priced products. In general, customers don't post bug reports just to annoy you. It is their way of letting you know they are not satisfied with your product in its current shape and it needs fixing so it can deliver the promised added value. If you have an issue with that being discussed publicly (which I understand to a certain extend, as it is a kind of negative advertisment), don't use public boards for bug reporting. If you are frustrated because a lot of bugs are triggered by pollution (hardware, third party add-ons) or the environment (e. g. underlying libraries not being under your control), don't wreak it on your customers.
Summing it up, my impression is that among commercial X-Plane add-on developers, there is plenty of room for improvement in basically all areas – pricing and communication, but most obvious in quality management and release policy, not to forget after sales support. With PMDG just having entered the market, I sincerely hope this triggers a phase of rising professionalism among X-Plane add-on developers. In the end, customers will vote with their wallet.