Additional Reactions to Activiti

Scott Francis
Next Post
Previous Post
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.
  • Pingback: Tweets that mention Process for the Enterprise » Blog Archive » Additional Reactions to Activiti -- Topsy.com()

  • Also, Alex has a point about embedded BPM: “Of course, we argue the precise opposite: that the problem with embedded workflow is that it's too limited by its container”

    In general I agree with this statement – but partly that is because too often the container application has limited the workflow by using something that is only partly functional, or not providing the interfaces that allow real users to leverage it. I think it is at least possible to have the best of both worlds. Alex gives some good examples of processes using ActiveVOS (and you could use similar examples for other pure-BPM packages) that illustrate how BPM often crosses the boundaries of the container.

  • Complete Solution and Open Source aren't generally compatible. “Complete” is expensive… and it's very difficult to come up with an “Open” model that is funded properly.

    Complete in the BPM space has a very, very high bar to clear, and arguably nobody has quite reached that yet or we wouldn't see all the pure-plays being gobbled up. Complete runs the spectrum from requirements through iterative deployment of process improvements… it's pretty daunting.

    I can envision Complete that is build on top of an Open engine like Tom's – we've seen that work before but it never really happened with jBPM for whatever reason. Better luck this time around.

  • I appreciate the sentiment about Completeness- which is why I used a lowercase “c” :) The definition of Complete with a capital C keeps changing. When I mentioned a complete solution – I refer more to the general sense that a business process problem can be addressed by the product, without having to figure out how to bring 5 or 6 open source projects together to do it.

    And completeness may indeed depend on layering – commercially or otherwise- a layer on top of an open engine. We have, in the past, seen commercial software vendors replace internal engines with opensource alternative engines (Webkit for web browsers for example).

  • Tom Baeyens has a response on his blog to ActiveEndpoints criticism: http://processdevelopments.blogspot.com/2010/05