La muerte del código cerrado

+1
0
-1

Dejando aparte los tiempos heroicos de la computación, donde para poder acceder y programar una computadora se requería poseer un doctorado en matemáticas y uno en física, podemos decir sin temor a equivocarnos que la programación y con ella la creación de aplicaciones se ha vuelto un asunto relativamente trivial.

Hace años, saber un lenguaje de programación, permitía crear aplicaciones que con relativa facilidad se convertían en “éxitos”. Recuerdo que desde la versión 4 del memorable Turbo Pascal, se incluía entre los ejemplos el código completo de una hoja de cálculo sencilla.

Con el paso del tiempo aumentó notablemente el poder de las computadoras, la complejidad de los sistemas operativos, la versatilidad de los periféricos, y lo más importante: la sofisticación del usuario final. Así comenzaron a aparecer librerías (lo que hoy conocemos como Frameworks) que liberaban al programador de muchas tediosas tareas, especialmente las relacionadas con la interfaz de usuario.

Este modelo siguió creciendo y hubo entonces la necesidad de crear los IDE RAD al estilo de Visual Basic y Delphi; esto fue un gran avance, pero aumentó en forma significativa la cantidad de código “escondido” detrás de cada aplicación. Al día de hoy cualquier programador apenas comprende estos frameworks y simplemente los usa como cualquier ama de casa abre una lata de conservas y agrega su contenido al platillo.

Esto sin duda ha sido el mayor factor para permitir la absoluta preeminencia del software privativo en las computadoras de hoy. Las grandes empresas de editoras de software tienen por supuesto sus propios frameworks, y cuentan con grandes equipos de expertos programadores dedicados a ellos; de tal suerte que los equipos destinados a la creación de aplicaciones dispongan de las herramientas necesarias.

Hoy sin embargo, y como ha ocurrido recurrentemente en la historia humana, comenzamos a ver el desgaste de este modelo. Por una parte podemos apreciar como la complejidad de estos frameworks ha crecido en forma exponencial, de tal suerte que ahora los equipos de programadores, deben a su vez ser divididos para que puedan encargarse de las diversas partes componentes de estas piezas de código; de la misma forma que los equipos de desarrollo de aplicaciones se han dividido para encargarse se los diversos aspectos de la aplicación. Incluso vemos nuevos frameworks que a su vez están construidos sobre otros frameworks de un nivel mas bajo.

Si de buenos deseos se tratase, este modelo podría continuar hasta “el infinito y más allá”, pero claro tiene un límite: el financiero. ¿Qué tanto puede crecer la plantilla de programadores, analistas y coordinadores? Evidentemente solo mientras que exista la todo poderosa “Utilidad”.

Existe además otro gran problema: los programadores. Si bien la programación es una técnica, también es un arte y bueno, todos sabemos que los artistas no se dan en maceta, son tan escasos que aún seguimos recordando el nombre de Fidias y su obra cumbre en Atenas (el Partenón), nos sentimos conmovidos hasta el tuétano con los “Fusilamientos del 2 de mayo de Goya”, listos a abrazar a toda al humanidad tras escuchar la Novena Sinfonía de Beethoven, o un poco perversos tras escuchar algunas de las más famosas piezas de los Doors.

Así una empresa editora de software puede encontrar uno de esos genios, que producirá alguna de las más importantes secuencias de programación jamás escritas, y tal vez nada más; pero no se puede dar el lujo de despacharlo ya que nunca se sabe cuando tendrá otra genialidad.

Las empresas que viven del código cerrado comienzan a enfrentar la muerte por éxito. Han sido tan buenas, que para poder mantener el paso deben seguir incrementando la calidad y las prestaciones de sus productos, además deben ser capaces de crear nuevos, acordes a las realidades de cada instante. Por otra parte deben de ser capaces de modificar sus productos de acuerdo a las creaciones de otros, que tienen su propia agenda, rara vez compatible en principio con la propia.

En el software libre este problema no existe (hay otros). Los programadores van aportando las piezas que conforman el código de un producto a su propio ritmo, aparecen espontáneamente simplemente porque el código está ahí a la vista de todos, y en el momento que no tienen o no quieren hacer más de “eso” o cuando la calidad de sus creaciones decae, simplemente son sustituidos por otros.

