Optimistic locking is a commonly used concurrency control method for web applications. It is so frequently needed that frameworks such as Grails use it by default. Alfresco FormService does not support it out of the box — and that may cause unexpected results. This post outlines an approach to change the system in order to get something “close to” optimistic locking behavior.

The Default Concurrent Write Situation

Today, I am working on an Alfresco Web Quickstart derived project. A part of the editorial interface is based on Alfresco Share and the editorial process as a whole makes heavy use of the FormService (which is used by the Web Editor as well). I have not used this service extensively in the past, but I was suprised to see that concurrent editing can end up “last writer wins”. A typical sequence of events goes:

• You open the editing form for one item two times — using one browser with two tabs will do. You can just as well use two diffrent users or browser sessions.
• You subsequently save the forms you just opened.
• The second write operation overwrites the changes of the first.

The risk of a conflict depends on the content change frequency, editing process duration and amount of editors working on the content. You may be tempted to address this using versioning, but doing so may open a new can of worms you don’t want. The first thing I thought was that other people should have been faced with this situation before, so I started googling for a solution. I was even more suprised not finding anything really useful and ended up DIY.

I found, that in fact it is quite easy to get a behavior which is not optimistic locking in the very strict sense, but close. Even more important, the system can behave much more expected in the situation of a conflict.

An “Almost” Optimistic Locking Implementation

The following is a rough outline of the solution I came up with (There is a link to the sources below). I have been using it with Alfresco Community 4.0.d.

In the repository, you deploy a filter

<bean id="optimisticLockFormFilter"
      class="OptimisticLockFilter"
      parent="baseFormFilter">
      <property name="nodeService" ref="NodeService" />
      <property name="namespaceService" ref="NamespaceService" />
      <property name="filterRegistry" ref="nodeFilterRegistry" />
</bean>

which hooks into the form processing. This filter is aware of a special field name prefix _olock_, telling it that a field is meant to be used for version checking. I used cm:modified just because it was here and there and ready to go. In beforePersist the filter checks whether fields matching this prefix have been submitted. If that is the case, it compares the values with current persisted ones. It throws an exception if they don’t match.

To make use of it, you use a special form control template in your form configuration:

<field id="cm:modified">
    <control template="olock.ftl"/>
</field>

The control template is derived from hidden.ftl and the important part is

<#if form.mode == "edit" || form.mode == "create">
   <input type="hidden" name="_olock_${field.name}"
          value="<#if field.value?is_number>${fieldValue?c}<#else>${fieldValue?html}</#if>" />
</#if>

With all this in place, the second save operation will (usually) fail showing the following dialog:

Alfresco Share “Optimistic Locking” Failure Dialog

Actually quite funny that Share behaves nice here (with no further customization), presenting us with the failure dialog. :)

Again, this solution may not be beautiful for academic eyes as it is not 100% bullet-proof. Nevertheless, it should handle the real world situation fairly well and it should be almost impossible to create the “accidentally overwritten” situation. In fact, aiming for perfection, I tried making it 100% bullet-proof. At first glance, it seemed LockService provides the functionality needed, but that is not quite the case. What I wanted was “select ... for update” style row level read locking. The code using LockService is still in place and in fact used when the service gets injected.

I still feel like I must have missed something and wonder how other people deal with this situation. To be honest, I think Alfresco should be shipping optimistic locking functionality out of the box. I wonder whether they have something in the making.

Resources:

• Optimistic Locking
• Alfresco Form Developers Guide
• Alfresco Web Editor
• Image Credits

Download Optimistic Locking Alfresco Forms Service Extension

Sobald eine neue Share Site erstellt wird, legt Alfresco eine sitespezifische Gruppe für die jeweilige Site mit vier Untergruppen an.

Die vier Untergruppen dienen hierbei der Zusammenfassung der Mitglieder entsprechend ihrer Rolle als Contributor, Collaborator, Consumer und Manager. Per Defaultverhalten werden diesen Gruppen die gleichnamigen Berechtigungen Contributor, Collaborator, Consumer und Manager zugewiesen.

DEFAULT:
Gruppe: GROUP_SITE_XYZ_Collaborator
–> Berechtigung: SiteCollaborator

