Back Draft

Open Up

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

By Jonathan Goodyear

One of the common complaints voiced by traditional ASPdevelopers who built Web sites for resale to external customers was thatkeeping their ASP code private was difficult. After all, their customers couldview it with a simple text editor such as Notepad. You had a couple options tohide your ASP source code. First, you could compile all the good stuff into COMobjects. This increased scalability but reduced code portability - especiallyif you needed to use one of the Chili!Soft UNIX or Linux editions of ASP (seethe References listed at the end of the article). COM objects did, however,provide a reasonable assurance that your intellectual property would remainin-house. You could also choose from a few code obfuscation utilities, but thisadded 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 Webapplication 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 MicrosoftIntermediate Language (MSIL) instructions. Anyone with an experienced eye candeduce 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 PlatformInvoke (PInvoke), including mostassemblies that ship with the .NET Framework. The most notable exception is theheart of the .NET Framework, mscorlib.dll, but most assemblies you will becreating with the .NET Framework will be an open book to ILDASM.exe.

If you're now thinking your source code will be accessibleonly 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, builtthe Salamander .NET Decompiler (see the References listed at the end of thearticle). This utility is absolutely amazing. It can decompile a .NET assemblydirectly back to C#, VB .NET, or managed C++ .NET source code. It can eveninterpret the unsafe code that trips up the ILDASM.exe utility. I took theSalamander .NET Decompiler for a test drive online and found it produces codeamazingly similar to the original. In some cases, it actually improves theformatting. Scary! Your .NET source code falls victim to the extensive Reflectionsupport baked into the .NET Framework. You can purchase a full version of theSalamander .NET Decompiler that can handle larger assemblies for about $1,100.

Before you fall too far into despair, Dr. Luo also built acorresponding obfuscating utility that transforms your source code in a waythat makes the decompiled version extremely hard to understand and unlikely tobe recompiled effectively. The obfuscator sells for approximately $500. You cantry it out online, but you are prohibited from distributing the demo obfuscatedassemblies it creates for you. One other option you could explore would be touse the Native Image Generator (NGen.exe) that ships with the .NET Framework tocompile your source code into native binary machine instructions pre-JIT (JustIn 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 foreach platform you wish to support.

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

Before you tar and feather me, hear me out. There reallyare some compelling reasons to allow your customers access to your .NET sourcecode. My support of open-source .NET software and components falls into threecategories. My first argument is that with .NET, the black magic is gone. Thereis little mystique about how things are done. There are no more crazy APIsecrets. Given an appropriate amount of time, the purchaser of your software orcomponent could produce nearly the same result. They are purchasing yourproduct to save the time it would take to build the solution themselves, not toplunder your intellectual property. Your customers have paid you already, so givethem their money's worth. Don't worry about your customer sharing yoursoftware's source code with his or her buddy. That person was probably toocheap to buy a copy from you anyway. Reputable companies ensure that they havelicenses for all of their software. Chasing software pirates is like chasingghosts.

The second reason why I favor an open-source model for.NET software is it increases product quality and reduces support costs. Theopen-source movement has proven time and again that the more eyes you put infront of a piece of code, the better it becomes. If you give your customers anopportunity to help you fix problems, you get a twofold advantage. You get amore stable product, and you reduce the number of people you need to keep onstaff to handle developer support. This translates into higher profits for you,or a lower cost for your customers - perhaps a mixture of both. A typicalsoftware developer will make a conscious effort to fix his or her own problemsif you give them the tools to do so. If you play your cards right, you can evenharness 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 tolevels you never thought possible.

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

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

Only time will tell how the development community willreact to the more open nature of source code under the .NET Framework. Theymight accept it, or they might do everything in their power to propagate thecloak of secrecy. I hope software and component vendors come to their sensesand realize that having their code in the open is not nearly as bad as itsounds. 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 Internetconsulting firm based in Orlando, FL. He's a Microsoft Certified SolutionDeveloper (MCSD) and author of Debugging ASP.NET (New Riders Publishing). Jonathan is acontributing editor for asp.netPRO andspeaks regularly at major technology conferences. E-mail him at jon@aspsoft.comor through his angryCoder e-zine at http://www.angryCoder.com.