Now that the last of the Alfresco Fall meetups has concluded in the US, I thought I’d summarize my takeaways. Overall I thought the events were really good. The informative sessions were well-attended. Everyone I talked to was glad they came and left with multiple useful takeaways.
Everyone has their own criteria for usefulness–for these events my personal set of highlights tend to focus on the roadmap. So here are my top five roadmap takeaways from the Washington, D.C., Atlanta, and LA meetups.
1. Repository unification strategy revealed
Now we know what Alfresco plans to do to resolve the “multiple repository” issue. In a nutshell: Alfresco will add functionality to the DM repository until it is on par with the AVM (See “What are the differences…“). What then? The AVM will continue to be supported, but if I were placing bets, I would not count on further AVM development past that point.
This makes a lot of sense to me. We do a lot of “WCM” for people using the Alfresco DM repository, especially when Alfresco is really being leveraged as a core repository. It also makes sense with Alfresco’s focus on CMIS (see next takeaway) because you can’t get to the AVM through CMIS.
2. CMIS, CMIS, CMIS
Clearly, CMIS is an important standard for Alfresco. (In fact, one small worry I have is that Alfresco seems to need CMIS more than any of the other players behind the standard, but I digress). Alfresco wants to be the go-to CMIS repository and believes that CMIS will be the primary way front-ends interact with rich content repositories. They’ve been on top of things by including early (read “unsupported”) implementations of the draft CMIS specification in both the Community and Enterprise releases, but there a number of other CMIS-related items on the roadmap:
- When the CMIS standard is out of public review, Alfresco will release a “CMIS runtime”. Details are sketchy, but my hunch is that Alfresco might be headed toward a Jackrabbit/Day CRX model where Alfresco’s CMIS runtime would be like a freely-available reference CMIS repository (Alfresco stripped of functionality not required to be CMIS compliant) and the full Alfresco repository would continue as we know it today. All speculation on my part.
- Today deployments are either FSR (Alfresco-to-file system) or ASR (Alfresco AVM to Alfresco AVM). The latter case is used when you have a front-end that queries Alfresco for its content but you want to move that load off of your primary authoring server. In 3.2, the deployment service has gotten more general, so it’s one deployment system with multiple extensible endpoint options (file system, Alfresco AVM, CouchDB, Drupal, etc.). Alfresco will soon add AVM-to-CMIS deployment. That means you can deploy from AVM to the DM repository. Does it mean you can deploy to any CMIS repository? Not sure. If not, that might be a worthwhile extension.
- One drawback to using DM for WCM currently is that there is not a good deployment system to move your content out of DM. It’s basically rsync or roll-your-own. On the roadmap is the ability to deploy from DM instead of AVM. This is one of the features the DM needs to get it functionally equivalent to what you get with the AVM. I wouldn’t expect it until 4.0.
3. Shift in focus to developers
Alfresco WCM has always been a decoupled system. When you install Alfresco WCM you don’t get a working web site out-of-the-box. You have to build it first using whatever technology you want, and then let Alfresco manage it. So, unlike most open source CMS’, it’s never been end-user focused in the sense of, “I’m a non-technical person and I want a web site, so I’m going to install Alfresco WCM”. Don’t expect that to change any time soon. Even Web Studio, which may not ever make it to an Enterprise release, is aimed at making Surf developers productive, not your Marketing team.
Alfresco is realizing that many people discard the Alfresco UI and build something custom, whether for document management, web content management, or some other content-centric use case. To make that easier, Alfresco is going to rollout development tools like Eclipse plug-ins, Maven compatibility, and Spring Roo integration (Uzi’s Spring Roo Screencast, Getting Started with Spring Roo ).
Alfresco has also announced that web scripts, web studio, and the Surf framework will be licensed under Apache and there were allusions to “making Surf part of Spring” or “using Surf as a Tiles replacement”. I haven’t seen or heard much from the Spring folks on this and I noticed these topics were softened between DC and LA, but that could have just been based on who was doing the speaking (see “What do you think of Alfresco’s multi-event approach?“).
Essentially what’s going on here is that Alfresco wants all of your future content-centric apps and even web sites to be “CMIS applications”, and Alfresco believes it can provide the best, most productive development platform for writing CMIS apps.
4. Stuff that may never happen but would be cool if it did
This is a grab bag of things that are being considered for the roadmap, but are far enough out to be uncertain. Regardless of if/when, these are sometimes a useful data point for where the product is headed directionally.
- Native XML support. Right now Alfresco can manage XML files, obviously, but, unlike a native XML database like eXist or MarkLogic, the granularity stops with the file. Presumably, native XML support would allow XML validation, XPath and XQuery expressions running against XML file content, and better XSLT support.
- Apache Solr. I think the goal here is to get better advanced search capability such as support for faceted search, which is something Solr knows how to do.
- Repository sharding. This would be the ability to partition the repository along some (arbitrary?) dimension. Sharding is attractive to people who have very, very large repositories and want to distribute the data load across multiple physical repositories, yet retain the ability to treat the federation as one logical repo.
5. Timeline
Talk to Alfresco if you need this to be precise, but here’s the general idea of the timeline through 4.0 based on the slides I saw:
- 3.2 Enterprise 12/2009
- CMIS 1.0 Release Spring 2010
- 3.3 Enterprise 1H 2010
- 4.0 Enterprise 12/2010 (more likely 2011)
Thanks, Alfresco, and everyone who attended
Lastly, thanks to Nancy Garrity and the rest of the team that put these events together. I enjoyed presenting on Alfresco-Drupal in Atlanta and giving the Alfresco Best Practices talk (Alfresco Content Community login required).
I always enjoy the informal networking that happens at these events. There’s such a diverse group of experience levels, use cases, and businesses–it makes for interesting conversations. And, as usual, thanks to the book and blog readers who approached me. It always makes me happy to hear that something on your project was better for having read something I wrote. It was good meeting you all and I’m looking forward to the next get-together.
Interesting news.
“Repository unification strategy revealed”:
I think you’re probably right about this. It’s a shame about the AVM. I’ve had an awful lot of experience using/programming with it, and despite some issues (to discuss another time) it’s an amazing idea.
I wonder how you can build the concept of ‘layered repositories’ into the DM? It’s a advanced concept of the AVM that allows the isolated editing/submission/rollback of ‘change-sets’. Very useful because of the interconnected nature of WCM content as opposed to traditional DM content – as I’m sure you now.
“Deployment”:
Version 4.0 for an Alfresco-DM-to-FS or an Alfresco-DM-to-AlfrescoDM? Shame – I would have thought it arriving much sooner than that. It’s very much needed.
“Native XML support”:
Oooh – That would be nice. Mind you, granularity doesn’t really have to stop at the file. We use XML meta-data extractors and XPath to copy values from the file-content into object-model properties, upon update. It’s flattened data and generally not a fabulous solution – but it does aid searching…
Thanks for the posting Jeff – interesting as always.
Jeff,
I missed the events that I was so looking forward to… but thanks for the great summary. Roadmap is always important to me, so it was great having this here.
I was just confused by your comment about the Webstudio not making to enterprise, is that a fact? Because that’s one piece that I was really waiting for.. 🙂
Thanks again for taking the time and writing about it.
Hallo Jeff,
I really appreciate most of the directions taken
regarding the evolution of alfresco.
I’m quite involved with web content management,
so the things that make me worry most are
native XML support and web studio. Native XML
support, because it would serve as the
foundation for referential integrity and querying of
(web)form generated content. Web studio as it is
the only authoring environment which is Surf
aware – I hope there is enough interest in it, so it
won’t die.
regards
Andreas
Claudia,
The future of Web Studio is unknown. All we know right now is that Alfresco hasn’t identified an Enterprise release for Web Studio. That’s quite odd when you see Alfresco talking about features 4.0 which is at least a year away. So we don’t know for sure that it will always be a Community project, but I definitely wouldn’t be counting on in any time soon.
In DC, John Newton talked about licensing Web Scripts and Surf under Apache. In Atlanta, I saw Web Studio included in that list for the first time. So maybe their approach will be to treat it as a community-supported development tool. We’ll see.
Jeff
Tom,
One of the things we included in our Best Practices talk was that layering “might not behave as expected” and that it is a feature that’s “best avoided”. It would not surprise me at all if layering didn’t make it into the DM. Again, speculation, but if I am trying to be as future-proof as possible, I think I would try to work around layering if possible.
Jeff
Thanks Jeff.
I actually meant the layering of entire repositories (default behaviour for multi-user contribution) – not on a per-folder basis.
For those that don’t know: New stores are created for each user which transparently point to the staging store, so that they only contain the user’s changes, but they appear to contain everything. Promoting changes enmasse moves the delta from the personal AVM repo (or temp workflow repo) to staging repo, then the personal repo is flattened.
Jeff, do you think the independently edit/reviewed stores, change-lists, previewable stores, revert, roll-forward/roll-back of an entire site can be modelled in the DM? Do you think these features are even important enough to try and replicate in the DM?
BTW: I agree on your best-practice that folder-layering betwen web-projects is best avoided.
Tom
Tom,
Can it be done as the DM currently stands? I don’t think so. Otherwise there wouldn’t have been a reason to create a new store implementation in the first place.
Are the features you mentioned important? I think of the ones you listed, versioning is still important. But if you are building a solution in which you have a completely custom front-end making CMIS (or custom web script) calls to Alfresco, particularly if the front-end itself may not even be managed by Alfresco, I’m not sure Alfresco-provided preview or authoring sandboxes are that useful.
Jeff
Jeff – not sure where to put this and maybe everyone in your world knew, but I didn’t! Mike Alsup
Whitehouse goes Drupal
From Personal Democracy Forum:
WhiteHouse.gov has gone Drupal. After months of planning, says an Obama Administration source, the White House has ditched the proprietary content management system that had been in place since the days of the Bush Administration in favor of the latest version of the open-source Drupal software, as the AP alluded to in its reporting several minutes ago.
This is a pragmatic decision because open source software is more likely to withstand time’s arrows (time’s arrow faces forward but it seems to fire them backwards at us), but it’s also important as a symbol: It is yet another validation of open software’s robustness and capabilities; it says that the White House is of and by the people, just as open software is; it symbolizes the Obama administration’s understanding of tech and its embrace of openness.
I think you’re absolutley right.
These are all advanced back-end team-working editorial features which benefit the content producers, and are no use to the final content consumer (that is, the custom public website).
Thanks again for the blog post.
Just read a couple of your article and thought about asking your opinion.
I just started with Alfresco, and it seems right for my needs for storing documents.
I’m an environmental engineer with some IT background. I’m trying to start a personal wiki related to my professional expertise, but I’m envisioning that it could get more serious, like my company wiki.
I feel like Mediwiki would be the way to go, but then I would like have links in my articles to files in the alfresco repository, as I have a lot of reports, e-books. Also for some articles, I would like to list documents related to the subject, maybe by categories or folders of Alfresco.
Can you suggest me where to move on, my time resources are limited and I’m more eager to populate my wiki then getting expertise in ECM, still I’ll like to get the right solution from the beginning.
I read something about joomla and this integration with cmis. I’m familiar with joomla, but a wiki is really what I,m looking for.
Regards,
Peritico
We used MediaWiki at Optaros for quite some time and it worked well. Our project-centric collaboration leverages Trac which has its own wiki. For a while, as you noted, we just manually put our own links to Alfresco in there and we still do that a lot. We also wrote a little integration between Trac’s wiki and Alfresco to make it easier for people to do things like display links to the contents of a folder in Alfresco from within a wiki page. I’ve never customized MediaWiki so I don’t know what it would take to do something similar, but that might be something to think about.
Alfresco Share is a project- or team-centric collaboration tool that has both a wiki and a document library (as well as other similar features). The wiki isn’t as powerful as a standalone wiki, and it doesn’t yet feature tight integration with the document library like you’re talking about, but it might be something to consider.
At one time there was a MediaWiki integration with Alfresco but I never looked at it. I think it had more to do with running MediaWiki and Alfresco in the same process. For what you are trying to do, I’d avoid that and instead see what MediaWiki’s extension model is. If you can write a little macro or something that knows how to hit an Alfresco web script to retrieve the folder contents, that’s the way to go.
Jeff