[eside-ghost] [Itsas] ¿El fin de una era de internet frenada por el Internet Explorer? Google Chrome Frame

[Alfredo Beaumont]

2009/9/27 Jon Ander Hernandez <jonan.h a bildua gmail.com>:
>> No digo que los miembros del equipo no quisieran ser más abiertos,
>> digo que no lo fueron, y estamos hablando que desde el 2002 hasta el
>> 2005 la situación era prácticamente de imposible colaboración. Incluso
>> después del 2005, la 'liberación total' sólo es aparente. La política
>> de desarrollo de webkit es muchísimo más restrictiva que la de KDE:
>> todos los parches tienen que ser revisados (proceso bastante lento),
>> conseguir acceso directo al repositorio es otro proceso bastante
>> lento, etc. etc. Totalmente contrario a la política de KDE a la que
>> los desarrolladores de KHTML están acostumbrados.
>
> El proceso de revisión de parches por 2 reviewers, es posible que sea
> lento para nuevas contribuciones, pero viendo el número de reviewers
> que existen actualmente está claro que todos los que han contribuido
> regularmente han recibido la condición de reviewers. No me parece tan
> dramático como lo planteas, en otros proyectos como el kernel también
> se requiere de una revisión por sus correspondientes mantenedores.

Cada proyecto tiene su forma de trabajar. El kernel es una dictadura,
KDE es una democracia.

> Y desde luego hay muchísima gente trabajando en el proyecto (Apple,
> Chromium, Nokia/Trolltech, Igalia, Gnome, etc....), y tampoco
> encuentro que la gente esté quemada con esto.

Bueno, en realidad todos los participantes que enumeras tienen modelos
de desarrollo más cerrados que KDE (desconozco el de GNOME, pero
intuyo que también). Aún así, la situación es muy diferente. Todos los
participantes del proyecto se han sumado a posteriori a un proyecto
con unas reglas preestablecidas. No es lo mismo 'estás en mi casa y
haces lo que yo diga' a entrar en casa de otro y establecer tus
reglas.

>> Esto también sería motivo de múltiples flames... Habría que coger cada
>> uno de estos proyectos y mirarlos más de cerca... y ver si realmente
>> se 'comparte' y 'unifica'. Deberías haber venido al GCDS, para ver
>> cómo se repartía brea especialmente con el tema de freedesktop. Así le
>> podrías haber preguntado en petit comité al mantenedor de poppler qué
>> opina del tema :D
>
> Joer pues se me escapa un poco los motivos de tanta polémica con
> Freedesktop, porque aunque sé que se han vertido críticas no las he
> leído. Aunque IMHO yo no creo que esté funcionando mal, por lo menos a
> nivel de proyectos Freedesktop nunca ha estado tan activo y con tanta
> comunidad, con grandes proyectos como : Xorg, Mesa3D, HAL/DeviceKit,
> dbus, Cairo, Gstreamer, Telepathy, etc...

Me temo que la realidad es un poco diferente de como la pintas, creo
que basta con mirar el listado de proyectos que has mencionado para
intuir por dónde van los tiros, sin contar los problemas burocráticos
que hacen que el proyecto no funcione tan bien como debería.

>> De todas formas, todo depende de lo que quieran hacer los
>> desarrolladores. La gente lleva años hablando de webkit en KDE, pero
>> aún no hay un navegador en KDE con webkit que ofrezca lo mismo que
>> KHTML, así que tampoco parece que el interés sea real. Si algún día
>> hay un interés real, y se consigue integrar webkit al mismo nivel que
>> KHTML, puede que la cosa cambie. De momento no es así.
>
> Yap, pero bueno... por lo que entendí, el problema de tener un
> konqueror basado en Webkit, no es de QtWebkit (y del KPart basado en
> QtWebkit) propiamente, sino del grado de dependencia de Konqueror
> respecto a las internals de KHTMLPart :
>
> http://www.kdedevelopers.org/node/3998

el mantenedor de konqueror tiene algo que decir al respecto:
http://lists.kde.org/?l=kde-core-devel&m=124654914508070&w=2

>> Voy a expandirme un poco más porque no me he explicado bien. Con esto
>> no quiero decir que no deba haber colaboración, sino totalmente al
>> contrario, que es precisamente el origen del 'flame': los problemas de
>> colaboración que comentabas de Google con Webkit. A lo que me refiero
>> es que para que haya una colaboración, debe haber una relación
>> equilibrada, de igual a igual entre las partes y esto es difícil de
>> conseguir. Esto se ha visto claramente p. ej. en freedesktop en
>> general y varios de sus proyectos en particular. Y esto es lo que
>> ocurrió con KHTML y webkit, lamentablemente. Y esperemos que no pase
>> con Google/Webkit.
>
> Bueno yo no creo tampoco que los desarrollos sean equilibrados en una
> especie de democracia, normalmente quien hace el trabajo decide, y si
> hay quien que cree que es mejor hacerlo de otra manera y en el
> proyecto original no se acepta, tampoco veo malo un fork.

Si queremos una colaboración entre varias partes debe en relación de
igualdad. Y no, no hablamos de democracia, sino de meritocracia como
comentas, pero lo que no puede ser es que trabajen 2 y decida 1. Y en
este caso no se daba un fork porque el proyecto original no aceptaba
cambios, sino porque el proyecto posterior no quería colaborar con el
original. Que es lo que pasa cuando alguien coge algo para sí y se
olvida de devolver a la comunidad.

> Un fork
> puede dividir recursos, pero también da la oportunidad (necesaria
> algunas veces) de plantear las cosas de distinta manera, y en el
> software libre tenemos cientos de ejemplos de casos en los que ha sido
> algo muy positivo (XFree->Xorg, XPDF->Poppler,
> Sodipodi->Inkscape,...).

Sin duda, en estos casos ha sido muy positivo, y (casualmente?) en
todos el proceso ha sido bastante similar: la mayoría (por no decir
totalidad) de la comunidad de desarrolladores estaba en contra de la
opinión del 'autor' original, deciden forkear, y todo el desarrollo
pasa al nuevo proyecto, desapareciendo el anterior. Es decir, el fork
es bueno porque prácticamente _todo_ el equipo de desarrollo se pasa
al fork. En el caso de KHTML vs WebKit esto no es así, y por eso no
fue una buena idea forkear. Es cierto que ahora hay más actores en
juego, y que estos han elegido WebKit por cuestiones técnicas, pero
eso no convierte en bueno el fork. Lo mismo que hay muchos otrs forks
que no son buenos (p. ej. OOo vs GO-OO que podría ser un caso similar)

> En el tema Google/Webkit no creo que a ninguno de los dos les interese
> dividirse así que yo confio en que compartiran en la máxima medida, y
> sino seguro que hay quien reintegre de vuelta el trabajo de Google a
> Webkit. :-)

El problema con Google no parece grave, pero bueno, quién sabe. Quizás
les dá por tirar por su propia rama de WebKit, en privado al
principio, al cabo de unos años la liberan del todo, integran su
segunda generación de máquina virtual javascript que le da n vueltas a
la actual y a la de webkit y todos los fabricantes colaboran con
ellos... en fin, una treta para el equipo de desarrollo de webkit y
una pérdida de esfuerzos.

> Y como siempre un honor leer y/o debatir con Alfredo!! ;-)l

Un placer intentar encontrar resquicios legales en la enciclopedia Jonan ;D