Inicio > Cómo crear negocios exitosos > Piratería: ¿Amenaza u oportunidad?

Piratería: ¿Amenaza u oportunidad?


Resumen

Al plantear la pregunta acerca de si la piratería es una amenaza o una oportunidad, mi intención es proponerle al lector un ejercicio que le permita visualizar la realidad detrás de esta cuestionable praxis.

A lo largo de este ensayo, usted conocerá los orígenes de la piratería moderna, la manera en que se configura, las implicaciones económicas y sociales, las razones por las que surge, su justificación y -más importante aún-, conocerá cifras que le permitirán evaluar la piratería como una industria y que le ayudarán a visualizar estrategias de negocios inspiradas en esta praxis, pero dentro del contexto legal, efectivas que le permitan optimizar sus operaciones al tiempo que optimiza sus resultados.

Antecedentes

Etimológicamente, la palabra pirata -en la opinión de algunos autores-, proviene del latín pirāta y éste -a su vez-, del griego  πειρατης (peiratés) que se compone de la raíz  πειρα, -ας (peira), la cual significa prueba y que se deriva del verbo πειραω (peiraoo), que puede traducirse como esforzarsetratar de, o intentar la fortuna en las aventuras.

Otros opinan que la palabra tiene su origen en la raíz griega pyros que significa fuego, debido a que los amotinados solían prender fuego a los navíos tras el motín, con el objeto de eliminar toda clase de pruebas que les incriminaran, dificultando la búsqueda de los culpables.

Un dato que adquiere relevancia para nuestros fines -según lo plantearemos más adelante-, concierne a los vitalianos, que acostumbraban repartir el botín obtenido en partes iguales y que se constituían como una sociedad sin clases, por lo que eran conocidos como los Likendeeler, o igualitarios.

La historia de la piratería es tan vasta como compleja y no es propósito de este ensayo abundar en los detalles históricos de esta praxis. No obstante, para aquellos de ustedes que sientan curiosidad por analizar a detalle su historia, este artículo en la Wikipedia puede ofrecerles una multitud de interesantes detalles.

El propósito de este ensayo es hablar sobre una de las formas de la piratería moderna, relacionada con las leyes de propiedad intelectual e industrial y de la manera en que esta práctica  afecta en términos económicos a la industria y a la sociedad.

De acuerdo con la PGR y el Acuerdo Nacional contra la Piratería, suscrito el 15 de Junio de 2006, se define a la piratería como:

“… toda aquella producción, reproducción, importación, comercialización, venta, almacenamiento, transportación, arrendamiento, distribución y puesta a disposición de bienes o productos en contravención a lo establecido en la Ley Federal del Derecho de Autor y en la Ley de la Propiedad Industrial.

En México, la PGR señala también a la piratería como la realización de acciones delictivas contra la propiedad, tales como editar una obra sin permiso del autor o propietario del título de propiedad, pero no la limita a obras e invenciones, sino que considera también como piratería la producción de bienes tangibles, tales como ropa, accesorios, bebidas y medicamentos -entre otros-, siendo estos últimos particularmente peligrosos para el ser humano en su consumo pues, además del robo o fraude, el consumo de bebidas o medicamentos piratas puede ser causal de problemas de salud que conlleven a la muerte de su consumidor. Además, en el caso de software, música o películas piratas, se indica que al violar los mecanismos de protección de originalidad, pueden ocasionar daños al equipo del usuario y que -en general-, el uso y consumo de productos piratas daña sensiblemente a la sociedad, ya que conduce a la pérdida de puestos de trabajo.

Particularmente en la industria del software, han existido una diversidad de movimientos cuyo propósito ha sido defender la libertad de acceso a la tecnología creada por los desarrolladores bajo el fundamento de que -por sus características-, una evolución natural y deseable del software solo puede surgir en un ambiente libre, que promueva a reutilización del código.

En el ámbito del desarrollo de software, una práctica común es la de compartir código entre programadores y se justifica al considerar los costes del desarrollo.

Como programador, puedo atestiguar que esto sucede con frecuencia y que -en realidad-, esta praxis simplifica enormemente el desarrollo. En palabras de Eric Steven Raymond -en su ensayo “The Cadthedral and the Bazaar“-:

“Los buenos programadores saben qué escribir. Los programadores grandiosos saben que re-escribir y -por tanto-, qué reutilizar.”

Seamos pragmáticos. El espectacular desarrollo alcanzado en la industria del software en nuestros días jamás habría sido posible si sus protagonistas no motivaran esta praxis.

También desde el punto de vista de un programador -que es lo que soy-, todo código es susceptible de contener errores dado que es el producto de un intercambio de ideas entre un analista de sistemas y un usuario. Al recabar información de un usuario con el fin de comprender en qué consiste su necesidad específica, puede tener lugar una comprensión errónea de las necesidades del usuario. Por eso, es un requisito que el analista de sistemas rectifique sus apreciaciones con el usuario, para confirmar que se entendió correctamente la necesidad o replantear las especificaciones.

Adicionalmente, el analista de sistemas debe plantear alternativas al usuario y permitir que este decida. Las alternativas que un analista de sistemas ofrece a un usuario normalmente tienen que ver con otros puntos de vista acerca de cómo resolver una necesidad. De la misma manera, el usuario puede interpretar lo que el analista de sistemas tiene que decirle de un trillón de maneras distintas y -de nueva cuenta-, se requiere trabajar exhaustivamente para asegurar que se ha comprendido punto por punto la manera de resolver una necesidad.

Toda esta información que se recaba con el fin de producir un sistema de software que resuelva las necesidades del usuario, debe ser traducida a un diseño, que es la herramienta a través de la cual se comunica al programador lo que debe codificar. Por si no fuera suficiente, el programador puede -a su vez-, interpretar el diseño de la manera equivocada, si el trabajo de diseño es paupérrimo o no se ha institucionalizado apropiadamente esta praxis.

Más aún, una vez producido el código correspondiente, la incidencia de errores puede no haber desaparecido del todo, a pesar de la meticulosidad con que se haya trabajado hasta este punto.

Esto es así porque todos los programas -para hacer algo productivo-, incluyen estructuras a las que denominamos condicionantes, que establecen diferentes cursos de acción que pueden tener lugar cuando un usuario utiliza el sistema de software. Son estas estructuras de control -las condicionantes-, las que dotan de inteligencia al software. Sin estas, el software no sería más que una curiosidad sin mayor trascendencia.

Para asegurarme de que el lector me ha seguido correctamente hasta este punto, propongo el siguiente ejemplo: Digamos que un programador está codificando un programa para registrar la venta de artículos de una tienda y ha llegado a la sección del programa en que el usuario registra el pago de un cliente.

Dentro de la especificación de sus necesidades, el usuario ha declarado que un cliente puede pagar en efectivo o mediante tarjeta de crédito.

