Microsoft and developer trust (or lack thereof)
There has been some talk around several internet outlets about the (seemingly) eroding trust developers have in Microsoft and its techniques (see David Sobeski's piece here, Tim Anderson's piece here and e.g. the Reddit Programming thread here). Trust is the keyword here and in my opinion it's essential to understand what that means in the context of a software developer to understand the problem at hand, or even to acknowledge that there is / isn't a problem. I try to explain below what I think trust means in this context.
Every day some individual or team comes up with a new tool, framework, version of an existing tool / framework, new OS or even a new way to bake those nice chocolate cookies. We as humanity tend to call this progress, even though in many occasions the (small) step taken by said individual or team is actually a (small) step sideways or even backwards. To understand why these individuals and teams still come out in the open to demonstrate their results which sometimes result in total lack of real progress, we first have to understand how product development works and why people even do it.
For every successful product (be it a commercial tool/framework/system, open source system/framework/tool or a cookie recipe, you the idea) out there, there are many many more failures, left for dead in repositories on dying harddrives on local servers or cloud storage. The core reason this happens is that there's no recipe for a successful product: to be successful you first have to create something, ship something. No shipping, no success, and as there's no way to know whether success will come after shipping, all we can do is ship as much as possible so the chances are higher that something is picked up and success eventually comes. The rest of the products are ignored, kicked to the curb and eventually moved to /dev/null.
The motivation to keep doing this of course is the vague 'success' term used in the previous paragraph. 'Success' can mean a lot of different things: become famous, earn lots of money, learn a lot, get a respected title, become respected among peers, the list is endless. All these different things motivate people to create new things, to ship their work in the hope it will give them the success they strive for. Microsoft isn't different in that, as a product producer they have to keep on shipping new, relevant products in the hope these products become successful and with that will make the company money so it lives on.
Microsoft has released a tremendous amount of products in the past decades: from frameworks to languages to operating systems to APIs to word processors. Some were successful, others keeled over right after their shiny boxes appeared on store shelves. The successful ones are continued, the less successful ones are abandoned and replaced with a new attempt to gain success. Over time even successful ones were abandoned or replaced because of a different phenomenon: the interest in the product faded, as illustrated in the technology adoption lifecycle.
So in short, Microsoft behaved like any other product producing individual / team: they produced as many products as possible in the hope that as many of them would become successful. That combined with the technology adoption lifecycle in hand, it's clear that to stay successful one has to keep producing products. That is, from the point of view of the product producer. But what about the product consumer, the person who bought into these products, learned how they worked, behaved, what their limits were, in short took a dependency on them? Is the story the same as the one from the product producer? Sadly, no.
As a software developer we are both product producers (commercial or OSS frameworks/tools/systems or project based custom software) and consumers: we consume frameworks, tools and systems to produce frameworks, tools and systems. To be successful we, like any other product producer, release as many products as we can in the hope that some will gain success. By 'release products' I mean this in the broadest sense: releasing successful custom projects, tools, commercial frameworks or OSS libraries: you shipped software. Shipping custom software written on consultancy basis still contributes to success: the more you ship, the more one will tend to hire you. No-one wants to hire a developer who sticks around for years without shipping anything.
If a product we ship gains success we want to keep that success, so we want to get that bell curve from the technology adoption lifecycle as wide as possible: the wider it is, the longer we can reap the product's success. However there's a problem. To produce this successful product, we took dependencies on the products of others, so our success is tied to the bell curves of those products. If our product can stay successful if the products we took a dependency on stay the same as they are today, the problem is not that big: our clients/customers/users use our product, not the ones we depend on. But what does that mean, 'stay successful'? Is that a given, once the product gets some success?
In most cases, to keep your success you have to keep working on your product: add new features, polish the features already there, remove the ones which don't work anymore, change the looks of the product so it looks new/changed. That way, new users might become interested and take the plunge and will start using your product. As software developers we can only make these changes if the products we depend on let us do so. If the products we depend on are too limiting, it might be the required changes to e.g. make the step from Early Adopters to Early Majority won't be added and the product will never reach the end of the bell curve and will die prematurely.
With writing custom software on consultancy basis this is actually the same thing: there the product you produce is what you can create with the knowledge and skillset you have, those are the dependencies you took. If you are hired to create software which requires knowledge of a product you don't know anything about, you have the same problem as the software producer who creates a software product and who's faced with a framework which is end-of-life: a dependency you took is out of date.
So in the Microsoft world we have on one side the company Microsoft who cranks out products like there's no tomorrow, and on the other side we have developers using these products to create new products, depending on the products Microsoft produces. As soon as Microsoft abandons a product, all developers who took a dependency on that product, either through knowledge for their consultancy work or for producing software with it, inherit a problem through that abandonment: their own products now run the risk of following the same road as the abandoned Microsoft product.
There are several solutions for this: take a dependency on an alternative product, e.g. from a 3rd party vendor/team/individual, rewrite the functionality the dependency was all about yourself, keep on using the (soon to be) outdated product or abandon your own product as well and create a new one. All have their side effects and all have some things in common: they all come with pain, loss of time, risk of losing the success and therefore loss of money. And all that for no gain at all: if the product wasn't abandoned, the software producer could invest the time in the successful product instead, which would benefit the user.
Taking a dependency is therefore a risk: if the product we depend on has a bell curve which doesn't match our own product, i.e. our product's bell curve is wider / ends later, we run the risk that our product will suffer from the fact the product we depend on reaches end-of-life and will be replaced and abandoned. To mitigate that risk, software developers therefore want to align the bell curves of their products with the ones they take a dependency on: if the products they depend on outlive their own products, they have nothing to worry about, give or take some breaking changes along the way.
But how do you know this bell curve of a product you take a dependency on? Well... you don't. Chances are the product producer doesn't even know for sure how the bell curve of the product is or will run: no-one can predict the future and especially not about products. All that is left is trust and hope: trust that the producer of the product you took a dependency on will keep producing the product in a form you can use and hope that the producer stays trustworthy. There's no certainty, only those two: trust and hope.
If the producer of products you depend on becomes untrustworthy, things fall apart: you can't trust them anymore to keep producing the product in a form you can use and therefore you have to acknowledge there's a problem: your own product has a higher risk of ending prematurely unless extra work is done to mitigate the risk. The core issue at play here is: who is doing that extra work.
As mentioned earlier, Microsoft produced and produces a lot of different products on a high speed. This isn't new and the problems for developers with prematurely ending lifecycles isn't either. In that light, one can't say Microsoft has become less trustworthy: if one trusted Microsoft in the past, what's there against not to do that today? However there is something which is new and which wasn't that much of a problem in the past due to monopoly positions: who's going to pick up the inevitable tab when a product is abandoned? Is it Microsoft so it will invest in ease of transition from the abandoned product to the replacement product, or is it the developer who took the dependency on the abandoned product and now has to invest in migrating her/his own product to a replacement product?
In the past, Microsoft did invest sometimes in transition technology but most of the time it didn't and the software developer who took the dependency was forced to invest the time to move to an alternative/replacement product. The developer did this as there was not really a real alternative. However today there are. Plenty. However Microsoft plays the same game as they have in the past: make the transition from abandoned product to a replacement the problem of the developer who took a dependency on the abandoned product, but with the alternatives growing wider in scope and more mature every day, it's not a given anymore that a developer will pick up the tab: if time has to be invested in migrating the product to an alternative, it might as well be wise to migrate the product away from all dependencies on Microsoft products.
The core motivation for doing that is, in my opinion, that there's severe lack of trust and hope that Microsoft takes the responsibility for the effects a premature end-of-life of a product will have, at least for a group of products. Code written against win32 15 years ago will likely still run today and will also do so tomorrow. It's a different story with .NET based applications even when .NET is a virtual machine based system and therefore could abstract away migrations to the products it depends on (underlying system/OS). At the same time the visibility and availability of mature, trustworthy alternatives elsewhere lowers the chance for Microsoft to get away with a lack of responsibility.
In my opinion, trustworthiness is closely tied to how much responsibility you want to take for the lifecycle of your product and thus for the effects the end of the bell curve will have on the people who take a dependency on your product: the more responsibility you're willing to take, the more people will trust you with their dependency as they know the risk for their own products is lower. Microsoft blew this on several fronts and on several occasions in the .NET world.
But is that really anything new? No, it has happened countless times before. In fact, the trust implied by the willingness of developers to pick up the tab in the past is in my opinion an illusion: there was never really any trust, there was just a large 'it is part of the game' acceptance among developers, largely due to lack of knowledge how things were done elsewhere. Compared to those other times, todays world is a different one than the one 10-20 years ago: Microsoft can't get away with it easily anymore: developers know there are other realms, other worlds out there who suffer less from a single company who calls the shots and more importantly: is not willing to face the consequences for developers when products are abandoned.
That's the real problem Microsoft is facing today with respect to developers: will they trust Microsoft enough that they are willing to take a new dependency on the new stuff Microsoft is producing, even though they know the pain will likely be as severe as it is today? Frankly, I doubt it, or at least, the group blindly doing so will be smaller and will do it with less enthusiasm. Simply because there's less reason to.
For the developers who need to take dependencies on Microsoft products, let's hope they realize they need to step up and take responsibility for the effects abandoning products will have on developers. Only then Microsoft will regain the trust it had.
PS: I am fully aware I produce a product which has many customers who take a dependency on it and at the same time has a few dependencies on Microsoft products like .NET, C# and ADO.NET and thus that this essay also applies to my work. The key take away is responsibility: the actions one takes, which effects will these have on the people who took a dependency on your product? I've spent many many months during the past 10-12 years to mitigate those effects as much as possible for my users and will continue to do so, additionally to the offerings like full sourcecode and rich extensibility points for most elements of my system to lower risks for users. This to answer questions people might get when reading the above text.