Die Benutzung des Administrationstools zur Gruppenverwaltung (Anlegen/Bearbeiten/Löschen von Gruppen sowie Zuweisen von Mitgliedern) obliegt einem Administrator. Der Manager einer Site kann diese vom Administrator vordefinierten Gruppen auf seine Site einladen. Zum Zeitpunkt der Einladung kann der Manager entscheiden, ob dieser Mitglieder der Gruppe zukünftig als Contributor, Collaborator, Consumer oder Manager Zugriff auf die Inhalte haben.

Das Basiswissen zum “out of the box” Berechtigungsmodell vermittelt nachfolgendes Video (kann von Alfresco “Profis” gerne übersprungen werden):

Alfresco Share Basiswissen: sitespezifische Gruppen / Rollen / Berechtigungen und deren Zusammenspiel

Verwaltung individuellen Share Site Gruppen

Der SiteManager einer Share Site soll die Möglichkeit erhalten, individuelle sitespezifische Gruppen anzulegen und zu verwalten.

Im nachfolgendem Diagramm haben wir versucht diese Erweiterung grafisch darzustellen (Vergrößerung per Mausklick):

Das Berechtigungsmodell wurde wie folgt vorgegeben (wobei die Firmen “abc” und “xyz” für beliebig viele Firmen stehen):

• interne Mitarbeiter haben entsprechend ihrer Rolle Zugriff auf alle Projektordner
• externe Mitarbeiter der “Firma xyz” haben ausschließlich Zugriff als Collaborator auf Ordner / Dateien der „Firma xyz”
• externe Mitarbeiter der “Firma abc” haben ausschließlich Zugriff als Collaborator auf Ordner / Dateien „Firma abc”
• externe Mitarbeiter der Firmen “xyz” und “abc” können Ordner / Dokumente der internen Mitarbeiter und der jeweils anderen externen Firmen nicht sehen

In einem früheren Beitrag haben wir bereits einen Prototypen zur Verwaltung von Berechtigungen für einzelne Benutzer vorgestellt. Diese Erweiterung wurde nun entsprechend der oben genannten Anforderungen auf Gruppen ausgeweitet. Zusätzlich wurde der Menüpunkt “Gruppen” unterhalb der Mitgliederverwaltung (Funktionalität für Manager einer Site) durch die neue Funktionalität Gruppen– / Mitgliederverwaltung ersetzt. Natürlich kann man die neue Funktionalität auch ergänzend implementieren.

Unser nachfolgendes Video beschreibt diese Erweiterung an einem Prototypen:

Alfresco is a very flexible content-platform in general. It provides mechanisms to customize almost every component (Spring-Bean, Webscript, Templates) shipped with the core product.

Still, sometimes the technical solution does not prove to be even close to what the developer had in mind. This post is about a recent personal challenge and the journey to the solution in an Alfresco Share customization project targeting version 3.4.

Business Requirements

The project consisted of various stories. One was about customization of the Share invitation email with the following requirements:

• As a Site-Manager, we want an optional personal message to be included in the invitation-email.
• As a Site-Manager, we want to receive invitee read-receipts for invitation-emails
• As a Site-Manager, we want the company logo to appear in the invitation email.

The customer was fairly pragmatic — requirements implemented quickly and decently priced being far more important than educational value of the code. Hence, it was ok to apply these customizations on a global level - to all share sites with no further scoping. That all sounded reasonably to me and I was confident to get it implemented “properly”.

The project was of type fixed-scope and fixed-price. A No-Go due to Heisenberg’s uncertainty principle — sure, but there was no way around.

Now, if you are an Alfresco developer reading this, please take a minute virtually outlining your solution and make a rough effort estimation before proceeding with solution journey on the next page. But even if you have no clue what Alfresco is, it might be worth reading further.

Andreas & Sandra

ORM = Unter Online-Reputationsmanagement wird die Überwachung und Beeinflussung des Rufs einer Person, einer Organisation oder eines Produkts in digitalen Medien verstanden. (Wikipedia)

In den letzten Wochen haben wir uns intensiv mit unserem eigenen Webauftritt auseinander gesetzt. Wir wollten unser Tätigkeitsfeld für „Nicht IT‘ler“ verständlicher kommunizieren, denn nicht selten haben wir uns anhören müssen, dass Freunde und Bekannte an Hand unserer Website nicht verstanden, was wir beruflich machen. Das sollte sich ändern.

