2 de Abril, 2009

Desechando Alfresco como gestor documental

Depués de un tiempo valorando Alfresco para gestionar la documentación de la empresa; algo que no era urgente (pero sí importante), ha pasado a ser urgente, y ya sabemos que de ahí a un dolor de cabeza hay poco :(.

Tras la experiencia, la impresión que me da Alfresco es negativa:

  • Es muy pesado. Por defecto tarda mucho en arrancar (¡incluso sin documentos!), y es complicado hacer que arranque/pare sin problemas. Da igual que leas las trazas de error, es más que probable que nunca sepas qué está pasando.
  • La documentacuión de la versión community es mala, y en muchos casos anticuada o errónea.
  • Si se te ocurre mirar los scripts de arranque/parada que vienen para Linux (como alfresco.sh), probablemente decidas que no es buena idea que tu empresa dependa de algo programado así (feo, muy feo).
  • Es un producto Open Source de muy poca calidad. Parece que las versiones community son sin certificar (¿aforismo de pre-beta?), sin actualizaciones de correcciones de fallos, y sin soporte de ningún tipo: si algo no va, espera a la siguiente versión y, con suerte, actualiza.

Podrían cuidar mucho más esta versión, si es que quieren vender alguna licencia de su propuesta de pago. Estoy acostumbrado a trabajar con Open Source de mucha calidad, y visto lo visto, creo que no pagaría por el soporte ni la versión de pago (igual es un producto completamete diferente), aunque hay cierta inercia en el mercado hacia Alfresco.

Nuestro requerimiento era trabajar directamente sobre los ficheros, minimizando el uso de la web, y hemos probado en profundidad varias posibilidades que nos da la aplicación:

  • CIFS: desde el interfaz con fuse que trae Gnome en 2.24.1 va lento, con cuelgues de las aplicacicones (OpenOffice.org ahí no es usable). Se le podría atribuir a fuse, pero con smbfs pasa parecido (aunque es más estable).

    La copia masiva de ficheros, un desastre. Lento y con cuelgues del cliente.

    Otro tema es que Alfresco crea unos ficheros ficticios en cada directorio, para uso interno, y causan problemas al borrar dichos directorios. Igual es cosa del cliente Linux.

  • WebDAV: no hemos encontrado un cliente lo suficientemente transparente par atrabajar sobre los ficheros directamente. Probamos con davfs2, pero creemos que no está preparado para este uso (hay que deshabilitar los locks en el servidor para que funcione algo, y luego es de inestable como CIFS).
  • FTP: las escrituras van (casi) perfectamente, pero hemos tenido problemas con los borrados (nuevamente los ficheros ficticios). Ni hablar de trabajar directamente sobre el contenido, las aplicaciones no lo soportan.

Al final hemos concluído que el producto no se ajusta a nuestras necesidades, aunque la autenticación LDAP si la implementaba perfectamente y, en general, la web funciona obviando lo que cuesta que el Tomcat que trae... arranque y se pare en condiciones.

Hemos quedado bastante decepcionados, porque tenemos conocimiento de varios casos de éxito de gente trabajando con clientes Windows sin problemas (sobretodo con WebDAV). Además creo que eran esos casos de éxito los que nos habían formado una imagen equivocada del producto.

La verdad es que mirando las cosas con perspectiva, la elección de Alresco como proyecto Open Source no pasaría los controles que precisamente yo explico en mis clases en la EPSE de Valencia :(. De todo se aprende.

Anotación por Juan J. Martínez, clasificada en: alfresco, open source.

Hay 7 comentarios

Gravatar

Hola, lo primero felicitarte por el site, me parece bastante interesante.
Al leer el post de Alfresco me sale la siguiente duda.......
Estoy viendo como comentas, cierta inercia hacia Alfresco y conozco bastantes empresas contentas de su rendimiento, aunque desconozco las pruebas realizadas.
Si tras probarlo concluyes que no es una opcion que te plantearias.... ¿Que opciones barajarias para implantar en un entorno corporativo?¿Plone...?

por un visitante, en 2009-04-02 23:28:51 ∞

Gravatar

...o eso quiero pensar.

Nosotros teníamos unos requisitos y diseñamos una batería de pruebas que tenía que pasar el producto para que nos valiera.

Trabajamos con unos 6GB de información que tiene que poder actualizarse de forma ágil, permitiéndonos búsquedas y aplicar metadatos.

Uno modo de trabajo que no nos valía es precisamente el que funciona bien en Alfresco: descargas un documento, lo modificas y lo subes con la web.

Insisto en que dependerá de los requisitos de cada caso.

por Juanjo, en 2009-04-03 06:12:26 ∞

Gravatar

...usar plone para eso.

Es web, es robusto y es fiable. Puedes adaptarlo de forma realmente sencilla y tiene algunos "productos" que te permiten agregarle soporte para meter los ficheros fuera de la ZODB de zope (y servirlos luego por DAV/FTP desde el propio Zope).

Ademas, tienes un sistema de roles/grupos/usuarios/permisos que es muy muy flexible, y si encima tienes en cuenta que tienes un editor de workflows en el que puedes definir practicamente cualquier politica de uso/trabajo con ficheros determinados (o grupos de)...

Pues es una solucion muy completa. Todo el mundo piensa en plone como un drupal/joomla/slashcode/etc para montar portales web, pero es muucho mas que eso...

por Wu, en 2009-04-03 13:15:14 ∞

Gravatar

Otra opcion que he visto recientemente y que tambien esta muy bien es OpenERP. Si, es un ERP, pero tiene una opcion para configurarlo como gestor documental (obviando muchas de las cosas que tiene a mayores) que es bastante completo y sencillo de utilizar (con acceso FTP a los ficheros, interfaz web, GTK y QT).

Si tienes un ratin, echales un ojo y ya me diras... :D

(comment muy largo... tuve que meterlo en dos :D)

por Wu, en 2009-04-03 13:16:59 ∞

Gravatar

no se exactamente lo que necesitas, pero viendo lo de fuse y después de haber probado muchas alternativas para gestionar ficheros remota y localmente me quedo con ssh, todo ha través de ssh, fish para konqueror y mc, montado a través de fuse para rox y otras aplicaciones como rsyn, y escritorios remotos con freeNX a través de ssh...
una pasada va todo de muerte excepto la fonera con wpa2/ccmp que la versión que lleva tiene el conocido bug que si tiras mucho con protocolos samba y ssh peta, con poner un limite justo un poco menor de 1M/s todo arreglado, con scripts qos en la fonera
ssh es una pasada, claro que para una empresa todo con ssh, pues no se, pero seguro que se puede.

por elpeor, en 2009-04-03 13:44:27 ∞

Gravatar

elpeor: pero SSH solo te soluciona el tema del acceso "fisico" a los ficheros (no tienes index de contenidos, busquedas, metadatos, etc etc) (bueno, si lo tienes pero a base de shell scripting, y eso no se yo si es la mejor opcion para lusers...)

Con un sistema de gestion documental ademas, tienes el tema de definir flujos de trabajo, es decir, que pasa cuando el usuario X crea tal documento (envio de notificaciones de alta de documentacion, por ejemplo, o cuando el usuario X le envia una copia del documento tal al usuario Y, cosas de ese estilo.

por Wu, en 2009-04-04 11:15:57 ∞

Gravatar

Además de lo que comenta Wu, no podemos tener suficiente control sobre los ficheros.

Un acceso por SSH signfica que se puede mover por todo el disco, y gestionar los permisos a nivel de sistema de archivos (aunque potente, si usamos ACL), es algo que no me dejan hacer :(

Si os digo la verdad, lo de la gestión documental no lo veo como algo brutal. Al final es almacenamiento + metadatos + búsquedas + ¿versiones?

por Juanjo, en 2009-04-04 11:20:24 ∞

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.

Algunas anotaciones relacionadas: