CORRECTION: The original version of this post attributed comments to John Knowles. John wasn’t at DevCon. The comments should have been attributed to Mark Heath, VP of Product Development. Also, the ADF announcement was at BeeCon 2016 in Brussels. Sorry for the mistake and thanks to alert readers for the correction.
This week Alfresco held a conference for its developer community in Lisbon, Portugal. Alfresco has been very focused on its new Alfresco Developer Framework (ADF) in terms of both marketing and engineering, and that was reflected in this year’s conference program.
However, there has been a lot of confusion and concern amongst customers and the rest of the community regarding the future of Share, the out-of-the-box web client that ships with Alfresco. In this post, I’m going to focus on why there is confusion, what, if anything, got cleared up during the conference, and speculate on what might happen going forward.
Summary of Customers’ Concerns
Alfresco Share was originally built using a proprietary framework called Surf. It was immediately controversial because even at that time (roughly 2009) there were widely-used frameworks that Alfresco could have chosen to build upon, but didn’t.
Fast forward to BeeCon 2016 in Brussels when Alfresco announced it would build a new framework featuring components based on the popular AngularJS framework. This was a welcome announcement because it painted an appealing vision of a future where a broader community of developers would be able to develop applications using well-known frameworks and established skills. But it also caused concern because, for the seven years prior, customers had been configuring and extending Alfresco Share in a myriad of ways ranging from small tweaks to massive custom applications. With Alfresco building a new developer framework, it seemed unlikely that Share, built on the old, proprietary framework, would have much of a future.
Another concern is about what a customer can expect when they install Alfresco in terms of base functionality. Alfresco Share was created when the company was going after Microsoft SharePoint, so it includes basic document management as well as some light collaboration features. A central question customers have is whether or not Alfresco will eventually replace Alfresco Share with something else, and, if so, will it address the “light collaboration” use case. Until this week Alfresco was largely silent on this point.
What We Learned about the Future of Share at DevCon
During the conference, Richard Esplin, one of Alfresco’s product managers, showed a slide that confirmed what had previously been speculated: Alfresco Share will be deprecated–some day. Most found this unsurprising, but it was the first time Alfresco had made a public statement to that effect.
This was touched upon again by Thomas DeMeo, Alfresco’s VP of Product Management. During the closing Q & A session he answered a question about the future of Share by saying (paraphrasing), “Will there be another Share? No there will not be another Share. But as the ADF continues to evolve we will release more components which could be used to build all kinds of apps”. I think some people heard, “There will be no Share replacement”, but I interpreted this as “There will not be a feature-by-feature port of Alfresco Share to ADF called Share” and my interpretation was confirmed by multiple high-level Alfresco employees, although I did not speak directly to Thomas about this.
What happened next seemed to reinforce the “Share is going away without a replacement” view. Mark Heath, who is VP of Product Development at Alfresco, said something like, “We want to be a platform company. We do not want to develop applications. We want to be the platform and let you guys develop applications.” Again, I am paraphrasing and was unable to find Heath to get a clarification, but discussions with employees indicate that’s pretty clearly how he feels.
So the messaging around the future of Share continues to be a bit of a mess. What we do know is that Share will go away some day, but we don’t know when. It could be years. What we also don’t know is what, if anything, will take its place.
What Might Happen Next
When Alfresco introduced Share, there was already a web client called Explorer. Just like Share, many customers had extended and customized Explorer. To help those clients, Alfresco kept both clients around for a long time until we eventually bid Explorer goodbye. There is no reason to think Alfresco will behave any differently this time around.
I realize Alfresco wants to be a platform company. But that doesn’t mean it can provide only a library of components and a couple of example applications unless it wants to radically alienate its existing customer base and go after a completely different market than it does now. Maybe that will be what happens over many years, but I don’t see it happening abruptly. So there will have to be some sort of Share replacement, even if Thomas doesn’t want to call it that and despite the fact that developing and supporting applications may not be ideal for a platform company.
Can you imagine implementing Alfresco for a customer and then saying, “Okay, everything is installed and working great. But before you can actually use it for anything, you’ll need to use these components to assemble an application that does what you want.” It would be like buying a car, except it only comes as a chassis, an engine, and four tires.
Alfresco points out that they are already providing at least two example applications built with the ADF. Those are helpful for developers, but a short time-to-value demands that a production-ready, supported, configurable, and extensible client be made available to customers out-of-the-box.
I suspect Alfresco will realize this and will ultimately provide it. If the past is prolog, the current “Example Content App” might evolve to be that thing.
If that does not happen, one or more of the following will happen:
- Customers will cling to Alfresco Share for as long as possible and may ultimately delay its deprecation by threatening to not renew their support subscription unless Share support is continued.
- Partners will start developing competing front-ends (funded by their clients). Of course alternative front-ends already exist, but you’ll see this increase, big-time.
- The community might step up and organize around a true open source project that aims to approximate Alfresco Share, either with ADF or with their own components. I floated this idea on Twitter during the conference and it sparked a lot of discussion.
- The Alfresco Share code base could fork. If Alfresco decides to end support for Alfresco Share before customers are ready, which I find highly unlikely, people who need it could carry it forward. A slight variation on this would be if Alfresco volunteered to make Share a community project as they’ve done with other products for which they’ve dropped support.
- Customers could decide to migrate to some other vendor’s product.
There are many customers who don’t use Share at all. I suspect some within Alfresco believe that because many of their biggest clients don’t use Share anyway it wouldn’t be a big deal to sunset it without a replacement. I’m hoping that there’s a stronger contingent that realizes it’s not that simple and that there are a variety of customers using the platform. Alfresco can’t afford to walk away from customers who can’t or don’t want to develop and support their own custom apps for simple document management or light collaboration use cases.
The bottom line is that you should not count on Alfresco Share being around forever. This will take years to unfold, but we should all wrap our heads around that fact now and plan accordingly.
We believe the existing customers should have a choice to continue using Share and would like to hear from any customers who want to move away from Enterprise or want to explore alternatives.
They can continue to utilise their investments in the add-ons and customisations with LXCommunityECM built on top of Alfresco Community edition. (Yes, support for clustering and cloud connectors are available if required).