[OOTB-hive] "Keep SPP IP proprietary"

[Richard Esplin]

The current implementation of AOS is meant to meet the same use case that was met by the VTI module, but work more reliably. This is why there is not much that is currently expected to be excluded from Community Edition. The big Enterprise-only feature in the current proposal is to allow custom content models to be exposed so that metadata can be edited using the properties pane within Microsoft Office. This provides a lot of value in some environments, but I don't believe it is a common enough use case to be considered "core collaboration functionality".

We do not currently have any other improvements to AOS scoped for development, but theoretically there are many other MS Office SharePoint collaboration features that can be added to the module. I think the current features meet the core use case necessary for Community Edition, and so these potential future features would be reserved as a differentiator for Enterprise Edition. Our integrations team is booked through the next release of AlfrescoOne, after which they will evaluate further development of AOS.

I certainly agree that there is a lot of value to the open source community if we release the entire module as open source, but the open source community is not the only stakeholder. <grin> We will be releasing everything for which I can make a convincing business case. It's taken some time to put together a solid proposal, but I think it shows a lot of value for everyone.

As always, thanks for the conversation. And than you for your patience as this has taken far longer then we expected when we discussed it last November.

Richard

On Tuesday, June 16, 2015 05:52:54 Peter Löfgren wrote:
> This is interesting, and I think a step in the right direction.
> What would be the features of Advanced Sharepoint classes that are left out
> access to Community? Reading ALF-21295 I think this has the list what will
> be in Open version, but what is left out? I've never been able to find
> product page on AOS (or any other addon like Transformation server)
> 
> As much as I value the Open Source part of this I do not argue against
> proprietary modules. After all, we have proprietary modules ourself. More
> of a concern is that Community edition users will not be able to purchase
> the full module. Not knowing what features AOS Community/Enterprise will
> have, if I have to choose between a very slimmed downed Community that is
> open source or a AOS full feature proprietary available for purchase for
> all, I may go for the latter. I've argued this for modules/addons with
> Alfresco employees before, but it seems like it is not going to happen.
> 
> I actually had a Community customer wanting to purchase this, but it was
> not an option from Alfresco to offer this for them.
> 
> But best is of course full open source for the entire module :)
> I'll even be happy with slimmed down version, as long as it at minimum
> supports what the SPP module does today.
> 
> Peter
> 
> <richard.esplin at alfresco.com>:
> 
> > Thank you for the feedback, it is very useful.
> >
> > I just want to highlight that ALF-21304 is part of Epic ALF-21295. This is
> > a
> > proposal, and has not yet been approved by management.
> >
> > There were some concerns about my making the issues public, but I
> > considered
> > it important to explain the concerns some members of the team have about
> > open
> > sourcing AOS.
> >
> > One concern with the proposal was that members of the team feared the open
> > source community would not appreciate a closed source module in Community
> > Edition. It is good to know that many of you feel that is a reasonable
> > approach for us to take. I want to make Community Edition as full-featured
> > as
> > possible, even if we are not able to release all of the code. I can see us
> > taking this approach with other add-ons that are currently Enterprise-only.
> > However, I think it is important that any proprietary modules in Community
> > Edition be optional and that the open source product be robust and useful
> > without them.
> >
> > Thank you again for the feedback.
> >
> > Richard
> >