Para hacer más realista este ejemplo, diremos que el usuario ha establecido que cuando el cliente paga con una tarjeta de crédito, esta puede ser una tarjeta Visa o una tarjeta American Express.

Con el fin de validar la tarjeta de crédito, tanto Visa como American Express utilizan un código que normalmente se localiza en la parte posterior de la tarjeta, junto a la firma del tarjeta-habiente. La estructura de este código es distinta tanto para Visa, como para American Express.

Tan solo con este pequeño ejemplo hemos identificado ya 4 cursos diferentes de acción. En el escenario en que el cliente paga en efectivo, solo registra el pago y la acción se detiene ahí.

Pero si el cliente paga con tarjeta de crédito, es necesario determinar si la tarjeta es Visa o American Express y -en cada uno de estos casos-, al introducir la clave que viene en la parte posterior de la tarjeta, deberá asegurarse que la clave se introduce en el formato apropiado.

Todo programa puede incluir cientos de miles -quizas millones-, de estructuras de control como las descritas -cada una atendiendo a un caso que puede llegar a tener lugar-, al momento de utilizar el sistema de software.

Habrá casos que se presenten con mayor frecuencia que otros y algunos que es muy raro que tengan lugar.

Debido a estas estructuras, se estima adecuado dedicar a la comprobación previa a la liberación de la versión final del software, tanto tiempo como se haya destinado a su confección, pero esto suele no ser costeable.

En la práctica, se considera un conjunto limitado de casos de prueba -aquellos con mayor probabilidad de ocurrir- y se organiza un plan de prueba en torno a éstos.

Debido a esto, el software -una vez que se libera-, puede contener errores. Todo programador debe estar consciente de este hecho y ésta debe ser su primera suposición: “Todo programa es susceptible de tener errores“.

Cuando una empresa editora de software insiste en mantener su código oculto, la incidencia de errores es algo que se mantiene en familia. Por eso empresas como Microsoft, con frecuencia publican parches para su software.

Al restringir el acceso al código solo a los programadores de la empresa que lo edita -software privativo-, la evolución del software será tediosamente lenta, el software producido será normalmente de inferior calidad y el resultado que se obtenga -con seguridad-, presentará continuas fallas en su operación.

En términos económicos, para una empresa editora de software, matener una licencia privativa de su software es altamente costoso, no solo por el costo de oportunidad relacionado con la producción de productos de calidad inferior, sino también en el contexto de las continuas correcciones al software que se ha liberado con anterioridad, la aplicación de las garantías -que pueden sortearse a través de las cláusulas especificadas en la licencia de uso- y las posibles demandas por daños que la empresa reciba de sus clientes -lo cual es uno de los principales puntos que se evaden en detrimento de los usuarios en las licencias de uso regularmente.

Una mejor praxis es la producción de software libre -licenciamiento libre-, cuyo código puede ser compartido con otros y no solo eso; se motiva a otros a compartir el código.

La idea subyacente es que el mismo código puede ser revisado por millones de otros programadores que podrían, o bien, sugerir cambios, o bien, realizar dichos cambios ellos mismos.

Sé que este proceso suena caotico, pero es el mismo esquema de trabajo que utilizó Linus Torvalds al liberar su kernel de Linux y el resultado ha sido tal, que ha puesto a temblar a empresas como Microsoft.

El licenciamiento libre no solo es más efectivo en sus costes -lo que se hace evidente al momento de reutilizar el código-, sino que facilita la evolución del software, al grado de que los productos de software libre son -con frecuencia-, de más alta calidad que los productos de software privativo.

El licenciamiento libre nació gracias a uno de esos movimientos de los que hablo párrafos atrás, cuando comencé a abordar este tema.

La referencia obligada es Richard Stallman, a quien se atribuye el concepto de Copyleft, que otorga a los usuarios de los productos amparados bajo este la libertad no solo de utilización, sino también de distribución tanto del código ejecutable que utiliza el usuario final, como del código fuente con que se genera el ejecutable, de manera que otros programadores puedan corregir errores y ampliar su funcionalidad.

Stallman inició el proyecto GNU -acrónimo recursivo que significa GNU no es Unix-, el 27 de Septiembre de 1983,  con el que pretendía la creación de un sistema operativo basado en Unix que pudiera utilizarse y distribuirse libremente, tanto en su forma ejecutable como en su codigo fuente. En 1985, Stallman publicó su Manifiesto GNU, en el que establecía esta ideología de libertad y -poco más adelante-, fundó la Fundación del Software Libre para promover esta ideología y -gracias a su concepto de Copyleft-, creó la Licencia Pública General GPL, que establece los 4 preceptos del movimiento: (0) Libertad de uso, (1) Libertad para estudiar el código y modificarlo para adaptarlo a nuestras necesidades específicas, (2) Libertad de distribución y (3) libertad para mejorar el código.

En Europa, en los países bajos, en la Universidad Vrije de Amsterdam, Andrew S. Tanenbaum creó su sistema operativo Minix -basado en Unix-, en 1987, para la IBM PC. Como profesor de la citada Universidad, Tanenbaum desarrolló Minix con propósitos puramente pedagógicos, que le permitieran a los estudiantes de la asignatura de Sistemas Operativos comprender la construcción de estos. Dado su enfoque pedagógico, Tanenbaum insistió en conservar la simplicidad de su sistema operativo.

Para 1991, en Helsinki, Linus Torvalds inició lo que más adelante de convertiría en el kernel -núcleo-, de Linux, basado en Minix. Poco después, en 1992, Stallman decide utilizar el núcleo de Linux para complementar su sistema operativo libre basado en Unix y así nace GNU/Linux.

La relevancia de Linux en el mundo de la informática radica en el esquema de trabajo -tal vez no inventado por Torvalds-, pero ciertamente promovido por él, que consiste en la cooperación conjunta de miles de programadores a lo largo del planeta para contribuir al desarrollo de software con el acceso libre a su codificación.

A través de ese resumen podemos visualizar como surge el movimiento del software libre, que promueve la libertad para compartir conocimientos en aras de un desarrollo tecnologico sustentable y como se contrapone con la praxis sugerida por el licenciamiento privativo.

De acuerdo a la praxis que sugiere el licenciamiento privativo, al compartir software, para estudiar como está hecho y tener la posibilidad de modificarlo para adaptarlo a nuestras necesidades específicas y -más aún-, para mejorarlo, el programador estaría incurriendo en una serie de acciones consideradas delictuosas, ya que -con el fin de estudiar la ingeniería del software y realizar mejoras a éste-, el programador utilizaría técnicas conocidas como ingeniería inversa.

La licencia GPL previene esta interpretación y requiere que el autor del software registre su propiedad intelectual, antes de distribuirlo con dicha licencia. De esta manera, al licenciar el uso del software bajo GPL, el autor -reconocido por la ley gracias al registro de su obra que lo hace acreedor a la propiedad intelectual de la misma-, reconoce, está consciente y acepta que su obra sea distribuida libremente, estudiada y modificada, lo que previene cualquier interpretación de la realización de actos delictuosos.