Wir möchten bei unseren Kunden kostengünstige, leicht verständliche, einfach bedienbare und schnell erweiterbare webbasierte Dokumentenverwaltungs– / Kollaborationssysteme einsetzen. Bei unseren Webprojekten steht ein flexibler und schlanker (agil) Softwareentwicklungsprozess im Vordergrund. Gemeinsam mit unseren Kunden fokussieren wir uns auf die zu erreichenden Ziele und möchten mit geringem bürokratischen Aufwand Projekt erfolgreich abschließen.

Mit unser bisheriger Webauftritt konnten wir dieses offensichtlich nicht vermitteln.

Maßnahmen an unserer Website

• Umstrukturierung der Inhalte, aktuelle Beiträge auf der Startseite.
• „Technologie“ und „Wir über uns“ wurde unter dem Punkt „Sie benötigen Unterstützung?“ zusammengefasst und durch die Verwendung von Mindmaps (hoffentlich) „leicht verdaulicher“ gemacht.
• Unter „Projekte“ haben wir eine chronologische Übersicht (auf Basis des WordPress Plugins Timeline) umgesetzt.
• Unser „altes“ WordPress Theme „Oracle“ von ThemeTrust durch ein Freies WordPress Child Theme für Twenty Eleven: Paper (HTML5 / CSS3) ersetzt und durch CSS Anpassungen an unser CD angeglichen.

Das verwendete Theme spiegelt für uns den handwerklichen Teil unserer Arbeit wieder. Wir beginnen bei vielen unserer Projekt mit einem Papier und Bleistift Konzept. Es werden Diagramme gezeichnet, Abläufe skizziert usw. .

Das Child Theme (verantwortlich für das Grundlayout der Website) wird von WP Charity kostenlos zur Verfügung gestellt und kann durch eine Spende an weltweite Hilfsprojekte freiwillig unterstützt werden. Also eine gute Sache!

Durch den Einsatz eines Child Themes auf der Basis von Twenty Eleven sind wir von Weiterentwicklungen durch WordPress am „Eltern“ Theme nicht ausgeschlossen und somit zukunftssicher (soweit man das in unserer Branche sagen kann).

Im letzten Jahr haben wir einige Kundenprojekte unter Verwendung von WordPress kostengünstig umgesetzt und sind von den unzähligen Möglichkeiten der individuellen kundenspezifischen Anpassungen begeistert. Zwei Website Beispiele (neben unserem Auftritt) sind die Sites Saselmädchen und Ingenieurkonzepte.

Ob wir mit den beschriebenen Maßnahmen das Ziel erreicht haben .… wir hoffen es ;)

Quellen:

• WP Charity Child Theme Paper
• Wikipedia Online Reputation
• Saselmädchen
• Ingenieurkonzepte

Sometimes you need to know where an application is spending time and how long things take to finish.

In situations with sources at hand, you may have applied the intuitive straight forward approach wrapping doHeavyLifting() calls in System.currentTimeMillis() to compute the duration. The obvious drawback is the fact that instrumentation code is mixed in code doing what needs to be done. The encapsulation concern can of course be addressed using AOP.

Another less obvious disadvantage is the fact that you need sources and a compiler to get the instrumentation code into the application.

Spring Instrumentation without Source and Compiler

Today, all a lot of java based applications are built on top of Spring dependency injection. A few months ago me and a colleague were faced with the challenge to analyze an application showing massive performance problems. We did not have the source code, but we were at least lucky with the fact, that this application was built with Spring. This provided us with possibilities to drop-in Spring bean definitions like org.springframework.jmx.support.MBeanServerFactoryBean and
org.hibernate.jmx.StatisticsService allowing us to export instrumentation data for analysis.

A few weeks ago, another colleague was wondering about Alfresco performance. I was immediately asking myself whether an approach similiar to the one taken before could be applied to gather Alfresco performance data. Sure, the situation was a little different in that we have Alfresco sources, but I wanted a more clean solution without touching sources.

Proof of Concept with Alfresco

Even though I had no concrete performance problem with Alfresco, I wanted to find out how far I’d get. Looking at all the *-context.xml files, I felt Alfresco must be the ultimate Spring application on the planet. My out of-the-box installation has roughly 2000 Spring bean definitions with nested application contexts and seems to use each and every feature Spring has to offer.

