OJS es un sistema de publicación y gestión de publicaciones electrónicas desarrollado para adherir a los estándares de la Iniciativa de Archivos Abiertos, OAI.

Está escrito en PHP y utiliza una base de datos MySQL; corre perfectamente sobre Apache u otros servidores web y tiene licencia GPL.

Puede ser utilizado para administrar una o varias publicaciones; permite el envío de artículos en línea y la coordinación del proceso editorial (corrección, edición) a través del mismo sistema; está disponible en varios idiomas tanto el back-end como el front-end (la navegación e interfaz del usuario, y en caso de estar disponible, también presenta el contenido en el idioma solicitado); ofrece canales de sindicación RSS/Atom; búsqueda avanzada, etc.

En general, es un software bastante bien desarrollado y bien posicionado en su nicho… pero como siempre, hay algunas cosas que se podrían mejorar: el desarrollo parece estar un poco-demasiado centralizado, hay elementos diseñados para la web de hace un siglo (frames en las páginas de contenido, pop-ups no accesibles, etc.), no tiene un sistema de plantillas intercambiables, la lógica para nombrar las clases e ids de los elementos HTML es algo confusa… pero en fin, nada que sea imposible de superar, y ciertamente, nada que le reste mérito.

Dejo algunos PDF con documentación en inglés y español. También pueden ver algunas publicaciones que utilizan OJS

Documentación en español

• Manual de usuario de OJS
• Guía práctica de OJS · Publicar un número de una revista

Documentación en inglés

• OJS/OCS Quick Reference
• OJS in an hour · An introduction to Open Journal Systems
• An introducion to Use of Roles in OJS
• Open Journal Systems · Technical Reference

Tags: estándares, gpl, php, proyectos, Software

Artículos relacionados

• Y tenemos WordPress 2.1
• WordPress y Habari
• WordPress es todo oídos
• WordPress 2.1 Beta 3
• Tres trucos para OJS
• Software para crear DVDs
• Satorii, un (nuevo) tema para WordPress

A continuación, revisaré algunas de las formas que conozco para crear archivos PDF… no es una lista exhaustiva ni pretendo crear un tutorial para cada una de las alternativas, pero espero que esta información sea suficiente para utilizar este formato.

Acrobat, InDesign, Photoshop, Illustrator y Acrobat.com

Empecemos con las alternativas “oficiales”, las de la familia de productos de Adobe, quienes crearon originalmente este formato. Todos estos programas son comerciales, con licencias propietarias (o sea, no son ni gratis ni software libre, hay que pagarlos) y están disponibles tanto para Windows como para Mac, con la excepción de Acrobat.com que es un servicio web.

Vamos en orden inverso:

• Acrobat.com es un servicio web desarrollado en Flash por Adobe, que permite crear, compartir, almacenar documentos y crear archivos PDF a través de un navegador web. Los servicios son gratuitos, pero la opción de crear PDF está limitada a solo 5 archivos. Hay algo más de información al respecto en Genbeta.
• Illustrator, Photoshop e InDesign son programas de la Creative Suite de Adobe, su paquete de programas de diseño. Estos, en particular, se utilizan principalmente para el diseño de gráficos vectoriales, edición de imágenes y diseño editorial respectivamente, y todos ellos tienen la opción de exportar a PDF. Puesto que estos programas tienen un uso bastante específico, probablemente no son la mejor opción si sólo quieres crear un PDF; claro que si los tienes, debes saber que cuentas con esa posibilidad.
• Acrobat es la opción que debes elegir si, por ejemplo, deseas convertir un documento que hayas creado en un procesador de textos (como Word) a PDF. Trabaja como una impresora virtual, es decir, cuando vayas a imprimir un documento (desde cualquier programa del que puedas imprimir) te aparecerá una nueva impresora que corresponde a Acrobat; si la seleccionas e imprimes el documento, el resultado será un archivo PDF.

Como es de esperar, ya que se trata de las aplicaciones desarrolladas por quienes han creado esta tecnología, los resultados que puedes esperar son de primer nivel, con acceso a una gran cantidad de opciones de manera fácil. El costo de estos programas es bastante alto: por ejemplo, la versión Standard de Acrobat 9 cuesta alrededor de US$ 299.

OpenOffice.org

OpenOffice.org es una suite de ofimática, o más simplemente, algo así como un “Microsoft Office gratis”. En realidad, OpenOffice.org es un programa de código abierto y software libre… y claro, también es gratis.

Se puede descargar gratuitamente desde su sitio web, está disponible para Windows, OSX, Linux (de hecho, viene incluido en varias distribuciones, como Ubuntu, OpenSUSE o Fedora) y FreeBSD.

Incluye un procesador de textos, hoja de cálculos, presentaciones, editor de gráficos vectoriales, base de datos y un editor de fórmulas matemáticas. Puede abrir y editar archivos creados en Microsoft Office (Word, Excel, PowerPoint…), con los que es altamente (pero no totalmente, quizás en algo así como un 95%) compatible… claro que la culpa de esto no es suya sino de los formatos propietarios y cerrados.

Crear PDFs desde OpenOffice.org es bastante fácil: basta con ir a Archivo → Exportar en formato PDF. Cuenta con un buen conjunto de opciones de calidad, seguridad y funcionalidad, lo que lo convierte en una excelente opción.

Existen algunos proyectos relacionados con OpenOffice.org, como StarOffice o NeoOffice: el primero es el “padre” de OpenOffice.org, desarrollado por Sun como una alternativa a Microsoft Office; es propietario y de pago, pero se puede descargar gratuitamente si utilizas Google Pack (sólo para Windows). NeoOffice es una versión derivada de OpenOffice que se integra de forma nativa en OSX.

PDFCreator

PDFCreator es algo así como Acrobat, pero desarrollado como software libre y gratis. Está disponible para Windows, aunque tiene algunos problemas menores con Vista (como todos, ¿no?).

Se puede descargar desde su sitio web y al instalarlo funciona como una impresora virtual, o sea que funciona desde cualquier programa que pueda imprimir (incluido todos los de Office: Word, Excel, PowerPoint; tu navegador web, etc.)

También ofrece una buena cantidad de opciones de calidad y seguridad.

cups-pdf

cups-pdf es un paquete de software para Linux que permite la creación de archivos PDF a través de una impresora virtual.

En Ubuntu, puedes instalarlo buscándolo a través de Synaptic o bien tecleando desde una terminal sudo apt-get install cups-pdf.

De manera predeterminada, guarda los documentos convertidos en /home/tu-usuario/PDF

PDFonline.com

Este sitio web ofrece convertir archivos DOC, RTF, XLS, PPT, etc. a PDF. El servicio es gratuito, pero no se pueden configurar las opciones de conversión y sólo se puede convertir un documento a la vez.

Luego de subir el documento a convertir, envían el PDF a tu dirección de correo electrónico.

Básicamente se trata de hacerle publicidad a su programa de pago (para Windows) para convertir a PDF… que en verdad (hasta donde recuerdo de la demo que ocupé) no tiene nada de mejor que PDFCreator.

A pesar de que el servicio del sitio web es bastante básico, es útil para sacar de apuros.

Google Docs

Ya sea en Google Docs o en las aplicaciones de Google para tu propio dominio, tienes la posibilidad de exportar a PDF tus documentos de texto, hojas de cálculo o presentaciones (Google Docs es algo así como Office, pero en internet).

Aquí no hay ningún control sobre el archivo resultante, pero resulta conveniente al estar integrado al servicio.

Microsoft Office 2007

Office 2007 ofrece un plugin para convertir directamente a PDF… hasta ahora ese plugin se debe descargar previa “validación” de tu copia de Office, pero supuestamente vendría incluido luego gratuitamente en una actualización a Office 2007 durante este año (el Service Pack 2 para Office 2007).

Tags: Diseño, estándares, Google, Internet, Linux, pdf, Software, Ubuntu, windows

Artículos relacionados

• Xubuntu (IV): Compartir Internet
• Un nuevo tema para yukei.net (II)
• Servidor de música DAAP en Ubuntu
• Personalizar las opciones del TouchPad Synaptics en Linux
• Eyecandy para GNOME
• Express Scribe
• El desafío (de) Ubuntu

Una mejor alternativa que comenzar a comprimir cosas por acá y por allá, y tras haber echo el obvio paso de desinstalar el software que no utilizas (o reemplazar grandes armatostes como Adobe Reader por alternativas más ligeras como Foxit Reader), es simplemente encontrar qué cosas están ocupando más espacio y luego decidir si mantenerlo o borrarlo.

Por supuesto, ver cuánto ocupa cada carpeta es una tarea bastante poco agradable, por ello es que afortunadamente existen varias aplicaciones que analizan la utilización del disco y la representan gráficamente. Algunas de ellas:

• Disk Usage Analyzer… anteriormente conocido como Baobab; disponible para Linux. Desde el 2006 forma parte del paquete GnomeUtils de GNOME, por lo que si usas una versión reciente de este entorno de escritorio ya lo tendrás instalado.
  • Screenshot
  • Sitio web
  • Documentación
• WinDirStat, gratuito y open source, para Windows.
  • Sitio web
  • Página del proyecto (en SourceForge.net)
  • Descargas
  • Screenshot
• Filelight, para KDE.
  • Sitio web
  • Screenshot
• KDirStat, también para KDE… y base de WinDirStat
  • Sitio web
  • Screenshot

Tags: Linux, Open Source, Software, windows

Artículos relacionados

• Servidor de música DAAP en Ubuntu
• Máquinas virtuales en Ubuntu/Linux
• Express Scribe
• Cómo crear documentos PDF
• Y tenemos WordPress 2.1
• Xubuntu (VII): Síntesis y evaluación final
• Xubuntu (VI): Más software

Su funcionamiento es bastante sencillo: cuenta con un conjunto de “dataproviders” (barra izquierda) que se pueden enlazar entre sí en un “lienzo” (área derecha). Algunos dataproviders solamente pueden enviar información, otros sólo recibirla y otros funcionan en ambos sentidos, lo que está representado por las flechas que acompañan a cada ícono. Además, es posible organizar un grupo de manera que desde un origen puedas enviar información a varios destinos: por ejemplo, desde tu carpeta de fotos hacia Flickr, Picasa y Facebook.

En mi caso, me interesaba mantener una copia de los archivos de mi tesis en otros lados, por lo que lo he arreglado para copiarlos desde mi disco duro a mi espacio en Box.net, una carpeta en un disco duro externo y una carpeta en mi servicio de web hosting; probablemente este sea la opción menos “obvia”, pero gracias a la posibilidad de crear enlaces con servidores (en Ubuntu, anda a Lugares > Conectar con el servidor... y configura tus datos), es bastante sencillo hacerlo.

Conduit es un proyecto en pleno desarrollo, y como tal, hay muchas cosas que todavía no funcionan completamente como deberían y su documentación es escasa. Afortunadamente, su progreso es dinámico y alentador; seguramente se convertirá en una herramienta indispensable en poco tiempo más.

Link: Conduit

Tags: Free-Software, gnome, seguridad, Ubuntu

Artículos relacionados

• Eyecandy para GNOME
• ¿Vale la pena actualizar a Edgy?
• Xubuntu (VI): Más software
• Xubuntu (V): Software
• Xubuntu (IV): Compartir Internet
• Xubuntu (III): ¡Funciona!
• Xubuntu (II): La instalación

PC-BSD es uno de estos proyectos: se trata de una distribución basada en FreeBSD y publicada bajo licencia BSD orientado específicamente a su utilización como sistema de escritorio —podría decirse que PC-BSD es a FreeBSD lo que Ubuntu a Linux.

PC-BSD is a free operating system with ease of use in mind. Like any modern system, you can listen to your favorite music, watch your movies, work with office documents and install your favorite applications with a setup wizard at a click.

Características

• Sistema operativo de escritorio totalmente funcional, corriendo FreeBSD 6-Stable “bajo el capó” y KDE 3.5 como entorno de escritorio
• Interfaz 3d opcional con Compiz-Fusion
• Sistema de instalación gráfico
• Disponibilidad en varios idiomas
• Paquetes de software auto-instalables desde PBI Directory
• Administrador de actualizaciones a través de internet

A prueba

En lo personal, bajé y probé una imagen para VMware de su última versión, 1.4.1 y he quedado bastante impresionado —aclaro, antes que nadie lo diga: no es Ubuntu, por lo que la experiencia es de todos modos bastante distinta. Aún así, todo corría sorprendentemente rápido, el sistema respondía muy bien y (a pesar de no ser muy amigo de KDE) debo decir que si ya has utilizado alguna distribución de Linux anteriormente, en cuestión de minutos ya me encontraba bastante a gusto.

El software que incluye es el típico de KDE: Konqueror (administrador de archivos y navegador), Kopete (mensajería instantánea), Konsole (línea de comandos), AmaroK (reproductor de música) y KOffice (procesador de textos, hoja de cálculos, presentaciones), pero a través de PBI Dir es posible descargar otros paquetes con lo que quizás tenemos algo más de familiaridad, como Firefox, Thunderbird, OpenOffice, Pidgin, etc. Desde este repositorio web es posible descargar paquetes auto-ejecutables, similares a los instaladores de Windows, y la selección de paquetes es lo suficientemente amplia como para satisfacer las demandas de la mayoría: desde Vim a Eclipse y KDEvelop, a GIMP, 7-zip, Skype e incluso World of Warcraft.

