Yesterday I hinted at how far back my loyalty to the Eclipse Platform goes, as if I was really gun-ho on this relationship. I glossed over warts that bugged me, because I'm a loyal guy.

The truth is, I'm not so excited about this relationship. Not most of the time.

The problem with Eclipse as a Platform is exactly what you would expect from a super powerful, super flexible, open source platform. It is frightfully challenging to maintain a working relationship with, for a small enterprise like my own.

Think Nothing of a Near Full-Time Build Guy

Modularity may be super cool, but re-assembling and deploying a significant number of modules in a working application can be a daunting proposition if you're green at it.

Any kind of serious enterprise app might end up with a near full-time build guy just to keep it all stitched together through release cycles. Not because it should, just because it might.

Hiring or Outsourcing

Hiring or outsourcing to a knowledgeable Eclipse programmer can be a challenge. It's just not that common a skill, and the good ones can be pretty sought after.

Specific Problem Technologies

Some of the coolest technologies within the Eclipse Platform can be the most troublesome. Perhaps p2 is the best example. I'm sure there are lots of people that are excited about p2, and I'm pretty excited too, if I just look at the good things that it is supposed to do.

But p2 is a perfect example of a priesthood gone amuck. Really cool and really smart programmers know how to operate this technology perfectly, I'm sure of that. But they haven't made it very easy on the rest of us. To me, p2 has been a needlessly challenging learning curve with lots of ways to do it wrong along the way.

There are plenty of other super great technologies within the Eclipse Platform, and for every one you plan to use, budget plenty of time and/or resources.

Just How Big Is Eclipse?

55k Java classes in the code base for the HEAD of Helios. That's not a meaningful number in the sense that not everything in HEAD is what you would use, but it still gives a pretty good idea just how overwhelming the codebase can be.

You'd find that a typical Eclipse commercial IDE might consist of over 300 modules, and that doesn't include the nested dependencies within those modules. Ever worked with OSGi before? Don't even ask about the challenges.

Wizard-Based Learning Challenges

Which wizards would you choose to learn from? Guided by which tutorials? How many pathways are there through the wizards? It's all very helpful, but once again, leave plenty of resources for every new piece of technology you wish to master.

Then too, most of the wizards and tutorials are years and years old, so you can't expect too much. Maybe that's the point? Hard to say.

Books and API are plenty helpful too, just so much to keep learning relative to the guidance you will receive.

Not For Sissies

The Eclipse Platform is arguably one of the most capable desktop development platforms in existence, and one of the best designed, too. 

But that doesn't mean it's easy, or without lots of warts, or even that it's something that works for anything less than a large enterprise with plenty of resources.

That's probably why I fell in love with Netbeans Platform this past weekend. Grass sure looks greener. Tomorrow, I'll make my decision on which way my own little shop goes. I've got plenty of good reasons to bolt to the Netbeans Platform, and I'm pretty excited about it. Advice?

update Aug 6, 2010: This article is followed up with these: