Capítulo 1: Optar por código abierto y conseguir vistos buenos

Antes de dar cualquier paso —antes de empezar a pensar en documentación, lenguajes e instrucciones para colaboradores— piensa si es necesario que otras personas de tu medio de prensa apoyen tu idea de código abierto. Obtener el visto bueno de los demás fomenta una cultura de apreciación y apoyo hacia este tipo de proyecto, ya sean grandes o pequeños, y sienta cimientos sólidos para que en el futuro sea posible llevar a cabo otras iniciativas más ambiciosas.

Esto normalmente significa convencer a gente en diferentes niveles de dirección de que tu participación en la creación de un software de código abierto merita una inversión de tiempo y recursos. Concretamente, necesitarás convencerles de que los beneficios son mucho mayores que los perjuicios. Cuando defiendas tu punto de vista puedes exponer claramente los argumentos a favor y en contra, y fijar un plazo para hacer una evaluación de tu participación en el proyecto.

¿A quiénes debes convencer?

Es bueno suponer desde el principio que todo el mundo en tu organización tendrá algún nivel de vinculación con tu proyecto y que necesitarás que estén de tu lado. Si trabajas en un medio de prensa grande, estaríamos hablando de los abogados de la organización, el departamento de Relaciones Públicas, o el Director(a) Ejecutivo(a). En un medio más pequeño con menos personal, serían solo un puñado de colegas, pero no dejan de ser válidas las mismas preocupaciones legales y de relaciones públicas.

¿Qué valor tiene liberar código?

Para conseguir la aprobación de los demás es importante saber por qué la gente libera su trabajo en primer lugar. Hay una serie de beneficios asociados (aunque, por supuesto, también debes estar al tanto de lo que se pierde). Comprender la pregunta "¿Para qué sirve liberar código?" desde varios ángulos te ayudará a comunicarte con gente cuyas prioridades no son las mismas que las tuyas.

Las listas siguientes parafrasean sugerencias de la comunidad y recursos externos como OpenSource.com, Open Source Everything! y Why Open Source.

Beneficios técnicos:

  • Rápida detección y corrección de errores. Cuando los programas son privativos, los únicos que pueden detectar y arreglar errores son los ingenieros de ese equipo. Liberar tu programa significa que podrá ser revisado por muchas más personas, que se pondrá a prueba bajo una serie de circunstancias mucho más diversas y que el enorme ecosistema de programadores que no están en tu equipo estará ayudando a arreglarlo. Recuerda la Ley de Linus: "Dada una cantidad de ojos lo suficientemente elevada, todos los errores se vuelven obvios."

  • Colaboración directa. El código abierto permite a las empresas colaborar en problemas que les son comunes, sin necesidad de complicadas asociaciones comerciales, ni contratos previos, etc., y encontrar así mejores soluciones más rápido.

  • Incentivo a la modularidad. Programar a la vista pública puede producir programas más limpios, más seguros y con una arquitectura más modular —lo cual también es bueno para el desarrollo interno. Al hacer que tu código sea lo suficientemente flexible y modular para ser usado por el público en diferentes proyectos, estás contribuyendo a que tus propios equipos internos dispongan de una herramienta que no caducará con el paso del tiempo.

  • Niveles más altos de calidad del trabajo. Hay un nivel mínimo para la creación de proyectos de código abierto —documentación, comentarios, exclusión de información sensible— que normalmente da lugar a buenos proyectos de programación. El simple hecho de pensar que el código de un proyecto podría liberarse ayudará a fomentar mejores prácticas.

Beneficios comerciales/de relaciones públicas

  • Coincidencia de necesidades comerciales. El código abierto permite a las empresas colaborar en problemas que les son comunes, sin necesidad de complicadas asociaciones comerciales, ni contratos previos, etc.

  • Buena promoción en los medios cuando los proyectos son buenos. Los proyectos de calidad generan buena publicidad y conquistan la buena voluntad del público. También le dan a la empresa la oportunidad de reclamar públicamente la cuestión para sí, y establecer los términos por los cuales se regirá el diálogo alrededor de una tecnología o servicio dado.

  • Crear una rueda nueva, sin tener que inventarla de cero. Cuando permites que otras personas accedan a tu código, les evitas tener que reinventar la rueda; en lugar de eso, pueden dedicar esa energía a mejorar tu rueda. Un buen ejemplo es Resque. Esta herramienta, además de mejorar gracias al trabajo de desarrolladores externos, contó con las contribuciones de cientos de desarrolladores que colaboraron con plug-ins que expandieron sus funcionalidades sin costo alguno. En lugar de malgastarse en un ecosistema de herramientas relacionadas pero diferentes e incompatibles, los esfuerzos de la comunidad se concentraron en hacer que el programa fuera portable, más amplio y extensible, lo cual a su vez incrementó el valor de Resque.

  • Reclutamiento y financiamiento. Los proyectos de buena calidad ayudan a atraer a desarrolladores que pueden ser una inspiración para tu trabajo y, al mismo tiempo, tu trabajo puede servirles de inspiración a ellos. En los medios de prensa financiados por comunidades, puede ser beneficioso que la organización sea percibida como un líder en la industria.