El código cerrado no va a morir mañana, ni el año que entra, puede ser que aún se conserve “vigoroso” otros 20 años, pero el éxito lo está llevando a la tumba en forma irreversible.

Hoy ya vemos como casi todos los principales Frameworks para el desarrollo Web son libres, No hay un solo CMS de importancia que sea de código cerrado; vemos incluso como la mayoría de los grandes jugadores del negocio de Internet usan en forma preeminente el código abierto y su tendencia es al alza.

Sin embargo para que el software libre o incluso el Open Source tengan viabilidad tiene que cambiar el modelo de negocios. No es sostenible en el largo plazo un modelo en el que la única motivación real que tiene un programador de código abierto sea el ver su obra incluida en X o Y proyecto, en tanto que una minoría afortunada, a lo mejor no tan buena programando (sin arte), pero si con mucha habilidad política, obtiene un puesto bien remunerado en alguna empresa que lucra con el fruto del trabajo de muchos otros. De igual forma las casas editoras de software, no deben morir, deben transformarse para que continúen siendo como hasta ahora un factor relevante en la economía de cada país y del mundo entero.

¿Realmente hay escasez de programadores? Aquí dejo la liga a un vídeo que muestra al CEO de M$ haciendo el “Baile del Oso”. Independientemente del evento en el que ocurrió, a mi en lo personal me muestra que ya comienzan a sentir “desesperación”. ¿Hay por aquí algún psiquiatra que nos ilustre a respecto?

Comentarios

Imagen de Scorpyo82

Me ha gustado tu reflexión.
Da mucho que pensar.
Un saludo.

Si entro en Window$ estoy más tenso que en el bautizo de un gremlin.
Linux user: 545.017
Por favor, si solucionas el hilo añade [Solucionado] al título.

Imagen de furtaxi

Pero yo empecé a programar a los 15 años, sin estudios superiores ni nada. Primero, los diferentes Basic que traían las consolas-antecesor /Amstrad, Commodore, Spectrum), y luego ya en PC, desde el GWBasic al Clipper, pasando por Ensamblador, Pascal, DBase, el odioso (para mí) Cobol, y alguno que otro más.

Programar requiere una cierta aptitud personal, yo cambiaba de lenguaje de una semana a otra, incluso rehice desde cero un programa de contabilidad en gw-basic (con un código odioso, sin la más mínima estructuración, y plagado de "gotos" carentes de un simple comentario que dijera a donde iba) a Clipper. Y no tenía ni idea de contabilidad...

Pero con la llegada del Visual Basic y similares, por querer progresar ... dí un gigantesco paso atrás: Me matriculé en Formación Profesional, pensando que me iban a poner al día y se pasaron tres años tomándome el pelo con estupideces, y asignaturas absolutamente irrelevantes para la programación. Y me quedé atrás, porque el C ya había despegado, pero seguíamos haciendo los ejercicios en RPG .... Sí, marcando casillas en hojitas de papel...

Nunca aprobé unas "Matemáticas para la computación" en las que no se usaban ordenadores para nada (el profesor, era enemigo acérrimo de una calculadora de 8 dígitos, iba a dejar que tecleáramos código), ni una Contabilidad en que se hacían los mismo exámenes para todas las ramas de FP en el gimnasio, que en clase no cabíamos todos los suspensos, por un profesor tan bueno como duro, ni un inglés que basaba la nota en saberse de memoria los verbos irregulares, siendo insignificante que los alumnos, sin Internet de aquella, tradujéramos al vuelo las revistas de informática importadas de Estados Unidos, e, incluso, conocí a una persona que no le dieron el título por suspender gimnasia (una hora a la semana, menos el tiempo de cambiarse dos veces, a ver quién se pone en forma).

Así que dejé de programar. En el uso de librerías, apenas llegué por mi cuenta a algunas para usar el entorno en modo gráfico de Clipper, u otras que me hacía yo a medida con funciones propias. Pero me gustaba más el modo antiguo... desde cero, un editor de textos, y un manual, que cargar un generador de código, y dejar que te meta la porquería que quiera. Porque sólo hay que editar cualquier .exe en modo ascii, para ver que todo se repite una y otra vez, la misma cosa, se añade al ejecutable cuantas veces se llame.

