Introducción

<chapter id="introduction">

<title>Introducción</title>

<simplesect>

<!--
<para>Most free software projects fail.</para>
-->

<para>La mayoría de los proyectos de software libre fracasan.</para>

<!--
<para>We tend not to hear very much about the failures.  Only
successful projects attract attention, and there are so many free
software projects in total<footnote><para>I tried to estimate the
number, by looking at just the number of projects registered at the
most popular hosting sites, and the closest I could calculate to an
answer was somewhere between one hundred thousand and two hundred
thousand.  That would still be far lower the total number of free
software projects on the Internet, of course, as it only counts the
ones that chose to use one of the major hosting
sites.</para></footnote> that even though only a small percentage
succeed, the result is still a lot of visible projects.  We also don't
hear about the failures because failure is not an event.  There is no
single moment when a project ceases to be viable; people just sort of
drift away and stop working on it.  There may be a moment when a final
change is made to the project, but those who made it usually didn't
know at the time that it was the last one.  There is not even a clear
definition of when a project is expired.  Is it when it hasn't been
actively worked on for six months?  When its user base stops growing,
without having exceeded the developer base?  What if the developers of
one project abandon it because they realized they were duplicating the
work of another&mdash;and what if they join that other project, then
expand it to include much of their earlier effort?  Did the first
project end, or just change homes?</para>
-->

<para>Tratamos de no prestar mucha atención a los fracasos.  Solamente
los proyectos que tienen éxito llaman la atención, y hay tantos proyectos de
software<footnote><para>Traté de calcular el número, mirando sólo el
número de proyectos registrados en los sitios de alojamiento más
populares, y lo más cerca que pude calcular como respuesta está en
entre una centena de mil y doscientos mil. Eso todavía sería mucho
menor que el número total de proyectos de software libre en
Internet, por supuesto, ya que sólo cuenta los que optaron por utilizar
uno de los principales sitios de alojamiento.</para></footnote> que aún
cuando solo un pequeño porcentaje tiene éxito, el resultado es de una
apreciable cantidad de proyectos.  Pero tampoco prestamos atención a los
fracasos porque no los contamos como un evento. No existe un momento
puntual en el que un proyecto deja de ser viable; simplemente se los
deja de lado y se deja de trabajar en ellos.  Puede haber un momento en
que se hace un cambio final al proyecto, pero quienquiera que lo haga,
normalmente no sabe en ese momento que ese cambio fue el último.
Tampoco hay una definición clara del momento en que un proyecto se
acaba.  ¿Podrá ser cuando se haya dejado de trabajar en él por seis
meses?  ¿O cuando su base de usuarios deja de crecer, sin antes haber
excedido la base de programadores?  ¿Y qué pasaría si los programadores
de un proyecto lo abandonan porque se dan cuenta que estaban duplicando
el trabajo de algún otro&mdash;y si se unen todos en el otro proyecto,
y lo amplían para incluir ahí su esfuerzo realizado? ¿Acaso el primer
proyecto finalizó, o simplemente cambió de lugar de residencia?</para>

<!--
<para>Because of such complexities, it's impossible to put a precise
number on the failure rate.  But anecdotal evidence from two decades
in open source, some casting around on multi-project hosting sites
(see <xref linkend="canned-hosting"/><phrase output="printed"> in
<xref linkend="technical-infrastructure"/></phrase> for more about
them), and a little Googling all point to the same conclusion: the
rate is extremely high, probably on the order of 90&ndash;95%.  The
number climbs higher if you include surviving but dysfunctional
projects: those which <emphasis>are</emphasis> producing running code,
but which are not pleasant places to be, or are not making progress as
quickly or as dependably as they could.</para>
-->

<para>Dada esta complejidad, es imposible obtener un número preciso
para un promedio de fracasos.  Pero la evidencia de lo que ha ocurrido
en dos décadas con proyectos con fuente abierta y curioseando un
poco en sitios de alojamiento de múltiples proyectos, y otro poco en
Google, se llega siempre a la misma conclusión: el porcentaje es muy
alto, probablemente algo así como el 90&ndash;95%.  Este número crece
aún más si se incluyen los proyectos que sobreviven pero son
disfuncionales: aquellos que <emphasis>producen</emphasis> un código
que funciona, pero no son placenteros ni amigables, o no progresan tan
rápidamente ni son tan confiables como tendrían que ser.</para>

<!--
<para>This book is about avoiding failure.  It examines not only how
to do things right, but how to do them wrong, so you can recognize and
correct problems early.  My hope is that after reading it, you will
have a repertory of techniques not just for avoiding common pitfalls
of open source development, but also for dealing with the growth and
maintenance of a successful project.  Success is not a zero-sum game,
and this book is not about winning or getting ahead of the
competition.  Indeed, an important part of running an open source
project is working smoothly with other, related projects.  In the long
run, every successful project contributes to the well-being of the
overall, worldwide body of free software.</para>

-->

<para>En este libro se habla de cómo evitar los fracasos.  Se examina
no solamente cómo se hacen bien las cosas, sino también cómo se hacen
mal, para que se puedan reconocer desde el comienzo, y se corrijan los
problemas.  Tengo la esperanza que después de que se lea este libro,
se adquiera un repertorio de técnicas no sólo para evitar los errores
comunes en el desarrollo de programas de fuente abierta, sino también
para manejar el crecimiento y el mantenimiento de un proyecto exitoso.
El éxito no es un juego para que haya un solo ganador, y este libro no
busca producir un solo ganador que salga airoso de una competición. 
Así pues, una parte importante de impulsar un proyecto de fuente
abierta es trabajar en armonía con otros proyectos relacionados entre
sí.  Y a la larga, cada proyecto exitoso contribuye al bienestar de
todo el mundo del software libre.</para>

<!--
<para>It would be tempting to say that free software projects fail for
the same sorts of reasons proprietary software projects do.
Certainly, free software has no monopoly on unrealistic requirements,
vague specifications, poor resource management, insufficient design
phases, or any of the other hobgoblins already well known to the
software industry.  There is a huge body of writing on these topics,
and I will try not to duplicate it in this book.  Instead, I will
attempt to describe the problems peculiar to free software.  When a
free software project runs aground, it is often because the developers
(or the managers) did not appreciate the unique problems of open
source software development, even though they might be quite
well-prepared for the better-known difficulties of closed-source
development.</para>
-->

<para>Sería muy tentador afirmar que los proyectos de software libre
fracasan por las mismas razones que los proyectos de software
propietario. Ciertamente el software libre no tiene el monopolio de
los requisitos descabellados, las especificaciones vagas, del manejo
pobre de los recursos, fases de diseño insuficientes, y tantas otras
complicaciones ya conocidas en la industria del software. Se ha escrito 
mucho sobre estos temas, por lo que no se duplicarán esos esfuerzos en este 
libro. Más bien se intentará describir los problemas particulares al software libre. 
Cuando un proyecto de software libre se estanca, a menudo es porque
los programadores (o la dirección) no caen en cuenta de los problemas
típicos del desarrollo de software de fuente abierta, aunque pareciera
que estan muy bien preparados para las dificultades más conocidas del
desarrollo de software de fuente cerrada.</para>

<!--
<para>One of the most common mistakes is unrealistic expectations
about the benefits of open source itself.  An open license does not
guarantee that hordes of active developers will suddenly volunteer
their time to your project, nor does open-sourcing a troubled project
automatically cure its ills.  In fact, quite the opposite: opening up
a project can add whole new sets of complexities, and cost
<emphasis>more</emphasis> in the short term than simply keeping it
in-house.  Opening up means arranging the code to be comprehensible to
complete strangers, setting up development documentation and email lists,
and often writing documentation for the first time.  All this is a lot
of work.  And of course, if any interested developers
<emphasis>do</emphasis> show up, there is the added burden of
answering their questions for a while before seeing any benefit from
their presence.  As developer Jamie Zawinski said about the troubled
early days of the Mozilla project:</para>
-->

<para>Uno de los errores más comunes es tener expectativas
desproporcionadas sobre los beneficios propios de la fuente abierta. 
Una licencia abierta no es una garantía de tener una legión de
programadores activos que de repente se ofrecen para el proyecto, ni
tampoco un proyecto con problemas se cura por el sólo hecho de pasarlo
a fuente abierta.  De hecho es todo lo contrario: abrir un proyecto
puede agregar una serie de complicaciones, y resultar a corto plazo
<emphasis>más</emphasis> costoso que manejarlo dentro de casa. 
Abrirlo va a significar acomodar el código para que sea comprensible a
gente extraña, crear la documentación de desarrollo y una lista de
correos, y a menudo redactar la documentación del proyecto por
primera vez.  Todo esto significa mucho trabajo.  Y además, si
<emphasis>aparece</emphasis> algún programador interesado, habrá que
soportar el peso agreqado de contestar sus preguntas por un tiempo,
antes de ver el beneficio que se recibe por su presencia.  Como dijo
el programador Jaime Zawinski comentando los días ajetreados cuando se
lanzaba el proyecto Mozilla:</para>

    <blockquote>
<!--
      <para><emphasis>Open source does work, but it is most definitely
      not a panacea.  If there's a cautionary tale here, it is that
      you can't take a dying project, sprinkle it with the magic pixie
      dust of "open source," and have everything magically work
      out. Software is hard.  The issues aren't that simple.</emphasis></para>
-->
      <para><emphasis>La fuente abierta anda, pero no es
definitivamente la panacea.  Hay que advertir con cautela que no se
puede encarar un proyecto moribundo, rociarlo con el polvo mágico de
la "fuente abierta" y tener de repente todo en funcionamiento. El
software es difícil. Las cosas no son tan simples.</emphasis></para>

<!--
      <para>(from <emphasis role="bold"><ulink
      url="http://www.jwz.org/gruntle/nomo.html"
      >jwz.org/gruntle/nomo.html</ulink></emphasis>)</para>
-->
      <para>(de <emphasis role="bold"><ulink
      url="http://www.jwz.org/gruntle/nomo.html"
      >jwz.org/gruntle/nomo.html</ulink></emphasis>)</para>
    </blockquote>

<!--
<para>A related mistake is that of skimping on presentation and
packaging, figuring that these can always be done later, when the
project is well under way.  Presentation and packaging comprise a wide
range of tasks, all revolving around the theme of reducing the barrier
to entry.  Making the project inviting to the uninitiated means
writing user and developer documentation, setting up docs that are
informative to newcomers, automating as much of the
software's compilation and installation as possible, etc.</para>
-->