De hecho, para Stallman -por mencionar a uno de los muchos que comparten esta idea-, el empleo de la palabra piratería para definir la libertad de compartir conocimientos y utilizarlos de la mejor manera en beneficio de la comunidad, se constituye en un exceso.

Es necesario tener en mente que las leyes de propiedad tanto intelectual, como industrial, fueron creadas durante la era industrial y que esta era comenzó a fenecer hace más de 30 años.

Los fenómenos característicos de la era de la información -principalmente la aparición de la Internet, pero no limitado a esta, tales como los movimientos que promueven libertades de uso y distribución, como las ya mencionadas, y la proliferación de compañías basadas en Internet, tales como Google, Twitter y Facebook, que basan su ingreso en la oferta de productos de uso gratuito y libre-, han hecho inoperantes tales leyes, al menos para los empresarios que fundamentan sus emprendimientos en las nuevas circunstancias globales.

Desde la lupa de una corporación -digamos, que produce música-, el efecto de la piratería es potencialmente dañino para su propia existencia. Amenaza su fuente de ingreso y modifica las condiciones de su nicho de mercado, lo reduce y tiene el potencial de aniquilarlo. Como corporativo, justifica la eliminación de puestos de trabajo con su incapacidad para competir bajo las nuevas circunstancias.

Sin embargo, para el músico, el aprovechamiento de la distribución de su música en forma gratuita no necesariamente se constituye en una amenaza, sino en un beneficio, ya que la distribución gratuita permite que más gente conozca su trabajo, con lo que gana prestigio y aumenta sus beneficios al participar en conciertos y otros eventos. Más aún, el ingreso que puede percibir por regalías es -por mucho-, inferior al que le producen sus presentaciones en público, de acuerdo con el artículo Infracción de derechos de autor” en Wikipedia.

Así que llegamos al punto crítico de este ensayo:

¿Cuál es la importancia del impacto que la piratería tiene en la industria?

De acuerdo con el artículo “La piratería es el mejor negocio de México” -y conforme a cifras presentadas en el 2010-, los ingresos provenientes de la industria de la piratería en México alcanzaron los 75 mil millones de dólares anuales, tres veces más que los ingresos producidos por la industria petrolera, cuatro veces más que las remesas de dinero de los Estados Unidos a México y siete veces más que lo reportado por la industria del turismo.

Desde el enfoque que establece la práctica de la piratería en el contexto del delito -conforme a lo dictado por las leyes de propiedad intelectual e industrial-, el daño se produce contra las empresas establecidas directamente.

Indirectamente, el usuario de productos piratas puede verse afectado por amenazas a su salud, a la integridad de su patrimonio y a su situación laboral, además de ser víctima de fraude.

Así que, por un lado, tenemos a las empresas a la antigua usanza, diseñadas bajo un esquema anacrónico, propio de la era industrial, interesadas en defender a toda costa su participación del mercado y -por el otro lado-, al usuario, que es afectado en su integridad individual.

Sin embargo, esto nos lleva a la siguiente disyuntiva:

¿Por qué surge la piratería?

De acuerdo con el mismo artículo, que menciona cifras de la Encuesta Nacional de Ocupación y Empleo, durante el 2010, 63 de cada 100 mexicanos ganaban hasta 3 salarios mínimos que -para entonces-, representaban $5,834.00 MXN por mes y que se descompone como sigue: 5.9 millones de mexicanos ganaban solo un salario mínimo ($1,795.00 MXN al mes), 10.4 millones de mexicanos ganaban entre uno y dos salarios mínimos ($3,590.00 MXN por mes), mientras que 9.5 millones de mexicanos, ganaban de dos a tres salarios mínimos ($5,834.00 MXN cada mes).

¡Estamos hablando de que una persona ganando 1 salario mínimo al mes durante ese ciclo, tenía un ingreso diario equivalente a $4.60 USD diarios!

Con un salario de menos de 5 dólares diarios, esta persona debía mantener a su familia, proveyéndole de alimentos, vestido y vivienda, por mencionar lo básico.

Si a esto añadimos la educación de sus hijos, esta persona -además-, debía invertir en material escolar.

Para ponerlo en perspectiva, si esta persona tiene un hijo que -no entiendo cómo, pero supongámos que así es para efectos del ejemplo-, estudia en la preparatoria o en la universidad y lleva una materia tal como Cálculo Diferencial e Integral o Matemáticas Aplicadas e Investigación de Operaciones, es probable que a ese muchacho le pidan que adquiera una licencia del software MathCad, para ayudarse a resolver sus deberes escolares.

Si este muchacho comprara la licencia de la versión 14, debería pagar $49.95 USD por ella, es decir suponiendo un tipo de cambio acorde con esa época -el 2010- de $13.00 MXN por dólar, $649.35 MXN. Peor aún, si sus profesores le requirieran la versión 15, entonces el precio de la licencia sube hasta $129.95 USD que -al tipo de cambio propuesto-, representaría en pesos $1,689.35 MXN.

Sin necesidad de realizar las conversiones a pesos es muy sencillo percibir que si su padre gana -digamos- $5.00 USD diarios para mantener a su familia, tendría que dejar de darle a esta el sustento para alimentación, vestido y vivienda durante 10 días, si debe comprar la licencia de MathCad 14, o durante 26 días, si debe adquirir la licencia de Mathcad 15 para que su hijo pueda cumplir con el requerimiento de su escuela.

En términos llanos, la piratería surge en respuesta a las condiciones de vida del pueblo en que este problema tiene lugar.

Seguramente, el padre de familia de nuestro ejemplo decidirá buscar una copia pirata del software que su hijo necesita pagando -quizás-, hasta $30.00 USD por el programa y seguramente mucho menos que eso.

Cuando el problema de la piratería se recrudece en una nación, se debe a la fragilidad de su sistema legal y sus instituciones. La fragilidad de su sistema legal frecuentemente es el resultado de una inconsistencia entre las leyes promulgadas y la realidad de la sociedad para la que son creadas estas leyes.

La fragilidad institucional puede tener que ver -por una parte-, con la corrupción dentro de ellas y -por la otra-, con la negligencia producto de la ignorancia en lo relativo a la esencia de las leyes y -ergo-, de su aplicación.

En el caso partícular de México, las leyes disponibles en materia de la regulación y protección de la propiedad intelectual e industrial se constituyen en una legislación obsoleta y mediocre, diseñada para una era cada día más cercana a la extinción como lo es la era industrial. En adición -por si fuera poco-, se da una profunda apatía por parte del Gobierno a los problemas fundamentales de la sociedad y hacia sus circunstancias.