Cuando contábamos los ciclos de procesador que necesitaba un bucle condicional, aprovechábamos la máquina al 100% ... ahora,, como hay velocidad de proceso y memoria de sobra, creo que todo es un desperdicio.

¿ Y a que viene todo ésto ?

Pues tenía ganas de decirlo, y rogar a cualquier programador que lo lea, que por favor, revise lo que haga, línea a línea, variable a variable. Estoy absolutamente seguro que estamos desperdiciando la enorme potencia que los ordenadores actuales nos proporcionan, lo que nos obliga a ampliarlos y renovarlos con más frecuencia de la que quisiéramos. Bastante menos, para los que usamos GNU/Linux frente a los que tienen a Windows en su disco, pero creo que mejores programas, desde el punto de vista del uso de recursos, podrían darle dos o tres años de vida más a nuestras máquinas.

Desgraciadamente, lo visual parece estar en el foco de atención, Beryl, Compiz, y ahora Unity... No es el camino que me gusta. (opinión personal, claro).

Mi web : www.vigovideo.es
Buscar es más rápido que esperar una respuesta.

Imagen de 11.10Elcelote

A mi me pasó igual!
en la Universidad Don Bosco de El Salvador, no hicieron mas que timarme!!!
Disque estaba yo en la carrera de Ingeniería en sistemas, y llevaba al mismo tiempo un técnico en computación, siempre en la Udb.

Lo mas gracioso es que en un ciclo nos enseñaban a crear los programas en C de;

-"hola mundo!!!"
-matrices 3x3
-a leer cadenas de caracteres

Y en el siguiente ciclo nos enseñaban a crear codigo para juegos!!!
Sin tener el mas minimo conocimiento de que diantres estaba yo haciendo!!
solo recuerdo que hablaban de unos famosos destructores(estructura C)

Un fiasco total.
me vacilaron y me robaron, hasta es mas, siempre que recuerdo eso, quiero demandar a esa institución.

Imagen de ivisdrek

El ejemplo que comentas está muy bien traído con respecto al tema de este hilo, pero de hecho puede aplicarse a casi todo hoy en día. El despilfarro de recursos y de energía es la tónica habitual en esta sociedad globalizada.
Todavía hablando de ordenadores, las prestaciones que trae el más básico de los aparatos que podamos comprar ahora mismo están estratosféricamente por encima de lo que necesitan la inmensa mayoría de los usuarios medios. Es como si para ir al trabajo me compro un fórmula uno. Es una locura.

La cantidad de energía que gastamos para que una autopista esté iluminada a medianoche como si estuviéramos en pleno día, la cantidad de comida que tiramos a la basura para que los stand de comida refrigerada de los hipermercados puedan mantenerse con un aspecto de superabundancia, etc., etc., es de quitar el hipo.

Pero bien es cierto que hablábamos de programación de código abierto vs. código cerrado. Pues más de lo mismo.

____________________________

https://eljardindelexilio.wordpress.com/

Imagen de Goyo

Al día de hoy cualquier programador apenas comprende estos frameworks y simplemente los usa como cualquier ama de casa abre una lata de conservas y agrega su contenido al platillo.

Esto sin duda ha sido el mayor factor para permitir la absoluta preeminencia del software privativo en las computadoras de hoy.

Yo lo dudo, no veo qué relación tiene una cosa con la otra.

Hoy sin embargo, y como ha ocurrido recurrentemente en la historia humana, comenzamos a ver el desgaste de este modelo.

¿Qué modelo? ¿El de usar bibliotecas y frameworks? ¿En qué se nota el desgaste? Yo no noto nada.

No es sostenible en el largo plazo un modelo en el que la única motivación real que tiene un programador de código abierto sea el ver su obra incluida en X o Y proyecto

No sé si es sostenible pero da igual porque la situación real no es esa. Muchos programadores de código abierto tienen motivaciones adicionales que en muchos casos son fundamentales en productos muy importantes (firefox, chromium, linux, gnome, ubuntu, libreoffice...)

Imagen de furtaxi

Si yo necesitaba un editor de texto para un programa (por ejemplo, que el usuario añadiera unos comentarios a un dato, sin que constaran en el capo memo), me lo hacía yo casi desde cero... tamaño del cuadrado de edición, ponerle un marco con códigos ascii, interceptar el teclado y detectar las pulsaciones de enter, flechas de dirección y retroceso, comprobar si una palabra sobrepasaba el tamaño de línea y mandarla a la siguiente... Hoy en día, llamas a la función windows-edit (o como se llame), y ya está.