Beneficios éticos, de transparencia y de rendición de cuentas

  • Reciprocar el apoyo de la comunidad. Si usas computadoras es muy probable que emplees un poco de código abierto, y si eres desarrollador(a), probablemente dependes de decenas de estas herramientas. Libera tu propio trabajo para que en el futuro otros desarrolladores puedan beneficiarse.

  • Mantener una actitud coherente respecto a la transparencia en la empresa. De la misma forma que los periodistas citan las fuentes de sus datos y explican sus procesos metodológicos, liberar el código de un software lo hace transparente para los lectores y usuarios. Esto impulsa a la organización a interrogar sus propios procesos y a reflexionar sobre ellos.

  • Redundancia y distribuibilidad. Mientras más liberemos —datos sobre todo— más podremos aportarles a los periodistas herramientas para hacer su trabajo. Además, mientras más distribuido esté un recurso, más difícil será de borrar o de censurar por completo por una fuerza externa.

Para completar esta lista, aquí un par más de recursos (en inglés):

Preguntas y concepciones erróneas sobre código abierto

A continuación aparece una lista de preguntas y concepciones erróneas que es común encontrar al iniciar un proyecto de código abierto, especialmente la primera vez que se le explica el concepto a una organización. Algunas de estas preocupaciones tienen respuestas directas, mientras que otras exigirán que pienses en el alcance a largo plazo de tu proyecto. Puedes usar el siguiente guión para cubrir las que necesites.

Si encontraras preguntas o inquietudes que no aparecen en esta lista, recuerda siempre que es muy probable que alguien ya haya tenido que responder a algo parecido, así que pedir ayuda a la comunidad puede ser la forma de obtener una buena respuesta. (Y siempre puedes contactar a la gente que mantiene esta guía a través del correo fieldguide@opennews.org)

Abogados/Relaciones Públicas

Por lo general, a estos departamentos les preocupará la imagen pública de la organización, especialmente los riesgos legales y lo que pueda decir la prensa (positivo y negativo). Es posible que expresen inquietudes sobre los derechos legales que puedan corresponder a los colaboradores, sobre el riesgo de que el proyecto fracase en público, o sobre cómo la publicación de código inconcluso podría afectar la imagen de la empresa.

Si preguntan "¿Qué riesgos legales corremos aquí?"

Puedes responder:

  • "Discutamos las opciones de licencias y decidamos cuál es la que más se ajusta a nuestras necesidades" (consulta el capítulo 2 para más información sobre cómo elegir una licencia.)

  • "La [licencia que elegimos] nos da cobertura para _ y ______. Eso deberá despejar cualquier inquietud sobre posibles problemas legales."

¿Cuáles son los riesgos que suponen cada una de estas licencias?

¿Cómo afectará nuestra imagen liberar código inconcluso?

  • "Colaborar con la comunidad de software libre incrementa la visibilidad de nuestro trabajo y pone de relieve un valor neto añadido del periodismo. La gente de Relaciones Públicas puede hablar de nuestros aportes a la comunidad y promover proyectos que usen nuestras herramientas."

  • "Liberar un proyecto nos ayuda proclamar públicamente que la idea fue nuestra, muestra que somos líderes en nuestro campo y que contribuimos al avance de la industria."

  • "Estableceremos una serie de directrices claras, tanto para colaborar aportando código, como para conducirse en la comunidad, y garantizar así que el proyecto mantenga los estándares rigurosos de nuestra organización." (Consulta el capítulo 6 para más información sobre cómo hacer esto.)

¿Cómo nos aseguramos de que el proyecto que estamos liberando no contiene información de terceros protegida por derechos de autor?

  • "Seguiremos las prácticas establecidas para limpieza de bases de código antes de liberarlas a la vista pública." (Consulta el capítulo 3 para más información sobre cómo hacer esto.)

  • "Nos aseguraremos de mantenerles al tanto de cada versión nueva que lancemos para que nos comuniquen cualquier preocupación que puedan tener sobre información protegida por derechos de autor."

  • "Aquí están los detalles sobre qué vamos a liberar y qué permanecerá para uso interno/privativo:"

Líderes del medio de prensa

¿Cómo venderles un proyecto a los directores/editores, jefes de tecnología, administradores de proyectos y demás personas con el poder de tomar decisiones sobre las prioridades de nuestra redacción? He aquí algunas preguntas comunes que podrían hacerte cuando intentes venderles un proyecto de código abierto.

Si preguntan "¿Y si alguien toma nuestro código y desarrolla nuestra idea primero?"

Puedes responder:

  • "Siempre existe el riesgo de que la competencia esté trabajando en proyectos o ideas similares. Lo que vamos a liberar es la herramienta, no el contenido ni las ideas específicas de la historia."

  • "Podemos colaborar en la herramienta/los datos y competir en las historias/la realización."

  • "Podemos planear nuestro cronograma de lanzamiento para que coincida con la publicación de nuestra [historia/proyecto]. Así la gente puede contribuir a partir de ese punto, sin tener que preocuparnos de que nos roben la historia porque publicamos nuestro código/datos."

¿Cuál es el beneficio real de esto (para la comunidad y para nosotros)? ¿Por qué invertir tiempo/energía/recursos en esto?

  • "Liberar nuestro código nos ayudará a mantener ventaja en la competencia. Nos permite entablar una conversación más amplia sobre cómo resolver un problema X, en lugar de sentarnos en un rincón solitario a tratar de resolverlo por nosotros mismos."

  • "Nuestra participación en este proyecto nos señala como líderes en nuestro campo, y nos permite impulsar el desarrollo del periodismo (y de nuestra organización al mismo tiempo)."

  • (potencialmente) "¡Voluntarios que testearán la herramienta sin cobrar!"

  • "Siempre estamos lidiando con los mismos obstáculos para _ y _ . Al dedicarle recursos a este proyecto, esteremos resolviendo [problema específico en tu medio de prensa] y, a la larga, estaremos ahorrándoles tiempo a nuestros programadores."

  • "Liberar el código de nuestro trabajo nos obligará a mantener un diseño elegante y a desarrollar nuestro programa con disciplina, lo cual nos ayudará a minimizar la deuda técnica." (parafraseado de este escrito de Sumana Harihareswara)

  • "Liberar datos/software va ganando en importancia a medida que los datos se vuelven menos transparentes."

  • "Liberar código es muy parecido a explicar la metodología de un artículo de investigación: les permite a nuestros lectores comprender cómo construimos algo, los supuestos de los que partimos, y fomenta más transparencia en nuestro trabajo."

  • "En esa misma línea, el código abierto nos obliga a cuestionar las suposiciones que hicimos al construir una herramienta, al analizar los datos o al aproximarnos a un problema."

  • "Nosotros nos beneficiamos de recursos de código abierto (datos/herramientas) y tenemos la responsabilidad de reciprocarle esa ayuda a la comunidad."

  • "Dada la amplia distribución que hoy tiene el código abierto, nos volvemos más competitivos/atractivos para contratar a desarrolladores. Con frecuencia los mejores desarrolladores tienen algo de experiencia en crear o mantener este tipo de proyectos, y les atraen más las empresas que tienen alguna cultura de código abierto."

No quiero trabajar con/ayudar a mi competencia.

  • "Al trabajar con socios tendremos mejores probabilidades de encontrar financiamiento para proyectos futuros y de mantenimiento a largo plazo."

  • "Este proyecto no compromete nuestras metas ni nuestra misión, sino que nos dará el basamento para alcanzarlas más rápido."

  • "Ellos tienen recursos que necesitamos y esto nos permite acceder a ellos sin tener que pagar."

  • "Algunos de los mejores medios —lugares como ProPublica, Vox, y The New York Times— trabajan de manera colaborativa y comparten herramientas de código abierto. Han demostrado que la colaboración es buena para el negocio."

