Additional Reactions to Activiti

  • May 18, 2010
  • Scott
  • 5 Comments

Well, its only the second day since the Activiti news hit the wire and we have quite a few reactions.  Kudos to Theo Priestley for an unconventional take:

But there’s something else brewing under the surface. Whilst I could have focused on a review based on a powerpoint presentation, Tom’s direction made it pretty clear that he’s throwing down the gauntlet to the likes of Bonitasoft; we’re going with Apache and we’re going to win.

As Theo points out, there has been, lately, less vocal support of open source BPM – Intalio has been a bit quieter, and to the extent anyone is getting press, it is Bonitasoft – while jBPM went largely unnoticed outside of the developer community.

On our call with Tom and the Alfresco team, we specifically asked about the licensing – why Apache instead of LGPL – (honestly, I thought both were reasonably permissive) – and John Newton expressed the point of view that most software vendors were very comfortable with the Apache license, and not as comfortable with LGPL. So they believe more software vendors will be likely to take up Activiti as an embedded solution.

I think it is a good goal to make Activity embeddable.  But I advise them not to lose sight of having a good, complete, solution as well – which I believe is much of the secret sauce behind Bonita’s rise: they’re attempting to solve the whole problem, not just part of it.

ActiveVos takes a harder line view of the Activiti team throwing BPEL under the bus:

Today, Alfresco announced that it had digested the former developers of the jBPM project from JBoss. jBPM had never really made much of an impact as a BPMS because its real purpose in life was to cater to a core Java developer community. Much as hard-core coders might hate it, BPM is about collaboration among an extended development team that includes business users, analysts, developers and operations staff. jBPM was limited to developers and too proprietary to get much traction across the extended development team.

Let me be clear…we’ve got no issue with the jBPM team moving to greener pastures to try and rescue a moribund open source project. We do, however, have a very strong reaction to the transparently re-thought propaganda surrounding their new strategy. It feels like the jBPM architects have something to get off their chest about BPM in general… something they couldn’t get across inside JBoss and they’ve picked what is a rather run-of-the-mill addition of process capability to a document management system to proclaim a completely new metaphor for BPMSs.

Ouch.  I think Alex has a point: that the Activiti team could have made their announcement with no mention of BPEL at all and I don’t think it would have hurt their announcement.  However, I do think that Activiti is prioritizing correctly on BPMN2 first, and other process engine back-ends as lower priority for the core team.  If the project takes off, no doubt someone will contribute hooks to a commercial BPEL engine, or provide an open source implementation project for BPEL. There’s no reason that Tom and his core team have to provide this – at the beginning they’ll have limited resources and they need to focus on the most important bits first.

My biggest concern is how they build momentum around addressing the end-user concerns, starting from such an engineering-focused point.  It can be done – but only if really good APIs form the boundary between the BPM and the UI, and that good projects are started around the UI software that will expose BPM to the masses.

Related Posts
  • November 19, 2018
  • Scott
  • 0 Comments

From the BPM.com discussion forum, a question was asked: "From Emiel Kelly: When a customer orders something,...

  • November 19, 2018
  • Joe
  • 0 Comments

Editors Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse based...

  • November 15, 2018
  • Joe
  • 0 Comments

Editor's Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse base...