A lost battle?

Going through the explanation of why Java was being displaced by .NET in an organization, it struck me how many arguments used in the post could have been applied to XMPP. It is another demonstration that the KISS concept (in this case the Stupid probably refers to corporate America) always prevail…

If I want to design a website look-and-feel and page flow in .NET, I use ASP .NET. That’s it. If I do so in Java, I use JSP. Or I use JSP and JSF. Or Facelets and JSF. Or Echo2. Or Tapestry. Or Velocity. The number of choices can be intimidating. And that is just for web design. With persistence frameworks, .NET developers have ADO .NET. Java developers have entity beans and JDO as Sun standards or open-source options like Hibernate, Torque, Spring JDBC, and on and on.

I was earlier commenting on the difficulties facing an XMPP client developer when discovering the huge number of different libraries available. The parallel is really easy to draw with the finding about Java and .NET. I know the XMPP community is boiling with energy, and has achieved amazing results with the efforts of many brilliant, dedicated individuals. I am nevertheless under the impression what could have been an opportunity is turning into a detriment.

How many times have I heard the same story on how XMPP is “so much more adapted” at solving a business issue, and how the “management did not endorse the project”. When business is at stake, “management” will always look at minimizing risk and getting a solution quickly and cheaply out. To minimize the risk, the solution will be using HTTP, because they know it works. They will host it on an IIS, because as for Java against .NET:

… deployment to IIS is a simple matter for developers—as simple as copying the project to the wwwroot folder. Java developers must build WAR files or EAR files in order to deploy across servers. Not terribly difficult thanks to Ant, but still more work than a simple copy.

They would be right in doing so. Certainly not smart, but this is not why they are in this position. On the other hand, one does not fight gregarious ignorance through technology, because technology is frightening to herds of corporate creatures... Reduce the fear, increase the usability, and you are already a long way to push a technology into acceptance. When I see on the XMPP developers list yet another question on “what library for (add your favorite development language name here) should I use to create an XMPP client”, I cannot but think XMPP is not as easy as it should. But enough of this, I may just be in a bad mood

Technorati Tags: XMPP, Jabber, Antecipate