Algunos consejos prácticos sobre cómo poner precio a tu aplicación web: How to price your web application. Es una lectura interesante en la que se nos habla de cómo diferenciar los distintos planes, qué estrategia de precios puede resultar interesante, etc.

Si os interesa este tema y no lo habéis leído, es imprescindible leer Camels and Rubber Duckies de Joel Spolsky.

Por cierto, leyendo el artículo sobre Endeve en Alzado la respuesta parece ser: En España, mejor no le pongas precio.

Resumiendo: Endeve es una aplicación para gestionar nuestras facturas, especialmente recomendado para autónomos y pequeñas empresas. Hace un año, decidieron abrir la plataforma y poner gratuita una buena parte de su funcionalidad. Aunque han conseguido multiplicar sus usuarios (gratuitos) un 800%, parece que muy pocos usuarios pagan por el servicio (o por lo menos esa es mi impresión tras leer el artículo).

¿Cual es el problema? ¿Quizá esa aplicación no interesa a su publico objetivo? ¿O es que en España nadie quiere pagar por una aplicación web? ¿Alguna empresa ha conseguido vivir de una aplicación web?

En Design-Nation se han lanzado a la aventura de convertirse en una microISV(Micro Independent Software Vendor) y a raíz de la aparición de su primer producto, han escrito un artículo reflexionando sobre la creación del mismo: FND postmortem

Aunque yo le diría a Cesar, su creador, que el nombre del artículo no está muy bien traído (al fin y al cabo, se supone que su producto no está mortem sino recién nacido) creo que es una lectura que merece la pena. Nos habla de dónde encontrar motivación, de lo importante que es saber delimitar qué funcionalidades debemos incluir y cuales descartar, y mucho más.

Un tema este del microISV que me parece que es muy interesante y que merece un artículo más largo. Por ahora os dejo con la definición y referencias en la Wikipedia

Un defecto que se achaca a diversas metodologías es que no están basadas en estadísticas de mejoras de productividad, sino que se basan en la impresión anecdótica de sus desarrolladores. Puede que se deba al estado aún primitivo de la ingeniería del software, donde hay poco regulado y las diferencias de productividad entre dos métodos quedan en gran medida minimizadas por las enormes diferencias de productividad entre unos programadores y otros y al efecto Hawthorne.

En cualquier caso, algunos seguidores de la Programación Ágil han creado un wiki donde se recopilan, anotadas, referencias bibliográficas sobre esta metodología de desarrollo: Agile Bibliography Wiki

Una buena cantidad de lecturas para comprobar la eficiencia (o no) de la Programación Ágil.

Creo que son muy interesantes la serie de artículos publicados por Martín Pérez sobre cómo el trabajo en un proyecto de soft libre puede desembocar en una oportunidad laboral: Sobre Software Libre y las nuevas formas de encontrar trabajo.

Divide las oportunidades según sea crear un nuevo proyecto o unirse a uno ya existente. Algunas de estas son:

• Que el producto tenga éxito y puedas montar una empresa alrededor de él.
• Que te contrate alguien que utilice tu producto.
• Que los contactos hechos en el proyecto te ofrezcan trabajo.
• La mejora demostrable de tus conocimientos en una tecnología (no solo puedes decir que has leído un libro sobre ROR, por ejemplo, puedes demostrar con código que lo conoces).

Sergio Montoro reflexiona en La Pastilla Roja sobre cosas que son demasiado fáciles:

Y por último, por la parte que me toca, odio los lenguajes de scripting y todas las herramientas de desarrollo rápido que sólo nos han traído la filosofía de “Paco esto tenlo listo para mañana”. Programar en ensamblador con 16Kb y programas re-entrantes era igual de divertido que hacerlo en Rails o en lo que toque ahora, y, al menos, los clientes no asumían que el software es algo así como las setas, que crece en el servidor por la noche y está listo para hacer un guiso en la mañana.

Por cierto, Sergio escribe siempre unos muy buenos artículos de opinión en La Pastilla Roja, muchos sobre consultoría y desarrollo en general (no sólo sobre software libre) y merece la pena leerle en ese blog, aunque el tema del software libre no sea de nuestro interés (que también).