¿Vamos a terminar siendo nosotros los que paguemos la cuenta para que todo el mundo se beneficie de gratis?

  • "Nuestra inversión de recursos ahora será retribuida a largo plazo porque seguimos enfrentando [este problema específico] y esta herramienta solucionará esos problemas."

  • "Asociarnos con otros y liberar esta herramienta nos permitirá conseguir contribuciones de gente fuera de los medios: nos beneficiaremos del tiempo y la experiencia donada por los demás."

  • "El software nunca es completamente gratis: incluso si alguien está usando nuestro software de código abierto, también necesitará dedicarle recursos, igual que nosotros."

  • "Aunque liberar código implica costos, necesitaremos invertir recursos en la creación de esta herramienta."

La última vez que hicimos esto fue un fracaso total. ¿Por qué sería diferente esta vez?

  • "Tienen razón, [el proyecto pasado] enfrentó muchos obstáculos reales. Este es nuestro plan para aprender de esa experiencia y lograr que este nuevo proyecto triunfe: _"

  • Comenta las razones por las cuales "fracasó" el proyecto anterior, pero también menciona qué salió bien, y cuáles son tus planes para evitar esos obstáculos esta vez.

  • Presenta un cronograma y hoja de ruta claros, acompañados de planes de contingencia para cuando, inevitablemente, se presenten problemas.

  • Los análisis post mórtem son un buen lugar para empezar a plantar la semilla del próximo proyecto. Invita a los principales actores involucrados a discutir los proyectos una vez que hayan concluido, especialmente si no marcharon del todo bien.

Tu jefe inmediato

Por "jefe inmediato" nos referimos principalmente a la gente que controla tu horario y recursos (y/o los de tu equipo). A estas personas les preocupa cómo un proyecto de código abierto afectará la carga de trabajo de todo el mundo, tanto a corto como a largo plazo, a medida que el proyecto entra en modo de mantenimiento.

Si preguntan "¿Cuánto va a tardar? ¿Durante cuánto tiempo vas a trabajar en esto?"

Puedes responder:

  • "He aquí el tiempo que planeo dedicarle al proyecto cada semana (muéstrales un plan y una hoja de ruta detallados para la primera fase del proyecto. ¿Todavía no los tienes? Consulta el capítulo 4 para más instrucciones sobre cómo perfilar esto).

  • "Una parte del proceso de liberación de código será definir qué tipo de mantenimiento planeamos realizar para esta herramienta, y comunicarle eso a nuestro público. Podemos explicar si el proyecto recibirá mantenimiento, si se ofrecerá asistencia técnica y si estamos aceptando contribuciones desde el principio, lo cual nos ayudará a gestionar esas expectativas." (Más consejos aquí.)

  • "Este es el valor que pienso que va a aportar este proyecto: [pon ejemplos específicos que se conecten con la misión principal de tu organización]."

  • "Teniendo en cuenta el valor que aportará, ¿qué prioridad creen que deba darle a este proyecto con respecto a los demás?"

¿Cómo vas a balancear este proyecto con los demás?

  • "Este proyecto facilitará muchísimo nuestro trabajo en __ y ____, y consumirá semanalmente el mismo tiempo que le dedicamos a [ejemplo de proyecto/reunión/revisar Twitter]."

  • Pregúntales qué piensan al respecto: "Teniendo en cuenta el valor que aportará, ¿qué prioridad creen que deba darle a este proyecto con respecto a los demás?"

  • "Creo que puedo dedicarle X horas cada semana sin que se afecte el resto de mi trabajo. Si al final de cada semana les envío un informe de cuánto hemos progresado, podemos evaluar cómo priorizar este proyecto a medida que avanzamos."

Clientes/Departamento comercial

Si tienes que lidiar con clientes externos o con un equipo comercial interno, probablemente tengas que justificar la apertura de software contra el ingreso neto de tu organización.

Si preguntan "¿Cómo haremos dinero con esto?"

Puedes responder:

¿Por qué tenemos que ser nosotros los que paguemos por algo va a beneficiar a todo el mundo?

  • "Estableceremos una imagen de liderazgo y de contribución a la industria, algo que viene acompañado de mucho reconocimiento. Estamos invirtiendo en algo que mucha gente va a usar y que resaltará los vínculos con nuestra empresa. Se nos dará crédito cada vez que otra organización use la herramienta.

  • "Es posible que en el futuro queramos beneficiarnos de alguien que esté haciendo lo mismo (karma)."

  • "Estamos recibiendo la colaboración de otras personas sin costo alguno a medida que avanzamos. ¿Por qué pagarle a un desarrollador para que mantenga un programa de software privativo para siempre si podemos tener cualquier cantidad colaborando de gratis?"

