Are YOU Missing Out?

If you’re reading this you’re probably not. I’m referring to a post on AvSim bemoaning the fact that many, many FS users never install a single add-on (also called a ‘mod’ in the general gaming world). I agree that having more people engaged in the hobby would benefit it. The suggestion in the initial post is for Microsoft to be more active in promoting this dimension of the product. The ensuing thread impressed me for a couple of reasons.


First, (at least as of this writing) it was incredibly civil. Perhaps its sad I’m even having this reaction but so many of these threads quickly devolve into a “Micro$oft sucks/doesn’t care/are stupid”, “I know everything/you know nothing”, “they should just do it like this and my life would be perfect” mud-slinging orgy of vitriol. The other thing that impressed me was how many of the early responders thought that we ought not to come within a wingspan of promoting third-party developers.


It’s an interesting dicussion to me, not necessarily because of things we’re either doing or not doing with respect to FS, but because I’ve been involved in promoting software developers before. Long before I joined the FS team I was a technical evangelist for Visual Basic for Applications, something I knew a little about. VBA was an outgrowth of both Developer Tools and Office and was originally used to provide scripting support to Office applications like Excel. Microsoft decided back around 1995 to componentize VBA and license it to third-party ISVs (independent software vendors). As I recall the first two to sign up were Autodesk and Visio. At the time the only way you could get VBA was to enter into a formal agreement with Microsoft. This agreement entitled you to integration support as well as co-marketing opportunities. The ISV also had to submit to software testing by a third-party to ensure a certain level of quality and functionality. Today all of this is readily available via the VBA Partner Program on MSDN but back then it was quite exclusive. I think there only about 20 licensees when I joined the group and just under 100 when I left.


So here is a case where Microsoft worked closely with a few selected ISVs and helped promote their products. We did this through joint press releases, use of our ‘certified VBA’ logo, participation at ISV industry events and so on. There are tons of examples around the company where we do this. So why wouldn’t we consider it for FS? After all, we have ISVs using our platform just like Autodesk, Visio, and a myriad of other companies used VBA.


I think a lot of people forget that business is not black and white, it’s gray. Everything is the result of tradeoffs made as part of a cost/benefit analysis. Let’s look at some of the points made in the thread:


Working with some ISVs and not others will tick off the folks left out. Maybe. VBA represented a value proposition to the ISVs. Those that chose not to work with us were just making a business decision that what we had to offer just wasn’t valuable to them for whatever reason. We didn’t give VBA away–there was a cost in both time and money to the ISV. Who we worked with was dictated by conditions that lead to a win-win situation.


Promoting ISVs software will result in additonal support costs for Microsoft. Possibly. We can never control who a user decides to contact when they experience problems. Part of the issue is that it’s often difficult for an average person what is at the root of the problem. With VBA we tried to mitigate this by requiring ISVs to support their VBA implementation and to submit to software testing (that they paid for). But again, any forecasted support cost to us was traded off against the value of those people using our technology.


ISV software would be seen as stuff that should have been in the core product. Probably not. Successful ISVs find niches that work. With VBA the ISVs weren’t creating tools that made writing script easier. They were using VBA to make better software for engineering, diagramming, process simulation, manufacturing control, etc. The FS consumer is also segmented and gravitates to those things that interest them. Successful FS ISVs focus on functionality and content that doesn’t compete with the core product.


The cost of ISV software will be a turnoff to average users. Doubtful. Price is only a reflection of value aggregated by the laws of supply and demand. Is a Hummer H3 too expensive? Not to me because I don’t want one. Some VBA ISV software sold for tens of thousands of dollars. Was it worth it? To those that needed it, yes. I don’t see why the same thing wouldn’t be true in the FS world. Those people who value certain add-ons highly will pay the high prices. If ISVs recognize a latent demand for lower priced add-ons they will create them.


Some ISVs may not be around tomorrow. True. But consider that this relationship is two-way. With VBA we worked closely with the first crop of ISVs to understand their businesses and see how making them more successful would make Microsoft more successful. We picked companies where there was synergy that we felt would lead to greater customer value. Over time, once the program and brand were established, we relaxed our criteria because the synergy came from large numbers of ISVs. Sure, some of them might not have the strongest business model or best technical implementation but as a whole the VBA brand was successful because of the vast choices.


I think the thing that troubles people is that when Microsoft (or any large company) gives the appearance of endorsing an ISV product (and this can happen in any number of ways) we evaluate that in terms of our own needs and wants. If it matches then we think, “That makes sense.” If it doesn’t the reaction is more like, “That’s a mistake.” The thing to keep in mind is that in a market the size of ours there are many, many different interpretations of value and just because it doesn’t work for you doesn’t mean it doesn’t work for a whole lot of other people.

Comments (5)

  1. Umberto C. says:

    I’m not sure if the parallel between VBA Partner Program fits completely in the FS world.

    The VBA Partner Program allowed ( correct me if I’m wrong ) 3rd parties to create separate stand-alone applications with the VBA engine inside, that didn’t require to buy another MS product to run. Of course it makes sense that ISV had to pay and to sign an agreement with MS to use that technology, it only added value to the ISV application, but there wasn’t any direct gain for MS, only the indirect widespread adoption of VBA.

    This, applied to FS, would be similar as if MS licensed the FS graphic engine to ISV to create other stand-alone games that do not require FS to run.

    FS addons do not run without FS, the situation is then more similiar to MS Office addon products, that don’t require any special licensing, except the developer has to buy a copy of Visual Studio and perhaps MS Office for developers. And subscribe to MSDN, optionally. But even withouth MSDN subs, there’s plenty of useful informations from MSDN website available for free in form of knowledge base and reference manuals.

    A good compromise between the worthless SDK we have now, and having to sign a formal agreement with MS for developing, would be putting FS SDK as it is now ( maybe with some error checks ) on the free MSDN site, and offering support only to MSDN subcribers, so FS developers that find worth the price, will be free to subscrive themselves to MSDN, but there will still some free information available for those not interested, and for freeware guys.

  2. Garry Trinder says:

    Umberto, the purchase model wasn’t really the point of the post but I understand what you’re saying.

  3. Thomas Perry says:

    I’m sorry, but the point of your article went a little over my head. I had trouble connecting how VB would be similar to something for FS. Are you suggesting that you will increase the functionality of the SDK, document it more fully, and sell it? Are you just discussing the benefits of offering an SDK and some of the consequences?

    Anyway, a question that has always boggled my mind is, having worked for a software company before that had 3rd parties developing addons, how do you deal with keeping vendor attitude up when you put the idea for their addon into the software in the next version and take their business away? Does that drive 3rd party vendors away? You can’t stagnate the software, but, at the same time, I think it is a good thing to have outside developers around. Then again, the proportion of users who actually use "mods" seems to usually be low, so maybe it doesn’t matter? hmmm

  4. Garry Trinder says:

    Thomas, the point was merely that promotion of ISvs can work and does work elsewhere at Microsoft. It’s a fairly standard model in the software industry at large.

Skip to main content