Sus requerimientos de hardware son bastante modestos: un procesador con arquitectura 686 (Intel Pentium Pro/II/III/IV, Core/Core 2, AMD Athlon/Duron/Opteron/Turion, etc.), 128 :mb: de :ram: (aunque recomiendan 512 megas), 4 :gb: de disco duro y lector de CD-ROM.

En general, y hasta donde he visto, todo funciona como debería, o sea, bien, por lo que si estás con ánimo de experimentar, aprovechar un equipo viejo, deseoso de un sistema muy estable, buscando un sistema operativo libre con todo lo esencial y quizás algo más, o con ganas de que te miren con una cara aún más rara de la que ponen cuando hablas de Ubuntu, PC-BSD podría ser una excelente alternativa: lo instalas y lo usas, y te olvidas de virus, software espía y pantallazos azules.

Tags: bsd, Free-Software, KDE, Linux

Artículos relacionados

• Xubuntu (VI): Más software
• Xubuntu (V): Software
• Xubuntu (IV): Compartir Internet
• Xubuntu (III): ¡Funciona!
• Xubuntu (II): La instalación
• Máquinas virtuales en Ubuntu/Linux
• Eyecandy para GNOME

eXtplorer es un administrador de archivos basado en web, o lo que es lo mismo pero en más palabras, una interfaz gráfica para navegar por directorios, copiar, subir, descargar y borrar archivos y otras cosas más.

Hace tiempo andaba buscando algo así, ya que si bien me gusta bastante el servicio de algunos servicios de alojamiento de archivos como Box.net, las típicas limitaciones al tamaño máximo de los archivos o el límite de descargas me dejaban algo disconforme. Necesitaba un medio gráfico y amigable para compartir algunos archivos (grabaciones de audio, videos, fotos, etc.) y mi cuenta de :DreamHost: seguía sub-utilizada, con un montón de gigabytes sin ocupar ni transferir, por lo que mi búsqueda de una solución instalable siguió hasta dar con eXtplorer… y creo que hasta aquí ha llegado.

Otra buena alternativa es eyeOS, un “sistema operativo” basado en Web, pero le faltaban dos cosas que eXtplorer sí tiene y me parecían indispensables:

1. La posibilidad de subir archivos por :ftp: y que el programa los “reconociera” (es decir, que pudiera tener acceso a ellos a través del software)
2. Poder transferir archivos entre servidores

Para funcionar, requiere solamente de PHP 4.3 o mejor y un navegador con JavaScript. El tamaño máximo de los archivos que se pueden subir dependerá del valor fijado en la configuración de PHP de tu servidor; en mi caso es de 7 :mb:, pero los archivos de mayor tamaño se pueden subir por :ftp:, el que (hasta donde se) no tiene límite para los archivos.

Otras de las gracias de eXtplorer es que también se puede utilizar en español y es posible crear múltiples cuentas de acceso con diferentes privilegios: solo ver, modificar, cambiar password, modificar & cambiar password o administrador.

…y todo esto funciona con mucho, mucho :ajax:, cortesía de Ext JS y bajo licencia :gpl: o MPL

Tags: ajax, aplicaciones-web, php, Software, web-2.0

Artículos relacionados

• Y tenemos WordPress 2.1
• WordPress y Habari
• WordPress es todo oídos
• WordPress 2.1 Beta 3
• vi.sualze.us, marcadores sociales visuales
• Tres trucos para OJS
• Referencia del código de WordPress (versión en desarrollo)

Cualquiera sea la razón, la tecnología de virtualización nos ofrece una estupenda oportunidad para poder quedarnos solamente con un sistema operativo sin necesidad de reiniciar cada vez que necesitemos ocupar alguno de estos programas. La idea básica es la siguiente: crear una máquina virtual (algo así como un computador simulado dentro de tu computador “físico”) sobre la que es posible instalar y ejecutar otros sistemas operativos, y por consiguiente, cualquier programa que haya sido creado específicamente para ellos.

En Ubuntu/Linux, la oferta no es limitada, y en este artículo comentaré mi experiencia probando tres de los productos más populares para esta tarea: VMware Server, QEMU y VirtualBox.

VMware Server

Éste es un producto propietario de virtualización creado por VMware y distribuido gratuitamente. Para utilizarlo, es necesario registrarse y aceptar una licencia —que, desgraciadamente, limita la posibilidad de publicar resultados de benchmarks a menos que sean aprobados por la empresa— e instalarlo vía apt-get o compilándolo desde las fuentes que se pueden descargar desde su sitio web.

Una vez instalado, la creación de la máquina virtual es bastante sencilla gracias a una interfaz gráfica bien cuidada y un proceso guiado por un asistente que permite seleccionar las alternativas más útiles y comunes para tener nuestra máquina virtual corriendo al cabo de unos cuantos clicks. Entre otras cosas, permite montar imágenes de CD o acceder a la unidad óptica desde la máquina virtual, establecer el acceso a internet y conectar dispositivos USB.

Además cuenta con un complemento llamado VMware Tools que una vez instalado en la máquina virtual permite compartir transparentemente el mouse entre la máquina física y la virtual, utilizar un mejor driver de pantalla y mejorar el rendimiento de la red… al parecer, también debería permitir compartir una carpeta del equipo físico con la máquina virtual a través de Samba para poder montarla como unidad de disco en red, pero en lo personal no me funcionó —no sé si por ineptitud, algún problema de configuración u otra dificultad.

A prueba

Dado que no es posible publicar resultados de pruebas de benchmark, me limitaré a comentar que el rendimiento de la máquina virtual es bastante bueno, cercano a la velocidad esperada de la ejecución nativa del sistema operativo (o sea, corriendo directamente sobre el hardware; en otras palabras, near native). Lo que pensé que podría ser una de sus mayores ventajas en comparación a los otros sistemas de virtualización, extrañamente, no lo fue tanto: la posibilidad de aprovechar los dos núcleos de un procesador Intel Core Duo en realidad no marcaba una diferencia tan significativa en el rendimiento de la máquina virtual ni en la percepción que se pudiera tener del mismo —me estoy refiriendo, en primer lugar, a lo que los números dicen sobre el rendimiento de la VM, y por otra parte a la sensación subjetiva del mismo.

