This week, WSO2 announced its “Carbon” technology, including a new “business process server.” Some have suggested that we should welcome another BPEL-based BPM server into the market as it demonstrates that the market for standards-based business process servers has grown large enough that new entrants see market-share opportunities.

Maybe another marketing guy might be happy to believe that..but not me. 

Two things bother me. First is the presumption that somehow “open source” solves the cost problem. Because IBM, Oracle and SAP cost millions, open source must be the answer, right?

Wrong. Consider that, in fact, WSO2’s announced pricing for their “BPM server” actually costs more than an ActiveVOS production server over three years. Nobody — and I mean nobody  – can build a business model on “free.”  Software companies have to pay people to survive and support customers. SOA middleware is complex stuff and whether you get a perpetual license and maintenance or open source with “subscription,” you have to pay somehow. The question is how much. And ActiveVOS has the best answer, bar none.

The second problem is the Achilles heel of the SOA and BPM world: the astonishingly misguided belief that customers want to build SOAs from piece parts. C’mon…let’s get past this. Java developers working on BPM want products — not little pieces of carbon-based coal they have to meld together into something resembling a development and deployment environment.

I’ve been at Active Endpoints for a year…and I am still astonished at the disconnect between vendors and customers over this. IBM’s, Oracle’s and, to a lesser extent, SAP’s strategy I understand. They bought and built stuff that was never designed to work together. They have to sell piece parts and make it seem like a virtue. But open source fans have transformed the mistakes of the monoliths into a purported benefit that delivers the same ultimate result: a dumping of middleware product engineering onto the end user developer who never gets to the real BPM application as a result.

What basis do I have to make this claim? It’s not me who says WSO2 Carbon isn’t a product. It’s none other than Paul Fremantle, CTO of WSO2, who blogged that “Carbon isn’t a product.” Q.E.D.

So, in a spirit of fun — and as a public service to BPEL developers who might have open source stars in their eyes — here’s our top 10 list of frustrations with the WSO2 Carbon BPM server that “isn’t a product:”

  1. No worklist support (Why would anyone need a worklist in a business process?)
  2. No clustering (Hey, it’s open source…why not just write it yourself? Clustering ain’t so complicated.)
  3. No reporting (Wanna know things about running business processes? Write it yourself…after you’ve engineered that clustering thing.
  4. No fixing of in-flight processes (Got a process that’s been running for a month and failed because the SMTP server was down? Go straight to BPM Jail, do not collect $200, lose your work and start again.)
  5. Rudimentary monitoring (Need to see what’s happened with a process? Check that log file and use mental gymnastics to match it up with the process definition.)
  6. Hand-editing WSDL’s to specify where the service is hosted (Miss Notepad very much? Haven’t used “localhost” enough? Wanna hard-code the hostname in the WSDL? This piece of Carbon’s for you…)
  7. Installation (Use Eclipse to check out BPEL designer plugins, then build it in one Eclipse workspace. From that workspace, kick off another copy of Eclipse, in a different workspace, that uses those plugins. And if something goes wrong? Rinse, lather, repeat.)
  8. Deployment (Have fun specifying how the services should be deployed by editing WSDL bindings directly. Of course, if you write something that isn’t supported by the engine, it will be valid WSDL…it just won’t deploy.)
  9. BPMN modeling (Have some BPMN that you want to use to get started on that critical BPM app? Translate to BPEL by hand.)
  10. And the number thing you cannot do with the WSO2 Carbon BPM server-that-isn’t-a-product: Include people (People in a business process…feh! Who needs ‘em anyway?)