<para>Una equivocación relacionada es escatimar en la presentación y
el empaquetado, creyendo que esto se puede hacer después, cuando el
proyecto esté encaminado.  La presentación y el empaquetado comprenden
una amplia serie de tareas, todas en torno a reducir la barrera de
ingreso al proyecto.  Hacer un proyecto atractivo para un no iniciado
significa documentarlo para el usuario y el programador, establecer un
sitio web para los recien llegados, automatizar cuanto sea posible la
compilación e instalación del software, etc.</para>

<!--
<para>Many programmers unfortunately treat this kind of work as being
of secondary importance to the code itself.  There are a couple of
reasons for this.  First, it can feel like busywork, because its
benefits are most visible to those least familiar with the
project&nbsp;&mdash;&nbsp;and vice versa: after all, the people who
develop the code don't really need the packaging.  They already know
how to install, administer, and use the software, because they wrote
it.  Second, the skills required to do presentation and packaging well
are often completely different from those required to write code.
People tend to focus on what they're good at, even if it might serve
the project better to spend a little time on something that suits them
less.  <xref linkend="getting-started"/> discusses presentation and
packaging in detail, and explains why it's crucial that they be a
priority from the very start of the project.</para>
-->

<para>Desgraciadamente muchos programadores dan a este trabajo una
importancia secundaria comparado con el código.  Hay un par de razones
para esto.  De entrada se puede percibir como trabajo no productivo,
porque aparentemente beneficia más a los que no están familiarizados
con el proyecto. A su vez, los que desarrollan el código no
necesitan realmente del empaquetado.  Ya conocen como instalar,
administrar y usar el software, porque ellos lo escribieron.  En
segundo lugar, los conocimientos para hacer bien la presentación y el
empaquetado son a menudo completamente diferentes a los que se
requieren para escribir el código.  La gente tiende a concentrarse en
lo que más sabe, aún cuando podría ser más útil al proyecto que se
dediquen un poco a lo que no les resulta tan familiar. En el <xref
linkend="getting-started"/> se trata la presentación y el empaquetado
en detalle, y explica por qué es importante que sean una prioridad
desde el comienzo del proyecto.</para>

<!--
<para>Next comes the fallacy that little or no project management is
required in open source, or conversely, that the same management
practices used for in-house development will work equally well on an
open source project.  Management in an open source project isn't
always very visible, but in the successful projects, it's usually
happening behind the scenes in some form or another.  A small thought
experiment suffices to show why.  An open source project consists of a
random collection of programmers&mdash;already a notoriously
independent-minded species&mdash;who have most likely never met each
other, and who may each have different personal goals in working on
the project.  The thought experiment is simply to imagine what would
happen to such a group <emphasis>without</emphasis> management.
Barring miracles, it would collapse or drift apart very quickly.
Things won't simply run themselves, much as we might wish otherwise.
But the management, though it may be quite active, is often informal,
subtle, and low-key.  The only thing keeping a development group
together is their shared belief that they can do more in concert than
individually.  Thus the goal of management is mostly to ensure that
they continue to believe this, by setting standards for
communications, by making sure useful developers don't get
marginalized due to personal idiosyncracies, and in general by making
the project a place developers want to keep coming back to.  Specific
techniques for doing this are discussed throughout the rest of this
book.</para>
-->

<para>Después se introduce la falacia de que no se requiere una
dirección del proyecto cuando es de fuente abierta, o a la inversa,
que las mismas prácticas de gestión usadas para un proyecto hecho en
casa van a funcionar bien en un proyecto de fuente abierta.  El manejo
de un proyecto de fuente abierta no siempre resulta visible, pero
cuando éste es exitoso tiene lugar detrás de las bambalinas de una u
otra forma.  Un pequeño experimento mental será suficiente para
mostrar por qué.  Un proyecto de fuente abierta consiste en una
colección de programadores al azar&mdash;los que ya de por sí son
gente con diferentes mentalidades&mdash; que muy probablemente nunca
se han visto, y que quizás tienen objetivos personales
muy diferentes para trabajar en el proyecto.  El experimento consiste
en imaginar sencillamente qué va a pasarle a dicho grupo
<emphasis>sin</emphasis> dirección. Salvo por un milagro, el
proyecto va a colapsar y diluirse muy rápidamente. Las cosas no
funcionarán simplemente por sí solas, por más que los deseos sean
grandes. Pero la administración, aún cuando sea muy activa, es a
menudo informal, sutil, y de bajo perfil.  Lo único que mantiene unido
al grupo de desarrollo es el convencimiento compartido de que juntos
pueden hacer más que individualmente.  Entonces el objetivo de la
dirección es mayormente asegurar que continúen con ese convencimiento,
estableciendo estándares de comunicación, cuidando que los
programadores útiles no queden marginados debido a idiosincrasias
personales, y en general procurando que el proyecto sea un lugar
acogedor para los programadores.  Las técnicas específicas para
realizar esto se discuten a lo largo de este libro.</para>

<!--
<para>Finally, there is a general category of problems that may be
called "failures of cultural navigation."  Twenty years ago, even ten,
it would have been premature to talk about a global culture of free
software, but not anymore.  A recognizable culture has slowly emerged,
and while it is certainly not monolithic&mdash;it is at least as prone
to internal dissent and factionalism as any geographically bound
culture&mdash;it does have a basically consistent core.  Most
successful open source projects exhibit some or all of the
characteristics of this core.  They reward certain types of behaviors,
and punish others; they create an atmosphere that encourages unplanned
participation, sometimes at the expense of central coordination; they
have concepts of rudeness and politeness that can differ substantially
from those prevalent elsewhere.  Most importantly, longtime
participants have generally internalized these standards, so that they
share a rough consensus about expected conduct.  Unsuccessful projects
usually deviate in significant ways from this core, albeit
unintentionally, and often do not have a consensus about what
constitutes reasonable default behavior.  This means that when
problems arise, the situation can quickly deteriorate, as the
participants lack an already established stock of cultural reflexes to
fall back on for resolving differences. </para>
-->

<para>Finalmente, hay una categoría general de los problemas que
podría llamarse "fallas de orientación cultural".  Hace veinte años, o
quizás sólo diez, hubiera sido prematuro hablar de una cultura
global de software libre, pero ahora ya no es así.  Lentamente ha
emergido una cultura visible, y aún cuando ésta no es monolítica
&mdash;por lo menos es tan propensa al disentimiento interno y al
corporativismo como cualquier cultura limitada geográficamente&mdash;
tiene, ciertamente, un núcleo básico consistente.  Los proyectos de
fuente abierta más exitosos muestran algo o el total de las
características de ese núcleo. Se premian ciertos tipos de conductas y
se castigan otros.  Se crea una atmósfera que incita a la
participación espontánea, a veces a expensas de una coordinación
central. Se tienen conceptos de lo que es ser amable o ser rudo que
difieren substancialmente de lo que prevalece fuera.  Lo más
importante es que los participantes que son asiduos tienen ya
interiorizados esos conceptos y comparten un cierto consenso sobre la
conducta que es aceptable.  Los proyectos no exitosos a menudo se
desvían apreciablemente de ese núcleo, aunque sin intención, y no
tienen un consenso sobre lo que razonablemente constituye una conducta
predeterminada razonable.  Esto quiere decir que cuando surgen los problemas la
situación se viene abajo rápidamente, porque los participantes carecen
de un conjunto de reflejos culturales determinados que les permita
resolver sus diferencias. </para>

<!--
<para>That last category, failures of cultural navigation, includes an
interesting phenomenon: certain types of organizations are
structurally less compatible with open source development than others.
One of the great surprises for me in preparing the second edition of
this book was realizing that, on the whole, my experiences indicated
that governments are less naturally suited to participating in free
software projects than private-sector, for-profit corporations, with
non-profits somewhere in between the two.  There are many reasons for
this (see <xref linkend="governments-and-open-source"/>), and the
problems are certainly surmountable, but it's worth noting that when
an existing organization&nbsp;&mdash;&nbsp;particularly a hierarchical
one, and <emphasis>particularly</emphasis> a hierarchical,
risk-averse, and publicity-sensitive one&nbsp;&mdash;&nbsp;starts or
joins an open source project, some adjustments will usually be
needed.</para>
-->

<para>Esa última categoría, los fallos de navegación culturales,
incluye un interesante fenómeno: ciertos tipos de organizaciones son
estructuralmente menos compatibles con el desarrollo de código abierto
que otras. Una de las grandes sorpresas para mí en la preparación de
la segunda edición de este libro fue darme cuenta de que, en general,
mis experiencias indican que los gobiernos se adaptan menos
naturalmente a la participación en proyectos de software libre que
en el sector privado, corporaciones con fines de lucro, quedando las
que son sin fines de lucro en algún lugar entre los dos. Hay muchas
razones para ello (ver <xref linkend="governments-and-open-source"/>),
y los problemas son superables sin duda, pero vale la pena señalar que
cuando una organización ya existente &mdash; en particular, una
jerárquica, y <emphasis>sobre todo</emphasis> una jerárquica, aversa al
riesgo, y publicitariamente sensible &mdash; inicia o se une a un
proyecto de código abierto, por lo general se necesitan algunos
ajustes.</para>

<!--
<para>This book is a practical guide, not an anthropological study or
a history.  However, a working knowledge of the origins of today's
free software culture is an essential foundation for any practical
advice.  A person who understands the culture can travel far and wide
in the open source world, encountering many local variations in custom
and dialect, yet still be able to participate comfortably and
effectively everywhere.  In contrast, a person who does not understand
the culture will find the process of organizing or participating in a
project difficult and full of surprises.  Since the number of people
developing free software is still growing by leaps and bounds, there
are many people in that latter category&mdash;this is largely a
culture of recent immigrants, and will continue to be so for some
time.  If you think you might be one of them, the next section
provides background for discussions you'll encounter later, both in
this book and on the Internet.  (On the other hand, if you've been
working with open source for a while, you may already know a lot of
its history, so feel free to skip the next section.)</para>
-->

