One of the favorite arguments of the Open Source community is that if you use Microsoft technology you are negatively tied into a “proprietary” solution. So what does “proprietary” mean anyway?

From Wikipedia:

1 . indicates that a party, or proprietor, exercises private ownership, control or use over an item of property, usually to the exclusion of other parties

2 .Software which is privately owned or controlled is known as proprietary software. However, the extent to which proprietary rights can be claimed or maintained in relation to software is a matter of considerable controversy (see software patent debate).

Proprietary software is not free software or open source software as end-users generally do not have the ability to:

• Run the software for any purpose
• Study and modify the software
• Copy the software and provide it to third parties
• Make and release improvements to the software

Ok so according to this definition, is a proprietary solution such a bad thing? Well maybe from the point-of-view of the average open source advocate, hard-core programmers who enjoy being able to poke around in millions of lines of code, it is. But is this a negative thing from the perspective of a business trying to implement systems that they will depend on daily? Would an organization really want to deploy a system where the source code is open to all, and an ambitious programmer might go into the code to make an “improvement” and end up breaking something?

Let’s look at an example, a recent post here on my blog is an example of how to use Sharepoint Team Services to store documents related to MSCRM records. http://blogs.msdn.com/jstraumann/archive/2006/01/15/513069.aspx

This is a really great value proposition for our customers and shows a way for businesses to use the best features of several Microsoft products for a powerful collaboration solution.

So to build the demo I used the following products, all of which a CRM customer will already have as CRM depends on this infrastructure to run, and in fact anyone running WS 2003 (i.e. not just CRM customers) has access to Sharepoint Team Services.

So I used all of these “proprietary” products and tied them together into a very compelling value solution for our customers. What if a customer wanted to hire an open source developer to build a solution like this in Open Source? Take a look at this matrix:

So the primary components (Sharepoint) used in the solution don’t even exist in open source, and the choice of the other products used will be the personal preference of the developer hired to create this.

So let’s say our developer gets started and makes the following choices

So the first red flags for our customers are the last 2 items, both of which need to be custom built by the developer. How long is this going to take? A long time at a large hourly rate, very good for the developer, but not a good value proposition for the client. Furthermore, even if the developer can build these components in a reasonable amount of time and money, what about maintenance? Ongoing maintenance is the biggest factor in TCO – Total Cost of Ownership  - a topic most open source advocates prefer to avoid. They like to say “The software is free” and perhaps to acquire the base software for the project is free, but is the developer going to do all the work for free? Not likely. I always like to say that IBM doesn’t invest a billion dollars, the amount they publicly pledged to open source a few years ago, in *anything* that is free!

So to sum up this situation, we need to make sure our customers understand the inherent risks in this strategy. If the customer hires someone to implement the open source solution, many questions come to mind, each of which apply equally across each product needed for the project:

Which version of the product did they use? A packaged distribution from an ongoing concern like a RedHat or SuSE, or some obscure distro they found on the web somewhere? Who is going to maintain the OS, who is responsible for bug fixes, security patches, ongoing support, etc.

If they use Java for the programming language; which version? Is it going to be supported in the long term?

Who created/supports the directory services they chose?

What IDE did they use? Is it common, i.e. do many people use it and are familiar with its features or is it a personal favorite of the developer that no one else has ever heard of?

What about the office suite? What can/can’t it do? Sure it can create text, but can it accurately open the Microsoft Word/Excel documents which the other 95% of the world will be sending to the customer? Or does it mangle the contents beyond recognition?

Can the custom built components the developer is using to replicate the abilities of Sharepoint *really* do so? And perhaps more importantly, is the code clearly designed, written, documented, and commented? Most likely not, most developers just sit down and start typing.

Ok let’s end these questions, we could continue but we would eventually fill up all the space on the MSDN servers!

So with all these questions in mind, ask the customer the final, most important question:

“So your brilliant open source developer gets this thing done, throws the switch and it all seems to be working OK. But then tomorrow he/she looks at this/her bank account and sees that you have paid them an enormous sum of money to get all this done, and they can go open that surf board shop they have always dreamed about. So it’s ‘Thanks for your business but I am out of here, and here is a CD with all the source code on it’”

Wow. I would not want to be this customer! So can anyone hazard a guess as to what has ended up happening here?

Now the customer REALLY does have a proprietary solution, but it’s not proprietary to a particular company or technology, but to ONE PERSON!  And this person is now on a beach somewhere…

So now let’s say the customer needs to add or modify the project so they go searching for a consultant. First of all, finding a consultant with expertise in the exact same products the first consultant used is going to be difficult. Chances are consultant #2 will have different personal favorites than consultant #1. With luck we might find someone with similar expertise in some of the products and the ability to ramp up on the others, on your nickel of course!

So let’ say we do find another consultant with the exact same skill set, what happens next? They report to work on a time and materials basis, because no consultant in their right mind is going to give you a total price on the job when they are picking up someone else’s work, pop the CD in their machine and begin digging into the 0 documentation, 0 architecture and design documents, 0 source code comments, code. How long do you think it will take for consultant #2 to even begin to figure out what consultant #1 has done? A long, expensive, time!

If these facts are not enough to make a customer think twice about the FREE open source software, keep in mind that this same process applies to most of the products used on the project. Where do these products come from because if the acquisition truly was free, they most likely come from a code dump somewhere. If the consultant uses open source software products that are maintained by a commercial company ala Red Hat or JBoss, chances are that ongoing support is definitely not free.

So now let’s compare this scenario with my Microsoft solution. I created the entire solution in a Visual Studio .NET project that is downloadable here  http://blogs.msdn.com/jstraumann/archive/2006/01/15/513069.aspx  . Since I used the SDK (Software Development Kits) provided by the various Microsoft products, and adhered to best practices of .NET development, anyone familiar with .NET development who has the same infrastructure components can download the source code and very quickly implement the solution. In fact, people involved in the MSCRM community from all over the world have done just that. They didn’t have to worry about what obscure products I might have used, or any crazy code I wrote myself. It’s all Microsoft, all portable between Microsoft systems, and easy to implement as many times as they need to. Furthermore, they get the ongoing support of Microsoft for the products used, including patches, security updates, service packs, etc.

So in the case of one of our partners implementing a similar project at a live customer site, the customer can rest assured knowing that if and when Microsoft Partner #1 decides to move on, any of  Microsoft Partners #s 2 thorough 750,000 (or whatever the number is) can easily pick up where partner # 1 left off.

And since the Microsoft products used are, according to the definition at the beginning of this article, proprietary, it is not possible for an ambitious developer to get it in his/her head that they should change and recompile part of one the products, which could lead to big time long term problems. Any such “improvements” are going to come from Microsoft, with all of the expertise and testing of Microsoft behind them.

So what is the end result? Is a Microsoft solution proprietary? Well yes, according to the strict definition given above. However is the fact that the Microsoft solution is proprietary negative? Well I hope this article clearly answer this with “NO”! But what about the open source solution, is this proprietary and if so, is this a negative thing? Well I would leave that up to the customer. Present these facts and let them make up their own minds!

One last note, if, even after reading this article and/or hearing these facts, a customer does decide to hire an open source programmer to build a solution like this, please call me! I am very happy at Microsoft however I don’t think I could turn down the opportunity to make a million bucks and then have a customer who needs me for life to maintain the project I built for them since I am the ONLY person in the world who can understand what the heck I did!