De manera que no solo existe una carencia de actualidad en las leyes correspondientes, sino una terrible inconsistencia entre lo que dichas leyes protegen -los intereses corporativos, principalmente-, y la realidad y necesidades de la sociedad.

Esto tiene un efecto mucho más relevante. La profunda brecha en el nivel de vida de los mexicanos, entre quienes ganan más y quienes ganan menos, conduce también a la necesidad de crear el empleo informal que -entre otros efectos-, conduce a una escasa recaudación fiscal, la que -a su vez-, conduce a la escases de recursos para que el Gobierno satisfaga adecuadamete las necesidades sociales.

¿En qué consiste el empleo informal?

Cuando una persona se ve imposibilitada para obtener un empleo, buscará maneras alternativas de producir un ingreso. Esto hace que las personas en empleo informal, recurran al auto-empleo, ofreciendo sus conocimientos y habilidades en el mercado por cuenta propia, muchas veces sin el requerido registro ante Hacienda, por lo que no están cumpliendo con obligaciones fiscales de especie alguna.

Un problema adicional al empleo informal es que los ingresos que estas personas perciben es normalmente limitado, lo que dificulta -aún cuando resuelve en parte-, el producir el ingreso suficiente para satisfacer sus necesidades y las de su familia.

Básicamente, lo que el individuo hace es sobrevivir. Pero…

¿Qué tiene que decir la teoría económica al respecto, desde el punto de vista del mercado?

En teoría económica, se establece que cuando el precio de un artículo pesa mucho en el presupuesto, o existen muchos sustitutos del artículo, lo más probable es que la demanda de dicho artículo sea elástica y sugiere la estrategia de disminuir el precio para aumentar el ingreso.

Por otra parte, también establece que en condiciones en las que el precio sea bajo o el artículo tenga pocos sustitutos, la demanda será probablemente inelástica frente al precio y -en este caso-, la estrategia sugerida es aumentar el precio para aumentar el ingreso.

Continuando con el ejemplo que hemos venido planteando, en el caso específico de software como MathCad -con licencia privativa-, se trata de un programa  caro, con pocos sustitutos -desde el punto de vista de MathCad como software privativo con licencia legal, con respecto a su competencia que incluye otros programas similares, también privativos y con licencia legal- y -en el caso de las copias piratas-, ocurre lo contrario, es un artículo barato, con muchos sustitutos -desde la perspectiva de la piratería, en la que existe una gran oferta de copias piratas.

La contradicción con respecto a la teoría económica es clara. Siendo fieles a esta, considerando la adquisición de una licencia legal del software, por su propiedad de pesar mucho sobre el presupuesto, la elasticidad del producto debería ser alta y la estrategia adecuada -basándonos únicamente en el enfoque del precio-, debería ser la de disminuir el precio del producto.

Por otro lado, bajo el mismo supuesto de adquirir una licencia legal, pero basándonos en la existencia de pocos sustitutos, entonces la elasticidad es baja y la estrategia adecuada debería ser aumentar el precio del producto.

Para complicarlo todavía más, dado que el producto es extranjero y su precio ha sido fijado para un nivel de vida distinto al nuestro, bajar el precio no es una opción y -a menos que los profesores del muchacho de nuestro ejemplo sean flexibles en cuanto a que programa adquiera el padre del muchacho-, no existe la posibilidad de adquirir un producto sustituto.

Un análisis similar puede inferirse para la alternativa de la piratería.

En este caso -software pirata-, el precio es bajo, por lo que los distribuidores intentarán vender la copia pirata al precio más alto que puedan pero, como hay una gran oferta -muchos piratas ofreciendo la misma copia-, el padre podrá comprar el software al pirata que le dé el mejor precio.

La proliferación de sustitutos -en este caso-, no es un problema relevante, ya que al ser copias piratas y existir la alternativa de comprarlo al pirata que ofrezca el mejor precio, el padre de familia podrá adquirir exactamente la versión que los profesores le requieran al muchacho.

Considerar el efecto de la elasticidad precio-demanda es fundamental para cualquier negocio. Mientras las cosas funcionen como lo explica la teoría, las acciones a seguir son sumamente sencillas, pero en el entorno económico -frecuentemente-, no ocurre así y es imprescindible recurrir a disciplinas tales como la econometría para encontrar la elasticidad de nuestros productos.

Una epifanía que modificó mis paradigmas

Hace unos ocho años me encontraba preocupado por la escases de ventas del software que creaba. Me preocupaba que la gente no compraba mi software y pasé mucho tiempo pensando en las razones que me permitieran explicar este fenómeno para determinar una solución.

De pronto, tuve una visión: La gente no estaba adquiriendo mis productos porque podía obtener sustitutos baratos en el mercado de la piratería.

Fue entonces que empecé a intuir que si algo andaba mal, no era el mercado, ni mis productos, sino mi modelo de negocios. Entendí -de repente-, que estaba esforzándome por abarcar un nicho de mercado utilizando un modelo de negocios -que resulta obsoleto-, si no se vende el tipo de software que las empresas normalmente utilizan porque están obligadas a hacerlo, principalmente por cuestiones fiscales, como el software de Contabilidad.

Pero esta súbita comprensión de lo que acontecía no paraba allí.

En aquella época, el software que yo producía no era el tipo de software que las empresas utilizan para cumplir requisitos fiscales. Si bien, era software para administración, las empresas siempre podían recurrir a cualquier programa de administración disponible en el mercado; inclusive al mío.

Sin embargo no vendía. No vendía -en parte-, por la misma razón que en el caso anterior. Las empresas siempre podían recurrir al mercado de la piratería para resolver sus necesidades pero -más aún-, porque había en el mercado programas de administración con una presencia de muchos años. Programas con una base de usuarios enorme, con presupuestos gigantescos de publicidad y cuya venta se facilitaba -principalmente-, porque los mismos usuarios se sugieren entre sí que alternativas utilizar -publicidad de boca en boca. En pocas palabras, porque ese software contra el que estaba empeñado a competir, era un software firmemente posicionado en el mercado.

Hoy en día, ocurre lo mismo en la mediana y gran empresa. Parece que muchas empresas han adoptado la moda de los ERP. Lo hacen, porque vendedores como SAP ofrecen sistemas apegados a las certificaciones que las empresas de mediana y gran escala requieren para competir en el mercado internacional.

De nueva cuenta, este tipo de software -ERP-, es privativo y excesivamente costoso.

Para competir en este mercado, debería concentrarme en el nicho de mercado al que SAP y otros ERP no pueden llegar: la pequeña empresa. Sin embargo, el problema del posicionamiento persiste: hay otros programas similares a lo que yo puedo ofrecer, que tienen décadas en el mercado. Cuando un usuario piensa adquirir un programa de tales características, pensará invariablemente en las alternativas posicionadas y -aunque no es imposible-, quizás, una pequeña parte de los usuarios en el mercado llegue a considerar mi programa.