<para>Este libro es una guía práctica, no un estudio antropológico o
un libro de historia.  Sin embargo, un conocimiento efectivo de los
orígenes del software libre actual es una base esencial para cualquier
consejo práctico.  Una persona que entienda esta cultura puede viajar
sin límites en este mundo de la fuente abierta, encontrándose con
muchas variaciones en costumbres y dialectos, y a la vez estar en la
condición de participar cómoda y efectivamente en cualquier lado.  Por
el contrario, una persona que no entiende esta cultura encontrará que
el proceso de organizar y participar en un proyecto es algo difícil y
lleno de sorpresas.  Puesto que el número de gente que desarrolla
software libre sigue creciendo a grandes saltos, habrá muchos en ésta
última categoría&mdash;ésta es mayormente una cultura de inmigrantes
recientes, y continuará así por mucho tiempo.  Si crees que eres uno
de estos, en el próximo título se presentarán algunos antecedentes
útiles para las discusiones que vendrán después, tanto en este libro
como en Internet.  (Por otro lado, si ya has trabajado en proyectos
de fuente abierta por algún tiempo, puede ser que conozcas mucho sobre
esta historia, y y sea mejor saltar a la siguiente sección.)</para>

</simplesect>

<!-- ========================== SECTION =========================== -->
<sect1 id="history">
<title>Historia</title>

<!--
<para>Software sharing has been around as long as software itself.  In
the early days of computers, manufacturers felt that competitive
advantages were to be had mainly in hardware innovation, and therefore
didn't pay much attention to software as a business asset.  Many of
the customers for these early machines were scientists or technicians,
who were able to modify and extend the software shipped with the
machine themselves.  Customers sometimes distributed their patches
back not only to the manufacturer, but to other owners of similar
machines.  The manufacturers often tolerated and even encouraged this:
in their eyes, improvements to the software, from whatever source,
just made the hardware more attractive to other potential
customers.</para>
-->

<para>Compartir el software tiene tanta historia como el software
mismo.  En los primeros tiempos de los ordenadores, los fabricantes se
dieron cuenta que vendrían avances competitivos en la innovación del
hardware y no prestaron mucha atención al software como una ventaja
para el desarrollo de sus negocios.  Muchos de los usuarios de las
primeras máquinas eran científicos o técnicos que podían modificar y
ampliar el software que incluía la máquina.  A veces los usuarios
distribuían sus aportes no solamente al fabricante, sino también a
otros usuarios que tenían máquinas similares.  A menudo los
fabricantes toleraban esto, e incluso lo estimulaban: para ellos
cualquier mejora en el software, fuera cual fuese su procedencia,
contribuía a que el hardware resultase más atractivo para otros
usuarios potenciales.</para>

<!--
<para>Although this early period resembled today's free software
culture in many ways, it differed in two crucial respects.  First,
there was as yet little standardization of hardware&mdash;it was a
time of flourishing innovation in computer design, but the diversity
of computing architectures meant that everything was incompatible with
everything else.  Software written for one machine would
generally not work on another; programmers tended to acquire
expertise in a particular architecture or family of architectures
(whereas today they would be more likely to acquire expertise in a
programming language or family of languages, confident that their
expertise will be transferable to whatever computing hardware they
happen to find themselves working with).  Because a person's expertise
tended to be specific to one kind of computer, their accumulation of
expertise had the effect of making that particular architecture
computer more attractive to them and their colleagues.  It was
therefore in the manufacturer's interests for machine-specific code
and knowledge to spread as widely as possible.</para>
-->

<para>Aunque esta primera época se parece de muchas maneras a la
cultura actual del software libre, difiere fundamentalmente en dos
aspectos:  primero que había poca estandarización del hardware&mdash;
era un momento de mucha innovación en el diseño de los ordenadores,
pero la diversidad en las arquitecturas hacía que cualquier cosa
resultara incompatible con la otra.  El software que se escribía para
una máquina generalmente no servía para otra.  Los programadores se
inclinaban hacia una arquitectura en particular o familia de
arquitecturas y en ellas se hacían expertos (mientras que hoy se
adquiere experiencia en un lenguaje de programación o una familia de
lenguajes y se espera que esa experiencia se pueda luego transferir a
cualquier hardware en que se vaya a trabajar).  Puesto que un experto
se inclinaba a sólo un tipo de ordenador, la acumulación de sus
conocimientos tenía el efecto de hacer más atractivo ese ordenador
tanto para él como para sus colegas,  por lo que los fabricantes
tenían gran interés en difundir tanto como pudieran  la codificación
y el conocimiento de alguna máquina específica.</para>

<!--
<para>Second, there was no widespread Internet.  Though there were
fewer legal restrictions on sharing than there are today, the
technical restrictions were greater: the means of getting data from
place to place were inconvenient and cumbersome, relatively speaking.
There were some small, local networks, good for sharing information
among employees at the same lab or company.  But there remained
barriers to overcome if one wanted to share with the world.  These
barriers <emphasis>were</emphasis> overcome in many cases.  Sometimes
different groups made contact with each other independently, sending
disks or tapes through land mail, and sometimes the manufacturers
themselves served as central clearing houses for patches.  It also
helped that many of the early computer developers worked at
universities, where publishing one's knowledge was expected.  But the
physical realities of data transmission meant there was always an
impedance to sharing, an impedance proportional to the distance (real
or organizational) that the software had to travel.  Widespread,
frictionless sharing, as we know it today, was not possible.</para>
-->

<para>En segundo lugar, no se había generalizado Internet. Aunque
habían menos restricciones legales que hoy para compartir, había más
restricciones técnicas: Hablando comparativamente, los medios para
transmitir datos de un lado a otro eran difíciles y engorrosos. Había
algunas pequeñas redes locales, aptas para compartir información entre
empleados del mismo laboratorio de investigación o compañía. Pero
quedaba por superar una serie de trabas si se quería compartir con
el mundo. Estas trabas se <emphasis>superaban</emphasis> en muchos
casos. A veces eran grupos varios que se contactaban
independientemente, enviándose discos o cintas por correo, y a veces
eran los fabricantes mismos que servían como centrales de intercambio
de los aportes individuales. También ayudaba que muchos de los que
desarrollaban los primeros ordenadores trabajasen en las
universidades, en donde era costumbre publicar los avances.  Pero la
realidad de la transmisión de datos implicaba que siempre que se los
quería compartir se topaba con un impedimento que era proporcional a
la distancia (física u organizacional) que el software tenía que
viajar. Era imposible compartir algo con todo el mundo sin
resistencias, tal como se puede hacer hoy.</para>

<!-- ========================== subsection ========================== -->
<sect2 id="propertization">
<title>El Florecimiento del Software Propietario y del Software Libre</title>

<!--
<para>As the industry matured, several interrelated changes occurred
simultaneously.  The wild diversity of hardware designs gradually gave
way to a few clear winners&mdash;winners through superior technology,
superior marketing, or some combination of the two.  At the same time,
and not entirely coincidentally, the development of so-called "high
level" programming languages meant that one could write a program
once, in one language, and have it automatically translated
("compiled") to run on different kinds of computers.  The implications
of this were not lost on the hardware manufacturers: a customer could
now undertake a major software engineering effort without necessarily
locking themselves into one particular computer architecture.  When
this was combined with the gradual narrowing of performance
differences between various computers, as the less efficient designs
were weeded out, a manufacturer that treated its hardware as its only
asset could look forward to a future of declining profit margins.  Raw
computing power was becoming a fungible good, while software was
becoming the differentiator.  Selling software, or at least treating
it as an integral part of hardware sales, began to look like a good
strategy.</para>
-->

<para>A medida que maduraba la industria, ocurrían simultáneamente
algunos cambios  interrelacionados.  La gran diversidad de los diseños
del hardware finalmente cedieron el paso a unos pocos ganadores
&mdash;ganadores por tener una tecnología superior, o una
comercialización superior, o una combinación de ambas cosas.  Al mismo
tiempo, no coincidente en su totalidad, el desarrollo de los así
llamados lenguajes de programación de "alto nivel" significaba que
se podía escribir un programa de una sóla vez en un lenguaje, y luego
traducirlo automáticamente ("compilarlo") para que funcionase en
diferentes tipos de ordenadores.  Las consecuencias de esto no se
quedaron perdidas en los fabricantes de hardware: un usuario podía
ahora emprender un mayor esfuerzo de ingeniería de software sin
encerrarse en una arquitectura particular.  Cuando esto se combinaba
con la disminución gradual de las diferencias en la calidad de
funcionamiento entre los ordenadores, y mientras los diseños menos
eficientes eran eliminados, un fabricante que se centraba en el
hardware como único beneficio podía divisar una disminución de sus
ganancias en el futuro.  La potencia de computación pura se convertía
en un bien fungible, mientras que el software se convertía en el
diferenciador.  Aparecía como una buena estrategia vender software, o
al menos, tratarlo como parte integral de las ventas del hardware.</para>

<!--
<para>This meant that manufacturers had to start enforcing the
copyrights on their code more strictly.  If users simply continued to
share and modify code freely among themselves, they might
independently reimplement some of the improvements now being sold as
"added value" by the supplier.  Worse, shared code could get into the
hands of competitors.  The irony is that all this was happening around
the time the Internet was getting off the ground.  So just when truly
unobstructed software sharing was finally becoming technically
possible, changes in the computer business made it economically
undesirable, at least from the point of view of any single company.
The suppliers clamped down, either denying users access to the code
that ran their machines, or insisting on non-disclosure agreements
that made effective sharing impossible.</para>
-->

<para>Esto significó que los fabricantes tuvieran que ser más estrictos
defendiendo los derechos de copia de los códigos.  Si los usuarios
hubieran continuado simplemente con su costumbre de compartir y
modificar los códigos de manera libre y gratis, hubieran instalado en
forma independiente las mejoras que ahora empezaban a ser vendidas
como "valor agregado" por los proveedores.  Peor aún, el código
compartido podría haber caído en las manos de los competidores.  La
ironía de esto es que ocurría al mismo tiempo que Internet estaba
ganando terreno.  Justamente, cuando se hacía técnicamente posible
compartir el software y se caían los obstáculos, los cambios en el
mundo de los negocios hacían del compartir algo económicamente
indeseable, por lo menos desde el punto de vista propio de una
compañía. Los proveedores imponían sus controles, ya sea negando el
acceso al código a los usuarios que corrían el programa en sus
máquinas, o mediante acuerdos de no difundir el código, lo que hacía
que el compartir fuera imposible.</para>

<sect3 id="history-conscious-resistance">
<title>Una resistencia conciente</title>

<!--
<para>As the world of unrestricted code swapping slowly faded away, a
counterreaction crystallized in the mind of at least one programmer.
Richard Stallman worked in the Artificial Intelligence Lab at the
Massachusetts Institute of Technology in the 1970s and early '80s,
during what turned out to be a golden age and a golden location for
code sharing.  The AI Lab had a strong "hacker
ethic",<footnote><para>Stallman uses the word "hacker" in the sense of
"someone who loves to program and enjoys being clever about it," not
the somewhat newer meaning of "someone who breaks into
computers."</para></footnote> and people were not only encouraged but
expected to share whatever improvements they made to the system.  As
Stallman wrote later:</para>
-->