Socios

Quizás ya tengas una asociación establecida con otro medio de prensa, o estás pensando que crear una podría ayudar muchísimo a tu proyecto de código abierto. La cultura abierta y las posiciones con respecto a la liberación de código varían de un medio de prensa a otro: lo que piensan sobre la pertinencia de esta modalidad, qué licencias usar y qué directrices seguir en el flujo de trabajo y con la comunidad para lograr que todo marche sin obstáculos.

Si preguntan "¿Por qué deberíamos trabajar con ustedes?"

Puedes responder:

  • "Este es un problema que enfrentamos todos, y colaborar con recursos nos ayudará a resolverlo mejor (y a evitar tener que resolverlo una y otra vez)."

  • "Tenemos un plan claro, con metas y un cronograma establecidos."

  • "Al trabajar juntos, tenemos más oportunidades de convencer a fundaciones para que apoyen nuestro proyecto."

¿Qué ganamos con esto?

  • "Es conveniente para el presupuesto. Este es un problema que enfrentamos todos, y colaborar con recursos nos ayudará a resolverlo mejor (y a evitar tener que resolverlo una y otra vez)."

  • "El nombre de ustedes aparecerá en un proyecto de código abierto de primera línea y muy respetado."

Las necesidades de nuestros medios son diferentes, ¿cómo resolveremos controversias/conflictos?

  • "Identificaremos a un líder en cada uno de nuestros equipos, y ese grupo central de actores involucrados trabajará de conjunto para establecer el alcance del proyecto."

  • "Juntos debemos poder identificar metas y valores comunes para este proyecto y remitirnos a esa misión/manifiesto si nos vemos en problemas."

  • "Crearemos un equipo en Slack para cuestiones y conversaciones diarias, y tendremos un chequeo semanal con el grupo central de actores involucrados para asegurarnos de que estamos en el camino correcto."

Desarrolladores

Dado que mantener un proyecto de código abierto puede tomar tiempo, es posible que a algunos desarrolladores pueda preocuparles la forma en que esta modalidad va a afectar sus horarios. Probablemente saben bien que los posibles colaboradores/usuarios estarán a la espera de documentación y ejemplos actualizados, nuevas versiones, respuestas a solicitudes de incorporación de cambios (pull requests) y corrección de errores a medida que se expande el uso de la herramienta.

Si preguntan "¿Cuánto trabajo añadirá esto a mi contenido de trabajo actual (tanto a corto como a largo plazo)?"

  • Conversa con tus desarrolladores e inclúyelos en el proceso de decidir si vale la pena que determinado proyecto sea de código abierto o no. Por ejemplo, ¿por qué piensan que esto es importante? ¿Qué vamos a ganar al retribuirle su apoyo a la comunidad de esta forma? Con los demás proyectos que tienen actualmente, ¿pueden encontrar cinco horas para dedicarle a este proyecto? ¿diez horas?

  • Explica claramente los roles en el proyecto: ¿Quién se encargará de dar asistencia técnica a largo plazo? ¿Hay un plan de desactivación? Define sus responsabilidades desde el inicio.

  • "Una parte del proceso de liberación de código será definir qué tipo de mantenimiento planeamos realizar para esta herramienta, y comunicarle eso a nuestro público. Podemos explicar si el proyecto recibirá mantenimiento, si tiene asistencia técnica y si estamos aceptando contribuciones desde el principio, lo cual nos ayudará a gestionar esas expectativas." (Más consejos aquí.)

¡Tú!

Antes de lanzarse en una aventura de código abierto, es importante analizar si dispones del tiempo y los recursos necesarios para contribuir.

  • ¿Tengo tiempo para esto?

  • ¿Es algo en lo que quisiera trabajar a largo plazo?

  • ¿De cuánto tiempo dispongo para dedicarle? ¿Cómo disminuir (o incrementar) mi participación a medida que pase el tiempo?

  • ¿Es algo que voy a mantener? ¿O simplemente lo estoy lanzando al mundo?

  • ¿Hay alguien trabajando en una herramienta/proyecto como este ya? ¿Va a ser un aporte verdaderamente significativo a los recursos de código abierto para los medios? ¿O será mejor invertir el tiempo en contribuir a un proyecto parecido que ya esté en marcha?