Quienes lo hagan, lo harán porque no pueden o no están dispuestos a pagar el precio por licencia de las opciones posicionadas y porque se resisten a recurrir a la piratería como alternativa. Además, es probable que algunos de ellos quieran implementar características específicas que no obtendrán con las alternativas posicionadas.

Una consideración final es que no soy el único productor pequeño de software de administración y -buscando en la Internet-, es posible encontrar a muchos otros productores en las mismas circunstancias que yo.

El problema se agudiza al ver como se establece una guerra de precios, en la que los diferentes actores bajan el precio de sus productos como factor diferenciador, con lo que el negocio deja de ser rentable, ya que las ventas no se incrementan a pesar de la reducción de precios para ninguno de los que estamos en las mismas condiciones.

En concreto, ¿cuál es el problema con el modelo de negocios?

Como se puede ver, el problema es complejo, si, pero se reduce al modelo de negocios. Todos los programadores estábamos en aquella época luchando por entrar a un mercado en el que existen oligopolios firmemente posicionados, bajos sus mismas reglas, ofreciendo software privativo a precios que no dejaban margen de utilidad para nadie.

¿Por qué es esto un problema? Porque no estábamos haciendo más que imitar a los oligopolios y una característica de estos -los oligopolios-, es que imponen fuertes restricciones para entrar al mercado.

De manera que, si la idea era entrar en el mercado con éxito, era forzoso modificar nuestros paradigmas. Desafortunadamente hoy en día no hay muchos que hayan comprendido la necesidad de esta medida.

Cómo formular una estrategia efectiva

Uno de los aspectos clave que Stallman insistiría en destacar, es que libre, no significa gratis. En inglés, el vocablo Free tiene dos acepciones: una para indicar libertad y la otra para señalar la ausencia de precio.

El software libre no necesariamente es software gratuito, aunque a mucha gente le gustaría pensar que es así.  En realidad, que el software libre tenga o no un precio, depende de la estrategia de mercado que se adopte. Incluso servicios y productos que se entregan sin costo para el usuario, pueden convertirse en negocios sorprendentemente rentables.

En la práctica, existe software libre cuyo valor de cambio es mucho más alto que el del software privativo.

No obstante, al considerar el valor de uso, el software privativo siempre será mucho más costoso que el software libre.

La razón que explica esta última aseveración es que el software privativo tiene asociados costos de licenciamiento que no es posible evitar, a menos que se incurra en prácticas de piratería. Además, el mantenimiento de dicho software termina relegado a la empresa productora, quien monopoliza el producto. La monopolización de un producto y los servicios asociados, con frecuencia da lugar a la fijación de precios abusivos, ante la imposibilidad de acudir a alguien más para obtener el mismo resultado.

En contraste, el valor de uso del software libre suele ser más eficiente para sus usuarios, dado que la naturaleza misma del licenciamiento promueve la libre distribución del mismo y fomenta la creación de comunidades que participan en el desarrollo de nuevas funciones del software y en la mejora de las prestaciones que ya ofrece.

Esto invariablemente nos conduce a considerar los costes de operación de las casas editoras de software dependiendo de si sus productos incorporan licenciamiento privativo o libre.

Para una empresa que produce software privativo, los costes de operación se mantienen altos debido a los requerimientos de personal para adaptar el software a las nuevas circunstancias del mercado y mantenerlo actualizado. Pero más importante que los costes de operación son los costes de oportunidad: el producto resultante no podrá beneficiarse de las contribuciones de una comunidad interesada en el proyecto.

La decisión de mantener el código cerrado con frecuencia se fundamenta en la protección de secretos comerciales que tienen el potencial de poner en peligro la ventaja competitiva de la empresa.

En su ensayo “El caldero mágico“, Eric Steven Raymond explica las distintas motivaciones para mantener el licenciamiento del software como privativo, así como las implicaciones de cada una. Así mismo, también explica las implicaciones del licenciamiento libre.

Con frecuencia, el desarrollador debe debatirse entre producir software bajo una licencia privativa o hacerlo mediante un licenciamiento libre.

De elegir una licencia privativa, muy probablemente sus costos de operación crezcan, conforme el proyecto adquiera mayor importancia.

Pensemos en un desarrollador freelance que crea un sistema de software para PYMEs. Al inicio, las cosas se mantienen sencillas y él puede administrar su proyecto -sin mayores consecuencias-, por si mismo. Con el tiempo, sus clientes le recomendarán a otros y pronto deberá atender a una comunidad de usuarios en crecimiento. Llegará un momento en que él solo no podrá darse abasto para atender a sus clientes y necesitará contratar ayuda.

Ahora, supongamos que este desarrollador freelance considera que su software es su ventaja competitiva ya que, de no ser así, no habría conseguido que sus usuarios le recomendasen en primer lugar.

Debido a esta percepción, el desarrollador puede llegar a suponer que compartir su tecnología podría ser una mala idea, así que, antes de aceptar, obliga a los candidatos a las posiciones de apoyo a firmar acuerdos de confidencialidad, de no competencia y de cesión de derechos.

De esta manera se ha constituido una casa editora de software privativo y -para garantizar la lealtad de su plantilla de personal, está obligado a ofrecer altos salarios que les desanimen a competir con él.

Por otro lado, dado que el prestigio de esta naciente compañía esta en pleno auge, nuestro desarrollador emprendedor toma la decisión de vender su prestigio, más que su software.

Después de todo, la casa editora de software ya es conocida y existe una comunidad de usuarios que la recomiendan. Ahora esta empresa puede darse el lujo de añadir al precio de sus productos y servicios la plusvalía de la percepción de sus clientes.

Por si esto fuera poco, ha comenzado a constituirse un oligopolio que -de no actuar los mecanismos reguladores diseñados para prevenir la formación de monopolios-, podría transformarse en monopolio.

Poco a poco, esta nueva casa editora comienza a imponer fuertes restricciones para abordar su nicho de mercado, dejando fuera del mapa a sus competidores.

Pero, ¿cómo se incrementan sus costes operativos?

La formación de este naciente oligopolio obliga a la casa editora a reclutar desarrolladores -principalmente-, otorgándoles excelentes salarios para disuadirlos de competir contra la propia empresa. Así mismo, debe construir un equipo de soporte técnico, que resuelva los requerimientos de los usuarios de su software, con un esquema de atención a clientes preferentemente de 24×7 -las 24 horas del día, los 7 días de la semana. Por otra parte, deberá considerar la inversión en infraestructura para educación y capacitación, ya que -con seguridad-, uno de los servicios complementarios más atractivos que puede ofrecer es la capacitación de usuarios en lo relativo a la operación de su software.

Aunque puede invertir en publicidad, su mejor publicidad es la publicidad de boca en boca, ya que fue está la que le colocó en esta posición ventajosa para empezar.