No os perdáis tampoco los artículos de Sergio Montoro aquí, en Versión Cero.

Interesante el artículo Developers are from Mars, Programmers are from Venus, en el que se definen y contraponen las actitudes del programador (centrado en la tecnología, el código bonito y los puzles lógicos) frente al desarrollador (que se preocupa de obtener una solución centrada en el cliente y del proyecto como un todo, más allá del código).

Aunque algo estereotipado y claramente favorable al desarrollador, el artículo presenta estas dos visiones del desarrollo de software con las que todos tenemos que lidiar.

Relacionado: Small ISVs: You need Developers, not Programmers, un artículo anterior de Eric Sink con una opinión parecida.

Desde La Pastilla Roja nos avisan de una nueva votación sobre las patentes de software en el parlamento europeo.

Algunos datos preocupantes:

• La Oficina Europea de Patentes es un organismo no comunitario que concede patentes bajo sus propios criterios y que la UE acepta en virtud de un acuerdo.
• En caso de aprobarse no existiría ningún control político ni judicial sobre las patentes concedidas y no cabría recurso en los tribunales nacionales.
• Todos los paises con idiomas distintos del inglés estarían en desventaja competitiva.

La anterior votación sobre patentes de software fue rechazada.

Puede que muchas personas no lo sepan, pero Versión Cero nació como un proyecto hermano de Planeta Código, proyecto del que salieron los primeros editores de Versión Cero.

Planeta Código tiene varias partes, un agregador de weblogs que es la parte principal, pero también un wiki sobre desarrollo, y unos foros.

Sobre los foros os quiero hablar hoy. Y es que bajo mi punto de vista son unos foros de gran calidad, de poco tráfico pero con gente muy interesante suscrita, gente que sabe mucho sobre desarrollo de software. Difícilmente obtendrás una respuesta muy técnica en estos foros (“¿Cómo se utiliza la función X de C#?”) pero desde luego podrás charlar sobre desarrollo de software con gente con experiencia real.

Y como muestra un botón: En un mensaje llamado Dudas, dudas y mas dudas, se le dan consejos muy interesantes (técnicos y organizativos) a uno de los tantos informáticos desesperados que hay en esta profesión.

Desde hace unos días, los foros de Planeta Código son también los foros de Versión Cero, y como tales aparecen enlazados en la parte superior de este weblog.

Últimamente he leído un par de análisis interesantes sobre Ruby on Rails.

Por un lado, y de producción hispana, tenemos Ruby on Rails, ¿vale la pena?, desde el weblog Sobre Raíles. Para su autor, Rails es un entorno ventajoso respecto a PHP para el desarrollo web.

Por otro lado, en EvaluatingRuby, Martin Fowler analiza tanto Ruby como ROR (Ruby On Rails). Lo considera una buena opción y relata algunas experiencias positivas dentro de su compañía.

Juan Palacio analiza en Navegapolis las diferencias entre las empresas “manufactureras” y las empresas del conocimiento (como podría ser una empresa de software).

Las empresas manufactureras o industriales parten de una materia prima, sobre la que trabajan personas, usando unos procesos y aplicando una tecnología. En estas condiciones, las empresas tratan de optimizar su producción mejorando los procesos y minimizando el valor de las personas, ya que es la forma más eficiente de asegurar la calidad del producto de forma predecible.

Ahora bien, ¿qué ocurre cuando dicha mentalidad se aplica a las empresas de conocimiento? Para Juan Palacio, la clave es preguntarse ¿cual es la materia prima de una empresa de conocimiento?

La respuesta es: El talento.

Con esta premisa, minimizar el valor de las personas va en contra de la lógica ya que con una materia prima mediocre sólo conseguiremos productos mediocres.

Termina diciendo:

Las pautas que en los entornos industriales logran eficiencia, en el software producen mediocridad.
Gestionar empresas del conocimiento con teoría de management industrial genera productos mediocres y técnicos desmotivados.

Una muy interesante lectura.