En general, VMware Server otorga lo que se podría esperar de un sistema de virtualización: es fácil de instalar y utilizar y su rendimiento es bastante aceptable. Aparte de mi dificultad para compartir una carpeta a través de Samba, sólo tuve otra gran dificultad con él: la utilización de dispositivos USB; más específicamente, al tratar de conectar un disco duro externo (conectado por USB) a la máquina virtual, todo parece indicar que se desmontó de manera no segura de la máquina física, causando que fuera imposible volver a montarlo en Linux pues me indicaba que el sistema de archivos estaba corrupto, lo que me ha traído un gran dolor de cabeza al tratar de acceder nuevamente al disco; y sin una carpeta compartida ni el disco externo para servir como “puente” entre Linux y la VM, éstas quedaban prácticamente aisladas la una de la otra, sin posibilidad de compartir archivos entre ellas. Desconozco si esto habrá sido por algún error mío o del software, pero sinceramente no se lo deseo a nadie —este problema, quiero decir; en cuanto a VMware Server, aun creo que es una buena alternativa, aunque en lo personal no es mi preferida.

Cabe mencionar que VMware también ofrece gratuitamente VMware Player, un programa para ejecutar (pero no crear) máquinas virtuales.

VMware/Server – Community Ubuntu Documentation

QEMU

QEMU es probablemente la opción más “clásica” entre los usuarios de Linux. Desarrollado porFabrice Bellard (también ligado al desarrollo de ffmpeg), es software libre licenciado bajo LGPL (la mayoría del programa) y :gpl: (la emulación en modo de usuario).

A diferencia del anterior (y de VirtualBox) su modo de operación es principalmente vía línea de comandos, lo que quizás podría ahuyentar a más de alguno… bueno, no debería, porque gracias a la documentación creada por la comunidad de Ubuntu (y seguramente disponible también para otras tantas distribuciones) en base a concisas y precisas instrucciones, es posible tenerlo corriendo en poco tiempo sin ningún problema.

Y para quienes la ventana de gnome-terminal definitivamente les da alergia, existe también una :gui: (la pueden encontrar con Synaptic en los repositorios de Ubuntu) pero que no se caracteriza precisamente por su simplicidad… a decir verdad, es algo enredada a menos que uno sepa exactamente lo que está haciendo; por otra parte, lo bueno es que da acceso a las opciones más importantes de QEMU, desde la creación del disco virtual hasta la selección de carpetas compartidas mediante Samba.

Valga decir que QEMU por sí solo es reconocidamente lento… pero lento, lento. No importa qué tan rápida sea tu máquina física, tu VM va a andar muy lenta en QEMU… lógicamente, a alguien se le ocurrió algo para tratar de solucionar este problema, y así nació KQEMU, un driver que hace las veces de acelerador, permitiendo una velocidad razonable de la máquina virtual. Al igual que QEMU, KQEMU se distribuye gratuitamente con licencia GPL.

Lamentablemente, KQEMU tiene una desventaja: para usar este acelerador es necesario que tanto el huésped (o host, o máquina física) como el invitado (o guest, o máquina virtual) utilicen procesadores x86 o compatibles (Intel, AMD).

A prueba

Y el veredicto es… me quedo con otro.

K/QEMU tiene prácticamente todo lo que me haría comprometerme con él —en resumen: funciona, es software libre (cada día me doy más cuenta de que esto en sí es una ventaja), tiene un desarrollo activo y pujante, y no solo busca igualar sino sobrepasar las prestaciones de soluciones comerciales.

Pero… es dolorosamente lento. Sin acelerador, lento. Con acelerador, casi-igual de lento. En verdad la diferencia fue tan mínima que varias veces tuve que chequear que estaba funcionando con el acelerador… y tristemente, sí estaba funcionando, pero todo funcionaba igual de lento.

Como éste no prohibía la publicación de resultados de benchmarks, me propuse comparar su rendimiento con y sin acelerador… y debo decir que todo fue tan insoportablemente lento que preferí detener las pruebas, o hubiese estado esperando mucho más rato del que quería.

A su favor debo decir dos cosas: en primer lugar, reiterar que su desarrollo se ve bastante activo, por lo que no me extrañaría encontrar grandes mejoras en poco tiempo, incluyendo soporte para núcleos múltiples. En segundo lugar, en las comparaciones que encontré QEMU era señalado sin variaciones como una tortuga, pero con KQEMU los resultados eran bastante distintos, near native, lo que me hace pensar que es posible que alguna particularidad propia de mi sistema haya influído para no obtener la tremenda mejora de rendimiento que éste supone.

VirtualBox

Una solución de virtualización desarrollada por innotek GmbH, que viene en dos sabores: una versión :gpl: totalmente funcional, pero limitada con respecto a la otra versión, comercial y propietaria (o sea, que no es ni código abierto ni software libre, aunque sí gratis) que incorpora soporte para USB, directorios compartidos con Samba y otros chiches más (que honestamente no alcanzo a comprender muy bien de qué se tratan).

En su página de descargas es posible encontrar paquetes para Ubuntu, Debian (también en repositorios), Fedora y otras distribuciones Linux, un instalador para Windows y uno para MacOSX que en este momento está en su segunda beta… no el instalador, sino el software, quiero decir.

En estas condiciones, su instalación es bastante sencilla, y su puesta en funcionamiento también. Es algo similar a VMware en el sentido que utiliza una interfaz gráfica y un asistente para la creación de la VM, y en que también cuenta con un paquete de “mejoras” que se instala en el guest. Con éste (y en la versión comercial) es posible tener integración transparente del mouse y teclado entre la máquina física y la virtual, además de auto-ajustar la resolución del sistema guest al tamaño de la ventana —a propósito: la placa de video emulada funciona de manera predeterminada con 8 :mb: de memoria, pero se puede aumentar mediante la GUI… aunque en realidad no le veo mucho propósito.

VirtualBox intenta ejecutar el código del invitado directamente en el procesador tanto como sea posible; cuando esto no es posible recurre a un dynamic recompiler basado en QEMU pero con algunas mejoras que le permiten obtener un desempeño bastante (mucho) mejor.

A prueba

Lo digo altiro: fue el que más me gustó. Desde la máquina virtual, la instalación del sistema operativo, poder ajustar las opciones con facilidad… ¡y el rendimiento! ¡Oh, el rendimiento!

Así de bueno.

En verdad, según la mayoría de las opiniones que he leído al respecto, su velocidad es “comparable” con los productos de VMware, pero debo decir que la experiencia subjetiva de operar sobre el sistema invitado es mucho mejor… las razones no me las pregunten, pero se siente defintivamente más “suave”. Probablemente, el ajuste automático de la resolución de pantalla ayuda bastante

