Whether your preferred Steve is Jobs or Ballmer, there’s no denying that Microsoft technology has been and continues to be the standard in business.
But should it be the standard in your business?
That’s a different question.
While turning away from Microsoft’s massive market share is even harder than turning a battleship, making a change in your business is far more feasible.
So your business has the opportunity to question whether Microsoft and its associated .NET software framework is the right fit. These days, more and more businesses are answering that question with a resounding no.
There’s a reason that Python–not .NET and its associated languages–are the most popular languages for programmers right now.
So it’s important for your business to know the reasons that companies are leaving the .NET framework. Here are some of the biggest ones:
Seat Licenses and Aggressive Audits
Microsoft isn’t the 19th biggest company in the world solely because of its product sales. Ongoing seat-license fees are a major part of their business. And that money is coming out of your bottom line.
Microsoft denies it, but some think that they are becoming more aggressive in policing seat licenses through audits.
There are multiple kinds of audits–those initiated by Microsoft and those conducted by third parties. No matter what kind of audit it is, your business will experience at least two pain points:
1) The time spent compiling the documentation required by the audit
2) The possibility of audit findings that result in a big bill at the end–whether because of license changes or some other reason
Even if your documentation is shipshape, this process is harrowing. It’s the kind of process that simply doesn’t happen with open-source software options like Python.
One of the big places where seat licenses come into play is with the SQL database. It’s the preferred option in the .NET framework. If you choose a different option, like the free SQL Express, you can save some money but will have to face limitations on storage.
The bigger question is whether Microsoft SQL is the best fit for your needs, or whether a different option like PostgreSQL is. That’s a question that the Microsoft stack assumes the answer to, without knowing your business’s unique software needs. If you want to optimize performance of your database and your software stack as a whole, you need the freedom to pick what’s best for you–not what’s best for Microsoft.
Lack of Flexibility
Back in 2011, Expensify Founder and CEO David Barrett got some attention for his comments about .NET development. A few of his comments remain important for business owners to this day.
".NET is designed to tightly integrate with and seamlessly extend the Microsoft stack in extremely powerful but ultimately incremental ways. Again, there’s nothing wrong about that if that’s what you want to do. But if that’s not what you want to do, then .NET probably isn’t the right choice, as evidenced by how few people in the startup world choose it."
This is a key point, because it shows the positives and negatives of .NET. Because Barrett comes at the idea from as a startup CEO, he values flexibility and disruption more than certainty and seamlessness. That may not be the right decision for your business, but it definitely needs to be a part of your decision process.
Barrett has more:
"Microsoft very intentionally (and very successfully) created .NET to be as different as possible from everything else out there, keeping the programmer far away from the details such that they’re wholly and utterly dependent on Microsoft’s truly amazing suite of programming tools to do all the thinking for them. Microsoft started down this path when they were the only game in town, explicitly to maintain their monopoly by making it as hard as possible to either port Windows apps to non-Windows platforms, or to even conceive of how to do it in the first place."
Barrett has already touched on this, but it’s important to note here that .NET developers tend to face a steeper learning curve in moving to other technologies than developers from other technologies do in moving into .NET. Developer Jonathan Oliver put it this way: "Traditional Windows devs are typically only good at Windows and get lost very quickly outside of their comfort zones."
Why does this matter? If you choose to build software in the Microsoft stack, you will need to choose .NET developers to support it–whether with in-house hires or with an outside firms. And because .NET developers are typically only good at .NET software development, this will be another factor limiting your flexibility going forward.
This may be getting into the weeds unless you have some background in software development, but the .NET framework lacks the scalability, customization, and third-party open source libraries. If these things are important to you, you need to consider a framework like django (written in Python) or Rails (written in Ruby). You can learn more in our free guide to django and discover more about django as a framework in this post.
You’ll want a software engineer to explain in more detail. It’s enough for now to know that the idea of framework needs to be factored in to your business’s decisions about its software stack.
All this may make sense to you, and leave you wondering:
So why do companies choose .NET? It is usually one of two reasons.
The first is that IT managers, CTOs, and other company leaders are used to it. They’ve lived in the world of Microsoft certifications for so long that the idea of a completely new tech stack is foreign. They may not be opposed to it, but they probably wouldn’t think of it on their own–because it’s not even on their radar.
The second reason is that the existing software stack is all built around .NET, SQL, and other Microsoft products. This limits flexibility for future changes–and makes continuing down the .NET seem like a foregone conclusion.
But it doesn’t have to be that way. Your business can broaden its horizons and explore life beyond .NET.
If the conversations we’re having are any indication, you may well find greater ROI than you expected on the journey.