Since almost one year I’m involved in Alfresco ECM huge architectures design, and considering my expertise in open source communities, I’m now at the level of being able to give a clear statement on which are the aspects (not in the Alfresco meaning 😉 in which this GREAT product still lacks, especially in terms of open source maturity and scalable community / enterprise application lifecycle support.
My past experiences with open source communities and frameworks like Apache Cocoon , recently released 2.2 version with features like complete springification but most important (to me) the full m10n (mavenization, from Apache Maven), taught me that even the most genius idea, the best architectural pattern or the killer app, will NOT have the desired penetration and adoption (and expected ROI, if you think about enterprise backed open source) if not properly backed by a solid foundation which can (at least) provide the following high level features (among many others which I consider as derivatives):
- Easy inter-component and intra-component reuse gearing best practices
- Centralized and standardized component management and definition
- Fast project startup and (fast if not “hot”) develop-test-commit cycle
When missing these characteristics, even the most customizable and flexible framework (and Alfresco is probably the best I’ve seen until now), will run out of maintainability and clarity of contracts. This is especially true if you think about all the new dynamics which an open source development process involves, e.g. open contributions, a committership process and enterprise licensing models, for which you (open source product company) would really prefer, where possible, a high degree of control or standardization to get the obvious benefits of these dynamics, reducing at minimum engineering review overhead and complicate versioning/merging/branching processes.
A community really opening up is a real valuable thing and I think Alfresco should and could (in compatibility with its resources, but more making its partner network work 🙂 become a mature open source project, in which there’s a committership process, where sources are always available, and with a cleaner single point of contact. I heard nice rumors about great community updates from people who were in San Josè, and I was confirmed in Barcelona of this 3.0 full community restructuring (website and wider process wise).
At the moment though, Alfresco claims to be an Enterprise Content Management platform, targeting mainly to enterprises than to individual/small scoped projects, and that’s especially true for partners which implement on top of the enteprise licensed version rather than on the community (and in many barely “opensource mature” regions, e.g. Italy more than Holland, this really makes the difference to even bigger clients who see opensource=free).
For this intrinsic double nature, I think Alfresco should offer, alongside with its enterprise class code base (that’s more than any enterprise could desire for ECM, especially considering the balance between code ease of understanding and offered features), a “process” around it which can lower the learning curve and provide best practices to enterprise developers and partners. SHARE could be an example, but that’s not about the process or the tool choice, is about the strategy.
That’s where I feel Alfresco (it’s not a critic, we’re talking of quite young product/company) lacks a little bit: having to consult tons of wiki pages, unstructured documentation, having to checkout a whole SDK for building even small things, being tied to manual ant/zip/unzip/deploy procedures is certainly not the best way to integrate within arbitrarily complex environments and to have a broad acceptance and easy support.
And that’s also why I have been putting so much effort in developing and contributing to Alfresco forge something which may give some ideas of what I believe developing with Alfresco should be, i.e. FUN 😉
In the Forge you’ll find out we developed an Apache Maven2 archetype for building extensions, which (by now relying on Sourcesense repositories) allows a developer to run just one command, and have Alfresco automatically downloaded, unpacked, set up for local
running, with a lot of samples inside, deployed, documented, etc. etc. etc. More references about this topic can be found on the forums, as there’s a lot of buzz in the professional enterprise developer community.
Apache Maven2 could also have dependency management and repository centralization for free, instead of building a custom one for the dynamic web framework 3.0 components. But it’s not a technology discussion I want to raise here.
Point is: a clearer standard application lifecycle, lets the developer focus on the GREAT codebase Alfresco has, leaving all the configuration hassle out (which is the first giant step any client has to overcome). If Alfresco defines centrally/gets contributions on the best practices by delivering artifacts, developers always will start up on those, instead of finding their way of working gluing up wiki infos and a complete SDK. And be aware: this may look not in the interest of partners like us, which are mostly called in by clients for solving these issues, but it’s not:
I instead envision us in providing high level architectural advises, process support and best practices, rather than focusing on why a file is not picked up because it’s in the wrong place.
And the important thing here is: this same model applied for the community, can be proficiently used by your partners to provide a more clean and neat impression of what Alfresco is, and to centrally standardize Alfresco development/release/deploy related processes within a company which ATM look, from an enterprise perspective, a bit poor.
In one word I think that this approach can SCALE.
You could manage from simple webscripts to complex alfresco integration builds with the same exact approach, as well as easily produced tailor made distributions of Alfresco (per user/per use case).
Considering Alfresco with 3.0, is moving to a completely component library based web framework, I think that the time to take a deep breath, stop a moment from delivering wonderful new features (as Alfresco usually does), look back, learn some lessons and catch the momentum for settling a proper basis for a huge growth which I see Alfresco can continue to have.
To wrap up, my vision here is:
Alfresco grows so fast, 3.0 will revolution frontend and architectural paradigms (at least a lot of it), finally maturing to target to bigger and bigger enterprises.
Where possible then, I believe this is the time for “freezing” a little bit features development (still 3.0 will offer so many good stuff) while focusing on providing a powerful and fast way of managing new projects with standard tools also at enterprise levels (custom approaches like AMP packaging are wrong to me, it should be JAR, same way as the MMT, which should just be a dependency/build management tool like maven or ant+ivy).
Our open source expertise suggests that sticking to the standards is always a gives a huge added value to the open source project it uses them and Maven2 is a standard de facto. To me, a neater support/set of contracts for development can complement and complete the big work Alfresco is doing in restructuring its opensource delivery model and in delivering outstanding new features every day.