<para>Mientras se extinguía el mundo del intercambio de códigos se
cristalizaba una contra reacción al menos en la mente de un
programador. Richard Stallman trabajaba en el laboratorio de
inteligencia artificial en el Instituto Tecnológico de Massachussets
en la década de 1970 e inicios de 1980, la época y el lugar de oro
para la costumbre de compartir los códigos.  El laboratorio de IA
tenía una fuerte "ética de hacker"<footnote><para>Stallman
usa la palabra "hacker" tiene el significado de "alguien
que ama la programación y disfruta si hace algo inteligente" y no
con el sentido más reciente de "alguien que se conecta como un
intruso en los ordenadores"</para></footnote> y no sólo se
estimulaba al personal de los proyectos sino que era de esperar que
todos los avances hechos en el sistema fueran compartidos.  Como luego
escribiría Stallman:</para>

    <blockquote>
<!--
      <para><emphasis>We did not call our software "free software",
      because that term did not yet exist; but that is what it was.
      Whenever people from another university or a company wanted to
      port and use a program, we gladly let them.  If you saw someone
      using an unfamiliar and interesting program, you could always
      ask to see the source code, so that you could read it, change
      it, or cannibalize parts of it to make a new program.
      </emphasis></para>
-->
      <para><emphasis>No le llamábamos "software libre" a nuestro
software porque ese término no existía; pero era precisamente eso.
Toda vez que alguien de otra universidad quería llevar y usar un
programa, nosotros se lo ofrecíamos con gusto.  Si se veía que alguien
usaba un programa distinto e interesante, se le podía pedir el código
fuente, para poder leerlo, cambiarlo o fusionar partes de él en un
programa nuevo.</emphasis></para>

<!--
      <para>(from <emphasis role="bold"><ulink
      url="http://www.gnu.org/gnu/thegnuproject.html" >gnu.org/gnu/thegnuproject.html</ulink></emphasis>)</para>
-->
      <para>(de <emphasis role="bold"><ulink
      url="http://www.gnu.org/gnu/thegnuproject.html"/></emphasis>)</para>
    </blockquote>

<!--
<para>This Edenic community collapsed around Stallman shortly after
1980, when the changes that had been happening in the rest of the
industry finally caught up with the AI Lab.  A startup company hired
away many of the Lab's programmers to work on an operating system
similar to what they had been working on at the Lab, only now under an
exclusive license.  At the same time, the AI Lab acquired new
equipment that came with a proprietary operating system.</para>
-->

<para>Esta comunidad edénica colapsó con Stallman poco después de
1980, cuando los cambios que venían ocurriendo en el resto de la
industria finalmente alcanzaron al laboratorio de IA.  Una compañía
que se iniciaba incorporaba a muchos de los programadores del
laboratorio para trabajar en un sistema operativo similar al que
habían desarrollado allí, pero ahora bajo una licencia exclusiva.  Al
mismo tiempo, el laboratorio de IA adquiría nuevos equipos que
llegaban con un sistema operativo de marca registrada.</para>

<!--
<para>Stallman saw the larger pattern in what was happening:</para>
-->

<para>Stallman vio la gran trama de lo que estaba sucediendo:</para>

    <blockquote>
<!--
      <para><emphasis>The modern computers of the era, such as the VAX
      or the 68020, had their own operating systems, but none of them
      were free software: you had to sign a nondisclosure agreement
      even to get an executable copy.</emphasis> </para>
-->
      <para><emphasis>Los ordenadores modernos de la época, como el
VAX o el 68020, venían con sus sistemas operativos propios, pero
ninguno era un software libre: se debía firmar un acuerdo de no
revelar los contenidos para poder recibir una copia
ejecutable.</emphasis></para>

<!--
      <para><emphasis>This meant that the first step in using a
      computer was to promise not to help your neighbor. A cooperating
      community was forbidden. The rule made by the owners of
      proprietary software was, "If you share with your neighbor, you
      are a pirate. If you want any changes, beg us to make them."
      </emphasis> </para>
-->
      <para><emphasis>Lo cual significaba que el primer paso para usar
un ordenador era prometer que no había que ayudar al prójimo. La
comunidad de cooperación estaba prohibida. La regla que establecían
los dueños del software propietario era: "si compartes con tu
vecino, eres un pirata. Si quieres cambios, nosotros los haremos, si
nos lo pides."</emphasis> </para>

    </blockquote>

<!--
<para>By some quirk of personality, he decided to resist the trend.
Instead of continuing to work at the now-decimated AI Lab, or taking a
job writing code at one of the new companies, where the results of his
work would be kept locked in a box, he resigned from the Lab and
started the GNU Project and the Free Software Foundation (FSF).  The
goal of GNU<footnote><para>It stands for "GNU's Not Unix", and the
"GNU" in that expansion stands for an infinitely long
footnote.</para></footnote> was to develop a completely free and open
computer operating system and body of application software, in which
users would never be prevented from hacking or from sharing their
modifications.  He was, in essence, setting out to recreate what had
been destroyed at the AI Lab, but on a world-wide scale and without
the vulnerabilities that had made the AI Lab's culture susceptible to
disintegration.</para>
-->

<para>Y por su personalidad peculiar decidió ofrecer resistencia a
esta nueva ola. En lugar de continuar trabajando en el diezmado
laboratorio de IA, o aceptar el trabajo de escribir código en alguna
de las compañías nuevas, en las que su trabajo iba a quedar bajo llave, 
renunció al laboratorio y comenzó el proyecto GNU y la
Fundación de Software Libre (FSF por sus siglas en Inglés).  El
objetivo del GNU<footnote><para>Siglas que significan "GNU No es
Unix" donde "GNU" en esa expansión resulta un infinitamente largo
pie de página.</para></footnote> era desarrollar un sistema operativo
y un conjunto de aplicaciones completamente libres y abiertas, donde
nunca se impediría a la gente hackear o compartir sus cambios. En
esencia, estaba empeñado en recrear lo que se había destruido del
laboratorio de IA, pero a una escala global, y sin las
vulnerabilidades que ponían a la cultura del laboratorio de IA en un
estado de posible desintegración.</para>

