COMMENTARY--NET is a difficult technology to explain to
non-programmers because .NET is developer-oriented
technology. Many of the features of .NET don't make
sense unless you know a lot about software
development. From a marketing standpoint, however,
understanding the essentials of .NET shouldn't require
expertise in software engineering any more than buying
a car requires a degree in mechanical engineering.
What is needed is a consideration of other markets
where technically abstract concepts are communicated
to a non-technical audience.
 | ||||
| | | ||
| Demystifying .Net Part II--Why .NET will conquer the world  Part III--Why .NET will benefit other platforms | | ||
| | ||||
| | ||||
That's the view of .NET from the moon. Getting deeper into it involves a keen understanding of software development. Automatic memory management, mandatory object orientation, streamlined APIs for everything from windowing to back end web development, a portable intermediate format in the form of MSIL, self-describing code, code metadata (essential to .NET code access security), XML usage in every aspect of the .NET library (configuration files, serialization formats, remoting), simplified native code interoperability through P/Invoke, versioned assemblies, etc. are meaningless if you don't know anything about software development.
That isn't a problem, however, if one considers that people aren't experts in many domains in which they are called upon to make purchasing decisions. I know a bit about cars. I can change my own oil (well, my car's, not my own), and even replaced the spark plugs and wires on a '66 Ford Fairlane I used to own back in high school (a pox on any town that still uses salt on their roads). However, I am FAR from an expert in automobile engines, particularly the sort that fill up modern cars like some bio-engineered nightmare from the brain of H.R. Giger (of "Alien" fame, who has a museum in quaint little Gruyères, Switzerland).
However, I still manage to buy cars. To manage this astounding feat, I use statistics compiled by third parties which tell me the performance characteristics of the car. I can determine what miles to the gallon (or kilometers per liter) a car gets, how fast it goes from 0-60, how it performs in cold weather, its tendency (or lack thereof) to seize up on long journeys through the Arizona desert, etc. I have absolutely no idea how the engine manages any of these things. I just know that it can do it based on third-party data.
In that light, the best way to promote .NET to non-programmers (CIOs, Managers, technology journalists) is to emphasize that .NET is developer productivity technology, and support that statement with third-party statistics. Create comparison tables showing how much more productive .NET developers are. Show that fewer bugs are found in .NET code, or that .NET applications are more secure.
What Microsoft Has to Change
Microsoft's problem has been its failure to keep the
.NET definition distinct from products that might be
used in or by .NET applications. The core definition
should be that ".NET is developer productivity
technology." Every press release or marketing
blurb needs to include that basic statement as an
axiom. Furthermore, this definition should be tightly
associated with the .NET "framework" or SDK (any .NET
SDK, including Ximian's Mono and dotGNU), so that
customers can understand clearly that .NET is
technology used by developers to build applications.
To support this definition should be data that shows what .NET does for consumers. Microsoft should show companies the development productivity and quality gains which result from shifting to .NET. Give them concrete statistics which emphasize the higher security, lower bug incidence and lower cost (due to more productive developers) of .NET applications.
There is value in communicating a product's .NET association to potential customers. That doesn't mean that .NET has to be like some nonsense Gatorade flavor (what the heck does "Riptide Rush" taste like?), slapped on every paperweight that ships out of Microsoft's product division.
A separate brand would keep the .NET message of developer simplification pure while allowing ancillary products to be linked to it. Therefore, Microsoft should create a new branding label, which I'll call ".NET Technologies." .NET Technologies are products that support code written with .NET (Windows.NET Server and SQL Server.NET (Yukon) will fall into this category), or else enhance the .NET development process either through adding new functionality (MapPoint.NET) or facilitating the development process (Visual Studio.NET). ".NET Technologies" are enhancements to or facilitators of .NET development, not a requirement of it.
A distinct brand would have helped when the .NET My Services rollout was deferred. Since people didn't have a clear idea of what .NET was, the .NET in .NET My Services left people with the impression that this critically affected .NET. It didn't, because .NET My Services is no more a fundamental underpinning of .NET than BEA's WebLogic server is essential to Java.
.NET is powerful technology that offers a lot of things I have always wished were in Java. Even more important, it is Microsoft technology, which means it will be used all across the Microsoft product catalog.
Everything in that catalog, from operating systems and game consoles to databases and handhelds will be unified by .NET technology. This is an important productivity enhancement for developers, as it makes knowledge in one domain even more applicable in another. Microsoft just needs to find a coherent way to communicate those benefits, one that creates a simplified core message that non-programmers can understand while allowing ancillary technologies to promote their association with .NET without clouding the definition.
This is Part I of 3 commentaries on the future of .Net. Follow the series with Part II, "Why .NET will conquer the world," and Part III, "Why .NET will benefit other platforms.
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.
