Concern: Activiti enterprise version diverging from community/open source version

[chuck_irvine]

We are in the process of purchasing the enterprise version of Activiti. To become familiar with Activiti, I've been studying both the community and enterprise products and the community and enterprise documentation sources. I'm starting to suspect that these two products are starting to diverge so much that the are really two separate products, and this is making me uncomfortable. Some examples:

1. I purchased "Activiti in Action" by Tijs Rademakers. I find that it is almost no help in using the Enterprise version. It's orientation is towards developers and developers tools -which is fine, I'm a Java developer. But if you look at the enterprise version of the documentation online, the orientation seems totally different.

2. The enterprise documentation introduces the discussion of workflow, not by describing how to model using BPM notation, but by describing the "Step editor".  Is this a new direction that Alfresco is going with Activiti? If so, I don't think I like it.

3. The enterprise documentation describes two REST APIs, one that is available for both enterprise and community, and another that is only applicable to the enterprise version. The docs seem to imply that the common version is inferior with regard to authentication. If so, since the REST API is so important, shouldn't the problem be addressed in the common code? Why introduce overlapping REST APIs?

There are lots of other examples, I'm afraid.

I'd be very interested in getting the developer community take on this issue. Is there a unifying vision for the open source and enterprise products? Thanks

[jbarrez]

Chuck,

In my humble opinion your opinion is not correct. As I'm developing on both products, let me clarify:

- The orientation of the enterprise docs might be a bit more user oriented, but for example https://docs.alfresco.com/activiti/docs/dev-guide/1.4.0/ is clearly a dev thing.
- Everything that concerns the engine is open source and will always be open source. The engine features are 100% the same.
- Everything about BPMN / custom java logic is in the OSS guide. No need to duplicate that. Everything you learned from the OSS docs is applicable to enterprise (except maybe LDAP integration or the OSS UI's)
- The Step editor is an easy way for people to get started with processes. But our flagship is the BPM modeler for sure.
- The two REST API's are there to make the migration for people being familiar with OSS rest API easy. The enterprise public API is more powerful (eg when it comes to permissions) and one should favour that. However, we have many people coming to us telling that they already wrote significant logic based on the OSS rest api, hence why it is there.

Hope this helps clarifying some bits!

[chuck_irvine]

Hi Joram,

In this case I actually did prefer to be incorrect, except opinion may be too strong a word. More like "sneaking suspicion" is the case. I appreciate your input.

The one difference of opinion may be with regard to the REST APIs. REST APIs are just plain fundamental these days, I think. For us, a comprehensive REST API was and is probably our most stringent requirement.

My view of the ideal community/enterprise split is that the community functionality should be a subset of the enterprise functionality. This allows initial experimental development with the community product and migration to the enterprise product when transitioning to comprehensive production implementations. This, I would venture, is the case for the folks you mention what already have code using the OSS rest APIs. Luckily, we will not face this predicament.

Perhaps Alfresco should consider migrating the enterprise REST api into the core community product.

Again, thanks for sharing your perspective.

[trademak]

Hi Chuck,

With Activiti 6 community and enterprise will be more aligned, and we will migrate some enterprise REST APIs to the core community product. The new Activiti 6 UI is a subset of the enterprise UI and the same will be true for the REST APIs.
I hope this addresses your concerns a bit.

Best regards,

[chuck_irvine]

This sounds excellent, Tijs. Thanks