También debe considerar importante una división de investigación y desarrollo ya que -de no hacerlo-, cualquiera de sus competidores estará feliz de llevarlo a cabo, con tal de arrebatarle la vanguardia.

En otras palabras. se produce una espiral económica, en la que un conjunto de acciones -por sus resultados efectivos-, conduce al establecimiento de nuevas estrategias que produzcan más acciones efectivas, lo que perfila las condiciones de crecimiento sustentable e incrementa paulatinamente los costes de operación.

Sin embargo, tomando en cuenta ahora los costos de oportunidad, como ya ha sido establecido con anterioridad, el bloqueo del código para eliminar la posibilidad de competencia tiene el efecto de limitar de manera importante la evolución del software.

Esto conduce a productos y servicios de calidad cuestionable que incrementan los costes de operación para ser capaces de evitar una desbandada de los usuarios cautivos. Se deben asignar recursos para intentar mejorar la calidad del producto, pero en muchas ocasiones estos esfuerzos serán banales.

Si -en vez de una estrategia de software cerrado-, se hubiese elegido la estrategia de código abierto, las circunstancias se habrían producido de la siguiente manera.

El desarrollador freelance enfrenta la disyuntiva de su capacidad para atender las necesidades tan diversas -muchas veces, dispares-, de sus usuarios. Se da cuenta de que -a pesar de haberles vendido un mismo programa-, los usuarios exigen adaptaciones a sus necesidades específicas y -en este punto-, comprende que mantener múltiples versiones del mismo software es un mal negocio. Así que opta por la ley de oro del programador:

“Cuando produzcas software, dótale de mecanismos de programación, de manera que tu software pueda ser adaptado a las necesidades cambiantes de sus usuarios, sin afectar a tu código.”

 O, lo que es lo mismo:

“Utiliza una estrategia de desarrollo por capas que te permita crear independencia entre los diversos estratos de tu software, orientándolos a propósitos específicos, pero permitiendo la comunicación entre los diferentes estratos, de manera que se establezca una funcionalidad cooperativa entre ellas.”

¿Qué tienen de relevante estos consejos?

Consideremos el primero de ellos: implementar una interfaz de programación a  nivel de aplicación, de manera que facilite a sus usuarios adaptar el software a sus necesidades específicas, sin que al hacerlo afecten a su código.

Cuando un desarrollador crea una aplicación que resuelve una necesidad general, como la administración de inventarios -por mencionar un ejemplo- y la coloca en una empresa, tarde o temprano esta empresa solicitará que se realicen modificaciones para que la aplicación de software atienda a necesidades específicas de esta; necesidades que no fueron consideradas durante el desarrollo porque se pretendía obtener un producto de funcionalidad genérica.

Las cosas empiezan a complicarse cuando se instala este mismo software en una segunda empresa que solicita sus propias adaptaciones, lo que produce una nueva versión.

El mantenimiento comienza a complicarse ya que -ahora-, en vez de asegurar que una versión del software funcione adecuadamente, hay que garantizar que dos versiones ligeramente diferentes del mismo software funcionan sin problemas.

He aquí el poder de la implementación de una interfaz de programación: a través de ella, el mismo usuario podrá introducir cambios en las funciones que -se sabe-, son susceptibles a modificaciones, ya sea porque dependen de requisitos fiscales que se modifican eventualmente y con cierta regularidad, o dependen de la ejecución de cálculos cuya fórmula podría cambiar de un momento a otro, o implementan una determinada apariencia en la manera de presentar la información, o se basan en fundamentos que se modifican gracias a la implementación de políticas de mejora continua o a la adquisición de una compañía por parte de otra. Las razones pueden ser ilimitadas.

Como parte de las prestaciones del software, se implementa un mecanismo de programación adecuado a los cambios que se puede prever podrían tener lugar de una manera más o menos regular. Este lenguaje incorporado en nuestra aplicación le permite al usuario realizar las adaptaciones que requiera, sin necesidad de modificar el código fuente de nuestro programa.

Esta sencilla acción le da control al usuario sobre la tecnología que adquiere y le otorga un cierto nivel de independencia en lo concerniente a la administración de dicha tecnología.

Lejos de resultar una oportunidad de mercado desaprovechada, se convierte en un aspecto altamente favorable, ya que hemos dado al usuario de nuestro software la habilidad para estudiar su confección y analizar las fortalezas y debilidades de nuestra tecnología.

Con el tiempo, este mismo usuario que ha adquirido control de la tecnología que ha comprado, determinará por sí solo la necesidad de implementar nuevas prestaciones en el software, ya que le hemos otorgado un nivel de poder sobre la tecnología y al experimentarlo, sabrá que puede pedir más poder aún.

Esta estrategia puede funcionar impecablemente, pero requiere que el software sea configurado como una secuencia de estratos, independientes uno de otro, pero interconectados gracias a la habilidad de comunicarse entre sí.

Cada estrato se hace cargo de una función particular y se concentra solo en ella.

Cuando una de las capas necesita una prestación que solo otro estrato le puede ofrecer, se comunica con este y solicita el servicio requerido.

Es como construir los diferentes subsistemas que integran un sistema más grande.

La ventaja de esta praxis es que localiza los problemas que pueden llegar a tener lugar, facilitando su ubicación. Además, garantiza que una vez corregido un problema, se podrá confiar en que no ha afectado a otros estrados y que la solución que se aplicó a la parte disfuncional, bastará para asegurar la robustez de nuestro software. Más aún, ciertas partes de nuestro software, pueden -a nuestra elección-, quedar ocultas al mismo tiempo que otras se mantienen abiertas.

La idea de mostrar ambas visiones, nos permite establecer un punto de partida para determinar un modelo de negocios apropiado a lo que pretendemos lograr.

Volviendo a la discusión que inicié para compartir con el lector mi experiencia en el mercado del software y las dificultades por las que atravesé cuando las cosas fueron mal y mi software no se vendía, situación que me llevó a entender que el problema era modelo de negocios que estaba utilizando, es momento de hablar de soluciones.

Como puede darse cuenta el lector, la primera decisión importante que un desarrollador en mis condiciones debería tomar es si el software que produzca debe ser privativo o libre.

La manera en que estructure su negocio dependerá en gran medida de esta decisión. En términos generales, una organización de código abierto siempre es más eficiente en costos que una organización de licenciamiento privativo; sin embargo, habrá ocasiones que sea requerido un licenciamiento privativo porque las condiciones así lo ameritan, por ejemplo, a petición del mismo cliente.

Entonces, la organización que adoptemos deberá contemplar ambas posibilidades.  Recordemos que el caso particular del que hablo, es el caso de un desarrollador independiente, que crea aplicaciones a medida y que compite en un entorno de oligopolios.