Como, por ejemplo, la ventana de edición que estoy usando para escribir éste post. ¿ te imaginas hacerla desde cero, en un lenguaje de bajo nivel ? Pues los programadores de ahora, se ahorran éste trabajo, pero se pierde la impronta personal, la creatividad, Pero, muy seguramente, también rendimiento. Y originalidad, casi todos los foros, deben usar éste mismo módulo de edición, o con algunas variaciones.

Sí, se trabaja más rápido, no lo niego. pero los,, no ya Kb, sino Mb, se van engullendo, haciendo que cada vez necesitemos mejores máquinas.

Vamos, la pescadilla que se come la cola... Windows nuevo, ordenador nuevo, y cuando alguno de los dos pide más, a cambiarlo. Por ejemplo.

No propugno que todo el mundo programe todo en código máquina o ASM, sería impensable para todas las cosas que hacen ahora los programas, pero si pienso que algunas tareas, deben ser hechas por cada programador, buscando la eficiencia, en vez de utilizar módulos multipropósitos sobredimensionados.

Como el office, tanto el privativo como el libre... Yo no uso ni el uno por ciento de sus posibilidades (con el gedit me sobra para el 99% de las ocasiones, y he dicho que me sobra, tampoco lo exprimo más allá que escribir y guardar). Y aún gente que trabaje en su entorno idóneo, las oficinas, dudo que necesiten ni la mitad de sus capacidades.

Creo que una mirada a los orígenes, no viene mal de vez en cuando. A mi me costaba menos hacer un programa desde cero, en muchas ocasiones, que buscar y arreglar fallos de lo que había.

De hecho, me gusta usar un programa para cada tarea, en contraposición a las suites. Para DV, capturo con Kino y edito con Cinelerra. Podría hacer la dos cosas con sólo uno de ellos, pero es que he comprobado que son dos tareas diferentes, que se hace mejor en cada uno de ellos. En HDV, Kdenlive. A veces, paso por fireware con un dvgrab en terminal, en vez de usar la captura de Kdenlive, si estoy haciendo, a la vez, otras tareas pesadas, y así conservo recursos para todo.

Si fuera un programador en activo, haría una aplicación para cada cosa, perfeccionando su funcionamiento (Cinelerra puede ser muy inestable con algunos tipos de fichero, y Kdenlive me presenta problemas con la previsualización), pero no me metería en una suite para todo... porque sé que la gente, rara vez tiene más de un tipo de cámara de vídeo, con un formato de archivo y resolución diferente. Suelo huir de las suites, porque siempre tienen algo que sobra.

Con los frameworks o librerías, más o menos lo que dice el autor del hilo... facilidad, a cambio de que tengas que tener muchas posibilidades, para usar sólo unas pocas.

Mi web : www.vigovideo.es
Buscar es más rápido que esperar una respuesta.

Imagen de Goyo

Sí, se trabaja más rápido, no lo niego.

Ni yo. ¿En qué se supone que estamos en desacuerdo esta vez?

Imagen de furtaxi

Al día de hoy cualquier programador apenas comprende estos frameworks y simplemente los usa como cualquier ama de casa abre una lata de conservas y agrega su contenido al platillo.

Yo si la veo. No es lo mismo abrir una lata, que pasarte 6 meses en el mar del norte con olas de 15 metros, para pescar su contenido. Es más sabio el que va en el barco (entre otras cosas, porque es capaz de mantener el estómago por debajo del pecho, y por encima de las rodillas). Pero está mejor visto el que vende las latas, que vomitaría en una barquita en un lago.

Digamos que defiendo el trabajo desde la base. Hoy en día, tiene mucho más mérito, precisamente, porque nadie quiere hacerlo... prefieren ir a la estantería del supermercado, y pillar el framework que necesita.

Mi web : www.vigovideo.es
Buscar es más rápido que esperar una respuesta.

Imagen de Goyo

En ésto, que no le ves la relación... Yo si la veo.

