X
Business

Why .NET will benefit other platforms

Just as .NET has been touted as the savior of the "little language," it may also be the technology that raises the fortunes of many non-Microsoft platforms and applications, including Linux.
Written by John Carroll, Contributor

COMMENTARY--As I discussed in my last article, I believe that .NET will grow into a standard development framework that encompasses both Microsoft and non-Microsoft platforms. Before you turn in your keyboard and become a Sherpa guide in the Himalayas, however, consider some of the advantages of a world unified around a common development framework like .NET. Just as .NET has been touted as the savior of the "little language" (due to its emphasis on multi-language support in .NET), it may also be the technology that raises the fortunes of many non-Microsoft platforms and applications, including Linux.


Demystifying .Net
Part I--Clarifying the .Net message
Part II--Why .NET will conquer the world


1. .NET hooks non-Microsoft platforms into the larger Windows development community. This increases the number of developers available to work on those platforms. Miguel de Icaza, founder of Ximian, offered the following as motivations for providing a .NET implementation on Linux:

  • Windows developers know how to write code for it.
  • Lets make it easy to bring developers from the Windows world into our platform.
  • Training materials, tutorials, documentation, tips and tricks are already available in large quantities, lets leverage this.

In other words, if it is easy for Windows developers to write for Linux, then they will write for it. Requiring them to learn an entirely different set of APIs virtually guarantees that they won't bother.

Furthermore, by adopting .NET, other platforms can leverage the billions Microsoft and others spend on .NET reference material and training. Microsoft's documentation is extremely good, as long-time Mac and BeOS developer and author of the "Pepper" text editor Maarten Hekkelman related in a recent interview. Microsoft caters to developers in ways that other companies don't. Leveraging that investment makes business sense, as it is essentially free money from which other platforms can benefit.

In sum, .NET lowers the cost of developing for non-Microsoft platforms. Lower costs and fewer hoops through which Windows developers must jump will lead to more applications. If network effects are the thing that keeps consumers returning to Windows, then hooking into that network will raise the likelihood that consumers will consider platforms such as Linux.

2. Better support for Microsoft apps on non-Microsoft platforms. Love them or hate them, but Microsoft applications are some of the most popular pieces of software in existence. Microsoft plans to convert most of their products to .NET. Once that happens, they have at least a fighting chance of working on a non-Microsoft platform. Granted, an application could still call into native code which only exists on Windows, or use Windows specific .NET assemblies. However, that's a market opportunity for some company to provide the non-standard feature which prevents Office from working completely.

The ability to support Microsoft applications would go a long way towards establishing the credibility of Windows alternatives among average consumers and businesses, EVEN IF they don't have all the features found in the Windows version. As many have noted in defense of StarOffice, the average consumer needs only a fraction of the features found in the Microsoft Office suite. For most users, even a less-functional Microsoft Office on Linux would be more than enough for their needs.

3. .NET widens the market for those who don't target Windows. ISVs who target non-Microsoft platforms can choose to avoid features specific to Windows, yet still sell their products to the Windows market. This widens the revenue base for these companies considerably, making them more viable business entities and generating revenue that can enrich the non-Microsoft world. Likewise, startups oriented around Linux platforms (as an example) will have an easier time making a business case, as they can include the large market for Windows software in their business plans.

4. .NET binaries are closer to the open source ideal. For a bit of a shock, track down ILDASM.exe in the .NET SDK, fire it up and drop your favorite .NET assembly on top of it. ILDASM stands for "Intermediate Language DisASseMbler," and what it does is use "reflection" to create a visual representation of the contents of a .NET assembly.

.NET, like Java, is completely self-describing, which is essential to a managed runtime's ability to monitor what running code is doing. This means that a surprising amount of information is contained in a .NET assembly, information which makes it very easy to figure out the original source code. Method names, return types, parameter names and types, the names and types of member variables, and other bits of useful information are all included inside of a .NET executable.

Click here for some sample ILDASM output

ILDASM outputs "IL assembler", which though much easier to understand than regular assembly language, is still not the same as the original source code. However, because .NET assemblies provide so much information about themselves, real, honest-to-god disassemblers generate much better output. A good example is the Salamander .NET Decompiler, which allows you to choose whether you want your code in C#, VB.NET or Managed C++ (which demonstrates one of the advantages of early emphasis on multi-language support).

Of course, obfuscators do exist, an example of which is available from the same company that made the Salamander .NET Decompiler (like selling guns and flower arrangements from the same corner shop). However, Java "suffers" from the same ability to decompile the source code, and thus Java software companies theoretically have the same motivation to obfuscate. Even so, I have yet to run across anything that I couldn't decompile. I suspect the same will apply to .NET. Obfuscators will exist for those who REALLY want to hide their source code, but those who do so will be far in the minority.

5. Boosts efficiency, as developers can program to just one API. There's a reason why programmers tend to fall into warring technology camps. Computing technology evolves very quickly, and it is expensive in terms of time and money to keep up with it. Hence, most programmers choose a particular programming domain, and are reluctant to deviate from it.

This is an unnecessary waste which balkanizes the programming world into isolated, even antagonistic, blocks. A better solution is to find a way for everyone to hook into the same API. This is the approach taken with .NET.

API unification should matter to proponents of non-Microsoft platforms, because the root cause of Microsoft's desktop popularity has been the expense of developing for warring APIs. Favoring Windows is the rational end product of market realities, both for developers who must decide where to concentrate their R&D efforts and for consumers who have to make compatibility calculations. If everyone can use the same basic APIs, then the costs which keep developers and consumers tied to a particular platform are diminished. This increases the likelihood of platform mobility, which boosts the fortunes of non-Microsoft platforms.

Why is Microsoft doing this?
If .NET so undermines the lock-in potential of the WIN32 API, why is Microsoft pushing .NET? First, I don't think they have much choice. A managed architecture like Java is an undeniable improvement over any native API. As the years pass and the requirements (and risks) of a networked environment are better understood, the advantages of a VM style environment like Java becomes more compelling. Hence, Microsoft needs to incorporate this sort of technology if they are going to keep Windows software development competitive in the coming years.

Second, I think Microsoft is more willing to let a bit of Windows market share slip away, so long as the loss is made up through increased sales of application software. Writing for multiple platforms can be expensive. In a networked environment, however, it's very hard to guarantee that everyone will run Windows. .NET makes up for this deficiency by creating a level middle layer that papers over many of the ideosyncracies of a particular operating system. If Microsoft writes to a standard middle layer like .NET, they can sell to everyone with access to a .NET runtime, whether or not they run a Windows operating system.

Additionally, Microsoft doesn't enjoy the attentions of the US government. Giving a bit of ground in the desktop market will take some of the antitrust heat off, and won't be a revenue problem so long as Microsoft can continue to sell to a large unified software market (as currently exists for Windows) and opens new .NET-oriented software markets through which it can leverage its cross-domain industry knowledge (explained further down).

Third, Microsoft is well positioned to remain an applications juggernaut. They regularly make software that ends up taking over its market segment (and no, it can't be explained away by Microsoft's popularity as a desktop operating systems). Microsoft has an organization that enables it to consistently do this, one that gives it a competitive advantage. Furthermore, given the difficulty of changing corporate culture, they are confident that it will be difficult for others to replicate it. As noted in a previous article, Microsoft consistently gets high marks from its own employees. Competitors won't match that overnight.

In addition, Microsoft has a presence in practically every technology market which would benefit from software. That gives them in-house knowledge about the interconnection needs of these markets that no one without the breadth of a Microsoft could hope to acquire. This is a competitive advantage in a world of ubiquitous networks, given that most of these domains either communicate today or can be expected to communicate in the near future.

Conclusion
The biggest barrier I see to the benefits I've enumerated is the resistance of many of those outside the Windows development community to associate with ideas traceable in any way to Microsoft. This is a mistake, because Microsoft has a lot of good ideas, many of them centered around ways of satisfying consumers, both non-technical "normal" users and programmers/corporations. Microsoft is smart enough to absorb good ideas when potential customers have proven they like them (Java certainly falls into this category due to its popularity in the enterprise). It is equally smart for others to borrow ideas from Microsoft.

Instead of complaining about Microsoft's market reach, co-opt it. Embrace Microsoft's protocols and conventions (something made easier by the recent settlement), as Ximian appears to be doing with their "Evolution" Outlook replacement. Accept that consumers like Microsoft's way of doing things, and do it better. That's certainly what Microsoft did in its battle with Netscape. They copied all of Netscape's non-standard HTML extensions (that is, those parts not blessed by the W3C), and endeavored to ensure that IE did everything AT LEAST as well as the dominant Netscape browser. Once they reached parity, they made a functionality leap with IE 4.0 that made IE BETTER, technology wise, than Netscape, thus starting the wholesale shift towards IE.

It is a pointless battle to pretend that boycotting the use of those (.NET) technologies will have any kind of effect on their reach (Miguel de Icaza). A friend of mine once described the Judo martial art as "the ability to use your opponent's attack momentum against them." Microsoft is spending billions migrating its developer community to .NET. Leverage that investment, and use Microsoft's own "momentum" to widen your market and boost your platform of choice.

This is Part III of 3 commentaries on the future of .Net. Read Part I, "Clarifying the .NET Message" and Part II, "Why .NET will conquer the world."

John Carroll is a software engineer who lives in Switzerland. He specializes in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.

Editorial standards