En esta experiencia no se trata de un desarrollador que crea una aplicación y basa toda su empresa en torno a dicha aplicación, sino de un desarrollador que se dedica a crear software a pedido, bajo las especificaciones de sus clientes y que, quizás, tenga alguna aplicación que ha instalado para varios clientes que comparten una misma necesidad. En otras palabras, quizás haya comenzado con la creación de una aplicación de software para PYMEs y tiene esta misma aplicación instalada con diferentes clientes, pero también puede ocurrir que algún cliente le pidiese que desarrollara una aplicación que solo este cliente tiene y que no le interesa a los demás clientes, como aquellas aplicaciones desarrolladas específicamente para resolver algún proceso de producción.

Dadas estas circunstancias, eso es lo que obliga a este desarrollador a mantener ambos enfoques. Un licenciamiento libre, para las aplicaciones que pueden compartir varios clientes y un licenciamiento privativo, para aplicaciones que son desarrolladas para un solo cliente.

El segundo aspecto a considerar es la propiedad sobre el código fuente, así como el acceso a éste. Muchos usuarios adquieren el software con el único propósito de utilizarlo como está. Pocas veces se preguntan cómo está hecho. Pero en algunos casos, el usuario demandará el libre acceso al código fuente.

El empresario deberá definir una política que describa como se realiza la distribución del código fuente.

Por un lado, cerrar el código implica que no desea compartir detalles sobre la implementación dado que estos detalles implican una ventaja competitiva -para empezar- y -además-, atan a los usuarios de su aplicación a recurrir solo a él para adaptar el software a sus necesidades específicas.

Por el otro lado, abrir el código abre también la posibilidad a que otros programadores estudien su confección y propongan mejoras fundamentadas en el análisis de la confección del software y -aún más-, realicen ellos mismos estas mejoras.

En México, la Ley Federal de Derechos de Autor contempla la producción de obras derivadas y -ante la posibilidad de que esto ocurra-, es menester que el licenciamiento sea claro es este aspecto.

Luego entonces, ¿cuál es la mejor postura? La respuesta a este planteamiento es muy sencilla: Si se produce código cerrado, el ingreso que se derive de la distribución del ejecutable y de los productos y/o servicios complementarios, dependerá de lo actractiva que resulte esta oferta para el usuario consumidor.

Consideremos el mercado de la facturación electrónica y más específicamente, de los PACs -Proveedores Autorizados de Certificación-. La Secretaría de Hacienda y Crédito Público, con el fin de establecer la facturación electrónica, reconoció la necesidad de abrir el servicio a la iniciativa privada, constituida por desarrolladores que crearon el software para realizar la facturación por medios electrónicos. Ante esta necesidad, estableció condiciones muy restrictivas para que solo algunos de estos proveedores pudieran prestarlo. La inversión que se requiere para acceder a este mercado es en el orden de un millón y medio de pesos que el PAC debe pagar a manera de fianza, sin incluir en esto la inversión que requiere en infraestructura, desarrollo, atención a clientes y otros requisitos operativos.

Dadas las dimensiones de la inversión requerida para ingresar a este mercado, las limitaciones que impone Hacienda con respecto a hacer pública la tecnología que hace posible la facturación, para garantizar que solo algunos proveedores son autorizados para prestar el servicio y las limitaciones que imponen los mismos proveedores con el fin de constituirse en oligopolios, este es un caso típico de licenciamiento privativo.

De no optar por el licenciamiento privativo, desde la perspectiva de un PAC, facilitaría el ingreso de otros proveedores y disminuirían su participación del mercado. Desde el punto de vista de Hacienda, mantener una base muy elitista de PACs le permite asegurar el control de la tributación.

Ahora, en el aspecto económico, la configuración de estos oligopolios permite la definición de precios a niveles abusivos. Después de todo, solo una reducida élite puede proporcionar el servicio y -además-, es una obligación fiscal el acceder a este servicio.

En otras palabras, dado que el contribuyente está obligado a utilizar este servicio, los PACs tienen un ingreso asegurado, pero su participación del mercado está acotada por la presencia de otros PACs y -para aumentarla-, están obligados a recurrir a la mercadotecnia para presentar de manera más atractiva para el usuario los servicios que ofrecen.

No obstante, incurren en prácticas muy similares y, cuando Hacienda decida utilizar otros mecanismos de tributación, toda su tecnología quedará obsoleta.

Precisamente eso fue lo que ocurrió cuando Hacienda decidió cambiar de la facturación en papel a la facturación electrónica. Anteriormente, los que se beneficiaban de este mercado eran los impresores. Con la llegada de la facturación electrónica las imprentas pasaron a segundo término y existe un enorme riesgo de que dejen el negocio ya que, si bien, aún es posible que se realice la facturación en papel, ahora puede resolverse implementando una sencilla hoja de cálculo con la que se genera la factura.

¿Cómo puede verse amezado el mercado de los PACs? Bien, consideremos el caso específico de las aplicaciones para dispositivos móviles. Alguno de los PACs -más avezado que sus competidores-, podría desarrollar una aplicación de facturación electrónica para móviles y luego venderla a una compañía de telefonía celular que se encargara de distribuirla. Con el tiempo, esta alternativa terminaría imponiéndose y desplazaría a todos los demás PACs en el mercado.

Esto es así, porque -considerando el cómputo ubicuo-, es más sencillo para el usuario emplear un dispositivo móvil que una computadora, le dá una mayor flexibilidad y autonomía, ya que no se ve obligado a estar frente a su computadora para facturar. Por otro lado, la aplicación podría distribuirse de manera completamente gratuita a quien quisiera utilizarla. La renta estaría en la producción de facturas, no en la adquisición de la aplicación. La cobranza podría realizarse a través del saldo disponible del móvil y -esto-, abriría las puertas a nuevos y mayores mercados.

Para que un PAC tradicional pueda ingresar a este mercado,debería convertirse en proveedor de telefonía, o desarrollar aplicaciones para el proveedor de telefonía y darles mantenimiento, con lo que cambiaría la esencia de su mercado.

Ahora, ¿cuál es el escenario para la postura de licenciamiento libre?

Abrir el código puede parecer una tontería si permitimos que nuestro egoismo nuble nuestra razón. Da la posibilidad de que otros se aprovechen de nuestro esfuerzo para lucrar con él en un viaje gratis. Pero esta es la percepción desde el punto de vista del desarrollador.

Desde la perspectiva del usuario, el código abierto le da control sobre la tecnología que adquiere, le permite instalarlo sin restricciones en tantos equipos como lo necesite y, mejor aún, permite la formación de un mercado de competencia monopolística en que hay muchos proveedores que pueden solucionar un problema específico, con lo que el usuario de la aplicación puede elegir a aquel que le ofrezca las mejores condiciones.

En otras palabras, abre la aplicación a una base de usuarios mucho mayor. El mercado es mucho más extenso y el ingreso que -si bien-, se comparte con muchos otros desarrolladores, también es mucho mayor.