No sé si me expliqué bien. Me refería a que no veo cómo la costumbre de usar frameworks ("como cualquier ama de casa abre una lata de conservas y agrega su contenido al platillo") puede ser el mayor factor para permitir la absoluta preeminencia del software privativo. Si tú puedes verlo, lo que dices no me aclara el misterio.

prefieren ir a la estantería del supermercado, y pillar el framework que necesita.

Al supermercado se va tanto para programar software privativo como para programar software libre y en la estantería hay frameworks privativos y también frameworks libres. ¿Dónde está la ventaja para el software privativo?

Imagen de furtaxi

En que las librerías del soft privativo, se usan en programas privativos que dominan el "mercado" (lo pongo entre comillas, porque no todos los usuarios acuden al mercado a comprar soft, lo pirateado o lo libre, creo que es lo más normal).

Obviamente, si no tienes acceso al código, de, por ejemplo, los frameworks de Autodesk Autocad, los programas libres no podrán superarlo (y concedo que Autocad sea superior... en herramientas inútiles o de nulo uso, por ejemplo, no sé si se nota que le tengo antipatía :) ). Sin embargo, otros productos de la misma empresa, los pueden reutilizar y apropiarse de otro segmento del mercado.

Claro, volvemos a lo de antes... para que ésas librerías funcionen en todos los productos de Autodesk, estarán sobrecargadas de funciones, que no se usan en cada uno de ellos.

Por lo tanto, la utilización abusiva de frameworks, beneficia a las empresas privativas, porque no les duele el desperdicio de recursos del usuario, y siendo la base del programa común, los adornos les permiten vender diferentes productos. Además, seguro que se llevan comisión por venta de equipos más potentes.

Mira ésta lista:

http://latinoamerica.autodesk.com/adsk/servlet/item?siteID=7411870&id=93...

Seguro que todos comparten componentes metidos en un sólo framework. Puede que se molesten en hacer modificaciones especiales, como variar el anticopia, o los colores de las ventanas... pero te toca soltar el dinero por cada uno de ellos.

Mi web : www.vigovideo.es
Buscar es más rápido que esperar una respuesta.

Imagen de Goyo

Lo siento, me perdí al llegar a "Por lo tanto..."

la utilización abusiva de frameworks, beneficia a las empresas privativas, porque no les duele el desperdicio de recursos del usuario, y siendo la base del programa común, los adornos les permiten vender diferentes productos.

Pero el software libre también puede usar (y de hecho usa) frameworks con adornos. ¿Dónde está aquí la ventaja para el software propietario? ¿En lo del dolor?

Además, seguro que se llevan comisión por venta de equipos más potentes.

Sí, esta parte la entiendo. El uso generalizado de frameworks "pesados" estimula el mercado de los hierros y aumenta la cuantía de las supuestas (¿seguras?) comisiones. Con ese dinero adicional pueden escribir código, poner anuncios, susurrar al oído de políticos y personas influyentes y cosas semejantes que contribuyen a que su software sea más preeminente. Aunque tanto como "el mayor factor"... no sé yo.

Imagen de furtaxi

Pero el software libre también puede usar (y de hecho usa) frameworks con adornos. ¿Dónde está aquí la ventaja para el software propietario? ¿En lo del dolor?

Un framework de GNU/Linux, puede referirse a alguna función, a una apariencia... Por ejemplo, muchos programas de vídeo utilizan Dvgrab, que no esté, en absoluto, sobredimensionado. Pero Kino y Kdenlive, se parecen ... en la "K" inicial, poco más. Digamos que en el software libre, los frameworrks (y similares, tampoco dvgrab casaría así con la definición) son muy concretos, para realizar una parte de un trabajo.

En cambio, en el soft privativo, tiene tendencia a querer hacerlo todo, llevar todas las funciones paridas y por parir, en cuatro paquetes enormes, que luego no hay manera de actualizar sin convocar un cónclave de programadores. El mismo Windows, tomado como un meta-framework, es así, se tiran años y años ocupando memoria en disco y en RAM, y cuando lo quieren actualizar (service packs), le provocan una obesidad mórbida crónica. Y, dicho sea de paso, un penoso detrimento del rendimiento... Un Windows sin actualizar a los service packs, es muchísimo más rápido... quiero decir, menos lento. :)

