Sobre proyectos de Software Libre / Código Abierto de "puerta cerrada":
Enseñanzas del enfoque de
selección de desarrolladores para Firefox
de Mozilla
- 1.
- 2. El equipo de desarrollo de
Firefox - 3. La teoría de la
cebolla - 4. Cinco
explicaciones - 5.
Conclusión - 6. Autor
Traducción: José Ventura Roda (Socio de
ATI), José Zurita Márquez (Socio de ATI, miembro
del Grupo de
Lengua e
Informática de ATI)
Resumen: en este artículo introduzco la
noción de un proyecto de
código abierto de puerta cerrada . En tales proyectos, las
tareas más importantes del desarrollo
(por ejemplo, revisión del código) son controladas
por un grupo restringido. Aquí presento cinco nuevos
argumentos sobre por qué hay grupos que pueden
desear organizarse de esta manera. La primera razón es que
los desarrolladores simplemente no tienen tiempo
disponible para evaluar a los aspirantes. Los dos argumentos
siguientes están basados en la autoselección, pues
mediante el establecimiento de requisitos exigentes de entrada,
el proyecto puede asegurarse de que se consiguen programadores de
calidad y con
mucha constancia.
El cuarto argumento es que la ampliación de un
grupo destruye la diversión. La quinta razón es que
los proyectos que requieren conocimientos variados precisan un
enfoque de puerta cerrada. Palabras claves: Firefox, puerta
cerrada, software de código
abierto, Software
Libre, selección de desarrolladores, tamaño del
grupo, cueva.
Envié al club un telegrama que decía:
"ACEPTE POR FAVOR MI DIMISIÓN. NO DESEO PERTENECER A
NINGÚN CLUB QUE ME ACEPTE COMO MIEMBRO."
Groucho Marx Marx,
cómico estadounidense (1890 – 1977)
La gran mayoría de proyectos de código
abierto son 'pequeños', es decir, tienen menos de cinco
miembros [3][5][4][11]. Muchos proyectos de código abierto
son 'cuevas' o cuentan con un único miembro
[7].
Al mismo tiempo, algunos estudiosos del código
abierto han sostenido que el número de desarrolladores da
una idea del nivel del éxito
de ese proyecto [9]. En esta línea de razonamiento, puesto
que los desarrolladores tienen opciones múltiples y muchas
demandas de su tiempo, la mera atracción de una gran
cantidad de desarrolladores por un proyecto es una
indicación de éxito. En [12] se ha argumentado que
los proyectos que no crecen más allá de un "
núcleo fuerte de desarrolladores … fallarán
debido a una carencia de los recursos
dedicados a encontrar y a corregir errores" (pp. 329-341). Sin
embargo este argumento de " cuanto mayor mejor" ignora algunos de
los aspectos negativos de atraer un número alto de
desarrolladores para un proyecto; por ejemplo, los costes de
coordinación, el conflicto, la
pérdida de calidad.
Lo que ahora estamos aprendiendo es que el mandato
recogido en "La Catedral y el Bazar" [14] –" tratar a tus
usuarios como codesarrolladores es el camino más sencillo
para mejorar el código de forma rápida y corregir
errores con efectividad "– no siempre es aplicable. Se observa
que algunos grupos no van en la línea del modelo
promiscuo 'raymondiano' de "usuario como co-desarrollador", que
permite el libre acceso al código y amplios privilegios de
revisión. Más bien vemos que no se solicita la
opinión de los individuos y un grupo cerrado controla las
tareas más importantes (por ejemplo, la revisión de
código).
En este artículo, usando el ejemplo del navegador
Firefox de Mozilla, argumento que algunos proyectos muy exitosos
de Software Libre / Código Abierto (FLOSS, Free/
Libre/Open Source Software) están diseñados para
ser pequeños. Lejos de buscar una gran cantidad de
desarrolladores, estos grupos desalientan activamente a los
aspirantes e incluso no permiten que los individuos interesados
envíen parches. En lugar de abrir las puertas a todos los
interesados, estos proyectos proporcionan el código de sus
programas al
mundo entero, pero no permiten que cualquiera participe en el
desarrollo del producto.
Basándome en conversaciones on-line públicas,
proporciono cinco explicaciones teóricas para explicar por
qué algunos grupos de fuente abierta toman la vía
de "puerta cerrada".
2. El equipo de desarrollo de
Firefox
El navegador Firefox, de la Fundación Mozilla,
<http://www.mozilla.org/products/firefox/>,
funciona muy bien. Ha sido descargado más de 60 millones
de veces en un período muy corto de tiempo. Aunque el
navegador Firefox se beneficia del extenso código de
Netscape, fue un equipo muy pequeño de programadores
comprometidos el que desarrolló el navegador Firefox
completo. En este momento, el grupo base lo forman seis persona: Blake
Ross, David Hyatt, Ben Goodger, Brian Ryner, Vladmir Vukicevic y
Mike Connor. En todos los sentidos, un
grupo pequeño ha tenido el privilegio de la
revisión del código. El proyecto Firefox
(originalmente llamado Phoenix y después retitulado
Firebird) lo inició Blake, que durante mucho tiempo
había solucionado fallos en el navegador de Mozilla y
estaba desencantado con la dirección del proyecto.
David Hyatt entró en el proyecto, puesto que era
ex-empleado de Netscape y tenía un conocimiento
profundo del código. Un subconjunto significativo de este
grupo base recibía un sueldo de la Fundación
Mozilla por trabajar en este proyecto.
Los documentos
redactados por los miembros de este equipo nos permiten observar
de forma poco habitual los motivos que llevan a algunos grupos a
mantener a otros a distancia.
Véanse estos extractos de las preguntas
más frecuentes (FAQ) en el manifiesto original del equipo
(la fuente es <http://
www.blakeross.com/firefox/README-1.25.html>):
Q2.
¿Por qué solamente un equipo
pequeño?
El
tamaño del equipo que trabaja en el núcleo es una
de las muchas razones por las que el desarrollo del núcleo
es tan lento. Tenemos la sensación de que menores
dependencias (sin restricciones de marketing),
una innovación más rápida
(ningún comité de interfaz de usuario) y más
libertad para
experimentar (sin requisitos de compatibilidad con versiones
anteriores) conducirán a un producto final
mejor.
Q3.
¿Dónde informo sobre los errores de este
paquete?
Estamos todavía trabajando con trazo grueso. Hay
muchas partes que obviamente están mal y no necesitamos
que nos informen sobre errores en las mismas. Si encuentra un
error (solicitar una prestación no es un error) y
está seguro de que es
específico de Firefox (no aparecía en Mozilla) y ha
leído suficientemente a fondo todos los errores existentes
en Firefox para saber que no está ya registrado,
siéntase libre para comunicarlo en el producto Phoenix en
Bugzilla. (…)
Q5:
¿Cómo puedo incorporarme? Por
invitación. Esto es una meritocracia: se invitará a
sumarse al grupo a los que se ganen el respeto del
grupo. Las respuestas son muy claras. Desalientan a los que
desean participar en el proceso.
Los participantes potenciales son advertidos de que se
es miembro solo por invitación. Claramente, el grupo ha
hecho todo lo posible para dejar fuera a la gente en lugar de
animarla a participar. Si la captación de desarrolladores
es el camino para el éxito de un proyecto de código
fuente abierto [9], éste no sería el
caso.
Esto nos enseña que algunos proyectos de
código abierto no son proyectos de "puerta abierta".
Muchos se pueden describir mejor como proyectos de puerta cerrada
. Formalmente, se definen los proyectos de puerta cerrada como
los que proporcionan acceso al programa y al
código fuente a cualquier persona interesada, pero no
facilitan el acceso a las funciones
nucleares del software desarrollado (especialmente a la
determinación de las líneas estratégicas, la
comprobación del código y el envío de
parches).
Tales proyectos desean que su público objetivo lo
descargue y utilice su producto y trate de corregir su
código. Sin embargo, mantienen a distancia a potenciales
participantes cualificados. Incluso no admiten en el equipo a los
desarrolladores que trabajan en errores y envían parches.
Firefox se ha desarrollado coherentemente como un proyecto de
puerta cerrada.
Si bien los usuarios pueden ofrecer sus opiniones en
foros abiertos, el desarrollo real está hecho por un grupo
base. Este método es
polémico y trastorna a muchos miembros de la comunidad de
código abierto. Si los proyectos de código abierto
se basan en formar una comunidad de expertos, el modelo de puerta
cerrada proporciona aparentemente una manifestación de
esta filosofía construida sin embargo sobre los principios de
control
habituales. He aquí una reacción pública a
la política
de reclutamiento
para el desarrollo de Firefox.
Dicen en voz alta que solamente están dispuestos
a aceptar en el proyecto a desarrolladores aprobados por ellos,
no necesitan a nadie que se presente. Y con esta actitud,
alejan a gente que quiere ayudar pero que no está segura
de sus aptitudes.
Después dicen que quieren que la gente
envíe parches y que echen una mano en el desarrollo del
proyecto. ¿Pero cómo suponen que alguien va a hacer
esto sin ser miembro? Bien, obviamente usted no tiene que estar
en el equipo para trabajar por el equipo. ¿Pero
quién desea trabajar para alguien que no va a tratarlo
como parte del mismo equipo?
Sin embargo, el espíritu del código
abierto (al menos de la parte BSD) es de apertura y
aceptación. No permitir la entrada de la gente o aceptar a
los nuevos miembros solo a través de invitación
huele a elitismo. Desafortunadamente cuando te relacionas con
otros seres humanos, inevitablemente terminarás
encontrando alguno que cree pertenecer a la elite y merecedor de
mirar al resto por encima del hombro. (Fuente:
<http://developers.slashdot.org/comments. pl?sid
=137815&cid=11526872>).
Por otra parte, confiar en un pequeño grupo
podría potencialmente poner en peligro el futuro de un
proyecto si sus componentes tienen otras oportunidades. Mike
Connor, uno de los principales desarrolladores de Firefox
expresó su frustración de esta manera: " Esto me
está molestando, y me ha estado
molestando desde hace tiempo. Por muchas razones, en los tres
años que llevamos trabajando con el proyecto, no hemos
logrado construir una comunidad de desarrolladores expertos en
torno a Firefox
(el subrayado es mío). Creo que ahora tenemos problemas. De
las seis personas que controlan realmente Firefox, cuatro
están ausentes sin permiso y uno no hace demasiadas
revisiones.
Y yo estoy a punto de irme indefinidamente, puesto que
siento que soy la única persona a la que todo esto que le
preocupa lo suficiente para convertirlo en un problema ".
(Fuente: <http://steelgryphon. com/blog/ index.php?p=37>).
En estos momentos, la teoría de la cebolla sobre
el desarrollo de software de código abierto se ha puesto
de moda (por
ejemplo, [13][15][3][10]. En esta teoría, un grupo
pequeño de individuos con poder
controlan los privilegios de revisión, mientras que
asignan a los miembros de las capas externas de la cebolla tareas
rutinarias como la corrección de errores. Las razones y
las implicaciones de esta estructura de
organización todavía no se han
explicado por completo en la literatura
especializada.
La explicación más común para
restringir el tamaño del grupo es que incrementar el
número de desarrolladores plantea problemas de
coordinación [2]. Algunos estudiosos han precisado que el
acceso al grupo base en la mayoría de los proyectos de
código abierto es controlado por un proceso
automático de alta. Los que saben cómo contactar a
los desarrolladores del proyecto de una manera culturalmente
compatible consiguen entrar, mientras que a otros se les niega el
acceso [15]. Las procesos de
alta automática desempeñaron ciertamente su papel
en la elección de los desarrolladores del grupo base de
Firefox –Dave Hyatt fue empleado de Netscape y conocía
desde luego su cultura, Ben
Goodger se incorporó como resultado de una cuidadosa
crítica
del navegador de Mozilla en su sitio web.
En este artículo, construido a partir de
conversaciones públicas sobre Firefox, discuto otras cinco
explicaciones para implementar un método de puerta
cerrada. No queda claro, por supuesto, si todas las explicaciones
proporcionadas aquí se aplican a todos los proyectos de
puerta cerrada. Una investigación futura debería evaluar
la importancia relativa de cada explicación. Estos
argumentos son, de alguna manera, nuevos en la manera que se
presentan y deben mover al diálogo
sobre el reclutamiento de los desarrolladores de código
abierto en lo sucesivo.
Explicación 1: poco tiempo disponible Evaluar a
nuevos miembros lleva un tiempo del que los desarrolladores no
disponen. Así resulta, con frecuencia, que los
líderes, que tienen un tiempo limitado a su
disposición, eligen hacer el trabajo
ellos mismos mejor que gastar el tiempo intentando identificar a
un potencial candidato. Blake Ross ha dicho que "Ahora mismo solo
busco tiempo para estar trabajando en Firefox y, a pesar de esto,
a menudo tengo 1-2 horas máximo (al
día).
Ben, obviamente, tiene sus manos ocupadas liderando e
intentando que todos los patos estén en fila ". (Fuente:
<http://blakeross. com/index. php?p=19>) Encontrar a nuevos
miembros del equipo es una tarea onerosa y arriesgada. La tarea
implica el coste de anunciarse y de examinar a los aspirantes. Si
el aspirante no conoce a un miembro del grupo base, puede ser
difícil juzgar la competencia y las
capacidades de nuevos miembros potenciales. Por otra parte, se
presenta generalmente el llamado "problema de la agencia",
según el cual los aspirantes pueden ocultar sus
habilidades o jugar esta baza como una vía para asegurar
su incorporación. Por lo tanto, cuando a los miembros les
falta tiempo, el beneficio de incluir un nuevo miembro se
contrarresta con el coste de buscar a esa persona.
Explicación 2: meritocracia (sólo el
más experto consigue entrar) Las comunidades de
código abierto compiten con las empresas por los
desarrolladores. El atraer a los mejores desarrolladores aumenta
las posibilidades de la comunidad de competir en un duro mercado.
Establecer los niveles más altos les permite reclutar a
desarrolladores altamente cualificados, mejorando sus
posibilidades de éxito. El cierre de puertas lleva a la
autoselección, contando con los desarrolladores
interesados más competentes.
Es posible determinar la calidad del trabajo de un
desarrollador de código abierto, puesto que el resultado
de una tarea es libre y por eso, fácilmente accesible.
Esta teoría es apoyada por una observación hecha por Blake Ross, un
desarrollador clave de Firefox: " Básicamente, utilizamos
el código abierto como la mejor entrevista de
trabajo del mundo. En vez de entrevistar a la gente delante de
una mesa de despacho durante dos horas y pedirle que muevan el
monte Fuji (el autor aclara que es una cita de un libro sobre
los procedimientos de
entrevistas de
Microsoft),
queremos que la gente envíe código que pueda
demostrar exactamente lo que podría aportar si se unieran
al equipo ". (Fuente: <http://blakeross.com/ index.
php?p=19>)
Un participante en una discusión en Slashdot
también formuló un argumento similar: " En Firefox
buscan a los ‘programadores más inteligentes’
para trabajar con su código base. Aunque está claro
que es elitista, se aseguran de que sólo la elite
(dedicación más habilidad) consigue trabajar en los
entresijos del navegador. Si esto termina haciéndoles
trabajar más rápidamente, con más fiabilidad
y más eficiencia,
entonces mejor que mejor. Un pequeño equipo de individuos
con mucha experiencia suele lograr más que un gran grupo
de gente con una experiencia media y habitualmente llegar
más lejos que un equipo grande de personas con un perfil
mediocre. Se puede garantizar que todos los que compiten con
ellos (empresas como MS y Opera) son bastante elitistas
(contratarán mediante entrevistas a los mejores
codificadores y diseñadores que puedan), así que,
¿por qué no debería hacerlo el equipo de
firefox? Por supuesto, como se ha indicado, si piensas que lo
puedes hacer mejor con tu forma de reclutar un equipo, entonces
crea tu propio proyecto, y veremos cual sobrevive ". (Fuente:
<http://developers. slashdot.org/ comments. pl?sid= 137815
&cid =11527401>)
Explicación 3: persistencia (sólo los
más persistentes logran entrar) Los proyectos de puerta
cerrada disuaden a la gente de aspirar a entrar. Frecuentemente
se hace referencia a la cantidad de trabajo que conlleva.
Véase, por ejemplo, este mensaje de Ben Goodger de Firefox
de Mozilla: " Se necesita ayuda. Necesitamos 'grandes
productores' de código. Si estás interesado en la
tecnología
de los navegadores
web, ¿por qué involucrarte en el proyecto de
navegador de código abierto más importante?
Buscamos sobre todo personas con experiencia de programación en Mac OS X y desarrolladores
en Windows.
Comienza hoy, buscando y arreglando algo. Aquí no se
facilita ninguna formación, puesto que averiguar
cómo se hace todo esto puede considerarse parte de los
'requisitos de entrada' 😉 ". (Fuente: <http:/ /www.
mozilla.org/projects/firefox/>) Debe ser el anuncio de
petición de ayuda más intimidatorio del mundo. Ben,
literalmente, dice a la gente que deben trabajar duro a cambio de nada
y si quieren impresionarle, deberían empezar a trabajar
por abajo, por ejemplo, solucionando errores. Blake Ross
justifica este enfoque de esta manera: " Ben admite que
percatarse de cómo hacerse notar es parte del proceso de
reclutamiento, y realmente lo es. Después de todo, muchos
de los actuales súper revisores de Mozilla y las personas
que llevan el proyecto empezaron como colaboradores 'novatos' y
escalaron hasta la cima de la meritocracia. Si no estás
dispuesto a realizar un poco de investigación y a imaginar
como dejar tu huella, ¿de verdad estás en el
equipo? ". (Fuente:< http://blakeross.com/
index.php?p=19>)
Esto llevará probablemente a las personas muy
persistentes a autoseleccionarse en el proyecto con resultados
positivos. Mientras que la autoselección basada en la
calidad del desarrollador es comprensible, la
autoselección basada en la persistencia puede conducir a
que sean admitidos programadores de baja calidad (por ejemplo,
aquéllos que tienen mucho tiempo disponible). Aunque una
dedicación prolongada al proyecto (por ejemplo, con muchos
mensajes en los foros) es una señal de persistencia, puede
ser también un indicador de fervor ideológico. Por
lo tanto, permitir la autoselección a través de la
persistencia puede llevar a peculiaridades en términos de
composición del grupo. Otros grupos han solucionado la
cuestión de los participantes persistentes que no aportan
mucho mediante la creación de listas electrónicas
específicas de desarrolladores [12].
Explicación 4: abriendo la puerta se puede matar
la diversión Los eruditos que estudian la
motivación de los desarrolladores de código
abierto nos dicen que muchos individuos están motivados
por la diversión que aporta construir algo [8][6]. En [1]
incluso se califica a los desarrolladores de código
abierto como homo ludens, y modelo de motivación
intrínseca de desarrolladores. Eric Raymond, un veterano
observador del FLOSS y autor del popular "The Catedral and the
Bazaar", ha dicho que: "puede resultar que uno de los más
importantes efectos del éxito del código abierto
sea enseñarnos que el juego es el
modo económicamente más eficiente de realizar
trabajo creativo" 1. Los proyectos de puerta cerrada son
iniciados con frecuencia por un pequeño grupo de personas
con relaciones de confianza entre ellos. Admitir a
extraños elimina esta sensación acogedora y reduce
la motivación intrínseca de los
desarrolladores actuales. Blake Ross ha comentado que Firefox
siempre ha sido un proyecto familiar: " A veces la gente pregunta
por qué trabajamos gratis en Firefox. Es difícil
contener la risa cuando dicen 'trabajo'. Dime otro proyecto que
to- que la vida de millones de personas en todo el mundo y que
tenga un nombre clave como 'The Ocho' , que consiga ser publicado
en todos los medios". ('The
Ocho' es el nombre familiar del canal de televisión
ficticio ESPN8 en la película Dodgeball; puntos para Ben
por su inspiración al inventar un nombre brillante para la
versión 1.5).
Lo mejor de Firefox es que aunque ha subido como un
cohete, nunca ha olvidado sus humildes raíces como
proyecto ‘canalla’ que era, coordinado con altas
dosis de cafeína
en Denny’s. En resumen, el proyecto nunca será
totalmente adulto. (Fuente: <http:// blakeross.
com/index.php?p=24>)
Como un observador dijo en Slashdot: " Quizás es
cuestión de divertirse… ". Si tu limitas los
desarrolladores a personas que realmente disfrutan trabajando
juntas y tienen ideas similares sobre cómo comportarse y
hablar con la gente, puede ser más divertido que si
invitas a todos los codificadores inadaptados socialmente, que no
pueden tomarse el rechazo de un parche más que como un
insulto (o, para los verdaderamente chiflados, como un cierto
juego político).
Hay más de un par de grandes codificadores fuera
de aquí con habilidad cero para tratar con la gente.
Pueden dañar un proyecto porque, aunque sus propias
contribuciones son buenas, bajan el nivel de diversión y
por lo tanto la productividad de
todos. Algunos de ellos hacen grandes proyectos en plan solista …
(Fuente: <http://developers. slashdot.org/
comments.pl?sid=137815 &cid =11527896>)
Observaciones similares se han oído en el
ámbito de los emprendedores. Con frecuencia encontramos
que una compañía la pone en marcha un grupo de
buenos amigos. Con el tiempo, según aumenta la
formalización, la compañía introduce
más procedimientos, haciéndolos más
estructurados y burocráticos, perdiendo su naturaleza ad
hoc y divertida. No está claro si esto puede ser solamente
una explicación parcial de la existencia de los proyectos
de puerta cerrada.
Explicación 5: los productos que
requieren capacidades variadas requieren el enfoque de puerta
cerrada Firefox es uno de los pocos productos de código
abierto dirigido a una audiencia general; es decir, a un mercado
de consumo. A
diferencia de la inmensa mayoría de los productos de
código abierto dirigidos a una audiencia general, Firefox
necesita tener éxito con los consumidores no
profesionales. Esto implica que para que el proyecto tenga
éxito necesita un interfaz de usuario intuitivo junto con
un producto robusto.
Por lo tanto, el equipo de proyecto necesita implicar a
gente con capacidades diversas, algunos que sean más
expertos en el diseño
de interfaces de usuario y otros que tengan grandes conocimientos
de programación.
El manifiesto original indica que: " tenemos la
sensación de que menores dependencias (sin restricciones
de marketing), una innovación más rápida
(ningún comité de interfaz de usuario) y más
libertad para experimentar (sin requisitos de compatibilidad con
versiones anteriores) conducirán a un producto final
mejor".
En palabras de Blake Ross: " Puesto que esta audiencia
era principalmente de carácter no técnico, estimamos
necesario para juzgar las mejoras no sólo su mérito
técnico, sino también cómo se alineaban con
esta nueva visión.
La revisión del código más la
interfaz de usuario llevó, sin embargo, mas tiempo del que
estábamos dispuestos a gastar en nuestra impaciencia por
desarrollar rápidamente Phoenix. Así que intentamos
encontrar a las personas que comprendieran nuestra visión
tan bien que no necesitaran capas adicionales de revisión
y las incorporamos al equipo ". (Fuente:
<http://blakeross.com/ index.php?p=19>)
Por lo tanto, la naturaleza única de Firefox hizo
necesario un enfoque de puerta cerrada. El grupo no quería
un comité de interfaz de usuario y quiso manejar los
parches de forma diferente (es decir, revisión de
código más interfaz de usuario). El aumento del
tamaño del grupo y la incorporación de
extraños hubieran diluido este proceso.
En este artículo he propuesto cinco nuevos
argumentos para organizar un proyecto de código abierto
como puerta cerrada.
El primer argumento es que los desarrolladores
simplemente no tienen tiempo disponible para evaluar a los
miembros potenciales y prefieren utilizar su tiempo en sacar
trabajo, mejor que en invertirlo en evaluar nuevos miembros. Los
siguientes dos argumentos están basados en la
autoselección, pues mediante la definición de
requisitos difíciles para entrar el proyecto se puede
garantizar que se consiguen programadores de gran calidad y muy
persistentes.
El cuarto argumento aplica la motivación
intrínseca inducida por la diversión (homo ludens)
y que implica que extender un grupo más allá de un
pequeño clan arruina la diversión.
El quinto argumento es que los proyectos complicados
(por ejemplo, aquellos que requieren conocimientos en
áreas técnicas y
de interfaz de usuario) precisan un enfoque de puerta
cerrada.
La investigación futura debe estudiar la
importancia relativa de estos argumentos. Por otra parte, no
sabemos si los resultados del proyecto son mejores o peores por
organizarse al modo puerta cerrada. Es necesaria pues una
comparación empírica de los enfoques de puerta
cerrada y puerta abierta.
Sandeep Krishnamurthy
Universidad de Washington, Bothell
(EE.UU.)
NOTA
1. Agradecemos a Bitzer, Schrettl y Schroeder (2004),
por avisarnos de la cita de la página 9 de la obra
de
Raymond.
Autor Sandeep
Krishnamurthy es Profesor
Asociado de comercio
electrónico y marketing en la Universidad de
Washington, Bothell (EE.UU.). En la actualidad centra sus
estudios en el impacto de Internet sobre las empresas,
las comunidades y las personas. Es autor de un libro de texto muy
exitoso sobre comercio electrónico para cursos de administración de empresas titulado
"E-Commerce Management: Text and Cases" y ha publicado
recientemente la obra "Contemporary Research in E-Marketing:
Volumes I, II". Sus trabajos académicos han sido
publicados en revistas como Organizational Behavior and Human
Decision Processes(OBHDP), Marketing Letters, Journal of Consumer
Affairs, Journal of Computer- Mediated Communication, Quarterly
Journal of E-Commerce, Marketing Management, Information
Research, Knowledge, Technology & Policy y Business
Horizons. Es editor asociado revisor de libros de
Journal of Marketing Research y ha sido coeditor de una
monografía de International Marketing
Review sobre e-Marketing. Algunos de sus artículos han
aparecido en sitios web especializados como Clickz.com,
Digitrends.net y Marketingprofs.com. Ha intervenido
recientemente en importantes emisoras de radio y televisión para señalar los errores
del programa de corrección de errores gramaticales de
Microsoft. Sus comentarios han ido reproducidos por diversos
medios de
comunicación. Trabaja asimismo en las áreas de
marketing genérico y marketing no lucrativo. Su sitio web
está en <http://faculty.washington.edu/ sandeep> y
su cuaderno de bitácora en
<http://sandeepworld.blogspot.com>.
Novática, revista de ATI
(Asociación de Técnicos de
Informática) http://www.ati.es/novatica
REFERENCIAS
[1] J. Bitzer, W. Schrettl, P.J.H. Schroeder. "Intrinsic
Motivation in Open Source Software Development", 2004. Disponible
en <http:// econwpa.wustl.edu/eps/dev/papers/0505/
0505007.pdf>.
[2] Frederick Brooks. The Mythical Man-Month: Essays
on Software Engineering, 20th Anniversary Edition,
Addison-Wesley Professional, 1995.
[3] K. Crowston, J. Howison. "The Social Structure of
Open Source Software Development Teams. Working Paper", 2003.
Disponible en <http:// floss.syr.edu/tiki-index.php>
[accedido el 22-8- 2004].
[4] K. Healy, A. Schussman. "The Ecology of Open Source
Software Development", 2004. Documento de trabajo no publicado.
Disponible en <http://
www.kieranhealy.org/files/drafts/ossactivity.pdf> [accedido el
22-8-2004].
[5] F. Hunt, P. Johnson. "On the Pareto distribution of
Sourceforge projects", en Proceedings of the F/ OSS Software
Development Workshop. 122-129, Newcastle, UK,
2002.
[6] S. Krishnamurthy. "On the Intrinsic and Extrinsic
Motivation of Open Source Developers", 2005. De próxima
aparición en Knowledge, Technology &
Policy.
[7] S. Krishnamurthy. "Cave or Community?: An Empirical
Examination of 100 Mature Open Source Projects", en First
Monday, 7(6), 2002. Disponible en
<http://firstmonday.org/issues/issue7_6/
krishnamurthy/index.html>.
[8] K.R. Lakhani, R. Wolf. "Why Hackers Do What
They Do: Understanding Motivation and Effort in Free/Open Source
Software Projects", en Perspectives on Free and Open Source
Software, editado por J. Feller, B. Fitzgerald, S. Hissam y
K. R. Lakhani. Cambridge, MA: MIT Press, 2005.
[9] J. Lerner, J.Tirole. "Some Simple Economics of Open
Source" en Journal of Industrial Economics, 52, pp.
197-234, 2002.
[10] Luis Lopez-Fernandez, Luis, Gregorio Robles, Jesus
M. González-Barahona. "Applying Social Network Analysis to
Information in CVS Repositories", 2005. Disponible en
<http://opensource.mit.edu/ papers/llopez-sna-short.
pdf>.
[11] G. Madey, V. Freeh, R. Tynan. "Modeling the F/OSS
Community: A Quantitative Investigation", en Free/Open Source
Software Development, editado por Stephan Koch, Hershey, PA:
Idea Group Publishing, 2004.
[12] A. Mockus, R. T. Fielding, J. D. Herbsleb. "Two
Cases of Open Source Software Development: Apache and Mozilla",
en ACM Transactions on Software Engineering and
Methodology, 11(3), pp. 309-346, 2002.
[13] K. Nakakoji, Y. Yamamoto, Y. Nishinaka, K. Kishida,
Y. Ye. "Evolution Patterns of Open-Source Software Systems and
Communities", en Proceedings of International Workshop on
Principles of Software Evolution (IWPSE 2002), pp. 76-85,
2002.
[14] E. Raymond. "The Cathedral and the Bazaar", en
First Monday, volumen 3,
número 3, 1998. Disponible en
<http://www.firstmonday.org/
issues/issue3_3/raymond/>.
[15] G. Von Krogh, S. Haefliger, S.Spaeth. "Collective
Action and Communal Resources in Open Source Software
Development: The Case of Freenet", en Research Policy,
32(7), pp. 1217- 1241, 2003.