SCM: Linus Torvalds (Linux), Larry McVoy (BitKeeper) and Andrew Tridgell (Samba, rsync, etc.)

Horst von Brand vonbrand en inf.utfsm.cl
Lun Abr 18 13:58:45 CLT 2005


Jens Hardings <jhp en csol.org> dijo:
> >El 18/04/05, Guillermo O. Burastero<linux.gb en gmail.com> escribió:

[...]

> >Time is money.. de seguro que Linus debe haber pensado en eso..la
> >gente que desarrolla el kernel,me imagino que sera gente muy ocupada
> >.no puede perder el tiempo o me equivoco?

> Me parece que hay dos extremos:
> 
> A) Utilizar la herramienta que ofrece la mejor solución técnica y
> económica, mirado solamente en el corto plazo.

O incluso el largo plazo.

> B) Seguir los principios éticos y morales detrás del Software Libre a
> toda costa.

> Y hay un equilibrio, que es bastante cercano a lo que hace Linus, IMHO.
> Pero en general es muy difícil verlo con claridad.

Si fuera facil...

> En el caso de BitKeeper, era una herramienta que existía.

En buena parte, fue disen~ada/desarrollada segun las especificaciones
de Linus y varios de sus tenientes mas importantes, por un personaje
que tiene una larga trayectoria en desarrollo de software de sistemas
(cosillas menores como lmbench como codigo abierto) y que participo
activamente en el desarrollo de Linux hasta que comenzo con su
aventura BitMover.

>                                                              No se tenía
> certeza que fuera a funcionar bien con el modelo de desarrollo del
> kernel, pero valía la pena un intento (desarrollar a esa altura una
> versión 100% libre para solamente averiguar si funciona habría sido un
> costo demasiado alto).

Y desarrollarla como codigo propietario tambien, solo que de esa forma
se financiaba el desarrollo...

>                        Ahora se tiene certeza que hay varios aspectos de
> BK son muy deseables para el desarrollo del kernel (y probablemente para
> otros proyectos con características similares), y que si se cuenta con
> una herramienta 100% libre eso va a traer muchos beneficios en el
> mediano/largo plazo. Es entonces buen momento para asumir un costo ahora
> que se recuperará con creces.

Nodz.

> Si seguimos principio A), nos quedaríamos con BK haciendo cada
> vez más concesiones, porque el costo en el corto plazo de generar
> una alternativa libre es demasiado alto. Pero si seguimos
> exclusivamente el principio B), estaríamos dejando de lado todo
> el aporte que hace una parte importante de la industria del
> software, duplicando esfuerzos y por ende agregando trabas a la
> innovación. (En un caso extremo, no podríamos utilizar los
> computadores de hoy en día, ya que primero debiéramos
> desarrollar una BIOS libre).

Y seguir con los firmware de un cuantohay, de tarjetas de video y
modems hasta discos duros. No olvidar los microprogramas de las CPUs
actuales...

Y nunca entendi porque el /software/ tenia que ser de especificaciones
(codigo fuente) libremente disponible, pero el /hardware/ no (si, p.ej.
hay especificaciones completas para una CPU SPARC, "cualquiera" puede
hacerse la suya).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513


Más información sobre la lista de distribución Linux