Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2016 > March
2016

With the recent release of Alfresco Community Edition 201602, and Alfresco One 5.1, the latest version of Alfresco is ready for broad adoption. The 5.1 release has exciting new capabilities that will benefit organizations large and small, and we want to be clear about which capabilities are in which product edition.

 

This lengthy blog post explains how we decided which innovations to open source, and which we reserved for our Alfresco One subscribers. It illustrates how we have been applying the principles laid out by Alfresco founder John Newton when he reiterated Alfresco’s commitment to a strong open source product. By being transparent in our approach to open source, we hope that people who adopt Alfresco Community Edition will have confidence that it will continue to meet their needs.

For those who want to skip the rationale, here are the highlights:

    • The technology for Smart Folders is included in Community Edition and is completely open source.

 

 

 

    • Records Management for Community Edition continues to improve, but we are also creating a proprietary Records Management module for Alfresco One that will contain advanced features tailored to specific use cases.


This post focuses on how we make decisions about differentiation between our open source and proprietary products. There are lots of additional improvements to Alfresco Community Edition and Alfresco One that are beyond the scope of this post. Also beyond the scope of this post are the new features of Activiti and our mobile apps.

Objectives of Alfresco Community Edition


Alfresco Software is a business with ambitious goals for growth and impact. Open source is an important part of our strategy because of the value it provides to customers, how it contributes to adoption of our products, and how it increases our rate of innovation.

We have four specific objectives for Alfresco Community Edition:

    • Be the default ECM solution, increasing ECM competence throughout the industry.

 

    • Foster product innovation as we bring the best contributions back into the product.

 

    • Spread community contributions to benefit all users of the product.

 

    • Be an on-ramp to our paid offerings.


There is a natural tension between some of these objectives. We want broad adoption of Community Edition, which requires a full featured product that everyone wants to use. But in order to continue to invest in innovation, we need to maintain a healthy business which requires us to reserve some value exclusively for our paid offerings. Openness is a core value at Alfresco Software, and we want to be transparent in how we draw this line so that people can participate in our open source community with accurate expectations.

Since Alfresco’s first statement about our open source strategy in 2009, we have been clear that Alfresco One is the product we design for scaled and production environments. But we are also proud that we produce an open source Community Edition product that is not crippled or unstable. Clearly defining the target audience for Community Edition helps us to make product design decisions. We have adopted an “open core” model that is distinctive because we do not limit the “open core” to a library or platform that is only useful to developers. Our “open core” is a collection of ECM use cases that we preserve as open source and which becomes the foundation of our proprietary products.

Defining Alfresco Community Edition


We have identified three use cases for Alfresco Community Edition:

    • Small deployments where the advanced capabilities of Alfresco One Enterprise Edition are not necessary,

 

    • Evaluation of new features and exploration of Alfresco on new projects,

 

    • Companies who want to keep ECM completely in-house, and have the IT expertise committed to expanding, customizing, maintaining , and collaborating around the open source product.


We believe that if we design for the first use case, we will also meet the other use cases while preserving the incentive to convert to our paid products as deployments grow and customers realize value from the platform.

So when evaluating a feature for Alfresco Community Edition, we ask if it meets the following criteria:

    • Important for deployments of less than approximately 100 users,

 

    • Single-server,

 

    • Non-mission critical, since we do not offer formal support,

 

    • Consists of a horizontal capability with broad applicability.


Examples of horizontal capabilities include document management, collaboration, case management, compliance, and business process management

We further reserve functionality for Alfresco One that fits one of these criteria:

    • Proprietary connections and 3rd party plugins. If our product is being used alongside other products that require subscriptions, we should share in the value of the solution. Examples include integration with MSSQL, Oracle DB, Amazon S3, Kofax, and Centera.

 

    • Scalability, high availability, advanced security, and related configuration. These capabilities are important for enterprise use cases running at enterprise scale. Examples include clustering, high performance content transformations, the LDAP configuration assistant, JMX administration, and encryption at rest.

 

    • SaaS products and 3rd party plugins that increase our delivery costs on a per-client basis.

 

    • Specialist applications and niche use cases, such as Contract Management and Media Management.

 