Éste fue de hecho el primero de estos programas que probé, y el único en el que todo funcionó perfectamente a la primera, y especialmente (lo que más me interesaba) al probar Photoshop 7 y MS Office 2003.

Sin poder publicar una comparativa entre éste y VMware, sólo puedo comentar que en números andan muy parejos, a veces uno y otras veces el otro a la cabeza… y esto a pesar de que en VMware tenía soporte para los dos núcleos del procesador.

En definitiva, si tendría que recomendar VMware, K/QEMU o VirtualBox, me quedaría totalmente con éste.

VirtualBox – Community Ubuntu Documentation

Otras alternativas

Por razones de fuerza mayor, quedó fuera de este comentario una de las alternativas que más me interesaba probar: KVM. Esas “razones” en verdad son una sola: mi procesador no soporta la tecnología de virtualización necesaria para KVM, por lo que quedé con ganas; de toda la serie de procesadores Intel Core Duo uno de los pocos que no tiene soporte para VT es el modelo T2250, hasta donde recuerdo todos los restantes Intel Core Duo, Intel Core 2 Duo y las últimas CPU de AMD lo tienen.

… De todos modos ahí está, y como siempre, pueden contar con la comunidad de Ubuntu para hallar algo de documentación al respecto: The Kernel Virtual Machine – Community Ubuntu Documentation

… Y para los que todavía quedaron con ganas de explorar más, siempre pueden recurrir a Wikipedia (aunque sea en inglés): Comparison of virtual machines – Wikipedia, the free encyclopedia.

Tags: Free-Software, Linux, Open Source, Software, virtualización

Artículos relacionados

• Xubuntu (VI): Más software
• Xubuntu (V): Software
• Xubuntu (IV): Compartir Internet
• Xubuntu (III): ¡Funciona!
• Xubuntu (II): La instalación
• WordPress y Habari
• Servidor de música DAAP en Ubuntu

¿De qué se trata esto entonces? De la GPL 2, y de los errores en los que es posible incurrir al “olvidar” algunos detalles que ésta implica, y que en definitiva hacen que no funcione como debería, o sea —parafraseando aStallman— limitando ciertas libertades para otorgar otras: libertades de software libre “a la Free Software Foundation“.

¿Cómo? A través de la presentación de algunos casos de desarrollo de software relacionado con WordPress que logran dar cuenta de descuidos en relación a la aplicación y respeto a la GPL —y ojo, que digo descuidos, porque desde ya quiero explicitar que no creo que se trate de tipos que se hayan “pasado de listos” con las licencias… después de todo, la GPL es un texto que presenta un cierto grado de complejidad tanto legal como informática, por lo que no es totalmente impensable el incurrir en algún error con respecto a su aplicación.

En definitiva, se puede pensar que este artículo es una ayuda para comprender una de las licencias de Software Libre más utilizadas en la actualidad.

Qué implica la GNU GPL

No voy a presentar un análisis completo de la licencia (quizás solamente un equipo interdisciplinario pueda ser totalmente competente para dicha tarea), sino que me gustaría presentar un resumen basado en los puntos que Christian presenta en sus artículos.

Si aplicas una licencia GPL a tu software:

1. Debes publicar el código fuente: “Open Source”, traducido literalmente, significa “Fuente Abierta”. En este punto es necesario recordar la indicación que Carlos hizo en los comentarios: en el caso de modificar el código y querer distribuirlo, debes publicar el código; no si solamente quieres utilizarlo con tus modificaciones
2. Estás autorizando la modificación y distribución de tu programa (de acuerdo a los términos de la licencia). Para complementar el punto anterior: la GPL no se aplica a la utilización del software, el acto de correr el Programa no está restringido.
3. Las obras derivadas deben conservar la misma licencia, no hay ninguna otra posibilidad al respecto
4. No puedes restringir la utilización del software ni agregar ninguna nueva restricción a la licencia, es decir, no puedes indicar que un programa no sea utilizado con fines comerciales
5. Estás limitando tu responsabilidad respecto al uso del software, por lo que si la ejecución del software causa algún perjuicio al usuario, el desarrollador no es responsable por los daños
6. Retienes la “atribución” por tu trabajo original, a la misma vez que quien modifique el programa debe indicar que ha sido modificado y la fecha de los cambios

Si te interesa más el tema, lo más recomendable es leer el texto original (en inglés) de la licencia; por supuesto que si vas a publicar un software con ella, más que una recomendación es algo así como un deber. También puedes revisar las traducciones no oficiales al castellano de las licencias GNU.

Importante: debes tener en cuenta que la única versión que debiera ser usada legalmente es la versión original en inglés o alguna de las traducciones oficiales.

Bien, pasemos ahora a los casos.

Cuando la GPL no es GPL

Uno

Este primer caso afecta a la traducción al español de WordPress 2.1 publicada recientemente, y podría calificarse fácilmente de un simple descuido u olvido.

WordPress utiliza gettext como sistema de traducción, lo que implica una serie de pasos para generar lo que constituye un catálogo de traducciones: básicamente, primero hay que marcar las cadenas que se habrán de traducir, luego juntarlas todas en un archivo .PO que finalmente deriva en un archivo optimizado para máquinas con extensión .MO —en este caso, el archivo .PO haría las veces de “código fuente” para el catálogo de traducciones… y en este caso, no lo publicaron.

¿Cómo aplicar una licencia de código abierto cuando sin otorgar acceso al código fuente? Simplemente no se puede.

Me contacté conReyson sobre este asunto, y ha respondido lo siguiente:

Hola Felipe,
Asi es, realizaremos algunos ajustes finales en la traducción y gracias a los que están comunicando algunos errores podemos hacerla lo mejor posible para luego liberarla y sirva de base para futuras traducciones, un poco de paciencia.. ;)

Por otra parte, esto plantea una cuestión que no deja de ser interesante: si publicamos un tema con licencia GPL, ¿acaso deberíamos publica lo que haga las veces de “código fuente” de las imágenes también? Y en ese caso, ¿cuál sería el “código fuente” de las imágenes: los archivos para Photoshop o GIMP? ¿O basta con incluir las imágenes “tal-cual”, como JPG, GIF o PNG? (considerando también que, por ejemplo, que JPG es un algoritmo de compresión con pérdida, y que en el caso de fotografías digitales a veces sería posible incluir los archivos raw).

De todos modos, hasta ahora el estándar de facto es incluir solamente los archivos JPG/GIF/PNG.

Dos

Hace algún tiempo publiqué una versión en español de 281, basada en 281 dePaul Stamatiou.