Pero como Windows viene preinstalado, al usuario le importa medio pimiento que la mitad del potencial de su flamante ordenador éste destinada a permitir que el S.O. funcione.

(He exagerado un poco tomando como ejemplos de framework a dvgrab y a Windows)

Edito: Un aspecto más... Los programadores privativos, compiten entre ellos. es más, tienen que vender su código, procurando que los demás no sepan como funciona, para que no se lo "soplen. En Soft libre, es justo al revés.

Obviamente, mantener un framework enorme, con unos programadores que se ocultan entre sí parte de la información, alarga los procesos de actualizaciones y aparición de nuevas aplicaciones. Para compensarlo, más publicidad, más instalaciones de prueba u OEM, y más medios para copar el mercado (que, en definitiva, es lo que consigue que la gente compre o use), y amortizar un trabajo que les sale muy caro. Comisiones y negociaciones incluidas, para que uno sepa lo que hace el código de otro... si es que no se lo entrega ya compilado en forma de .exe o .dll.

Mi web : www.vigovideo.es
Buscar es más rápido que esperar una respuesta.

Imagen de Goyo

Muy interesante todo esto que me cuentas. Tal vez recuerdes todavía que yo preguntaba por las supuestas ventajas que el uso de frameworks da al software privativo sobre el libre.

PS.

(He exagerado un poco tomando como ejemplos de framework a dvgrab y a Windows)

No has exagerado, se te ha ido la pinza.

Imagen de furtaxi

Tal vez recuerdes todavía que yo preguntaba por las supuestas ventajas que el uso de frameworks da al software privativo sobre el libre.

Te lo resumo... Que en software privativo, los frameworks se usan como herramientas para esclavizar clientes, atraídos por los fuegos artificiales, mientras que en el libre, para que las aplicaciones sean mejores.

El costo gigantesco de las empresas privativas para desarrollarlos y mantenerlos, con enormes dificultades por temas de autoría, patentes y similares, se traslada sin pudor a los usuarios. Y, como feedback, ésto van y pagan, por lo que son reacios a perder su inversión, y usar soft libre.

No has exagerado, se te ha ido la pinza.

Esto es algo normal en mí...
:)

Mi web : www.vigovideo.es
Buscar es más rápido que esperar una respuesta.

Imagen de Goyo

Por fin lo entendí. Los fascinantes pero inútiles fuegos artificiales, posibles o mejorados en el software privativo gracias a los frameworks y ausentes o minimizados en el software libre, son lo que atrae irremisiblemente a los clientes (que deben ser idiotas perdidos) hacia el software privativo, igual que la luz de la trampa luminosa a las moscas (que sí son idiotas, en esto no puede caber duda alguna).

Si además de entenderlo me lo creyera tendría a mi disposición un excelente framework para explicar la prevalencia del software privativo:

Sin duda los <palabro> son el mayor factor que ha permitido la absoluta preeminencia del software privativo. Porque, en software privativo, los <palabro> se usan como herramientas para esclavizar clientes, atraídos por los fuegos artificiales, mientras que en el libre, para que las aplicaciones sean mejores.

Veamos: python, java, las app stores, las actualizaciones automáticas... ¡demonios! redactándolo un poco creo que hasta las interrupciones podrían encajar.

Imagen de furtaxi

De éste hilo... ya hemos atrapado a unos cuantos posteadores gracias al framework multidisciplinar.

Están en nuestras manos, a partir de ahora, pagarán por leer ubuntu-es.

:)

Por cierto, es curioso. Los programas de Windows, suelen tener una pantalla de presentación animada, con muchos colorines, y tal. Y parece que éso gusta. Habría que crear un framework que usaran todos los programas libres, para que la gente se entretenga mientras se cargan los demás frameworks.

Seguro que entonces, dirían que las aplicaciones libres son mejores.

Mi web : www.vigovideo.es
Buscar es más rápido que esperar una respuesta.

Imagen de gato2707

Las citas que me haces notar, así fuera de contexto pues no tienen mucha relevancia claro. Me gustaría que comentaras el texto y su idea general.

Si lo reflexionas un poco, me refiero al aumento de complejidad por capas, donde cada capa al ser de código cerrado, requiere de su propio equipo de especialistas, y que estén de vena para poder cambiar en forma óptima su parte del código. Además con cada nueva capa se requiere de nuevas coordinaciones entre los equipos de cada capa y así sucesivamente. Digamos que es como la burocracia que tiende a crecer en forma indiscriminada.

