Tag: Deprecation

Future of Alfresco Share Remains Foggy After DevCon

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.

Photo Credit: Mark Gunn, CC by 2.0

You may be surprised at what’s not in Alfresco 5

4325797829_280db25ffe_zIt won’t be long before we’ll be celebrating Alfresco’s tenth birthday. Sniff, sniff, they grow up so fast!

As part of that growth, it’s only natural that certain areas of the product will reach their end-of-life. Since its first release we’ve seen very little pruning of old or obsolete features, but that changes with the Alfresco Community Edition 5.0.b release.

Some of the things that have been dropped won’t surprise anyone. Some I consider regressions and may actually come back quickly, at least I hope they do. The surprises have been handled a little sloppily–Richard Esplin, the current head of community apologized for that earlier this week, essentially saying it was due to the rush to get 5.0.b out in time for Alfresco Summit.

You can read Richard’s post and the release notes for the full list of feature removals. In this post I’ll call out the major items you will no longer find in Alfresco Community Edition as of 5.0.b.

Alfresco Explorer

If you’ve paid any attention to my blog or just about anyone else who speaks or writes about Alfresco you already knew to avoid the original JSF-based web client called “Alfresco Explorer”. It’s the original web client accessible at /alfresco.

Alfresco has been saying Explorer was going away for a long time and they’ve finally done it. If you fire up Alfresco 5.0.b Community Edition and go to /alfresco you’ll find our old friend is no more. Good night, sweet prince!

All of my clients have been focused on Alfresco Share for years so if the impact of the change was simply that you couldn’t log in to that old client any longer it wouldn’t be a big deal, but there has been some collateral damage, which brings us to the next section…

Workflow Console, Tenant Console, or Basically Any Console

Unfortunately, some vital consoles leveraged the same JSF code base as Alfresco Explorer. When that went, these consoles went as well. The old saying about babies and bathwater comes to mind.

The removal of the workflow console is particularly irksome. It’s critical to anyone doing anything with either Activiti or jBPM in Community Edition. In my opinion, this is the most important console of the bunch.

The data dictionary console is also gone, which is used to enable or disable hot-deployed content models. If you only use content models deployed as part of the WAR this won’t affect you.

The tenant console is also gone. This obviously won’t affect you unless you are using the multi-tenancy feature.

The AVM console is also gone, but then again, so is the AVM as I’ll touch on briefly next.

The frustrating thing about these missing consoles is that they aren’t planned to make a return until 5.1, according to Richard. That makes 5.0 Community Edition harder to use than it needs to be. It’s possible that Alfresco will make the console framework available so that the community can help get these back in place quickly.

The AVM

The AVM is the ill-fated Web Content Management offering that Alfresco told you was reaching its End-of-Life back in February of 2012 so, again, you should not be surprised about this one. All but a handful of people have found other WCM solutions.

Lucene

This one sparked a WTF moment on Twitter earlier in the month when I was shocked to realize that 5.0.b Community Edition required Solr to be fully functional. Without it, you can’t do a people search, for example. Actually, you can’t do a full-text search either. So in my book, this makes Solr required to run.

Prior to this change you could choose either Solr or Lucene. I often used Lucene locally because it was one less WAR to deal with and it was the default when doing a manual WAR install. Some people preferred Lucene’s in-transaction indexing over Solr’s asynchronous indexing and eventual consistency.

I understand that Solr is the way forward for Alfresco. It just felt like this one was a bit rushed. I don’t remember any public communication saying that Lucene would no longer be an option in 5.0. The Alfresco Product Support Status page doesn’t list it either. Richard’s post says, “When we added Solr to Alfresco 4, we deprecated Lucene.” That may be true, I’m just not sure Alfresco told anyone, although it is possible I missed it.

SDK, API, & Publishing Features

The release notes for 5.0.b includes a “Feature Removals” section. Noteworthy entries include:

  • The old Java SDK has now been replaced with the Maven-based SDK in Github. This has been a long time coming.
  • The CMIS API endpoints from 3.x and 4.0 have been removed (use the 4.2 URLs). People are constantly using the wrong CMIS service URL for their version. Maybe this will help that.
  • “CML” Web Services SOAP API. Another one that is past-due.
  • JCR / JCR-RMI. I rarely see this used.
  • URL Addressability API. Who needs it when you’ve got web scripts?
  • Social Publishing Features.
  • Blog Publishing Features

These are all positive changes and I suspect will help Alfresco a lot on the engineering and support side.

Future Removals

The release notes also include a note that NFS and jBPM are now officially deprecated. I’ve been expecting the jBPM removal for a while now. If you haven’t started moving everything to Activiti process definitions you should definitely do so now.

Getting the old stuff out of the distribution is great–I’m glad to see it. I hope that going forward Alfresco can do a better job communicating openly in a timely manner about major changes like dropping Lucene. It sounds like Richard is going to take that on as part of his new role in Product Management, which is a very good thing.