Este tema está basado en K2, publicado bajo licencia GPL, por lo que se publica también por esta licencia. Sin embargo, existe una modifcación bastante popular (que incluso está disponible en WordPress.com) llamada 2813, a cargo deEli Foner.

¿Y cuál es el problema con 281 o 2813? —se preguntarán.

El problema, es que Eli publica una licencia Creative Commons Attribution – NonCommercial – ShareAlike 2.5, y debería estar ocupando… sí, la GPL. En concordancia con esto, indica que su tema no debería utilizarse “con propósitos comerciales”, lo que ciertamente es algo ambiguo, pero si se refiere a la utilización en sitios comerciales está fuera de orden respecto a la licencia que debería tener.

A todo esto, a mí me pasó lo mismo cuando publiqué Satori, que ocupa código de Kubrick.

Tres

Este primer caso lo ví por primera vez en What makes you happy?, y es quizás el más polémico de todos.

Se trata de un tema basado en una plantilla GPL y que utliza código de K2, que también es GPL, por lo que lógicamente, este tema también debería utilizar esta licencia. Y lo hace, ese no es el problema, sino que en la página de descarga agrega un párrafo que dice:

Anaconda viene con la GPL (Licencia Pública GNU). Tanto Mollio como K2 han sido publicados bajo GPL. La única cosa que exigimos es que mantengas las atribuciones y los enlaces en el pié de página sin ningún cambio.

Claro, exigen mantener atribuciones y enlaces, y una de las cláusulas de la GPL especifica claramente que no se pueden agregar nuevas restricciones, con lo que la exigencia es totalmente inválida. Por otra parte, bajo la GPL está permitido modificar el código, y solamente reglamenta la “modificación y distribución”, o sea que en la práctica la “modificación y utilización” (sin redistribución) no estaría limitada por la licencia.

Pero esto no acaba acá: como indica Mark, existe en el blog de quienes publican este tema un post llamado Cómo remover las atribuciones / enlaces del tema Anaconda para WordPress, en el que señalan que para poder sacar los enlaces es necesario pagar US$30. De acuerdo a la GPL, se puede cobrar una cuota por el acto físico de transferir una copia, por garantía o incluso por el mismo software, pero cobrar por algo que es incompatible con la licencia… eso sí que no.

Porque además de exigir manter la atribución, la forma en que insertan los enlaces a su sitio es mañosa, ya que no está simplemente incluída en el código del footer.php, sino a través de una función que inserta los enlaces a través del hook wp_footer.

Por si les interesa, les dejo el enlace al tema en cuestión: Anaconda, Ultimate 3 Column WordPress Theme

Tags: Open Source, Software

Artículos relacionados

• Y tenemos WordPress 2.1
• Xubuntu (VII): Síntesis y evaluación final
• WordPress y Habari
• WordPress es todo oídos
• WordPress 2.5… en serio
• WordPress 2.3 y las preocupaciones por la privacidad
• WordPress 2.1 Beta 3

El impacto más obvio que WordPress ha tenido —sobre todos— es que realmente no hay mucho espacio para otra plataforma para bloguear. No importa qué tan bueno sea el producto competidor que alguien cree, es casi imposible para cualquier cosa superar a WordPress como la herramienta elegida para el trabajo —sin importar cuál sea éste. WordPress no es perfecto, y somos los primeros en admitirlo. Ciertamente no es la plataforma para blogs más liviana ni el CMS definitivo, pero definitivamente esto no le ha impedido conquistar el mercado.

Contundente, pero con una contradicción evidente: afirma que no existen alternativas reales a WordPress, a la vez que reconoce que si éste está en el primer lugar de las preferencias no es necesariamente porque sea la mejor opción.

Durante Enero tuvimos varias noticias sobre WordPress que, en mi opinión, han venido alterando un poco este panorama, y que quizás podrían llegar a hacer tambalear la seguridad del predominio. Vamos por partes…

El pasado reciente de WordPress

Enero del 2007 probablemente ha sido el mes con más movimiento en el blog de desarrollo de WordPress, con cuatro importantes posts:

1. WordPress 2.0.6 fue anunciado el día 5, un release orientado principalmente a arreglar fallas de seguridad, pero que sin embargo produjo nuevos problemas como el llamado “FeedBurner bug” que impedía a este servicio acceder correctamente a la información de tu feed.
2. El 9 se publicó Ideas and Kvetch!, una iniciativa para enfocarse en el ingrediente secreto de WordPress… tú, creando espacios para enviar quejas e ideas al equipo de desarrollo de :wp:… ¿alguien dijo bloatware?
3. Justo a mitad de mes se lanzó WordPress 2.0.7… ¿por qué una nueva versión menor tan pronto? En buena medida, para arreglar los errores con los que la anterior había sido publicada.
4. Finalmente, el 22 se hizo pública WordPress 2.1 Ella, la increíblemente atrasada y esperada nueva versión mayor de WordPress, sobre la que —como era de esperar— un montón de gente expuso su opinión: algunos la alabaron y otros (creo que muchos más que nunca antes) se quejaron, ya que a pesar de la considerable demora no hay muchas novedades visibles para los usuarios como para justificar la actualización, la que por otra parte no dejó de presentar sus dificultades en algunos casos

A esto, agregaría el anuncio de un ciclo de desarrollo para WordPress que significaría plazos de actualización regulares y estructurados.

Esto bien podría ser solamente una impresión personal, pero creo que como nunca antes los usuarios de WordPress se han manifestado como “menos que contentos” con el rumbo que se está delineando. No son solamente los errores en los lanzamientos que supuestamente deberían arreglarlos, o que tras una espera demasiado prolongada la nueva versión no haya respondido a las expectativas, o que su “conexión” con la comunidad pueda resultar en un software lleno opciones poco útiles… es cada una de estas cosas y todas juntas a a vez, es en definitiva un clima algo enrarecido que huele un poco a descontento, y quizás (sólo quizás) también un poco a cambio.

… Y entonces, el 20 de enero surgió un competidor a WordPress

¿Habari?

Habari es el nuevo proyecto para crear un sistema de gestión de contenidos de código abierto que ha producido mucha bulla en la blogósfera (sobre todo la anglófona), por la simple razón de que algunos connotados desarrolladores de WordPress son quienes están detrás de él… habría que decir ex desarrolladores de WordPress ya que han pasado a trabajar exclusivamente en Habari. Seguramente conocen a algunos de ellos:

• Chris J. Davis, co-desarrollador de K2, uno de los themes de WordPress más populares.
• Michael Heilleman, creador de Kubrick (el tema predeterminado de WordPress) y co-desarrollador de K2.
• Khaled Abou Alfa, diseñador de aquella soñada remodelación de la administración de WordPress llamada Shuttle.
• A estos habría que sumar el que alguna vez fuera el octavo miembro de Automattic, Bryan Veloso, quien estaría encargado de diseñar el sitio web del proyecto.

