Back Draft

Open Up

With .NET apps, your source code is available to any pair of prying eyes. And that's a good thing.

By Jonathan Goodyear

One of the common complaints voiced by traditional ASP developers who built Web sites for resale to external customers was that keeping their ASP code private was difficult. After all, their customers could view it with a simple text editor such as Notepad. You had a couple options to hide your ASP source code. First, you could compile all the good stuff into COM objects. This increased scalability but reduced code portability - especially if you needed to use one of the Chili!Soft UNIX or Linux editions of ASP (see the References listed at the end of the article). COM objects did, however, provide a reasonable assurance that your intellectual property would remain in-house. You could also choose from a few code obfuscation utilities, but this added a layer of complexity to code maintenance and distribution. In addition, most of them used common hashing algorithms that could be cracked easily.

Then, in marched ASP.NET, allowing your entire Web application to be compiled into DLL assemblies. Don't get too comfortable, though, because the .NET Framework ships with a disassembler utility (ILDASM.exe) that allows you to de-compile .NET assemblies into Microsoft Intermediate Language (MSIL) instructions. Anyone with an experienced eye can deduce what your code is doing with little trouble. ILDASM.exe works with any .NET assembly that doesn't make calls to external C libraries using Platform Invoke (PInvoke), including most assemblies that ship with the .NET Framework. The most notable exception is the heart of the .NET Framework, mscorlib.dll, but most assemblies you will be creating with the .NET Framework will be an open book to ILDASM.exe.

If you're now thinking your source code will be accessible only to the geeky folks behind the curtain who learn the MSIL instruction set, think again. It gets worse. Dr. Huihong Luo, a Stanford University alum, built the Salamander .NET Decompiler (see the References listed at the end of the article). This utility is absolutely amazing. It can decompile a .NET assembly directly back to C#, VB .NET, or managed C++ .NET source code. It can even interpret the unsafe code that trips up the ILDASM.exe utility. I took the Salamander .NET Decompiler for a test drive online and found it produces code amazingly similar to the original. In some cases, it actually improves the formatting. Scary! Your .NET source code falls victim to the extensive Reflection support baked into the .NET Framework. You can purchase a full version of the Salamander .NET Decompiler that can handle larger assemblies for about $1,100.

Before you fall too far into despair, Dr. Luo also built a corresponding obfuscating utility that transforms your source code in a way that makes the decompiled version extremely hard to understand and unlikely to be recompiled effectively. The obfuscator sells for approximately $500. You can try it out online, but you are prohibited from distributing the demo obfuscated assemblies it creates for you. One other option you could explore would be to use the Native Image Generator (NGen.exe) that ships with the .NET Framework to compile your source code into native binary machine instructions pre-JIT (Just In Time). The disadvantage is you lose the platform agnostic nature of MSIL, and you will most likely have to perform a separate pre-JIT compilation for each platform you wish to support.

You can rack your brain about the various ways to hide your source code and the equally numerous ways others can crack it, but it's a waste of valuable time. It is simply an elaborate chicken-and-egg conundrum that in most cases is counterproductive. Software vendors should take the opportunity with .NET to begin a policy of making their source code available with the purchase of their products.

Before you tar and feather me, hear me out. There really are some compelling reasons to allow your customers access to your .NET source code. My support of open-source .NET software and components falls into three categories. My first argument is that with .NET, the black magic is gone. There is little mystique about how things are done. There are no more crazy API secrets. Given an appropriate amount of time, the purchaser of your software or component could produce nearly the same result. They are purchasing your product to save the time it would take to build the solution themselves, not to plunder your intellectual property. Your customers have paid you already, so give them their money's worth. Don't worry about your customer sharing your software's source code with his or her buddy. That person was probably too cheap to buy a copy from you anyway. Reputable companies ensure that they have licenses for all of their software. Chasing software pirates is like chasing ghosts.

The second reason why I favor an open-source model for .NET software is it increases product quality and reduces support costs. The open-source movement has proven time and again that the more eyes you put in front of a piece of code, the better it becomes. If you give your customers an opportunity to help you fix problems, you get a twofold advantage. You get a more stable product, and you reduce the number of people you need to keep on staff to handle developer support. This translates into higher profits for you, or a lower cost for your customers - perhaps a mixture of both. A typical software developer will make a conscious effort to fix his or her own problems if you give them the tools to do so. If you play your cards right, you can even harness this developer energy into a strong community around your product. Instead of a bunch of developers venting their frustrations on the newsgroups, you now have a community posting fixes and enhancements, taking your product to levels you never thought possible.

Third, open-source .NET software fosters a learning environment. Why does this concern you, as a software or component vendor? .NET is still in its infancy, and adoption is crucial to the success of your .NET software business. One of the best ways to learn how to build effective .NET code is to look at complete production-quality examples of it. The tutorials available online, at conferences, in books, and even in magazines, can only take you so far, mostly due to space and time constraints. To take your knowledge further, you need to look at bigger chunks of .NET code. If your product offers both a solution to a development problem as well as the opportunity to learn more about .NET, you will garner a fierce loyalty for your product line from your customers. As I stated already, solving most programming problems with .NET is not a difficult task. Software companies need to take many more factors into consideration to keep their customers coming back for more.

It would be extremely na ve to think that all .NET applications and components should be open source. There are still some highly proprietary formulas, business intelligence, and processes out there. But most of these will fall under specific market niches. Code that implements patentable technology should still be obfuscated and hidden from customers. Usually, this can be localized to a specific black-box assembly, leaving the rest of the application open for your customers to explore. Microsoft (the veritable poster child for closed-source software) could have opted to obfuscate all of its .NET Framework source code but opted against it. This makes a serious statement to the development community. The Grid Control your company is building (no matter how cool it is) does not have anything in it that really needs protection against curious developers.

Only time will tell how the development community will react to the more open nature of source code under the .NET Framework. They might accept it, or they might do everything in their power to propagate the cloak of secrecy. I hope software and component vendors come to their senses and realize that having their code in the open is not nearly as bad as it sounds. They simply need to open their eyes to the fantastic possibilities.

References:

http://www.chilisoft.com

http://www.remotesoft.com/salamander

Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. He's a Microsoft Certified Solution Developer (MCSD) and author of Debugging ASP.NET (New Riders Publishing). Jonathan is a contributing editor for asp.netPRO and speaks regularly at major technology conferences. E-mail him at jon@aspsoft.com or through his angryCoder e-zine at http://www.angryCoder.com.