Considere el caso Google. Los creadores de Google desarrollaron un buscador e insistieron que la búsqueda debía ser gratuita. Durante mucho tiempo sus inversionistas se preguntaron cómo lucrar con un servicio que era por definición gratuito -y que debía serlo, a pesar de todo-, hasta que tomaron prestada la idea de lucrar al estilo de la sección amarilla.

Anunciarse en Google a través de anuncios patrocinados que aparecen al estilo de los resultados de las búsquedas, es bastante económico si se realiza de la manera adecuada y, sin embargo, los ingresos que percibe Google por este concepto son del orden de los miles de millones de dólares anuales.

Y el código de Google se mantiene cerrado, aunque presta servicios de índole gratuita. No obstante, Google también promueve la proliferación de desarrolladores de aplicaciones para Google, poniendo a su disposición APIs con las que pueden crear aplicaciones para esta plataforma.

El ejemplo de Google es el ejemplo de una compañía que ofrece la posibilidad a otros desarrolladores de crear aplicaciones basadas en su tecnología al darles acceso a una interfaz de programación, aún cuando mantiene el núcleo de su código cerrado.

Con todo lo anterior en mente, es claro que para resolver el problema de ventas de mis aplicaciones, la mejor postura era la de abrir mi código y mantener el licenciamiento privativo restringido solo a aplicaciones que -por su naturaleza inherente-, debieran manejarse de esta manera.

El mejor argumento de ventas lo constituye el conjunto de beneficios que el usuario puede obtener del código abierto: libre distribución, control de la tecnología que compra, posibilidad de seleccionar al proveedor que le plantee las mejores condiciones y la autorización para estudiar y mejorar el código.

En adición, la implementación de una interfaz de programación y el desarrollo por capas, me permite la integración de partes del código abiertas, al mismo tiempo que mantengo otras cerradas.

Más aún, esto me ha permitido la formulación de estrategias de mercadeo que en algunos casos, me permiten la distribución gratuita del software y la creación de otros productos y servicios complementarios que son la fuente de mis ingresos.

Para explicarlo de manera sencilla -sin entrar en los detalles de un proyecto concreto en el que estoy trabajando-, puedo facilitar el acceso a la aplicación de manera que el usuario la adquiera de manera gratuita, porque lo que me interesa es que la usen.

Mi ingreso -entre muchos otros productos y servicios-, se obtiene a partir de la consultoría. Es decir, sabiendo que tarde o temprano el usuario de mi aplicación necesitará de mis servicios, le permito el libre acceso a mi tecnología.

Conclusiones

Sé que la mayor parte de mi exposición está enfocada a la industria del software y lo hice así a propósito para ayudar al lector a comprender de manera directa las implicaciones de la piratería.

Después de todo, a los programadores suele asociársenos con la piratería. De hecho, es mi apreciación que el negocio del software está fundamentado en el plagio. Apple tomó prestada la tecnología de Xerox para introducir al mercado su interfaz gráfica y ¡qué bueno que lo hizo! Más adelante, Microsoft aprovechó el libre acceso a esta tecnología que Apple le facilitó para crear Windows y, de nueva cuenta, ¡qué bueno que lo hizo!

Sin el plagio, la industria del software no habría podido evolucionar al nivel en que se encuentra ahora. El plagio es el motor de la evolución del software.

En lo personal, considero que todo programador es por definición un hacker. Como programadores, en muchas ocasiones debemos estudiar meticulosamente código producido por otros programadores. Lo hacemos, para dar mantenimiento al software e introducir mejoras.

Si el ambiente fuese más restrictivo, el usuario no podría beneficiarse de las enormes ventajas que esta apertura le da.

¡Somos -en esencia- piratas!

¿Debemos todos los programadores del mundo estar en la carcel, pagando condenas, por compartir nuestro código? Creo que -si aún no lo estamos-, se debe al beneficio que otorgamos a la sociedad por nuestra praxis.

El título de este ensayo plantea al lector una simple pregunta: ¿Es la piratería una amenaza o una oportunidad?

Si usted está leyendo esto, su apreciación sobre este ríspido cuestionamiento se definirá por el bando en que se encuentre. Si usted es un empresario cuyo emprendimiento está estructurado para seguir las reglas del antiguo mundo de la era industrial, quizás la mayor parte de mis aseveraciones le hayan parecido una blasfemia contra el statu quo. Por otra parte, si usted es un consumidor como cualquier otro, o tiene una visión renovada, más contemporanea -ad hoc a la era de la información-, quizás haya descubierto que un cambio de paradigmas puede favorecerle más que afectarle.

Despues de todo, como industria, la piratería está produciendo ingresos de más de 75 mil millones de dólares anuales en nuestro país.

Por favor -insisto-, no me tergiverse. No estoy sugiriendo que nos convirtamos todos en piratas y vivamos al margen de la ley.

Lo que estoy diciendo -sin mayor ambigüedad-, es que la piratería es un resultado lógico, inevitable, de un conjunto de circunstancias a las que hemos sido llevados por la realidad económica de nuestro país y que -en un arranque de inspiración maquiavélica-, si no podemos vencerlos, deberíamos unirnos a los piratas, sin convertirnos en piratas.

Como alguna vez lo sugerí -en esa vieja novela que escribí hace más de 10 años: “Gene/Sys: La última frontera“-, para combatir la piratería hay que lograr que los piratas operen con pérdidas.

Si usted es un visionario que ya ha comenzado a sumar dos más dos, probablemente se haya dado cuenta que la piratería -si bien es una praxis reprochable-, más que amenaza es una oportunidad para redefinir nuestros emprendimientos y que podemos obtener mayores beneficios al crear modelos de negocios que la aprovechen.

A fin de cuentas, yo también tengo contenidos protegidos por la Ley Federal de Derechos de Autor y por la Ley de Propiedad Industrial. Aún así, me parece que el mercado de la piratería sigue siendo un mercado virgen, que no ha sido explotado porque mantenemos una visión retrógrada y anacrónica. Que podemos tomar ventaja de una praxis cuestionable, actuando siempre dentro del marco legal.

Decidí escribir este ensayo por la tarde del miércoles pasado. Tenía en mente hablar de otra cosa; tenía en mente enfocarme en las circunstancias europeas y la desaceleración del dragón rojo; pero de pronto surgió la idea de este ensayo y no quise desaprovecharla.

Luché con mi mente para encontrar la mejor manera de exponer este tema, hasta que la inspiración llegó y pude vaciar mis ideas en este documento de manera natural.

Como lo he hecho a lo largo de una década, le invito a pensar como empresario. Un verdadero empresario aprovecha las crisis para generar oportunidades. La piratería, más que una amenaza, es una oportunidad. Todo depende de su visión de las cosas.

Si desea contactar al autor, puede escribirle a: manuelmanrique@comocrearnegociosexitosos.com.

Anuncios
  1. Aún no hay comentarios.
  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: