Our efforts as a team are organized around two themes:
- Platform Thinking
- Robust and stable REST APIs
- A consistent architecture of the entire Digital Business Platform, encompassing content and process.
- Cloud Ready Architecture
- It needs to be easier to deploy Alfresco in AWS.
- Our proprietary products will take advantage of advanced AWS features. (P)
Things we have completed this year since the release of Alfresco Content Services 5.2.0:
- Replacing GhostScript with PDFium
- This was driven by GhostScript's license change, but PDFium appears to be performing better.
Unless otherwise noted, all of the below listed efforts are expected to be open source.
- Tooling upgrades:
- Migrating from SVN to Git.
- Splitting the code base into separate projects.
- Replace the CIFS shared network drive
- Microsoft will likely disable SMB1 / CIFS in a future service pack. We have been exploring alternative approaches to meet this use case. See the discussion SMB2 / SMB3 server support.
- We have evaluated supporting SMBv3, which would be a very large effort, but we do not consider it a good fit for content management use cases. A content management system does a lot more than a file server.
- Our current plan is to improve our support for the WebDAV protocol to address many of the concerns listed in that referenced thread and make our implementation more reliable and performant. We believe this will meet most use cases for which people want content management through a shared network drive. The remaining use cases are better met with a dedicated desktop client such as Alfresco Desktop Sync or a partner solution such as Xenit's Fred.
- Product insight from improved monitoring
- We need to better understand how our products are used so that we can invest in the right areas.
- Will replace the web pixel in Community Edition and the Heartbeat in Alfresco Content Services.
- Make it easy for administrators to know what data is being reported, and to opt-out.
- Produce a "Reference Deployment" of Alfresco to demonstrate how it should be used in production
- Based on containers (probably Docker and Kubernetes). See Docker Alfresco Resources?.
- Likely to replace the packaged installers and distribution.zip.
- Additional REST APIs, especially those needed for the Application Development Framework.
- Incorporate feedback on the new APIs
- Architectural changes for our next major upgrade, especially library upgrades (REPO-1283)
- Executable Content Repository: We will "invert the container" so that the application server is embedded within the Content Repository. We would like to support a standard deployment method such as Spring Boot, but we recognize that would be a big change in a single release and would make upgrades difficult. However, we will move toward this model because it simplifies deployment of Alfresco Content Services in a cloud or container environment. This also reduces the number of application servers we need to support. As we move in this direction, we want to better understand what advantages customers get today from running on JBoss, WebSphere, or WebLogic.
- Provide an SSO and API gateway that can be shared across Content and Process Services
- An event queue and APIs for subscribing to topics and queuing asynchronous actions
- Our first use case is for improved reliability in thumbnail generation
- Stand-alone identity server used across Content Services and Process Services
- Rework the SSO stack (including the proprietary components like SAML)
- Replace the embedded Activiti with the stand-alone Activiti
- Allow people to use the Activiti designers for "workflow", and make it easy to upgrade for full "process services"
- This will require re-implementing workflows to use out-of-process Activiti APIs.
- Improved import / export tooling
- A stand-alone administration console that can be used for both Content Services and Process Services
Some high profile projects are dependent on us completing projects already in our backlog:
- Improvements to content modelling (waiting on the planned new admin console)
- Improvements to transformations (waiting on the planned event queue)
- (P) Bi-directional repository synchronization (waiting on the planned event queue): This would be part of our proprietary product, and would replace the current replication and transfer service which would then be removed from Alfresco Community Edition. (See Applying the Open Core Model in Alfresco 5.1.) This implies also replacing the File System Transfer Receiver.
- (P) Reworking multi-tenancy (waiting on the planned identity server): The architectural improvements discussed above would give us the opportunity to improve our implementation of multi-tenancy, which we would tailor to our OEM customers. We plan to remove the multi-tenant capability in Alfresco Community Edition. (See Applying the Open Core Model in Alfresco 5.1.)
Given the above priorities, there are many projects that we are not currently progressing. We list some of them here to answer questions, help people plan, and so that we can collect feedback.
- (P) S3 on-premise replaces the Centera Content Connector: EMC has deprecated the Centera API, and their new ECS line of products supports the S3 API. We plan to support the S3 connector for this use case instead of our current Centera Connector.
- Web Quick Start: WQS provides a sample implementation of building web sites on top of Alfresco Content Services. It is one part of our approach to Web Content Services, which we consider to meet its target use cases and be feature complete. With our current strategy of focusing Alfresco Share as a collaboration-centric interface alongside custom ADF applications for general content management, we are deciding if WQS should be deprecated.
- IMAP: Our IMAP support is widely used and provides a user friendly and industry standard way of archiving specific emails within Alfresco. We would like to replace the current implementation with a new implementation that could be scaled independent of the content repository. The enhanced scalability would be part of our proprietary offering.
- FTP: Our current FTP implementation is reliable, but lacks support for SFTP. We would like to add that support, but not until we have completed the above projects.
- Smart Folders: We have received a lot of feedback on how to improve Smart Folders, and we want to incorporate those improvements. This project is prioritized below the above projects.