Si bien yo aprendí a programar de la misma forma que 11.10Elcelote y furtaxi, empezando por el Fortran IV con tarjetas perforadas, la verdad y a diferencia de él no extraño tener que programar cada coordenada del monitor, me gustan los frameworks, pero algunas veces extraño el poder ver las entrañas de algo porque mi instinto me dice que algo ahí adentro huele mal, claro por lo general no tengo tiempo.

Los productos de código cerrado se van a "morir" debido a que llegará un momento en que su complejidad sea tal que ningún equipo en particular será capaz de mantenerlos. Especialmente con el aumento tanto en el número de aplicaciones, a la complejidad de las mismas, como en la necesidad de actualización. Como sabemos el código abierto funciona de otra forma y el único límite a la cantidad de participantes en cada proyecto es el número total de programadores del planeta. El límite en este caso es el interés, y como todos sabemos "el interés tiene pies". De código abierto o cerrado los programadores tienen que comer.

La idea por supuesto no es nueva, ya en "La catedral y el bazar" se hablaba de algo así.

Saludos desde México
Mi Web: El Gato con Linux

Imagen de Goyo

Tienen relevancia para mí. No espero que las citas se interpreten fuera del contexto sino que, por el contrario, sirvan como referencia para poder situar mis comentarios en él sin tener que reproducirlo por completo.

En general, ya que lo preguntas y con ánimo constructivo (por si no lo parece, es que yo soy así), me parece que contiene afirmaciones poco claras, demasiado espectaculares y poco respaldadas por argumentos y datos. De ahí mis preguntas que según lo veo yo siguen sin ser contestadas y que reformulo por si no estaban claras.

¿Cómo favorece al software privativo la costumbre de usar frameworks del modo en que se usan?

¿De qué modelo comenzamos a ver el desgaste? En principio me pareció que te referías al uso de frameworks (¿y bibliotecas?) pero ahora pienso que probablemente es el modelo de desarrollo cerrado ("catedral"), o tal vez a la unión de ambas cosas... Bueno, no sé, por eso lo pregunté. En todo caso ¿dónde se comienza a ver el desgaste? ¿adónde hay que mirar para verlo?

Imagen de gato2707

No sé si es sostenible pero da igual porque la situación real no es esa. Muchos programadores de código abierto tienen motivaciones adicionales que en muchos casos son fundamentales en productos muy importantes (firefox, chromium, linux, gnome, ubuntu, libreoffice...)

¿Muchos? ¿Cuántos? ¿Cuantas líneas de código libre o abierto están en cualquier cantidad de proyectos y por las que no se ha pagado un solo centavo, a pesar de que estos producen ingentes cantidades de dinero?

Yo no soy de izquierda, creo en eso de ayudar al próximo, pero también creo que el buen trabajo honesto merece una adecuada retribución económica y no solamente palmaditas en la espalda.

Saludos desde México
Mi Web: El Gato con Linux

Imagen de Goyo

¿Cuántos? No lo sé, pero no es relevante para mi argumento. El ver su obra incluida en un proyecto no es la única motivación de un programador de código abierto. Bueno, a lo mejor de uno sí pero de otro no. El caso es que tú describes el modelo como si solo estuviera el uno y no el otro y eso no es así, están los dos. En realidad son mucho más de dos, pero me meteré en honduras sin necesidad.

Los merecimientos, por otro lado, no me parece que afecten a la cuestión. Al fin y al cabo ¿quién tiene lo que se merece?

Imagen de gato2707

pero me meteré en honduras sin necesidad.

Los merecimientos, por otro lado, no me parece que afecten a la cuestión. Al fin y al cabo ¿quién tiene lo que se merece?

Al igual que tu creo que nos estaríamos metiendo en honduras sin necesidad; esta vez me alegro de no coincidir contigo. Llegué, estuve y deje el Pesimismo de Shopenhauer mucho tiempo ha.

Dejemos pues esta discusión por la paz, que con seguridad habrá otras en el futuro donde podamos seguir intercambiando ideas en forma tan sabrosa como siempre.

Saludos desde México
Mi Web: El Gato con Linux