Al ver esta lista de eminentes personajes notablemente ligados al desarrollo de WordPress ponerse al servicio de un nuevo proyecto que se presenta frontalmente como un competidor, creo que es inevitable preguntarse qué razones podrían existir para este alejamiento.

Las hay. Algunas han sido brutalmente exageradas por algunas de las personas que han seguido esta teleserie y escrito sobre ella, pero no creo equivocarme al afirmar que podríamos resumirlas en una: diferencias “filosóficas” con el rumbo del desarrollo de WordPress.

Bryan Veloso vs. Matt Mullenweg

Ok, este es un encabezado sensacionalista, debo decirlo. No existe nada así como una confrontación directa o guerra declarada entre ambos. Para ser claros, es necesario indicar que Bryan Veloso ni siquiera es uno de los “padres” de Habari, pero su historia parece ser bastante representativa de lo que ha pasado, además de ser uno de los que más se ha dedicado a escribir sobre el asunto. Jamás se ha referido en malos términos a Matt ni a la gente con que trabajó en Automattic, aunque ciertamente ha sido el más abierto a mostrar el lado personal de esta historia.

A mediados del 2006 (fines de julio), Bryan Veloso fue integrado al equipo de Automattic para trabajar en el equipo de diseño y desarrollo de WordPress, bbPress y sus otros productos. El trabajo de Bryan pudo verse en la nueva barra de administración de WordPress.com, pero poco más se supo del trabajo que habría desarrollado.

Bryan es un excelente diseñador, por lo que pensar que su trabajo se abocaría al necesario rediseño de la administración de WordPress era una apuesta que podía suponerse segura, ya fuera implementando Shuttle o su propia versión, Atlantis.

Sin embargo, pasó el tiempo y las noticias al respecto escaseaban. Un par de posts en los que pedía sugerencias fueron todo lo que pudimos ver, hasta un post publicado el 7 de diciembre, Pressing for Change, en el que anunciaba que dejaba Automattic.

Sí, algo ha muerto hoy. Si es que esa muerte me afecta, o más bien, la magnitud con que esa muerte me afecta aun está sujeto a interpretación. De todas maneras, a partir de hoy, Automattic y yo recorreremos caminos distintos. Al pensar sobre eso ahora, veo que la razón ha sido una más fundamental. La forma en que trabajo simplemente no encajó a sus expectativas. Podría hablar de cómo difieren las expectativas de diseñadores y programadores, o cómo es que usar Trac para medir la producción puede no ser la mejor forma de medir mi progreso. Honestamente, eso no haría nada por la situación. Fueron unos cuatro meses espectaculares trabajando con algunas de las mentes más inteligentes en el medio. Sé que llegarán lejos.

Veloso, fuera. Matt Thomas —quien ha hecho todo el trabajo de identidad para WordPress— adentro. Shuttle entraba en pausa, a pesar de que una de las últimas solicitudes de Veloso fue completar su trabajo en el proyecto.

Pasaría poco tiempo para agregar un nuevo capítulo (¿final?) a esta historia: el 19 de enero de este año, Bryan publicó esta serie de imágenes en un post titulado Atlantis: lo que podría haber sido.

Junto a ellas, sus últimas declaraciones al respecto.

No considero a éste mi mejor trabajo, creo que por eso es que Matt [Mullenweg] me envió éste cierto libro ["Diseñando lo obvio: un acercamiento desde el sentido común al diseño de aplicaciones web"] cerca de la hora de mi partida. Pero en mi defensa, no tuve muchas oportunidades de trabajar en él. O más bien, para refinarlo. [...]

Algunas personas son muy apegadas a sus ideas, tanto como para impedir que cualquier otra persona se meta con ellas. Para ser honesto, me puedo identificar con eso, y toda esta experiencia abrió mis ojos a un montón de cosas.

Y hasta ahí llegó el idilio de Bryan con WordPress, el que alguna vez llamara el único software para bloguear que usaría jamás, pero que ahora tendría planeado reemplazar por Django (que en realidad es un framework para Python).

Bueno, ¿y? ¿Qué pasó con Habari?

Pasa que, al parecer, la gente tras Habari también se ha visto un poco frustrada en sus aportes a WordPress. Jim Whimpey ha caricaturizado algunas de estas quejas: Matt es un dictador malvado que maneja una compañía llega de sus igualmente malvados lacayos que trabajan juntos en una horrible monstruosidad llamada WordPress. Claro, esto es una exageración, pero ¿notaron las frases que destaqué en la última cita de Veloso? Los desarrolladores de Habari han aclarado que su partida no tiene que ver con resentimiento, sino a lo más con “diferencias” y el deseo de crear algo nuevo y sorprendente.

Para Michael Heilleman, se trata de llevar a cabo el diseño de la interfaz que fue postergada junto al proyecto Shuttle, pero junto a esto se muestra preocupado por el que para él es un movimiento innegable de WordPress hacia “aguas comerciales” (lo que sea que eso signifique), el que afirma no condenar pero que sin embargo le hacen añorar tiempos pasados.

Chris Davis, por su parte, confiesa haberse sentido algo irritado con la forma en que se maneja WordPress; invoca su experiencia en las conferencias de la Fundación Apache como un punto de contraste en la forma de hacer las cosas, afirmando sentirse más cómodo con la forma en que funciona Apache.

Rich es quien, definitivamente, dibuja más claramente el panorama:

Sí, habían frustraciones de las que nos queríamos alejar. Y habían diferencias filosóficas sobre cómo debería ser gestionada una comunidad de Código Abierto. Pero no hay mala voluntad hacia WordPress, aun cuando hay diferencias de opinión sobre la Manera Correcta de hacer las cosas. En el Código Abierto, cuando las cosas se hacen bien, no es dañino tener dos proyectos saludables en el mismo espacio. Cuando las licencias son sensibles los proyectos pueden aprender el uno del otro, mejorar las ideas de cada uno, y tener una competencia sana, así como también esforzarse por ser compatibles. No veo un lado malo, si es que podemos seguir existiendo en una amistosa rivalidad.

En WordPress, los cambios más importantes al código deben ser revisados y aprobados por Matt, así como también las ideas para implementar nuevas características. Habari pretende tener un modelo más abierto de desarrollo, sin dejar de estar organizado aunque quizás sí menos centralizado. Proponen un sistema de meritocracia para obtener acceso a modificar el código de la aplicación, ésta es la inspiración fundamental que han extraído de Apache (aunque aun no se ha plasmado en un modelo estructurado).