Estudios de casos

ESTUDIO DE CASO: Colaboración entre departamentos

Cómo Quartz creó Chartbuilder

"Por supuesto, lograr que nuestro personal usara Chartbuilder no fue algo que ocurrió de la noche a la mañana, pero con la ayuda de los reporteros más habituados a trabajar con gráficos pudimos enseñar a todo el mundo a usar la herramienta con una demostración de 30 minutos, seguida de ayuda personalizada para cada participante a medida que encontraban algún problema."

ESTUDIO DE CASO: Colaboración entre organizaciones (reclutar socios, comunicación, financiamiento)

Proyecto Burton Street

El Proyecto Burton Street comenzó en 2009 para ayudar a contar la historia de la comunidad del mismo nombre, un barrio con una población mayoritariamente negra en Asheville. En esa área se estaban realizando varias demoliciones como parte de una propuesta de expansión de la autopista interestatal, que amenazaba con destruir esta comunidad. El periódico local era relativamente pequeño, con recursos y competencias limitadas. Parte de su personal estaba absolutamente renuente a emprender ningún proyecto más allá del periodismo impreso tradicional. Eventualmente, tres periodistas, un editor, un grupo local de fotógrafos, dos empleados de la parte web con experiencia en programación (y entusiastas del código abierto) y varios otros amantes del software libre en la comunidad (personas distintas en varios puntos del proyecto) colaboraron todos para llevar adelante este esfuerzo común, comunicándose con los líderes de la comunidad y sus residentes para involucrarlos directamente.

La idea era mostrar desde diferentes frentes lo que estaba pasando en este lugar, con mapas, fotografías, historias tradicionales e información y experiencias aportadas directamente por los residentes, y al mismo tiempo brindarle al público una forma fácil de presentar la información e interactuar con ella.

Como no faltan por todo el país barrios que enfrentan situaciones similares, la idea era también crear un modelo que pudiera transferirse rápidamente a otros usuarios. Por lo tanto, poner el código a disposición pública era un aspecto del proyecto, aunque no uno en el que yo me centré como uno de los periodistas.

Para leer más sobre el Proyecto Burton Street como un ejemplo de comunicación comunitaria, consulta el capítulo 6. Para saber más sobre los problemas que tuvo que enfrentar a la larga por falta de un plan de desactivación, consulta el capítulo 8.

Herramienta educativa electoral para Asheville

El objetivo del proyecto Programa para Asheville (Code for Asheville, CoA) fue construir una herramienta electoral de código abierto para las elecciones de 2016 que abarcase todas las votaciones posibles, mucho más allá de los cargos de Presidente, Gobernador y Senador, para cubrir campañas que, a pesar de ser esenciales, tenían mucho menos cobertura, como la elección del Fiscal General, el Comisionado del Condado y los referéndums locales. Muchos medios locales ya habían enviado representantes a contactar a CoA, o habían sido contactados por esta y los Servicios Electorales de Buncombe. En este caso, las conexiones que existían ayudaron a que se organizaran rápidamente debates y coordinaciones (luego se decidió que todo el mundo se reuniera y trabajara cara a cara) para crear esta herramienta educativa electoral con el aporte de expertos de diferentes áreas.

Más recursos

Conclusión

Conseguir la aprobación de los diferentes grupos al interior y alrededor de tu medio de prensa puede parecer abrumador, pero cuando tienes de tu lado un sentido claro de tus objetivos y una hoja de ruta factible, no es nada inalcanzable. "Sin sorpresas" debería ser tu evangelio. Al comunicarte de antemano con todos los actores involucrados, estás sentando cimientos sólidos para el proyecto. A la postre, son estas relaciones las que harán que el esfuerzo de código abierto funcione o fracase.

Recuerda que está bien empezar con algo pequeño. Mide tus resultados con parámetros concretos para que la próxima vez sea todavía más fácil mostrarles a tus compañeros que liberar un proyecto de código abierto tiene beneficios cuantificables para tu organización.

Ahora que ya has aprendido algunas formas de lidiar con las reticencias organizacionales, entremos en materia y aprendamos cómo empezar un proyecto nuevo de código abierto.