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.