<!--
<para>In addition to working on the new operating system, Stallman
devised a copyright license whose terms guaranteed that his code would
be perpetually free.  The GNU General Public License (GPL) is a clever
piece of legal judo: it says that the code may be copied and modified
without restriction, and that both copies and derivative works (i.e.,
modified versions) must be distributed under the same license as the
original, with no additional restrictions.  In effect, it uses
copyright law to achieve an effect opposite to that of traditional
copyright: instead of limiting the software's distribution, it
prevents <emphasis>anyone</emphasis>, even the author, from limiting
distribution.  For Stallman, this was better than simply putting his
code into the public domain.  If it were in the public domain, any
particular copy of it could be incorporated into a proprietary program
(as also sometimes happens to code under permissive open source
copyright licenses <footnote><para>See <xref
linkend="licenses-terminology" /> for more about "permissive" licensing
versus GPL-style "copyleft" licensing.  The opensource.org FAQ is also
a good resource on this&mdash;see<ulink
url="http://opensource.org/faq#copyleft"
>opensource.org/faq#copyleft</ulink>.</para></footnote>).  While
such incorporation wouldn't in
any way diminish the original code's continued availability, it would
have meant that Stallman's efforts could benefit the
enemy&mdash;proprietary software.  The GPL can be thought of as a form
of protectionism for free software, because it prevents non-free
software from taking full advantage of GPLed code.  The GPL and its
relationship to other free software licenses are discussed in detail
in <xref linkend="legal"/>.</para>
-->

<para>Además de trabajar en el nuevo sistema operativo, Stallman
inventó una licencia de copyright cuyos términos garantizaban que los
códigos permanecerían gratis en perpetuidad.  La Licencia Pública
General GNU es una ingeniosa pieza de judo legal: dice que los códigos
pueden ser copiados y modificados sin ninguna restricción y que ambas
copias y trabajos derivados (a saber, las versiones modificadas) deben
ser distribuidas bajo la misma licencia que el original, sin poner
restricciones adicionales.  En efecto, se usan las leyes del copyright
para conseguir un efecto contrario al que apunta el copyright
tradicional: en lugar de limitar la distribución del software, prohíbe
que <emphasis>nadie</emphasis>, ni siquiera el autor, limite su
distribución. Para
Stallman, esto era mejor que si hubiera puesto su código en el dominio
público.  Si hubiera estado en el dominio público, cualquier copia
podría haber sido incorporada a los programas propietarios (como en
ocasiones se sabía que había sucedido con códigos que tenían licencias
permisivas <footnote><para>Ver <xref linkend="licenses-terminology" />
para más información sobre licencias "permisivs" versus licencias
"copyleft" al estilo GPL. Las FAQ de opensource.org son también un
buen recurso sobre esto&mdash;ver<ulink
url="http://opensource.org/faq#copyleft"
>opensource.org/faq#copyleft</ulink>.</para></footnote>). Aunque una
incorporación como ésta no hubiera disminuido la disponibilidad de los
códigos originales, hubiera significado que los esfuerzos de Stallman
iban a beneficiar al enemigo&mdash;al software propietario. La Licencia
Pública General puede entenderse como una forma de proteccionismo del
software libre, porque impide que el software no-libre se aproveche de
los códigos que están bajo esta licencia.  La Licencia Pública General y
su relación con otras licencias del software libre se discuten en
detalle en el <xref linkend="legal"/>.</para>

<!--
<para>With the help of many programmers, some of whom shared
Stallman's ideology and some of whom simply wanted to see a lot of
free code available, the GNU Project began releasing free replacements
for many of the most critical components of an operating system.
Because of the now-widespread standardization in computer hardware and
software, it was possible to use the GNU replacements on otherwise
non-free systems, and many people did.  The GNU text editor (Emacs)
and C compiler (GCC) were particularly successful, gaining large and
loyal followings not on ideological grounds, but simply on their
technical merits.  By about 1990, GNU had produced most of a free
operating system, except for the kernel&mdash;the part that the
machine actually boots up, and that is responsible for managing memory,
disk, and other system resources.</para>
-->

<para>Con la ayuda de nuevos programadores, algunos de los cuales
compartían la ideología de Stallman y otros que simplemente querían
ver abundante código disponible en forma gratuita, el Proyecto GNU
comenzó entregando versiones libres para reemplazar muchos de los
componentes críticos de sistemas operativos. Gracias a la
estandarización expandida del hardware y software para ordenadores, se
hizo posible usar los reemplazos GNU en sistemas no-libres, y mucha
gente lo hizo.  El editor de texto de GNU (Emacs) y el compilador C
(GCC) tuvieron especial éxito, ganando muchos seguidores leales, no
por términos ideológicos, sino simplemente por los méritos técnicos. 
Alrededor del año 1990, GNU había producido la mayor parte de un
sistema operativo libre, con excepción del núcleo&mdash;la parte por
la que realmente la máquina arranca y se hace responsable de manejar
la memoria, el disco y otros recursos del sistema.</para>

<!--
<para>Unfortunately, the GNU project had chosen a kernel design that
turned out to be harder to implement than expected.  The ensuing delay
prevented the Free Software Foundation from making the first release
of an entirely free operating system.  The final piece was put into
place instead by Linus Torvalds, a Finnish computer science student
who, with the help of volunteers around the world, had completed a
free kernel using a more conservative design.  He named it Linux, and
when it was combined with the existing GNU programs and other free
software (especially the X Windows System), the result was a
completely free operating system.  For the first time, you could boot
up your computer and do work without using any proprietary
software.<footnote><para>Technically, Linux was not the first.  A free
operating system for IBM-compatible computers, called 386BSD, had come
out shortly before Linux.  However, it was a lot harder to get 386BSD
up and running.  Linux made such a splash not only because it was
free, but because it actually had a high chance of successfully
booting your computer after you installed it.</para></footnote></para>
-->

<para>Desafortunadamente el proyecto GNU había elegido un diseño de
núcleo que resultó más difícil de implementar de lo esperado.  La
consiguiente demora impedía que la Fundación de Software Libre
ofreciera la primera versión de un sistema operativo enteramente
libre.  La pieza final fue instalada en su lugar por Linus Torvalds,
un estudiante de computación finlandés quien con la ayuda de
voluntarios de todo el mundo había completado un núcleo libre usando
un diseño más conservador.  Le llamó Linux, y cuando fue combinado con
los programas GNU existentes y otros softwares libres (Especialmente el
Sistemas de Ventanas X) tuvo como resultado un sistema operativo
completamente libre.  Por primera vez se podía arrancar un ordenador y
hacerlo trabajar sin usar ningún software propietario.<footnote><para>
Un sistema operativo libre para ordenadores compatibles con IBM,
llamado 386BSD, había aparecido poco antes que Linux.  Sin embargo,
era mucho mas difícil conseguir un 386BSD y hacerlo funcionar. 
Linux tuvo tanta resonancia no solo porque era libre, sino porque
realmente tenía una probabilidad alta de hacer arrancar exitosamente
al ordenador una vez que se instalaba.</para></footnote></para>

<!--
<para>Much of the software on this new operating system was not
produced by the GNU project.  In fact, GNU wasn't even the only group
working on producing a free operating system (for example, the code
that eventually became NetBSD and FreeBSD was already under
development by this time).  The importance of the Free Software
Foundation was not only in the code they wrote, but in their political
rhetoric.  By talking about free software as a cause instead of a
convenience, they made it difficult for
programmers <emphasis>not</emphasis> to have a political consciousness
about it.  Even those who disagreed with the FSF had to engage the
issue, if only to stake out a different position.  The FSF's
effectiveness as propagandists lay in tying their code to a message,
by means of the GPL and other texts.  As their code spread widely,
that message spread as well.</para>
-->

<para>Muchas partes del software de este nuevo sistema operativo no
fueron producidas por el proyecto GNU.  De hecho, el GNU no fue el
único grupo que trabajaba para producir un sistema operativo libre
(por ejemplo, el código que luego fue NetBSD y FreeBSD estaba ya en
desarrollo en ese momento).  La importancia de la Fundación de
Software libre no solamente residía en los códigos que se escribían,
sino en el tratamiento político del tema.  Al hablar del software
libre como una causa en lugar de una conveniencia, era casi imposible
que los programadores <emphasis>no</emphasis> tomasen una postura
política de ello.  Aún los que no estaban de acuerdo con la Fundación
de Software Libre tuvieron que enfrentar la causa, aunque más no sea
para proponer una posición diferente.  La efectividad que tuvo la
Fundación de Software Libre en el proceso de difusión residió en la
vinculación del código al mensaje, por medio de la Licencia Pública
General y de otros textos.  Al mismo tiempo que se difundían los
códigos, se distribuía también el mensaje.</para>

</sect3>

<sect3 id="history-accidental-resistance">
<title>Resistencia Accidental</title>

<!--
<para>There were many other things going on in the nascent free
software scene, however, and not all were as explictly ideological as
Stallman's GNU Project.  One of the most important was
the <firstterm>Berkeley Software Distribution</firstterm>
(<firstterm>BSD</firstterm>), a gradual re-implementation of the Unix
operating system&mdash;which up until the late 1970's had been a
loosely proprietary research project at AT&amp;T&mdash;by programmers
at the University of California at Berkeley.  The BSD group did not
make any overt political statements about the need for programmers to
band together and share with one another, but they
<emphasis>practiced</emphasis> the idea with flair and
enthusiasm, by coordinating a massive distributed development effort
in which the Unix command-line utilities and code libraries, and
eventually the operating system kernel itself, were rewritten from
scratch mostly by volunteers.  The BSD project became a prime example
of non-ideological free software development, and also served as a
training ground for many developers who would go on to remain active
in the open source world.</para>
-->

<para>Había muchas otras cosas sucediendo en la escena naciente del
software libre, sin embargo, y pocas eran tan explícitas ideológicamente
como el Proyecto GNU de Stallman.  Uno de los sucesos mas importantes
fue la <firstterm>Berkeley Software Distribution</firstterm>
(<firstterm>BSD</firstterm>), una reimplementación gradual del
sistema operativo Unix, que hasta finales de la década de los 70'
había sido un proyecto de investigación relativamente propietario de
AT&amp;T&mdash;hecho por programadores de la Universidad de California en Berkeley.  
El grupo BSD no hizo una declaración política sobre la necesidad de que los 
programadores se unieran y compartieran unos con otros, pero <emphasis>practicaron</emphasis> 
la idea con talento y entusiasmo, coordinando un esfuerzo masivo de desarrollo 
distribuido en el cual la línea de comandos y las librerías, y eventualmente 
el núcleo del sistema operativo Unix, fueron reescritos desde cero, en su mayoría 
por voluntarios. El proyecto BSD resultó un primer ejemplo de
desarrollo de un software libre no-ideológico, y también sirvió como
campo de entrenamiento para muchos desarrolladores que continuarían
activos en el mundo del software libre.</para>

<!--
<para>Another crucible of cooperative development was the <firstterm>X
Window System</firstterm>, a free, network-transparent graphical
computing environment, developed at MIT in the mid-1980's in
partnership with hardware vendors who had a common interest in being
able to offer their customers a windowing system.  Far from opposing
proprietary software, the X license deliberately allowed proprietary
extensions on top of the free core&mdash;each member of the consortium
wanted the chance to enhance the default X distribution, and thereby
gain a competitive advantage over the other members.  X
Windows<footnote><para>They prefer it to be called the "X Window
System", but in practice, people usually call it "X Windows", because
three words is just too cumbersome.</para></footnote> itself was free
software, but mainly as a way to level the playing field between
competing business interests and increase standardization, not out of
some desire to end the 
dominance of proprietary software.  Yet another example, predating the
GNU project by a few years, was TeX, Donald Knuth's free,
publishing-quality typesetting system.  He released it under terms
that allowed anyone to modify and distribute the code, but not to call 
the result "TeX" unless it passed a very strict set of compatibility
tests (this is an example of the "trademark-protecting" class of free
licenses, discussed more in <xref linkend="legal"/>).  Knuth wasn't
taking a stand one way or the other on the question of
free-versus-proprietary software; he just needed a better typesetting
system in order to complete his
<emphasis>real</emphasis> goal&mdash;a book on computer
programming&mdash;and saw no reason not to release his system to the
world when done.</para>
-->

<para>Otro proyecto de desarrollo cooperativo fue el <firstterm>X
Window System</firstterm>, un entorno gráfico de computación libre y
transparente en la red, desarrollado en el MIT a mediados de la década
de 1980 en coparticipación con empresas que tenían el interés común de
estar en condiciones de ofrecer a sus clientes un sistema operativo
con ventanas.  Lejos de oponerse al software propietario, la licencia
X permitía deliberadamente que se hicieran extensiones propietarias
encima del nucleo libre&mdash;cada miembro del consorcio quería
tener la oportunidad de mejorar la distribucion X predeterminada y
consiguientemente ganar una ventaja competitiva con respecto a los
otros miembros.  El X Windows<footnote><para>Preferían que se llamara
"X Windows System", pero en la práctica se le llama
comunmente "X Windows", porque tres palabras es demasiado
complicado.</para></footnote> era un software libre, pero
fundamentalmente como una manera de nivelar el campo de juego entre
intereses de las empresas competidoras e incrementar la estandarización,
y no por el deseo de poner fin a la dominación del software propietario.
Todavía hay otro ejemplo, el TeX de Donald Knuth, un sistema de
tipografía que surgió unos años antes que GNU. Ofreció una versión bajo
terminos que permitían que cualquiera modifique y distribuya el código,
pero que no se llamara "TeX" a no ser que superara una serie de pruebas
de compatibilidad muy estrictos (este es un ejemplo de una clase de
licencia libre "protectoras de marcas registradas" de las que se hablará
más en el <xref linkend="legal"/>). Knuth no estaba tomando partido para
un lado ni para el otro en la cuestión del software libre contra el
propietario, solo necesitaba un sistema mejor de impresión para cumplir
con su objetivo <emphasis>real</emphasis>&mdash;un libro sobre
programación de ordenadores&mdash;y no encontró escollos para
presentar al mundo su sistema una vez que estuvo hecho.</para>

</sect3>

<!--
<para>Without listing every project and every license, it's safe to
say that by the late 1980's, there was a lot of free software
available under a wide variety of licenses.  The diversity of licenses
reflected a corresponding diversity of motivations.  Even some of the
programmers who chose the GNU GPL were much less ideologically driven
than the GNU project itself was.  Although they enjoyed working on free
software, many developers did not consider proprietary software a
social evil.  There were people who felt a moral impulse to rid the
world of "software hoarding" (Stallman's term for non-free software),
but others were motivated more by technical excitement, or by the
pleasure of working with like-minded collaborators, or even by a
simple human desire for glory.  Yet by and large these disparate
motivations did not interact in destructive ways.  This may be
because software, unlike other creative forms like prose or the visual
arts, must pass semi-objective tests in order to be considered
successful: it must run, and be reasonably free of bugs.  This gives
all participants in a project a kind of automatic common ground, a
reason and a framework for working together without worrying too much
about qualifications or motivations beyond the technical.</para>
-->

<para>Aún sin tener un listado completo de proyectos y licencias, se
puede afirmar con seguridad que para el fin de la década de los 80'
había una buena cantidad de software libre y una amplia variedad de
licencias.  La diversidad de licencias reflejaba una diversidad de
motivaciones correspondientes.  Incluso algunos de los programadores
que eligieron la Licencia Pública General de GNU estaban mucho menos
motivados ideológicamente que el proyecto GNU mismo.  Aunque
disfrutaban trabajando en el software libre, muchos desarrolladores no
consideraron al software propietario una lacra social.  Había
quienes sentían un impulso moral de liberar al mundo del
"acaparamiento de software" (un término que usaba Stallman para el
software no libre), pero otros estaban más motivados por un entusiasmo
técnico, o por el placer de trabajar con colaboradores de pensamiento
afín, o simplemente por el deseo humano de la gloria.  Pero las
motivaciones disparatadas no intervinieron en forma destructiva en
todo este confín.  Esto pudo ser porque, en oposición a
lo que acontece en otras formas creativas como la prosa o las artes
visuales, el software debe superar pruebas semi-objetivas para ser
considerado un éxito: debe funcionar y estar razonablemente libre de
errores.  Esto otorga a todos los participantes del proyecto una
especie de pie de igualdad común, una razón y un encuadre para
trabajar juntos sin preocuparse mucho de otros títulos o motivaciones
que no sean los conocimientos técnicos.</para>

<!--
<para>Developers had another reason to stick together as well: it
turned out that the free software world was producing some very
high-quality code.  In some cases, it was demonstrably technically
superior to the nearest non-free alternative; in others, it was at
least comparable, and of course it always cost less.  While only a few
people might have been motivated to run free software on strictly
philosophical grounds, a great many people were happy to run it
because it did a better job.  And of those who used it, some
percentage were always willing to donate their time and skills to help
maintain and improve the software.</para>
-->

<para>Además, los desarrolladores tenían otra razón para permanecer
juntos: acontecía que el mundo del software libre estaba produciendo
códigos de muy alta calidad.  En algunos casos se podía demostrar que
eran técnicamente superiores a las alternativas del software no libre
que se les acercaban; en otros casos eran al menos comparables y por
supuesto, costaban menos.  Mientras que solo unos pocos pudieron estar
motivados para usar software libre por razones estrictamente
filosóficas, la gran mayoría se sentía feliz de usarlos porque
cumplían mejor con las tareas.  Y entre los usuarios, algún porcentaje
estaba siempre listo para donar su tiempo y habilidad para ayudar a
mantener y mejorar el software.</para>

<!--
<para>This tendency to produce good code was certainly not universal,
but it was happening with increasing frequency in free software
projects around the world.  Businesses that depended heavily on
software gradually began to take notice.  Many of them discovered that
they were already using free software in day-to-day operations, and
simply hadn't known it (upper management isn't always aware of
everything the IT department does).  Corporations began to take a more
active and public role in free software projects, contributing time
and equipment, and sometimes even directly funding the development of
free programs.  Such investments could, in the best scenarios, repay
themselves many times over.  The sponsor only pays a small number of
expert programmers to devote themselves to the project full time, but
reaps the benefits of <emphasis>everyone's</emphasis> contributions,
including work from unpaid volunteers and from programmers being paid
by other corporations.</para>
-->

<para>Esta tendencia de producir buenos códigos no era ciertamente
universal, pero se repetía por todas partes con frecuencia en aumento
en los proyectos de software libre.  Las empresas que dependían
fuertemente del software lo empezaron a notar gradualmente.  Muchos de
ellos descubrieron que ya estaban usando software libre en las
operaciones de todos los días, sólo que no lo sabían (los gerentes de
alto rango no siempre saben todo lo que ocurre en las dependencias de
la tecnología informática).  Las corporaciones comenzaron a tomar
cartas activas en los proyectos del software libre, contribuyendo con
tiempo y equipos, y a veces subvencionando directamente al desarrollo
de programas libres.  Estas inversiones podían, en el mejor de los
casos, retornar multiplicadas muchas veces.  Las subvenciones
solo pagaban a una cantidad pequeña de programadores expertos para que
dedicaran su trabajo de tiempo completo, pero cosechaban los
beneficios de las contribuciones de <emphasis>todos</emphasis>,
incluso de voluntarios no pagos, y programadores pagados por otras
corporaciones.</para>

</sect2>

<!-- ========================== subsection ========================== -->
<sect2 id="free-vs-open-source">
<title>"Libre" vs "Abierto"</title>

<!--
<para>As the corporate world gave more and more attention to free
software, programmers were faced with new issues of presentation.  One
was the word "free" itself.  On first hearing the term "free software"
many people mistakenly think it means just "zero-cost software."  It's
true that all free software is zero-cost,<footnote><para>One may charge
a fee for giving out copies of free software, but since one cannot
stop the recipients from offering it at no charge afterwards, the
price is effectively driven to zero immediately.</para></footnote>
but not all zero-cost software is free as in "freedom"&mdash;that is,
the freedom to share and modify for any purpose.  For example, during the
battle of the browsers in the 1990s, both Netscape and Microsoft gave
away their competing web browsers at no charge, in a scramble to gain
market share.  Neither browser was free in the "free software" sense.
You couldn't get the source code, and even if you could, you didn't
have the right to modify or redistribute it.<footnote><para>The source
code to Netscape Navigator
<emphasis>was</emphasis> eventually released under an open source
license, in 1998, and became the foundation for the Mozilla web
browser.  See <ulink
url="http://www.mozilla.org/" >mozilla.org</ulink>.</para></footnote>
The only thing
you could do was download an executable and run it.  The browsers were
no more free than shrink-wrapped software bought in a store; they
merely had a lower price.</para>
-->

<para>Cuando las corporaciones prestaron mayor atención a los
programadores de software libre se enfrentaron con nuevas formas de
presentación.  Una de ellas fue la palabra "libre", cuya traducción al
inglés también significa "gratis".  Al escuchar por
primera vez el término "software libre" muchos pensaron erróneamente
que solamente significaba "software de costo cero".  Es verdad que
todo software libre es gratis<footnote><para>Se podría
cobrar algo por repartir las copias del software libre, pero puesto que
no se les puede impedir a quienes lo reciben ofrecerlo
gratis después, el precio vuelve a cero
inmediatamente.</para></footnote>, pero no todo el software gratis es
libre.  Por ejemplo, durante la guerra de los navegadores de la
década de los &apos;90 Netscape y Microsoft repartían gratis sus
navegadores en la disputa por ganar la mayor participación en el
mercado.  Ninguno de estos navegadores era libre en el sentido que
tiene el "software libre". No se dispone del código fuente,
y si se lo tuviera, no se tiene el derecho de modificarlo o
redistribuirlo.<footnote><para> El código fuente del Navegador de
Netscape <emphasis>apareció</emphasis> eventualmente bajo una licencia
de fuente abierta, en 1998, y vino a ser la base del navegador Mozilla. 
Ver <ulink
url="http://www.mozilla.org/" >mozilla.org</ulink>.</para></footnote>
Lo único permitido era bajar los programas ejecutables y hacerlos
funcionar.  Los navegadores no eran más libres que los softwares
empaquetados y comprimidos que se compran en un negocio; sólo que el
precio era mas bajo.</para>

<!--
<para>This confusion over the word "free" is due entirely to an
unfortunate ambiguity in the English language.  Most other tongues
distinguish low prices from liberty (the distinction between
<emphasis>gratis</emphasis> and <emphasis>libre</emphasis> is
immediately clear to speakers of Romance languages, for example).  But
English's position as the de facto bridge language of the Internet
means that a problem with English is, to some degree, a problem for
everyone.  The misunderstanding around the word "free" was so
prevalent that free software programmers eventually evolved a standard
formula in response: "It's <emphasis>free</emphasis> as in
<emphasis>freedom</emphasis>&mdash;think <emphasis>free
speech</emphasis>, not <emphasis>free beer</emphasis>."  Still, having
to explain it over and over is tiring.  Many programmers felt, with
some justification, that the ambiguous word "free" was hampering the
public's understanding of this software.</para>
-->

<para>Esta confusión en la palabra "libre" se debe a una desafortunada
ambigüedad de lenguaje, en este caso del inglés.  En otras lenguas
romances aparece la diferencia entre precio bajo y libertad porque
existen las palabras <emphasis>gratis</emphasis> y
<emphasis>libre</emphasis> que se distinguen con facilidad.  Pero
siendo el inglés el lenguaje puente dentro de Internet, pasó esto a
significar que un problema con el inglés era también un problema para
los demás.  Este malentendido suscitado por la palabra "libre" era tan
penetrante para los angloparlantes que los programadores de software
desarrollaron una formula estándar que repetían: "Es
<emphasis>libre</emphasis> (free) como la
<emphasis>libertad</emphasis>, no como la cerveza
<emphasis>gratis</emphasis> (free)"  Aún así, tener que
explicar esto una y otra vez resulta fatigante.  Muchos programadores
sentían, no sin razón, que la palabra ambigua (en inglés) "libre"
(free) estaba obstaculizando la comprensión del público en relación a
este software.</para>

<!--
<para>But the problem went deeper than that.  The word "free" carried
with it an inescapable moral connotation: if freedom was an end in
itself, it didn't matter whether free software also happened to
be better, or more profitable for certain businesses in certain
circumstances.  Those were merely pleasant side effects of a motive
that was, at its root, neither technical nor mercantile, but moral.
Furthermore, the "free as in freedom" position forced a glaring
inconsistency on corporations who wanted to support particular free
programs in one aspect of their business, but continue marketing
proprietary software in others.</para>
-->

<para>Pero este problema se profundizó más aún.  La palabra "libre"
llevaba consigo una inevitable connotación moral: si la libertad era
un fin en sí mismo, no importaba si el software libre resultaba ser
mejor o más rentable para ciertos negocios en ciertas circunstancias.  Estos
últimos efectos aparecían como secundarios, por otras motivaciones que
no eran, en el fondo, ni técnicas ni comerciales, sino morales. Más
todavía, la postura de "libre como la libertad" llevaba a una
flagrante incoherencia de las corporaciones que subvencionaban algunos
programas libres para algunas áreas de sus negocios, pero continuaban
comercializando software propietario en otras.</para>

<!--
<para>These dilemmas came to a community that was already poised for
an identity crisis.  The programmers who actually
<emphasis>write</emphasis> free software have never been of one mind
about the overall goal, if any, of the free software movement.  Even
to say that opinions run from one extreme to the other would be
misleading, in that it would falsely imply a linear range where there
is instead a multidimensional scattering.  However, two broad
categories of belief can be distinguished, if we are willing to ignore
subtleties for the moment.  One group takes Stallman's view, that the
freedom to share and modify is the most important thing, and that
therefore if you stop talking about freedom, you've left out the core
issue.  Others feel that the software itself is the most important
argument in its favor, and are uncomfortable with proclaiming
proprietary software inherently bad.  Some, but not all, free
software programmers believe that the author (or employer, in the case
of paid work)
<emphasis>should</emphasis> have the right to control the terms of
distribution, and that no moral judgement need be attached to the
choice of particular terms.  Others don't believe this.</para>
-->

<para>Estos dilemas llovían sobre una comunidad que ya estaba
aplastada por una crisis de identidad.  Los programadores que
en verdad <emphasis>escriben</emphasis> el software libre no se
sienten necesariamente identificados con el objetivo central -si lo
hay- del movimiento del software libre.  Sería engañoso decir que las
opiniones van de un extremo al otro, porque esto implicaría la
falsedad de imaginar que nos movemos en una línea de pensamiento,
cuando en realidad es una distribución multidimensional.  Sin embargo,
si estamos dispuestos a obviar las sutilezas, por el momento pueden
diferenciarse dos amplias categorías.  Un grupo se alinea bajo el
punto de vista de Stallman, para quien la libertad de compartir y
modificar es lo más importante, y por lo tanto si no se habla de
libertad se está esquivando el núcleo principal de la cuestión.  Otros
piensan que el software es el argumento más importante a su favor, y
se sienten incómodos con la proclamación del software propietario como
algo inherentemente malo.  Algunos de los programadores de software,
aunque no todos, creen que el autor (o el empleador, en el caso de
trabajo pagado) <emphasis>debería</emphasis> tener el derecho de
controlar las cláusulas de la distribución y que no se necesita
agregar un juicio moral en la selección de algunas cláusulas
particulares. Otros no creen eso.</para>

<!--
<para>For a long time, these differences did not need to be carefully
examined or articulated, but free software's burgeoning success in the
business world made the issue unavoidable.  In 1998, the term
<firstterm>open&nbsp;source</firstterm> was created as an alternative
to "free", by a coalition of programmers who eventually became The
Open Source Initiative (OSI).<footnote><para>OSI's web home is <ulink
url="http://www.opensource.org/"
>opensource.org</ulink>.</para></footnote>  The OSI felt
not only that "free software" was potentially confusing, but that the
word "free" was just one symptom of a general problem: that the
movement needed a marketing program to pitch it to the corporate
world, and that talk of morals and the social benefits of sharing
would never fly in corporate boardrooms.  In their own words at the
time:</para>
-->

<para>Por mucho tiempo no se necesitó examinar o articular estas
diferencias, pero el éxito floreciente del software libre hizo que
esta cuestión fuera inevitable.  En 1998 un grupo de programadores
creó el término <firstterm>fuente&nbsp; abierta</firstterm> como una
alternativa para "libre" y fueron ellos quienes crearon la
Iniciativa por el Código Abierto(OSI por sus siglas en Inglés).
<footnote><para>El sitio web de la OSI es <ulink
url="http://www.opensource.org/"
>opensource.org</ulink>.</para></footnote>  La Iniciativa
por el Código Abierto creía que el término "software libre"
llevaba a una confusión potencial, y que la palabra "libre"
era tan solo un síntoma del problema general: que el movimiento
necesitaba una estrategia de mercadeo para lanzarlo al mundo de las
grandes empresas, y que hablar de moral y de los beneficios sociales
del compartir no iba a tener vuelo en las juntas directivas de las empresas. 
Tomando sus propias palabras para aquel momento:</para>

    <blockquote>
<!--
      <para><emphasis>The Open Source Initiative is a marketing
      program for free software. It's a pitch for "free software" on
      solid pragmatic grounds rather than ideological
      tub-thumping. The winning substance has not changed, the losing
      attitude and symbolism have.&nbsp;...</emphasis></para>
-->
      <para><emphasis>La Iniciativa por el Código Abierto es un
      programa de mercadeo para el software libre. Significa fundar el
      "software libre" sobre bases sólidas y prácticas más que en una
      discusión acalorada. La sustancia ganadora no ha cambiado, sí en
      cambio la actitud de perdedores y su
      simbolismo.&nbsp;...</emphasis></para>

<!--
      <para><emphasis>The case that needs to be made to most techies
      isn't about the concept of open source, but the name. Why not
      call it, as we traditionally have, free software?</emphasis></para>
-->
      <para><emphasis>La aclaración que debe hacerse a muchos técnicos
      no es acerca del concepto de fuente abierta, sino sobre el
      nombre. ¿Por qué no llamarle, como se ha hecho tradicionalmente,
      software libre?</emphasis></para>

<!--
      <para><emphasis>One direct reason is that the term "free
      software" is easily misunderstood in ways that lead to
      conflict.&nbsp;...</emphasis></para>
-->
      <para><emphasis>Una razón definitiva es que el término "software
      libre" se confunde fácilmente de manera que lleva a terrenos
      conflictivos.&nbsp;... </emphasis></para>

<!--
      <para><emphasis>But the real reason for the re-labeling is a
      marketing one. We're trying to pitch our concept to the
      corporate world now. We have a winning product, but our
      positioning, in the past, has been awful. The term "free
      software" has been misunderstood by business persons, who
      mistake the desire to share with anti-commercialism, or worse,
      theft.</emphasis></para>
-->
      <para><emphasis>Pero la verdadera razón del cambio de cartel es
      una razón de comercialización. Estamos ahora tratando de lanzar
      nuestro concepto al mundo corporativo. Tenemos un producto
      ganador, pero nuestra posición, en el pasado, ha sido terrible.
      El término "software libre" se ha malentendido entre
      las personas de negocios, quienes confunden el deseo de
      compartir con una conducta anticomercial, o peor todavía, con un
      robo.</emphasis></para>

<!--
      <para><emphasis>Mainstream corporate CEOs and CTOs will never
      buy "free software." But if we take the very same tradition, the
      same people, and the same free-software licenses and change the
      label to "open
      source"&nbsp;&mdash;&nbsp;<emphasis>that</emphasis>, they'll
      buy.</emphasis></para>
-->
      <para><emphasis>Los CEOs y CTOs de grandes corporaciones ya
      establecidas nunca comprarán "software libre."
      Pero si mantenemos la misma tradición, la misma gente y las
      mismas licencias de software libre y les cambiamos el nombre
      poniéndole "código abierto", &mdash; <emphasis>entonces</emphasis> sí lo
      comprarán.</emphasis></para>

<!--
      <para><emphasis>Some hackers find this hard to believe, but
      that's because they're techies who think in concrete,
      substantial terms and don't understand how important image is
      when you're selling something.</emphasis></para>
-->
      <para><emphasis>Algunos hackers encuentran esto difícil de
      creer, porque son técnicos que piensan en términos
      concretos y substanciales, y no entienden la importancia de la imagen de
      algo cuando uno lo está vendiendo.</emphasis></para>

<!--
      <para><emphasis>In marketing, appearance is reality. The
      appearance that we're willing to climb down off the barricades
      and work with the corporate world counts for as much as the
      reality of our behavior, our convictions, and our
      software.</emphasis></para>
-->
      <para><emphasis>Para el mercadeo la apariencia es la realidad. La
      apariencia de que estamos dispuestos a bajarnos de nuestras
      barricadas y a trabajar con el mundo corporativo importa tanto
      como la realidad de nuestras conductas o convicciones, y de
      nuestro software.</emphasis></para>

<!--
      <para>(from <ulink url="http://www.opensource.org/"
      >opensource.org</ulink>.  Or
      rather, <emphasis>formerly</emphasis> from that
      site&nbsp;&mdash;&nbsp;the OSI has apparently taken down the
      pages since then, although they can still be seen at 
      <ulink url="http://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php" >web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php</ulink>
      and
      <ulink url="http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing" >web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing</ulink> [sic].)</para>
-->
      <para>(de <ulink url="http://www.opensource.org/"
      >opensource.org</ulink>. O más bien,
      <emphasis>antiguamente</emphasis> de ese sitio &mdash; la OSI ha
      retirado esas páginas desde entonces, a pesar de que todavía se
      pueden ver en
      <ulink url="http://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php" >web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php</ulink>
      y
      <ulink url="http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing" >web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing</ulink> [sic].)</para>
    </blockquote>

<!--
<para>The tips of many icebergs of controversy are visible in that
text.  It refers to "our convictions", but smartly avoids spelling out
exactly what those convictions are.  For some, it might be the
conviction that code developed according to an open process will be
better code; for others, it might be the conviction that all
information should be shared.  There's the use of the word "theft" to
refer (presumably) to illegal copying&mdash;a usage that many object
to, on the grounds that it's not theft if the original possessor still
has the item afterwards.  There's the tantalizing hint that the free
software movement might be mistakenly accused of anti-commercialism,
but it leaves carefully unexamined the question of whether such an
accusation would have any basis in fact.</para>
-->

<para>En ese texto aparecen las puntas de muchos icebergs de controversia.  
Se refiere a "nuestras convicciones", pero
discretamente evita decir con exactitud de qué convicciones se trata. 
Para algunos, puede ser la convicción de que el código desarrollado en
concordancia con un proceso abierto será un código mejor; para otros
pudiera ser la convicción de que toda información debiera ser
compartida.  Aparece el uso del término "robo" para referirse
(posiblemente) al copiado ilegal&mdash;una costumbre que muchos
objetan alegando que pese a todo no es un robo si el propietario
original todavía tiene el artículo.  Hay una sospecha inquietante de que
el movimiento de software libre podría ser acusado por equivocación de
anticomercialismo, aunque queda por examinar detenidamente la cuestión
de si esta acusación tendría alguna base real.</para>

<!--
<para>None of which is to say that the OSI's web site is inconsistent
or misleading.  It's not.  Rather, it is an example of exactly what
the OSI claims had been missing from the free software movement: good
marketing, where "good" means "viable in the business world."  The
Open Source Initiative gave a lot of people exactly what they had been
looking for&mdash;a vocabulary for talking about free software as a
development methodology and business strategy, instead of as a moral
crusade.</para>
-->

<para>Esto no quiere decir que el sitio web de la OSI sea incoherente
o engañoso.  No lo es.  En realidad es un ejemplo de lo que la OSI
sostiene que le faltaba al movimiento del software libre: una buena
comercialización, donde "buena" significa viable en el mundo de los
negocios.  La Iniciativa de Fuente Abierta brindó a mucha gente
exactamente lo que buscaban&mdash;un vocabulario para referirse al
software libre como una metodología de desarrollo y una estrategia
para los negocios, en lugar de una cruzada moral.</para>

</sect2>

<!--
<para>The appearance of the Open Source Initiative changed the
landscape of free software.  It formalized a dichotomy that had long
been unnamed, and in doing so forced the movement to acknowledge that
it had internal politics as well as external.  The effect today is
that both sides have had to find common ground, since most projects
include programmers from both camps, as well as participants who don't
fit any clear category.  This doesn't mean people never talk about
moral motivations&mdash;lapses in the traditional "hacker ethic" are
sometimes called out, for example.  But it is rare for a free software
/ open source developer to openly question the basic motivations of
others in a project.  The contribution trumps the contributor.  If
someone writes good code, you don't ask them whether they do it for
moral reasons, or because their employer paid them to, or because
they're building up their r&eacute;sum&eacute;, or whatever.  You evaluate
the contribution on technical grounds, and respond on technical
grounds.  Even explicitly political organizations like the Debian
project, whose goal is to offer a 100% free (that is, "free as in
freedom") computing environment, are fairly relaxed about integrating
with non-free code and cooperating with programmers who don't share
exactly the same goals.</para>
-->

<para>La aparición de la Iniciativa por el Código Libre cambió el
panorama del software libre.  Formalizó una dicotomía que por mucho
tiempo no tuvo un nombre, y al hacerlo forzaba al movimiento a
reconocer que tenía una política interna al mismo tiempo que una
externa.  Hoy, el efecto es que ambos lados han tenido que encontrar
un terreno común, puesto que la mayoría de los proyectos incluye a
programadores de ambos campos, como también otros participantes que no
encajan claramente en una categoría.  Esto no impide que se hable de
motivaciones morales&mdash;por ejemplo, a veces aparecen
convocatorias con recaídas en la tradicional "ética de hackers".  Pero
es raro que un desarrollador de software libre / fuente abierta entre
a cuestionar abiertamente las motivaciones básicas de otros.  La
contribución encubre al contribuyente.  Si alguien escribe un buen
código, no se le pregunta si lo hace por razones morales o porque su
empleador le paga, o porque está engrosando su currículum, o lo que
sea.  Se evalúa la contribución en términos técnicos, y se responde
con fundamentos técnicos.  Inclusive organizaciones explícitamente políticas como el
proyecto Debian, cuyo objetivo es ofrecer un entorno computacional
100% libre ("libre como la libertad"), no tienen peros para integrarse
con el código no libre y cooperar con programadores que no comparten
exactamente los mismos objetivos.</para>

</sect1>

<!-- ========================== SECTION =========================== -->
<sect1 id="today">
<title>La Situación de Hoy</title>

<!--
<para>When running a free software project, you won't need to talk
about such weighty philosophical matters on a daily basis.
Programmers will not insist that everyone else in the project agree
with their views on all things (those who do insist on this quickly
find themselves unable to work in any project).  But you do need to be
aware that the question of "free" versus "open source" exists, partly
to avoid saying things that might be inimical to some of the
participants, and partly because understanding developers' motivations
is the best way&mdash;in some sense, the <emphasis>only</emphasis>
way&mdash;to manage a project.</para>
-->

<para>Cuando se maneja un proyecto libre, no se necesita hablar todos
los días sobre esos enfoques filosóficos. Los programadores no
pretenden que todos los integrantes del proyecto estén de acuerdo con
sus puntos de vista en todos los aspectos (aquellos que insisten en
hacerlo se encuentran rápidamente incapacitados para trabajar en
cualquier proyecto).  Pero se necesita estar advertido de que la cuestión
de "libre" contra "fuente abierta" existe, en parte para evitar decir
cosas que pueden enemistarlo a uno con algún otro participante, y en
parte porque un entendimiento con los demás y sus motivaciones es la
mejor manera, y&mdash;en cierto sentido&mdash;la
<emphasis>única</emphasis> manera de llevar adelante el
proyecto.</para>

<!--
<para>Free software is a culture by choice.  To operate successfully
in it, you have to understand why people choose to be in it in the
first place.  Coercive techniques don't work.  If people are unhappy in
one project, they will just wander off to another one.  Free software
is remarkable even among volunteer communities for its lightness of
investment.  Most of the people involved have never actually met the
other participants face-to-face, and simply donate bits of time
whenever they feel like it.  The normal conduits by which humans bond
with each other and form lasting groups are narrowed down to a tiny
channel: the written word, carried over electronic wires.  Because of
this, it can take a long time for a cohesive and dedicated group to
form.  Conversely, it's quite easy for a project to lose a potential
volunteer in the first five minutes of acquaintanceship.  If a project
doesn't make a good first impression, newcomers may wait a long time
before giving it a second chance.</para>
-->

<para>El software libre es una cultura por elección.  Para trabajar
con éxito en ella hay que entender por qué hay personas que
la eligen en primer lugar.  Las técnicas coercitivas no tienen efecto.
Si hay alguien que no se siente cómodo en un proyecto, recurre a otro.
El software libre se distingue incluso entre las comunidades de
voluntarios por sus inversiones limitadas.  Muchos de los
participantes nunca se encuentran cara a cara, y simplemente hacen
donación de algún tiempo cada vez que se sienten motivados.  Los
conductos normales que conectan a los seres humanos entre sí y se
concretan en grupos duraderos se reducen a un pequeño canal: la
palabra escrita, trasmitida por cables eléctricos.  Por esto puede
llevar mucho tiempo para formar un grupo dedicado y unido.  Y a la
inversa, es muy fácil que un proyecto pierda un voluntario potencial
en los cinco primeros minutos de haberse encontrado.  Si el proyecto
no impacta con una buena impresión, los recién llegados podrían
esperar mucho tiempo para darle una segunda oportunidad.</para>

<!--
<para>The transience, or rather the <emphasis>potential</emphasis>
transience, of relationships is perhaps the single most daunting task
facing a new project.  What will persuade all these people to stick
together long enough to produce something useful?  The answer to that
question is complex enough to occupy the rest of this book, but if it
had to be expressed in one sentence, it would be this:</para>
-->

<para>La transitoriedad real o <emphasis>potencial</emphasis> de las
relaciones es quizás la tarea más desalentadora que se debe enfrentar
en un nuevo proyecto.  ¿Qué va a persuadir a toda esa gente a
permanecer juntos el tiempo suficiente necesario para producir algo
útil?  La respuesta es tan compleja como para ocupar el resto de este
libro, pero si se tiene que expresar en una sola frase, sería la
siguiente:</para>

    <blockquote>
<!--
      <para><emphasis>People should feel that their connection to a
      project, and influence over it, is directly proportional to
      their contributions.</emphasis></para> 
-->
      <para><emphasis>Las personas deben sentir que su conexión con un
      proyecto, y su influencia sobre él, es directamente proporcional
      a sus contribuciones.</emphasis></para> 
    </blockquote>

<!--
<para>No class of developers, or potential developers, should ever
feel discounted or discriminated against for non-technical
reasons<footnote><para>There can be cases where you discriminate
against certain developers due to behavior which, though not related
to their technical contributions, has the potential to harm the
project.  That's reasonable: their behavior is relevant because in the
long run it will have a negative effect on the project.  The varieties
of human culture being what they are, I can give no single, succint
rule to cover all such cases, except to say that you should try to be
welcoming to all potential contributors and, if you must discriminate,
do so only on the basis of actual behavior, not on the basis of a
contributor's group affiliation or group identity.</para></footnote>.
Clearly, projects with corporate
sponsorship and/or salaried developers need to be especially careful
in this regard, as <xref linkend="money"/> discusses in detail.  Of
course, this doesn't mean that if there's no corporate sponsorship
then you have nothing to worry about.  Money is merely one of many
factors that can affect the success of a project.  There are also
questions of what language to choose, what license, what development
process, precisely what kind of infrastructure to set up, how to
publicize the project's inception effectively, and much more.
Starting a project out on the right foot is the topic of <link
linkend="getting-started">the next chapter</link>.</para>
-->

<para>Ningún desarrollador, real o potencial, debe sentir que no es
tenido en cuenta o es discriminado por razones que no sean técnicas.
<footnote><para>Puede haber casos en los que discrimines a ciertos
desarrolladores debido a la conducta que, aunque no está relacionada
con sus aportes técnicos, tiene el potencial de dañar el proyecto. Eso
es razonable: su comportamiento es relevante porque en el largo plazo
tendrá un efecto negativo en el proyecto. Debido a la variedad de las culturas
humanas, no puedo dar ni una sola regla breve para
cubrir todos esos casos, excepto decir que debes tratar de dar la
bienvenida a todos los colaboradores potenciales y, si tienes que
discriminar, hazlo sólo en base al comportamiento real, y no sobre la
base del grupo de afiliación de un contribuyente o su identidad de
grupo.</para></footnote> Claramente, los proyectos con apoyo de
empresas y/o desarrolladores pagos tienen que ser especialmente
cuidadosos en este aspecto, como se expresa en detalle en el <xref
linkend="money"/>.  Por supuesto, esto no quiere decir que si no hay
apoyo de empresas no hay nada de que preocuparse.  El dinero es sólo
uno de los tantos factores que pueden afectar el éxito de un proyecto.
Otras cuestiones son el lenguaje que se va a elegir, la licencia, cuál
será el proceso de desarrollo, qué tipo de infraestructura hay que
instalar, cómo promocionar efectivamente el arranque del proyecto, y
muchas otras cosas más.  El contenido del <link
linkend="getting-started">próximo capítulo</link> será cómo dar el
primer paso con el pie correcto al comenzar un proyecto.</para>

</sect1>

</chapter>

<!--
local variables: 
sgml-parent-document: ("book.xml" "chapter")
end:
-->