¿Y qué va a pasar con WordPress?

Probablemente no mucho muy distinto… o sea, las líneas de su desarrollo han sido en buena medida trazadas con lo que ha pasado durante enero, y creo que ahora podemos fijarnos nuevas expectativas de lo que podríamos esperar a futuro.

¿Rediseño de la administración? Difícil. ¿Muchas características nuevas? Quizás, y probablemente varias de ellas suplanten la función que hoy tienen distintos plugins. Está la posibilidad de que se convierta en un bloatware, y no me gusta… y no soy el único al que no le gusta.

La movida “hacia aguas comerciales” es bastante indefinida. Creo que, en primer lugar, podríamos esperar más énfasis en WordPress.com que en “.org”, Akismet y el soporte pagado para instalaciones comerciales de WordPress que se anunció hace tiempo en Automattic. Está bien, después de todo, esto se ha transformado en un gran negocio, sería estúpido no tratar de obtener beneficios de él o desperdiciar estas oportunidades. No creo que Automattic comience a publicar software que no sea de código cerrado, o que WordPress (.org) se vuelva de pago.

Y sobre Habari… habrá que ver. Actualmente, hay una versión que funciona que puede ser descargada, pero está a años luz de siquiera igualar a WordPress. En serio, la acabo de probar, y está bien, pero muy incompleto; de hecho, hay mucho más trabajo por hacer que el que ya está hecho. Por otra parte, el requerimiento de PHP 5 reduce la cantidad de personas que podrían ejecutarlo, ya que todavía hay muchos hosts que utilizan PHP 4. Finalmente, no es la primera vez que sus desarrolladores se han unido para crear algo que ha recibido mucha publicidad: hace tiempo, se anunció con bombos y platillos la creación de InkSmith, pero hasta el día de hoy página de inicio reza “coming soon”.

Al día de hoy, la mayor fortaleza de WordPress es su comunidad. ¿Logrará Habari un nivel de participación no solo de programadores sino también de usuarios suficiente para convertirse en una verdadera competencia?

Fuentes

• wordpress™ wank
• Habari Wank!
• Habari
• How WordPress Spoils Developers
• Atlantis: What May Have Been. Powered By Avalonstar.
• Pressing for Change. Powered By Avalonstar.
• Habari, primeras imagenes del posible asesino de WordPress | aNieto2K
• Time to Habari at Binary Bonsai
• Chris Davis: Why Move.
• DrBacchus’ Journal

Tags: Free-Software, Open Source, php, Software, Weblogs, WordPress

Artículos relacionados

• Y tenemos WordPress 2.1
• WordPress es todo oídos
• WordPress 2.5… en serio
• WordPress 2.1 Beta 3
• Yo [corazón] WordPress
• WPG2: WordPress + Gallery2
• WordPress, DreamHost y tiempo de CPU

Hoy se anuncia la creación de dos nuevas secciones en el sitio oficial de WordPress, ambas están destinadas a escuchar a sus usuarios en una forma en que nunca antes lo habían hecho. Antes, para reportar un problema o solicitar alguna nueva característica, debías crear un nuevo ticket en el sitio de desarrollo de WordPress, un proceso no muy amigable para un usuario común; a partir de ahora, y gracias a Kvetch, cualquier usuario tiene un espacio para quejarse de cualquier cosa con la que puedas estar en desacuerdo en el mundo de WordPress, mientras que en Ideas podrás compartir tus más salvajes deseos sobre WordPress con el mundo, y también votar por las ideas de otras personas.

Solamente porque lo que hemos hecho ha funcionado en el pasado no significa que sea lo mejor para el futuro. Tenemos que tomar una “auto-mirada” crítica a las suposiciones que tenemos sobre nuestro proceso de desarrollo y sobre el mismo WP. El próximo lanzamiento, que ha tenido un larga espera, es el momento perfecto para enfocarnos en el ingrediente secreto de WP… Tú [Ustedes].

Si pudieras agregar cualquier cosa al mundo de WordPress, ¿qué sería? Si pudieras nombrar la cosa que más te frustra de WP, ¿qué sería?

¿Oportunidad o amenaza?

Cuidado. Creo que este anuncio puede transformarse en un arma de doble filo: si bien la idea de conectarse más con la base de usuarios me parece admirable, expresar que las ideas mejor evaluadas serán incluidas en una próxima versión podría llegar a atentar contra el proceso de desarrollo:

1. En primer lugar, creando expectativas poco realistas sobre las nuevas características que se podrían incluir, lo que genera presión sobre un equipo formado al menos en parte por personas que no están dedicadas exclusivamente al desarrollo :wp: (algunos de los cuales incluso ya han reaccionado a propósito de la carga que supondría el ciclo de desarrollo propuesto porMullenweg)
2. En segundo lugar desviando la atención desde el desarrollo de un núcleo sólido y estable lo que podría aumentar la posibilidad de encontrarnos con bugs a poco tiempo del lanzamiento de nuevas versiones (como ocurrió con 2.0.6 y el “pequeño problema” con FeedBurner), errores de seguridad, etc.

Viendo las “ideas” propuestas es posible darnos cuenta de que la mayoría de los requerimientos están enfocados a integrar funciones que actualmente no son parte del núcleo sino que vienen agregadas mediante plugins: tags, instalación de un click para plugins y themes, “retos” para identificar comentarios humanos… o podrían ser manejadas por plugins o widgets (por ejemplo, un sistema de gestión de enlaces a páginas tipo menú que fácilmente podría ser parte de un widget de texto).

Creo que el equipo de WordPress deberá optar entre un sistema repleto de características (lo que me recuerda aquella pesadilla bloatware que es PHP-Nuke) o un desarrollo orientado a ofrecer una solución estable, segura, sólida.

Ochenta por ciento de los usuarios ocupa un veinte por ciento de las características de un software, ¿no? WordPress tiene una sólida arquitectura para plugins y una activa comunidad de personas que continuamente están creando agregados para los más diversos gustos. No se trata de sobrevalorar la simplicidad, sino de enfocarse en las “características críticas” y hacer de la robustez del software una característica importante, a la vez que manteniendo la opción de agregar cuanto haga falta a cada usuario en particular.

Mi opción está clara: prefiero un software sólido, y que los plugins hagan el resto.

Tags: Desarrollo Web, General, minimalismo, Open Source, php, plugin, Software, WordPress

Artículos relacionados

• Y tenemos WordPress 2.1
• WordPress 2.1 Beta 3
• 281 – Tema para WordPress en español
• WPG2: WordPress + Gallery2
• WordPress y Habari
• WordPress 2.5… en serio
• Localización con WordPress