Introduction
This is the second in a series of columns in which I will tell you how I started SplendidCRM Software, Inc. I hope that my entrepreneurial experience will inspire you. In my opinion, the creation of a company can be a wonderful adventure.
Article 2
What does it take to start a company? It takes an idea for a product or service; it takes a programmer (that means you); it takes a computer (you already have one); and it takes some sort of development tools (which you can get for free from Microsoft). But the real point is that starting a company means that you have to start doing something.
Don't bog yourself down with the legalities of the startup process. You don't need a lawyer or an accountant to start a company. You don't even need a name for your company. All you need is the program idea and the hope or desire that it will eventually turn a profit.
I started writing the application that would eventually become SplendidCRM one year before SplendidCRM Software, Inc. was incorporated. I did not incorporate until I reached a point where I believed that I had something unique and marketable. It may seem odd to use the word unique when I have previously established that my product is intended to be visually identical to another product. The point is that my version was an independent creation that targeted developers who had entirely different platform preferences.
If you recall from my first article, I started SplendidCRM by re-implementing an existing open-source application, SugarCRM. The deeper I got into the project, the more I realized that I was creating a better CRM. My implementation was faster; easier to customize; and took fewer man-hours to develop. I finally reached a point where I realized that "I can sell this". At this point, I created a corporation.
The beauty of open-source is that the whole movement is based on inspiring others to contribute, which is a deliberately broad and vague statement. While some may suggest that you must contribute to the same project only by using the same language tools, this suggestion is incorrect. Judging by the number of downloads of SplendidCRM, I believe that my contributions are appreciated.
The funny thing about re-implementing a LAMP-based -- which stands for Linux+Apache+MySQL+PHP -- product in .NET is that the resulting application can run on Linux. While some may claim that a .NET application is "locked" into running on Windows, I had no problem running SplendidCRM on SUSE Linux.
From my first article in this series, I received a few polite comments that the transition from business to programming was rather abrupt. Therefore, let these few sentences prepare you to learn about what it took to get SplendidCRM to run on Linux using Mono. Also, in a token effort to ease this preparation, I am going to start the next section with references to classic literature.
A Tale of Two Operating Systems
It was a dark and stormy night when I decided that I wanted to run SplendidCRM on Linux. If you are a .NET developer, you already know about Mono. Mono is a cross-platform, open-source .NET development framework that allows you to run your .NET application on Linux or Mac. I've been following the progress of Mono for many years and have been consistently impressed with the progress and accomplishments of the Mono developers. The goal of SplendidCRM is analogous to the goal of Mono. Whereas the goal of SplendidCRM is to take a Linux application and to re-implement it for the Microsoft crowd, the goal of Mono is to re-implement the entire .NET Framework to run on non-Windows operating systems, which primarily means Linux or MacOS. To find out more about Mono, please visit this link.
What does it take to run an ASP.NET application on Linux using Mono? The answer is: not much. If your application is 100% managed code, chances are that your application will run unmodified on Linux. Some of the newer features of .NET 3.0, such as Windows Workflow, Windows Communications and Windows Presentation are not supported in Mono 2.4; therefore, be warned.
SplendidCRM was first tweaked to run on Mono in July 2006; the original effort took 5 hours. Three years ago, I had to create my own VisualBasic class to support some simple things such as ControlChars.CrLf, or Information.IsDate. While this took very little effort, it is no longer necessary today.
One area that required a fair amount of effort had to do with the differences between the file systems of the two operating systems. Linux uses a different slash than Windows, so I had to make certain to use Path.Combine() to build paths instead of doing it by hand. Also, file names are case-significant on Linux, so I had to make certain that all references to files matched the file names. For example, on Linux Default.aspx is not the same as default.aspx.
There were a few other small issues, such as the fact that I could not set the CurrentCulture.NumberFormat.CurrencySymbol directly on Mono as it is read-only. The solution was to simply clone the culture and modify the clone. The same was true for the CurrentCulture.NumberFormat.CurrencyDecimalSeparator. Of course, if you are not developing a CRM, then you probably will not be creating an internationalized application, so you will not need to override the currency symbol or separator.
An interesting side-effect of being familiar with Mono was that I was able to leverage some of the Cryptography code from the Mono source code to manage certificates used by Amazon Web Services. AWS requires the use of X509 certificates. While one would think that Microsoft's own framework would provide the ability to work with public and private keys, this is one area where they are lacking. However, by leveraging the Mono source code, I was able to easily convert the Amazon PEM keys directly to the required PKCS12 certificate, without first saving it as a file and without using the OpenSSL tools. The PayPal Service API has a similar requirement with respect to the need to create a PKCS12 certificate.
The conclusion that I hope you will take away is that adopting .NET does not lock you into Microsoft. There are options to run .NET elsewhere, and Mono is the best option today. In fact, I would go so far as to say that I was able to achieve the "write once, run anywhere" promise that was once Java's reason for being. And, the more platforms that you run on, the higher the potential sales.
I hope that you have enjoyed this second article in the series. Please watch for article 3 within the next two weeks.
History
- 5th June, 2009: Initial post