First I got hurt learning that using the aop namespace in Alfresco Spring beans xml yields all kind of weird errors. Fortunately, the good old bean elements proved to provide the features I needed and work just fine. The basic proof of concept was successful — interceptors, advisors and pointcuts et al. did what I wanted them to do without touching Alfresco code.

Next steps

As the basic building blocks were working. The bean definitions looked like the following code:

<bean id="methodNamePointcut"
      class="org.springframework.aop.support.NameMatchMethodPointcut">
 <property name="mappedNames">
   <list>
<!--
public ResultSet executeQuery(SearchParameters searchParameters, String language)
-->
    <value>executeQuery</value>
   </list>
 </property>
</bean>

<bean id="profileAdvice"
      class="de.contentreich.instrumentation.ProfileMethodInterceptor" />

<bean id="profilingAdvisor"
      class="org.springframework.aop.support.DefaultPointcutAdvisor">
 <property name="pointcut" ref="methodNamePointcut" />
 <property name="advice" ref="profileAdvice" />
</bean>

<bean id="profilingAutoProxyCreator"
      class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
 <property name="proxyTargetClass" value="true" />
 <property name="beanNames">
  <list>
<!-- id=solr, id=lucene - core-services-context.xml -->
<!--
classpath*:alfresco/extension/subsystems/Search/solr/solr/*-context.xml
-->
   <value>search.solrQueryHTTPCLient</value>
 </list>
 </property>
 <property name="interceptorNames">
  <list>
    <value>profilingAdvisor</value>
  </list>
 </property>
</bean>

Questings now coming up where

• What (objects/methods) is actually available for instrumentation ?
• How do I get decent presentation of the data quickly ?
• What is a decent foundation to build performance gathering upon ?

To address the first question, I built a webscript to browse the (nested) Spring contexts and their beans including method signatures.

Regarding the second and third question, I found perf4j addressing them fairly well. As the Servlet shipping with perf4j does not really fit in the Alfresco repository context, I wrote a replacement webscript to get the graphical view of the gathered data. Perf4j is based on log4j and out-of-the box, Alfresco does not support log4j.xml files needed (due to AppenderAttachables). Hence, I extended Log4JHierarchyInit to implement the support for XML based syntax. The final challenge left with perf4js was the fact that AgnosticTimingAspect is based on annotation code, so I wrote an alternative working without.

One special “pointcut” with Alfresco are the webscripts it hosts. I implemented a special path based pointcut (DynamicMethodMatcherPointcut) allowing me to match and instrument them. Yes, I know AbstractWebScript already has timing code, but I wanted graphs. ;)

Below are screenshots showing beans, bean signature and a simple graph displaying execution times of a few solr webscript.

Source can be found at github and there is also a tarball with the binary amp file ready to deploy and sample extension code which should be dropped in tomcats shared/classes folder.

Finally I’d like to emphasize that the basic injection code is not dependent on Alfresco at all. It should work in just about any Spring based application.

Resources:

• Perf4J
• Spring AOP
• Alfresco Repository Architecture
• Source @ Github

Download Alfresco Instrumentation Repository Extension

In my post Alfresco Community Bugfixing I stated

I wish we (as the com­mu­nity) had some­thing — a sys­tem and/or process to sup­port our bug­fix­ing needs. A place to exchange com­mu­nity release (bug­fix) patches.

Alfresco Community Manager Jeff Potts and me agreed that the root “prob­lem” are two fla­vors (Community and Enterprise) of core alfresco code and the fact that com­mu­nity con­trib­u­tors have no easy way to “com­mit and share”.

Meanwhile I’ve been experimenting a bit, and I think the outcome is ready to try out for people feeling comfortable working with sources. The solution introduced here is based on git(hub) and git-svn. The latter is only required if you want to deal with subversion HEAD source from the official Alfresco Community repository as well.

The whole setup may also work for other Open Source projects where there is only a community read-only repo available. Due to the possibilities it introduces, git(-svn) may even prove to be helpful in the case where all you have is an ordinary svn repo. I for one am moving entirely to git —  wrapping svn where needed.

Subscribing to Bugfixes

At this time, the git repository has three branches (3.4.c-fixes, 3.4.d-fixes and 4.0.a-fixes) and three tags (3.4.c, 3.4.d and 4.0.a). As the names suggest, the tags correspond to the svn release revisions (r24514, r25020, r30857) and the respective branches are for bugfix maintaince only.

If you are just interested in subscribing to bugfix-only sources, all you need to do to hook up is

git clone git@github.com:deas/alfresco.git

To obtain the latest version of a certain branch, execute the following

cd alfresco
git checkout 4.0.a-fixes
git pull

Incorporating Official Subversion HEAD

If you want the latest source from the official subversion repository as well, you can link it in like so:

cd alfresco
git checkout 4.0.a
git svn init http://svn.alfresco.com/repos/alfresco-open-mirror \
 -T alfresco/HEAD
git update-ref refs/remotes/trunk 4.0.a
git svn fetch
git checkout -b svn-head
git svn rebase

Now, you are on a new (local only, up to date) branch svn-head. You may see a few warnings Couldn't find revmap ..., but those are not a real problems.

Cherry-Picking Bugfixes

Not everybody can or wants to work through code (possibly with a debugger) to fix a bug. Sometimes you don’t have to. ALF-10840 is an example. Well in fact I worked through the code fixing it myself in this case, but this example still shows how to fix a bug in the sources without actual coding. :)

This is what worked here:

git checkout svn-head
git svn rebase
git log

There, you’ll find commit 534ab26f191bb3fbef8bc0b05d5f13911112f106 mentioning “Fix for ALF-10840″. If you know the svn rev, you can just as well run

git svn find-rev r31335

to find out the corresponding git commit-id.

With the commit-id at hand, you can cherry-pick the bugfix into the 4.0.a-fixes branch.

git checkout 4.0.a-fixes
git cherry-pick 534ab26f191bb3fbef8bc0b05d5f13911112f106

Done — sources are now ready for compilation with the bugfix rolled in.

Final Words

Of course sometimes you won’t find a fix in svn HEAD and you have to do the heavy lifting yourself. Things may also get a bit messy when you want to introduce official fixes in sources you have already touched. Still, it should not be too hard — git revert ... and interactive rebasing are your friends.

I am in no way the official bugfix maintainer for Alfresco Community releases and I won’t be tracking Alfresco JIRA for fixes in general. For the time being, I will only be fixing bugs that affect me.

But I would definitely appreciate people joining a collaborative bugfix approach as that may save us all some time and give us better software. Just drop me a line if you’d like to be added as a contributor (repo write access).

Update Okt 27, 2011:
Tags and branches have been updated to 4.0.b.

Resources:

• Alfresco Community Bugfixing
• Alfresco Community Bugfix Repository @ github
• git-svn-tutorial

Waiting time during build and deployment phases of the code-build-deploy-test cycle can really be an annoying part of development. The amount of time “wasted” depends on various project “ingredients” — environment, experience, programming language, application bootstrap and system resources to name a few. The fact that PHP, Rails (and others) eliminate and/or keep these times at a minimum is a key factor of their success.

Long build/deployment times also have consequences. As a developer, you think twice whether you’ll “try out” something or not. But trying things out and exploring is important to get it right and gain experience.

Most Java based applications have a habit of making the developer wait. Today we have various approaches cutting this time on the JVM. JRebel is one, dynamic languages are another.

REPLs help exploring — and exploring is important

REPLs (Read-Eval-Print-Loops) are a beautiful tool to quickly explore and understand — very important as things tend to get more and more complex. On the JVM, most of the popular (dynamic) languages — Groovy, Ruby, Javascript, Scala and Clojure ship at least a console based one.

In order to explore your application you have to either bootstrap it within the REPL environment or embed the REPL in the JVM and provide it with access to your application. Grails supports this approach in general with its Shell and Console. Even though you can access and explore your bootstrapped application, it is not running within an appserver so you cannot use it with a browser.

REPL exploration approach has broad scope

Roughly a year ago, inspired by the Grails tools and the idea of embedding a Groovy REPL in an App-Server I was wondering if a similiar helpful solution could be quickly implemented for the Alfresco Repository.  I had a few tweets going back and forth with Peter Monks and a few others and started off using Groovy at that time. Altough it was working, the “quick shot solution” did not really prove to be useful. The main reason was that code was still too verbose. It then became clear to me what Peter had in mind talking about a CMS-DSL. Besides, Alfresco has special challenges like transaction and security to tackle. (Other) Alfresco centric approaches like the ones implemented by Peter and Florian Maul  (Javascript Console) avoid these by not keeping state on the server and wrapping code in a transaction.

So the overall story was a bit broader in scope than I realized at first glance a year ago. The idea of an embedded REPL can be applied in various dynamic languages, and there may be application dependent special challenges.

Alfresco implementation

Driven by demand to get something useful working for the Alfresco scenario, I started all over with Javascript (rhino) instead of Groovy (Alfresco ships with a proven Javascript environment) — keeping in mind that the REPL idea is far more general.

I remixed ideas (and code ;) from various sources in a quick hack solution to get something usable quickly.  The outcome Alfresco application is a telnet based Javascript REPL similiar to org.mozilla.javascript.tools.shell.Main with additional functions setUser, unsetUser, whoami, withTx and the usual Alfresco Javascript objects initialized.

Example Code:

// User guest is default otherwise
setUser('admin');
// Works w/o TX
for each (var f in companyhome.children) { print(f.name); }

// Needs TX
withTx(function() {
  companyhome.createFile("shell.txt").content = "Hallo World !";
});
// Restore default user guest
unsetUser();
whoami(); // guest

Below, you can find links to the source of the general Spring based REPL embedding code, the Alfresco extension (source and binary amp ready for deployment). At this time, the only “ready to use” application code is the Alfresco repository extension. But it should not be too hard hacking the code to implement a REPL based on another language (most ship a console application) or UI (in case you want to control the “security hole” it exposes at runtime — i.e. in a production system :).

The repository extension code should work with all community versions from 3.4 up to 4.0.a. Please remember that it is a quick hack so far. It works for me, but it may eat your system.

To try out the repository extension:

• Deploy alfresco-scripting-tools-1.0.amp
• Go to http://localhost:8080/alfresco/service/api/javascript/service and enable it
• telnet localhost 6790
• Type help(); and try some Javascript

I have a lot of potential ideas what to implement next with a Groovy based DSL on the very top of that list. But before going further, practice has to prove that I really eat my own dogfood. :)

I would appreciate if you drop me a line in case you find this useful.

Resources:

• Alfresco and Groovy, Baby!
• Alfresco Javascript Console
• Grails Command Line Tools
• Embedding a Groovy Console in a Java Server Application
• Github Scripting Tools Repository
• Github Alfresco Scripting Tools Repository

Download Alfresco Scripting Tools Repository Extension

All non trivial software has bugs — that’s just the ways it is. Alfresco is no exception — neither Enterprise nor Community edition. The major difference between these two versions is that you pay a subscription which provides support in case you run into “some kind of trouble” with the Enterprise product — bugs being a special case. We once bumped into a CMIS-QL problem with the Enterprise edition and Alfresco support provided us with a patch quite quickly. I have not checked whether this fix has has found its way into the Community edition.

Enterprise edition and the new Alfresco Team product may not be “the right” choice either for cost or other reasons. I fully understand that providing product support boils down to cost and hence, restricting flexibility of a product (Alfresco Team) is one approach to cut effort.

Anyways, I am sure there is still a significant amount of “brave” people (like us ;) running Alfresco Community in production.

What do we do, when we get affected by a production critical bug (happened to us more than once) ?

Alfresco and certified partners don’t help, now what ?

When I found ourselves in this situation, I usually googled and worked my way through the forums and JIRA picking up hints on the way. I cannot remember a single case where we have found a patch “ready to apply” against an official release, so usually, we had to fix the release code revision (as in svn) ourselves (the hints picked up during investigation more or less helpful). A few weeks ago it was ALF-2880 (patch against 3.4c below) and ALF-6182.

I wish we (as the community) had something — a system and/or process to support our bugfixing needs. A place to exchange community release (bugfix) patches. Google Code, github, sourceforge all work fine for extensions, but they don’t work well for “core changes”. Of course we could (technically) just attach patches to the JIRA issues, but I’m not sure whether that is fine with Alfresco people.

Anyone else feeling the need for better bugfix support in Alfresco Community ?

PS: We have been asked quite a few times what exactly is covered by Enterprise support subscription and how to handle the support situation when Community edition is used.

Update 04.08.2011

Alfresco JIRA ALF project description states:

Global project for Alfresco development — for Community issues,

Maybe I get something wrong, but I don’t quite understand why ALF-2880 (as an example) gets updated to

Resolution: Fixed
Fix Version/s: 3.3.5, 3.4.0 Enterprise

Download ALF-2880 3.4c Community Fix

Die Ereignisse der letzten Zeit, insbesondere die der letzten Tage scheinen im Alfresco Umfeld für Verwirrung gesorgt zu haben:

Das immer wieder genannte Commitment zu OpenSource, der neue Community Manager Jeff Potts, die Keynote von John Newton, die Jive Partnerschaft — Alfresco setzt auf Social im weitesten Sinne.

Am 17.06.2010 betont Alfresco Community Manager Jeff Potts die Bedeutung der Community in seinem Post With Commercial Open Source, Innovation Happens Everywhere auf socialcontent.com, am 20.06 launcht Alfresco ihr neues Produkt Alfresco Team. Überrascht also versuche ich zu verstehen wie Team ins Bild passt.

Ok, dass es Alfresco Bedarf jenseits des Enterprise Preissegmentes gibt war klar. Absolut in Ordnung, dass Alfresco selbst einen Teil des Kuchen abhaben will. Die Idee ist nun ein relativ starres Collaboration-Produkt (mit wirklich tollen Features !) für einen kleinen Preis anzubieten. Natürlich, schränkt man die Flexibilität ein, laufen intern weniger Support-Aufwände auf, s.d. man günstiger anbieten kann.

Wie aber stellt sich die Situation anderen Parteien dar ?

Aus Kundensicht

Der Einstieg in Alfresco Collaboration wird mit Team sehr einfach: Runterladen, interaktiven Installer laufen lassen, ein bisschen mit Browser konfigurieren — fertig. In einem kleinen Rahmen kann man nun ein tolles qualitätsgesichertes Produkt sogar kostenlos nutzen. Braucht man Support oder mehr User sind die Kosten überschaubar.

Was aber macht man, wenn man nicht erlaubte Änderungen braucht ?
Im Grunde gibt es hier zwei Wege:

1. Upgrade auf Enterprise
2. Migration auf Community

Der erste Weg ist wegen der damit verbundenen Kosten für das eine oder oder andere Unternehmen vielleicht nicht möglich. Im zweiten Szenario gibt man mindestens den Support auf.

Was also tun ?

Aus Community Sicht

In Alfresco launches Team for Departments and SMBs sagt Jeff Potts unter anderem, das Quellen der Neuerungen (und der  IOS Applikationen) Open Source sein werden und in die nächsten Community und Enterprise Releases eingehen werden. Trotzdem ist mir persönlich unverständlich warum das Produkt und der Code auf diese Art und Weise urplötzlich der “Welt” vorgestellt werden.

Speziell unter dem Gesichtspunkt “Community als Innovationsmotor” passt Alfresco Team bei mir nicht ins Bild. Im Loftux Blog sieht man Gedanken von anderen Leuten die offensichtlich Schwierigkeiten haben das Vorgehen von Alfresco nachzuvollziehen.

PS: Überhaupt haben ich persönlich als Teil der Community manchmal das Problem zu verstehen, wie Alfresco sich seine Community-Mitglieder wünscht. Wenn man sich z.B. Gruppen in Business-Netzwerken wie xing oder linkedin anschaut kann man fast das Gefühl bekommen das Alfresco Mitarbeiter dort grundsätzlich nicht auf Fragen eingehen — im Gegensatz zu Plattformen die Alfresco gehören (wie z.B. im Forum). Missverständnisse jedenfalls bauen am Ende kein Vertrauen auf (Social Web !) .

Aus Partner/Dienstleister Sicht

Wegen der erheblich eingeschränkten Möglichkeiten der Anpassung (Kerngeschäft vieler Dienstleister !) sehe ich für uns und unsere Kunden nicht, wie wir die supportete Variante sinnvoll einsetzen können. Außer vielleicht jetzt ganz aktuell um mal kurz (mit einem stabilen Stand) zu “spielen” und zu sehen was an Funktionalität in Community — und Enterprise Edition kommt. Selbst wenn ein Kunde nach einem Test mit dem Produkt “out of the box” wunschlos glücklich ist hätte ich ein Problem mit gutem Gefühl anzubieten — es sei denn allen Beteiligten ist zu 100% klar wie man verfährt, wenn Anpassungen erforderlich werden die bei Team nicht “erlaubt” sind.

Ich bin wirklich sehr gespannt wie sich dieses Produkt am Markt behaupten wird.