It is important to recognize that none of these criteria are absolute, rather they are intended to guide our thinking around product design. Specifically, we have no intention of limiting the product to 100 users, as we understand that any artificial restriction to an open source product would just be removed. Choosing a specific number helps us in our calculations around pricing and support, and it orients us when discussing features. Our research shows that the overwhelming majority of Alfresco Community Edition deployments are well under 100 users, and those deployments are usually successful with that product. When deployments grow larger, or when an organization can not tolerate even a short disruption to their systems managing content and processes, then the importance of advanced features, expert support, and Certified Partners grows. Of course some smaller deployments will still need to buy Alfresco One to meet their specific needs, and some larger deployments will be inclined to invest the effort to continue with Alfresco Community Edition as the basis of their ECM strategy.

In order to make Alfresco Community Edition be the default content repository in the industry, we need to market it broadly and aggressively. Organizations of all types should see immediate value in Alfresco Community Edition, and be free to evaluate Alfresco One when their use cases grows to the point that they can realize the value in the offering.

Specific Innovations in Alfresco 5.1



The above criteria leads us to include in Alfresco Community Edition features like Smart Folders and Custom Model Management. These are broad capabilities that are important for a wide variety of ECM solutions. We are proud to open source these innovations.

The latest release of Alfresco Community Edition also includes a significant upgrade to our integration with Microsoft Office through the replacement of the implementation of the SharePoint Protocol provided by the VTI module with the newer Alfresco Office Services (AOS) module.  AOS is a complete reimplementation of the latest standard of the protocol, and includes significant testing to ensure interoperability. It will be easier to maintain and improve as Alfresco and Microsoft Office continue to evolve.

Integration with Microsoft Office is important for broad adoption of our product because it is broadly applicable, including in small deployments. But it is also a proprietary integration that we can use as the foundation for advanced niche capabilities targeted at large enterprises. This leads us to include AOS in Alfresco Community Edition as an optional proprietary module so that most users can benefit, but those who want a pure open source platform are not required to use it. For those who want to collaborate around an open source implementation of the SharePoint protocol, the VTI library is still available under the LGPL and we are willing to assist you in your efforts.

The AOS functionality is currently identical between Alfresco Community Edition and Alfresco One. Though the source is not available, AOS is included as a default module in Alfresco Community Edition. This is a change from our previous stance toward ubiquitous proprietary software, but we think it is the right approach in a world of cloud services and bring-your-own-app IT.

A Product Tailored to Its Intended Use Case

The criteria we use to define Alfresco Community Edition might also lead us to remove some features. As an example, in Alfresco 5.0 we deprecated the social publishing framework. It was a proprietary integration and served a niche use case, but we didn’t consider removing it until we were faced with the challenge of keeping these integrations current with the various publishing services. Now it is part of our proprietary Media Management module where the investment in maintenance and development is tied to the specific customers who purchase it.

Similarly, we have discussed whether multi-tenancy or replication really belong in Community Edition, as these are not single server uses cases that are important in small installations. This is a good illustration of how we think about product design, but we don’t currently have plans to remove these capabilities.

In our analysis of Alfresco Community Edition, we did not identify any other existing features that we felt should be removed based on the use cases we are targeting.

The Future of Records Management



Some of the customers of our Records Management module have been asking us for advanced features which are tailored to specific governmental use cases and that don’t apply to smaller deployments. We have decided to make these part of a new Alfresco  Records Management  module that is intended to work on licensed versions of Alfresco One. Specifically, these features are:

    • Security clearance management and property controlled access,

 

    • Management of classified content, including classification guides and declassification review (necessary for the DOD5015.02 certification for classified records),

 

    • Delegation of RM administration, which is useful in the management of very large scale deployments,

 

    • Capstone email compliance, which is an email archiving capability designed to meet the requirements of the U.S. Federal Government,

 

    • Verifiable wipe and data destruction as required by certain national governments.


