The killer ClubDelphi application... (antes: aportarias tu codigo?)

[mamcx]

No indipensablemente.

Es por eso que la eleccion de herramienta no puede ir al principio, porque si no estan los requerimientos no se sabe que se va a hacer.

Sin embargo si seria una eleccion obvia Delphi, siendo este el clubdelphi, no necesariamente seria la unica opcion. Podria ser que la solucion requiera un hibrido entre cliente nativo y servicios de internet, o incorporar lenguaje de scripting como python o algo asi.

[jorge1987]

Bueno eso es cierto, entonses lo dejamos para despues, entonses, en que quedamos, que aplicacion vamos a intentar hacerla volar?

Saludos

[Ñuño Martínez]

Como ha dicho Al Gonzalez, con el que estoy completamente de acuerdo, primero habrá que definir el modelo de trabajo. Si no hay objeciones, querría ser el primero en hacer una proposición.

Supongo que será un proyecto de código abierto y de libre distribución, al estilo GPL (por cierto, que yo tengo una licencia adaptada a la legislación europea aprobada por un abogado, pueden echarla un vistazo aquí).

En estos casos se suelen utilizar dos modelos de gestión, la cátedra y el bazar. Brevemente:

• En la cátedra hay uno o varios administradores que se encargan de dirigir el proyecto. Estos administradores son los que deciden todo: cómo será el proyecto, quién trabajará en él, qué tareas realizará cada colaborador, qué calendario se seguirá... Sus decisiones pueden ser más o menos dictatoriales, pero nadie que no pertenezca al grupo de catedráticos tiene poder de decisión. Un ejemplo de cátedra es el proyecto Open Office.
• El bazar es casi opuesto: existe uno o varios administradores, pero estos se limitan a recibir las colaboraciones y a montarlas dentro del proyecto. No suelen existir pautas respecto a cual será la evolución futura del proyecto y vale casi todo, siempre que entre dentro de las características básicas del proyecto. Un ejemplo de bazar es el proyecto Allegro.

Seguro que pueden completarse estas definiciones, pero creo que sirven para hacerse una idea.

Una buena estrategia suele ser empezar con un modelo de cátedra y más adelante, cuando el proyecto ha madurado y existen varias versiones estables, se puede abrir más hacia el modelo bazar sin miedo ya que esa madurez hará que el proyecto crezca con una guía mínima.

Esta es mi opinión.

[EDIT]Hay veces que corro demasiado, y creo que esta es una de esas ocasiones...

[Casimiro Noteví]

Empezado por Ñuño Martínez

Como ha dicho Al Gonzalez, con el que estoy completamente de acuerdo, primero habrá que definir el modelo de trabajo. Si no hay objeciones, querría ser el primero en hacer una proposición.

Supongo que será un proyecto de código abierto y de libre distribución, al estilo GPL (por cierto, que yo tengo una licencia adaptada a la legislación europea aprobada por un abogado, pueden echarla un vistazo aquí).

En estos casos se suelen utilizar dos modelos de gestión, la cátedra y el bazar. Brevemente:

• En la cátedra hay uno o varios administradores que se encargan de dirigir el proyecto. Estos administradores son los que deciden todo: cómo será el proyecto, quién trabajará en él, qué tareas realizará cada colaborador, qué calendario se seguirá... Sus decisiones pueden ser más o menos dictatoriales, pero nadie que no pertenezca al grupo de catedráticos tiene poder de decisión. Un ejemplo de cátedra es el proyecto Open Office.
• El bazar es casi opuesto: existe uno o varios administradores, pero estos se limitan a recibir las colaboraciones y a montarlas dentro del proyecto. No suelen existir pautas respecto a cual será la evolución futura del proyecto y vale casi todo, siempre que entre dentro de las características básicas del proyecto. Un ejemplo de bazar es el proyecto Allegro.

Seguro que pueden completarse estas definiciones, pero creo que sirven para hacerse una idea.

Una buena estrategia suele ser empezar con un modelo de cátedra y más adelante, cuando el proyecto ha madurado y existen varias versiones estables, se puede abrir más hacia el modelo bazar sin miedo ya que esa madurez hará que el proyecto crezca con una guía mínima.

Esta es mi opinión.

[EDIT]Hay veces que corro demasiado, y creo que esta es una de esas ocasiones...

La Catedral y el Bazar, de Eric. S. Raymond

[jorge1987]

Empezado por Ñuño Martínez

Como ha dicho Al Gonzalez, con el que estoy completamente de acuerdo, primero habrá que definir el modelo de trabajo. Si no hay objeciones, querría ser el primero en hacer una proposición.

Supongo que será un proyecto de código abierto y de libre distribución, al estilo GPL (por cierto, que yo tengo una licencia adaptada a la legislación europea aprobada por un abogado, pueden echarla un vistazo aquí).

