Linux is better than Windows, Ruby on Rails is better than ASP.NET MVC, PHP is better than ASP.NET, Google Docs is better than Microsoft Office. Yada yada. Its all relative to the individual – thats my guess, simply because better in your perspective is not better for me and vice versa. Even though I have vain ambitions to learn Ruby or Python, I currently know C# and saying to me that I can do things faster and quicker with the latter seems like a rather pointless argument. Theoretically speaking I should be able to learn either Ruby or Python quickly but my general feeling is that both are best suited for running on Linux/Unix systems and honestly it seems kinda pointless trying to do development in a Windows environment with either because you already have .NET available. I really don’t take PHP developers who develop on Windows seriously. Why? Because its a contradiction in my book.

The tendency for open source CRM packages is to become commercial – this is a fact that nobody can deny. The reason is understandable because an open source product cannot financially stable if its completely “free”. CRM packages are complex pieces of software that do all kinds of weird and wonderful things such as managing your interactions with your customers and most importantly saving those interactions giving you a history. CRM packages are also useful because you can tie it in with a commercial product offering that creates one or product catalogues and allows you to interact with your customers by sending them detailed product information or by running promotions.

Before I dive into why commercial CRM packages are problematic I think I should define a CRM a bit further, not from a wiki definition but my own, because its my perception of a CRM that shapes my idea of what it is and what problem it solves. A CRM package really comes down to one thing, the value you place in your customers and the length you will go to in keeping your relationship professional. By professional I mean by not making an idiot out of yourself because you forgot about the topic of a previous conversation. In essence that is what I think a CRM is supposed to help with, help build rapport with customers – not do. The do part is up to you.

Windows based CRM solutions are a world of pain on several levels not the least of which is the fact that you will have to spend loads of $$$ in buying software that is needed apart from just the CRM. Microsoft Dynamics CRM requires SQL Server and Windows Server, and if you simply think in terms of licensing per user the costs quickly add up. Sure, the product itself might be awesome but if you think about it a CRM will require time and resources for setting it up and keeping it up and running. I can only imagine what the installation process for dynamics CRM will be and the time it will take. In fact you will also need training – which will not be free. All the other commercial CRM makers do this, especially those that run on a MS technology stack. Its a greedy money making business nothing else really.

Yesterday I asked our IS manager if Sage CRM can provide us with a demo or test environment for the CRM and guess what we have to pay for it, even if we have already bought a license for it. How am I suppose to develop against a product that gets shipped to us and gets installed in a production state? There is no room for testing against it, to do business specific things like workflows and integrate product data. Whats the point if you cannot take the existing CRM and mould it a little and customise it. Instead you get stuck with a huge bill to pay for training and installations.

I like the many-to-many mapping EF4 provides you simply because it allows such great navigation between entities and its easy to shape the query from one side to other and vice verse. The only issue is that it causes issues with JSON serialization, because the serializer does not know how to handle circular references, it can only serialize one way. Initially I dealt with this issue by creating “view classes” but it seemed rather tedious and pointless, so instead I started using the enumerable Select() method. It provides a very easy way to construct “anonymous objects”. So in my controller I would have a JSON Result and I would do something like this:

Json(courses.Courses.Select(t => new { CourseTitle = t.CourseTitle, CourseCode = t.CourseCode, CourseId = t.Id }));

Pretty damn neat, considering that Courses is a EF4 entity and I dont have to go and change or adapt it to play nicely with the JSON serializer.