In order to implement the new security clearance capability, we will deprecate the “supplemental markings” feature, and the related “lists of values” administration screen that were previously part of the open source release. We don’t think this impacts our open source community, as these features were not widely used. We plan to remove them and only maintain our proprietary security clearance capability that takes an entirely different approach to managing security clearance markups. The open source module will also gain a clearer way of managing Transfer Locations.

The next release of the Records Management module for Alfresco Community Edition will be compatible with Alfresco Share 5.1 and the 5.1 Platform. It will contain bug fixes and the improvements to the APIs and core services that are necessary to implement the new Enterprise-only features. As we better understand the use cases around these new features, some aspects of them might move into the Community RM module in future releases.

We will continue to enhance the Records Management module for Alfresco Community Edition, and it will be the core of the Enterprise RM module. We are working to move our RM development to git so that it is easier for you to track our enhancements and easier for you to contribute through pull requests. We are increasingly taking this approach with projects like Activiti, Aikau, and our mobile applications. We plan to incorporate these improved practices into our development for Alfresco Community Edition and Alfresco One.

Closing


We are working to focus Alfresco Community Edition on its target market, while also producing features for advanced use cases that can drive the Alfresco One business necessary for us to continue to invest in our products. As John Newton said in 2009: we aim to be guided by principles that are fair and accountable, as we believe that our model will result in a stronger open source product.

By clarifying the role Alfresco Community Edition plays in our product portfolio, we saw the need to increase our pace of open source innovation. In the six months before the Generally Available (GA) release of Alfresco 5.1, we released Alfresco Community Edition four times. Two of those releases incorporated major new features. We completed more QA testing on Alfresco Community Edition 201602 than for any previous release. And now that the product is out the door, we are excited to start pushing our next round of development to the public source tree.

I look forward to hearing your thoughts and feedback on our efforts, and to working with you in the Alfresco open source community. If you want to continue this conversation in person, join my session at BeeCon. We have many more innovations to share with you in the months and years to come.

by Tristan Bagnall

Following up on my recent post How to have engaging agile reviews[1] I wanted to share the experience of one team here at Alfresco.

I would like to call out a few of the aims from the review:

    • Find out how easy it was to consume the information we presented
    • Get people to play with the changes we had made
    • Start an engaging conversation with the consumers
    • Encourage people to part with their time
    • Listen to the stakeholder feedback, and use it to help us pivot


How did it go? What sort of thing are we developing?

The first piece of information that would be consumed by the stakeholders was the title of the invite, so this was carefully worded as a call to action

'Do you want to guide us on how we are doing with the new REST API?'

Next was the content of the review.

    • We put ourselves in the audience's shoes -
      • we were careful to ensure we had thought through and planned what were were going to show
      • what we were going to ask
    • Our audience was going to be as wide as possible - a few senior managers, plenty of people who would use that part of the product, we socialised the review and got referrals that increased the list.
    • We provided some snack food and booked a big meeting room.
    • In the invite we tried to spark interest, by saying it would be interactive and included instructions on how to get set up for the interactive part of the review.

 

Thinking about our audience, we wanted to

 

    • show them how our APIs  could be used - we settled on a 5 minute demonstration of a UI application currently in development that uses the new API.
    • highlight those APIs that had changed (added, updated, removed),
    • show them how to simulate the usage of the API - we chose to show some scenarios using Postman, but we could have used SOAP UI, SmartBear API tester
    • show them our new API Explorer, based on Swagger UI.
    • let them play in their own isolated environment, and get updates as we supply them - we decided to use a docker image / container
    • provide a Q&A, and gather feedback - we decided to use Skype group chat.


Overall the review went well. Once the play with our APIs started we got some very valuable feedback over Skype.

A few areas we would look to improve on were:

 

Sections of the review:

 

  1. We had a lot to show in the Postman scripts, going through them took a while. Although the questions that were asked during that part showed it was valuable.
  2. People loved being able to play - there and afterwards. This lead to deeper, useful and specific feedback.

 

Tools:

 

  1. Webex - we had difficulty getting it to work on Linux, to the extent that those with Linux were unable to present.
  2. Skype is not a suitable feedback tool, especially at scale as multiple cross conversation are forced into one thread.