En estos casos se suelen utilizar dos modelos de gestión, la cátedra y el bazar. Brevemente:

• En la cátedra hay uno o varios administradores que se encargan de dirigir el proyecto. Estos administradores son los que deciden todo: cómo será el proyecto, quién trabajará en él, qué tareas realizará cada colaborador, qué calendario se seguirá... Sus decisiones pueden ser más o menos dictatoriales, pero nadie que no pertenezca al grupo de catedráticos tiene poder de decisión. Un ejemplo de cátedra es el proyecto Open Office.
• El bazar es casi opuesto: existe uno o varios administradores, pero estos se limitan a recibir las colaboraciones y a montarlas dentro del proyecto. No suelen existir pautas respecto a cual será la evolución futura del proyecto y vale casi todo, siempre que entre dentro de las características básicas del proyecto. Un ejemplo de bazar es el proyecto Allegro.

Seguro que pueden completarse estas definiciones, pero creo que sirven para hacerse una idea.

Una buena estrategia suele ser empezar con un modelo de cátedra y más adelante, cuando el proyecto ha madurado y existen varias versiones estables, se puede abrir más hacia el modelo bazar sin miedo ya que esa madurez hará que el proyecto crezca con una guía mínima.

Esta es mi opinión.

[EDIT]Hay veces que corro demasiado, y creo que esta es una de esas ocasiones...

Si tengo que analizar los ejemplos utilizados, a mi me parece que el modelo de OpenOffice es un buen modelo, nose ustedes, espero mas comentarios al respecto.

Saludos

[[Al González]]

¡Hola a todos!

Mis colaboradores y yo actualmente experimentamos con un modelo llamado DTE. Aquí algo que publiqué al respecto el año pasado:

http://www.clubdelphi.com/foros/showthread.php?t=25463

Ojalá se retome también ese hilo, porque realmente pienso que la Red Colaborativa DTE sería algo muy bueno para todos.

Y aunque el esquema DTE aún está en proceso de maduración, creo que por ser el planteado un proyecto sin altas presiones económicas o de tiempo, podríamos darnos el lujo de probarlo en él.

Un abrazo distribuido.

Al González.

[Ñuño Martínez]

No he leído tu artículo entero, sólo las dos primeras partes, pero me parece algo realmente interesante y que, de imponerse en España, me ayudaría mucho a encontrar trabajo (¿Por qué es tan difícil que los empresarios entiendan que soy el mejor? ).

Por ahora estoy completamente de acuerdo con ese sistema de distribución del trabajo, y no es incompatible (a mi parecer) con el sistema "Cátedra" y aún menos con el "Bazar" de los que hablé antes.

Me sentiría realmente orgulloso por colaborar en un proyecto así, que podría derivar en un producto y un paradigma revolucionarios...

[jorge1987]

Y, en que quedamos?

Saludos

[[Al González]]

¡Hola a todos!

Empezado por Ñuño Martínez

...No he leído tu artículo entero, sólo las dos primeras partes, pero me parece algo realmente interesante...

Gracias por el comentario, pero creo que te has perdido de la mejor parte (la Red Colaborativa).

Por cierto, si alguien quiere publicar mi artículo en su Web, siéntase con la libertad de solicitarme el texto original.

Anoche estuve pensando que sería conveniente revisar la organización de las especialidades ahí propuestas. Después de haber ganado algo de experiencia en este experimental modelo, creo que sería adecuado colocar PO (la programación escrita para las interfaces de usuario), PB y PL —Programación de Lógica de negocios (nueva)— como subespecialidades de una nueva especialidad abreviada como "PR" (Programación). Y considerar RE como parte de DO (diseño visual de las interfaces de usuario), o sea, no mutuamente exclusivas. En cuanto a MD aún tengo mis dudas de si debe aparecer o dónde debe ir, ya que todavía no he puesto en práctica esa especialidad de manera formal, aislada o explícita.

Algo que me faltó agregar en mi propuesta hecha en este hilo (sobre el esquema de trabajo), es que también es importante definir la normativa de desarrollo, es decir, las reglas de estándares, estilos, nomenclaturas y demás que deberán seguirse durante el desarrollo del software, para no sólo trabajar bajo el mismo lenguaje sino también hablar el mismo idioma. Este asunto suele generar polémica cuando existe demasiado apego u obstinación a la manera de programar de cada uno, y para mí es uno de los parámetros clave que determina si una persona tiene o no facilidad para integrarse al trabajo en equipo; si antepone o no los objetivos del grupo a sus gustos personales.

En resumen, reiterando mi propuesta y, claro, si la mayoría de los interesados están de acuerdo, definamos el esquema general de trabajo y luego el proyecto de software.

Un abrazo esperando comentarios.

Al González.