What's Behind Door #2?

Microsoft tools are way overpriced for companies here in China with the result that the government is committed to Open Source.

I think the long term problem in Open Source is that in principle, ANYTHING can be modified without notice at any site.

Let me explain.

You go to a company to do some work. They say they have Java SDK, etc. But some ace has, at this company, MODIFIED let us say the Java compiler source and the company uses the MODIFIED source!

I may be missing something in my ignorance but I saw this happen in the mainframe system VM/CMS which was "open source" in the sense that it was distributed in source form.

The result, however, of the Microsoft overpricing is that a form of what must be called "corruption" and "crony capitalism" operates.

Sure, a developer might feel guilty about leaving a job and not erasing MSDN from his laptop.

But far more significant is the market failure that occurs so often when developers are given MSDN under a huge number of arrangements, some with labels like "academic" when a good faith academic usage IS NOT MADE.

In the USA, you can talk your way into getting the academic price or get your kid, who's at school, to but Visual Studio for your company.

It doesn't feel like theft but it is because the VS developers worked very hard to make the little bits.

I am going to BUY my next release of Visual Studio fair and square in Hong Kong for EIGHT THOUSAND DOLLARS. This sounds worse than it is (hint: exchange rates) but it still sucks.

At the same time, it is a fair and square value-for-value transaction.

What I'm tired of is the cheesy software culture in America in which you're a sap unless you make the best of what Eric Hobsbawm called "the anarchism of the lower middle class".

Furthermore...programmers will suffer from nervous disorders, excess geekiness, substance abuse, spousal desertion, acne and a thousand other ills until they get compensated fair and square through the market for what the create, and the sick "binary opposition" between "bad" writing and "reality" ends. What I mean is chip makers get compensated properly but the best programmers can come up with are xenophobic campaigns against offshoring and lifelong unpaid internships cranking Open Source for free.

Java is well and good, esp. from a purely biz direction. But you also have to consider your time in the TCO of a J2EE setup.
When you start looking at it, you might see that your hourly time spent negotiating the extremely variable J2EE toolset will quickly gobble up the price of a MS setup. At least, that's my take away after spending months learning the vagaries of ANT, Apache/Tomcat, WebLogic, Linux servers, etc. etc. And that's notwithstanding Java as a language/library itself.

Considered just doing the backend on MySQL? Couldn't you do that just as well from ASP.NET, given there's a valid provider?

Although there are many strengths to the J2EE platform, the tools are disparate & hard to learn, and often function in a way that is contrary to the habits of many MS programmers. It's a hard hill to climb.

But I do understand that bottom line....

Hello, Trevor. Great to see you start your blog. This is an interesting topic, and one I've thought a lot about. I can relate directly to your dilemma: I make my living as a Microsoft developer, but my developer.* project runs almost totally on open source non-Microsoft tools and technologies. My hosting account is Linux/Apache, and I make use of a variety of free tools (listed here), many of which are PHP-based. The software into which I am typing this message that runs the Cooperative Digest is an open source content managament system (written in PHP) called Drupal. It is safe to say that much of what you see on the developer.* web site would not exist were it not for the free tools I use, and in particular for the cheap hosting I'm able to get because my provider does not have to pay Microsoft licensing fees.

Changing the subject slightly, have you considered or tried the Eclipse IDE? That appears to be where the mindshare is today in the Java community. It's a really snappy UI, and because of its plugin architecture, there are tons of addons for it.

Since you're running Java (and probably Apache and Tomcat) anyway, I also recommend Rob MacGrogan's SourceJammer source code control tool.

I look forward to hearing how things go with your foray in the world of Java. I wonder, though, whether you will find J2EE to be overkill for what you need. You can do a lot with Java without having to take on the added complexity of J2EE. For example, I was struck recently by comments in Allen Holub's Java Watch column regarding the EJB standard:

Moreover, bad standards are destructive. Just look at created-by-committee junk like EJB and JSF. I personally believe that EJB has been responsible for the failure of more companies than almost any other single technology. EJB is too expensive at every level. The servers themselves, the learning curve, the time required for building and debugging EJB code—all these cost too much either in dollars or effort (which, ultimately, translates to dollars). Nonetheless, companies jumped onto the EJB bandwagon precisely because Sun was pushing it. EJB was the official standard.

This thinking is counterproductive, of course. Companies used EJB even when the technology was absolutely inappropriate, and they often used the technology inappropriately. I’ve seen entirely too many EJB applications that did nothing other than send entity beans around using RMI—probably the world’s least efficient way to access a database. I don’t buy the “if they knew what they were doing, they wouldn’t do that” argument. Well-thought-out technology doesn’t let you hang yourself in this way.

For a small Web app, direct JDBC calls to the database can work just fine (let the database server do the transactioning, failover and connection management). Wrap the JDBC in a “factory” layer, and you have the option of going to something else in the future if you need to. Similarly, messaging is often a much better solution than EJB for interprocess communication. (Message-related beans are a kludge—a desperate attempt on the part of the EJB folks to keep themselves relevant.)

You get the idea. Many bad systems that didn’t need or leverage EJB were built at the cost of many millions of dollars, and many of these systems were so complicated that they never worked at all, much less worked correctly.

That’s the danger of bad standards.

Dan