Next steps... can we do this with the Alfresco Developer Community?

ohej

Introducing Alfresco SDK 2.2

Posted by ohej Employee Mar 4, 2016

I'm happy to announce that we have just released Alfresco SDK 2.2.

This release brings support for 5.1 as well as a number of bug fixes, you can see the full list here.

There are a few notable changes in SDK 2.2:

    • SDK 2.2 is only compatible with Alfresco 5.1, no support for Alfresco 5.0

 

    • Spring loaded has been disabled by default, as it will currently prevent the repository from starting up

 


Be sure to check out the latest documentation to get up and running.

We will follow up early next week with more in-depth information about the changes above, stay tuned!

As always, we welcome your feedback! Raise an issue on GitHub or catch us on #Alfresco on FreeNode.

Background

The Aikau team is committed to providing weekly backwards compatible releases.

 

It is important to understand that whilst we guarantee that all configuration options for a widget will be honoured in future releases (unless deprecated for removal in the next major release), we will not guarantee that the internal implementation of any given widget will not change. This means that the HTML structure for any given widget could potentially change in any release.

 

This means that you cannot not rely on HTML structure or CSS classes used within a widget for customizing its appearance (the correct approach is to create a theme file that overrides the necessary LESS variables). It also means that any automated tests cannot rely on CSS selectors continuing to work for all future releases.

 

 

Solution

The Records Management (RM) team have recently run into this latter problem with their automated testing and have asked us to resolve the situation. Therefore from version 1.0.57 we have started to externalise the CSS selectors that can be used for automated testing.

 

These are provided in the form of Java ResourceBundle property files that are published as the test resources for the Aikau project. They are Java properties because the RM team are testing using Java based Selenium. However, it is possible to simply unpack the JAR file into your project for Intern JavaScript based testing.

 

We won't simply be providing the test selectors - we will also be updating our own unit tests to use these properties files in our own testing. This means that when we make a change to the struture or CSS classes of a widget we will need to update the associated selectors property file in order to ensure that our own unit tests do not break. This means that it will be safe to rely on these test selectors in your own testing (providing that the version of the Aikau tests JAR used in tests matches the version of the Aikau JAR that is being tested).

 

 

Process

Because the Aikau code base is so large and the Aikau team is so small, it will not be possible to do this in a single sprint. Therefore we will be providing the test selectors on demand. The RM team have provided us an with an initial set to provide and all new tests will be written using externalised selectors - however, full conversion is expected to take a considerable length of time. Therefore if you have a need for specific selectors in your tests then it is recommended that you raise a feature request on JIRA or an issue on GitHub (or better yet - provide the selectors yourself via a pull request!)

 

We will provide one properties file for each Aikau module, each property will have a comment to indicate what it will be used for and in most cases the property will be parametrized so that widget identifiers (and when required indices) can be provided.

 

 

Examples

This is an example excerpt from the alfresco/forms/controls/MultiSelectInput properties file:

# A specific result in the drop-down

nth.result=#{0}_CONTROL_RESULTS .alfresco-forms-controls-MultiSelect__results__result:nth-child({1})

 

This shows an example of a selector that allows you to find a specific result in MultiSelectInput form control drop-down menu. In Java testing you would access that property as follows:

ResourceBundle selectors = 

  ResourceBundle.getBundle('alfresco.forms.controls.MultiSelectInput');

String pattern = selectors.getString('nth-result');

String selector = MessageFormat.format(pattern, 'WIDGET1', '4');

 

In the Aikau unit test framework we are importing the 'properties-reader' package in order to be able to load the properties as follows:

var selectors = propertiesReader('./src/test/resources/test-selectors/alfresco/forms/controls/MultiSelectInput.properties');

var selector = selectors.get('nth-result').replace('{0}','WIDGET1').replace('{1}','4');

 

Summary

Aikau has provided backwards compatible releases for developing future proof Alfresco Share customizations and standalone clients and is now going to be provided a future proof way  of testing those solutions.

Filter Blog

By date: By tag: