🏗️ ¡Ya está aquí el nuevo plan de estudios Certified Full Stack Developer!

💬  El nuevo inglés para desarrolladores CEFR Nivel B1

🤳 Importantes actualizaciones de nuestras aplicaciones móviles.

La Ruta del Desarrollador Full Stack Certificado de freeCodeCamp

Aquí está el contenido completo de la nueva ruta del Desarrollador Full Stack Certificado. Es una pasada:

🛠️ 64 Talleres - Cursos interactivos de codificación paso a paso sobre herramientas que van desde HTML a SQL o Python (42 ya están en vivo)

🏛️ 513 Lecciones - Vídeos cortos que cubren conceptos de informática, con preguntas de opción múltiple para comprobar tu comprensión (313 ya están disponibles)

⚗️ 83 Laboratorios - Proyectos en los que empiezas con un editor en blanco y un conjunto de pruebas, (60 ya están disponibles)

📰 62 Páginas de repaso - Listas completas de temas de cada módulo que puedes repasar para prepararte para pruebas y exámenes (46 ya están disponibles)

🔬 66 Cuestionarios - Para afirmar su comprensión de los conceptos y herramientas de desarrollo de pila completa (46 ya están ahora disponibles)

🏔️ 1 Proyecto final - un proyecto grande, único, que va a construir para su cartera, revisado por los profesores dentro de la comunidad freeCodeCamp (Próximamente en 2025)

🤺 1 Examen Final - un examen de certificación completo de 90 preguntas realizado en el nuevo entorno de exámenes de código abierto de freeCodeCamp (Próximamente en 2025)

Te recomiendo que empieces por el principio, aunque ya hayas aprendido antes algunos de estos temas.

Puedes sumergiste de lleno y empezar a trabajar en el nuevo plan de estudios Desarrollador Full Stack Certificado ahora mismo.

El Plan de estudios de inglés para desarrolladores Nivel B1 del MCER

La pasada Navidad publicamos el curso de inglés de nivel A2 del MCER.

Y estoy encantado de decir que, tras un año de duro trabajo, no solo hemos puesto todo eso en marcha, sino que también hemos distribuido una gran parte del nivel B1.

Aplicaciones de freeCodeCamp para iPhone y Android

Las aplicaciones móviles de freeCodeCamp están mejor que nunca. ¡Nuestro código base Flutter acaba de alcanzar los 1.000 commits!

Ahora puedes:

📺 ver nuestros cursos

📚 leer nuestros libros

🤳 Explora el plan de estudios desde tu teléfono

Descárgalo en iPhone/Android y deja una reseña de 5 estrellas. ⭐️⭐️⭐️⭐️⭐️ 😉

Obtener la aplicación para Android

Obtener la aplicación para iPhone

2025 va a ser increíble.

Gracias de nuevo a todos los que contribuyen al plan de estudios de freeCodeCamp y a nuestros numerosos proyectos de código abierto.

Es genial que cualquiera pueda obtener ayuda en cualquier momento en el foro y Discord.

Anima a tus amigos a participar. Pueden empezar con nuestra documentación de contribución al código abierto.

Por último, gracias a todos los que hacen donaciones para apoyar la misión de freeCodeCamp. Esto es solo el principio.🥞

Anima a tus amigos a que también apoyen a nuestra organización benéfica. Juntos podemos garantizar que todo el mundo tenga acceso a una educación gratuita de categoría mundial. Únete a las 11.043 personas bondadosas de todo el mundo y hazte  partidario de este esfuerzo.

Si has estado considerando contribuir a un proyecto de código abierto, es posible que estés sopesando los pros y los contras de hacerlo.

Es posible que escuches cosas como que los proyectos de código abierto no te ayudarán a crecer. O que no pueden cambiar tu trayectoria profesional. Y que sus contribuciones definitivamente no se sumarán a su portafolio.

Si alguna vez has escuchado algo como esto, es posible que estas personas no sepan mucho sobre los beneficios de contribuir a proyectos de código abierto. Y esos beneficios son muchos.

En este artículo, compartiré oportunidades de contribución y cómo comenzar a contribuir.

Mucha gente asume que los desarrolladores siempre están trabajando solos sin ninguna conexión externa.

Pero eso no es necesariamente cierto para los desarrolladores en estos días. Muchos de ellos:

1. Crean proyectos para el público en general
2. Son activos en las redes sociales.
3. Se conectan activamente con personas de todo el mundo.    
   

De hecho, los proyectos de código abierto unen a los desarrolladores en un entorno más colaborativo que casi cualquier otra cosa.

¿Qué es código abierto?

Es posible que a menudo escuches sobre proyectos de código abierto y construcción en público. Pero, ¿qué significan estos términos?

Simplemente, significa que lo que creas es gratuito y está abierto para que cualquiera lo use. También significa que con la colaboración, tus proyectos siguen mejorando.

Plataformas abiertas de Blogging

Con los proyectos de código abierto; otras personas están adquiriendo la libertad de estudiar o desarrollar su propio proyecto existente.

Existen muchas plataformas que brindan a los desarrolladores la oportunidad de escribir en público. Está Hashnode, Dev.to, la biblioteca de desarrollo de Google y muchos más. Incluso podemos llamar a estos desarrolladores "Developer-as-a-blogger" (DaaB) por sus contribuciones de blogs. :)

He estado trabajando con la biblioteca de desarrollo durante más de un año. He visto casi más de 2000 presentaciones de más de 80 países ahora. ¡Bastante bien!

Cómo empezar a escribir tutoriales de tecnología

Pero, ¿Cómo sabes por dónde puedes empezar con tu viaje de blogueo como desarrollador?

Centrémonos en los siguientes consejos:

• No dejes que el síndrome del impostor gane: no importa dónde te encuentres en tu carrera tecnológica, el síndrome del impostor probablemente asomará su fea cabeza de vez en cuando. Incluso con 7 u 8 años de experiencia, a veces sudo pensando si soy lo suficientemente bueno.

No te preocupes: La mejor manera de comenzar a escribir es intentar escribir mientras crea un proyecto. Explícatelo a ti mismo como si estuvieras hablando con un amigo, ayudándole a entenderlo. De esta manera, cualquier persona que lea su tutorial sabrá cómo construir el proyecto.

• Existen muchos artículos sobre el mismo tema: este suele ser el caso. De los 7 mil millones de personas en el mundo, es muy probable que alguien más esté escribiendo sobre temas en los que has trabajado.

Pero la forma en que describes, defines y muestra las funciones será diferente. Concéntrate en eso.

• ¿Cómo empiezo?: La ansiedad de la página en blanco existe. Para superar esto, comienza a crear secciones con los temas de alto nivel. Un esquema, por así decirlo. Luego comienza a agregarle contenido. Asegúrate de agregar más pasos, viñetas y elementos visuales.

Para estructurar y editar mejor tu contenido, puedes consultar los cursos de redacción técnica y las guías de estilo de Google, como las de freeCodeCamp y MailChimp.

• Cómo hacer tus primeras contribuciones: Las primeras contribuciones son especiales pero abrumadoras. Para identificar el repositorio de GitHub adecuado, busque proyectos de código abierto en su área de especialización. Conéctese con las personas que han hecho contribuciones en su pila de tecnología. Entiende el proceso y comienza a contribuir.

Ahora que hemos repasado estos consejos, estás listo para iniciar su viaje de código abierto.

Mi viaje a código abierto

Para ayudarte a comenzar a contribuir a proyectos en tus áreas de especialización, compartiré algunos consejos y pautas en un minuto. Pero primero, un poco más sobre mí.

Hasta 2019, desconocía el término código abierto. Sí. No estaba activo en las redes sociales, excepto en LinkedIn, donde nadie hablaba de código abierto.

En pocas palabras, mis horizontes eran bastante estrechos.

Pero como era una escritora de tecnología, era miembro activo de una comunidad global de escritores de tecnología llamada Write the Docs. Estaba navegando por su canal de Slack cuando descubrí Google Season of Docs.

Revisé la lista de organizaciones participantes y encontré una interesante. Luego, me comuniqué con ellos a través de su canal de Slack y me ofrecí a actuar como voluntario.

Un año de voluntariado con 'The Good Docs Project' me abrió un montón de oportunidades. Creamos plantillas de código abierto para varios casos de uso como:

• Una plantilla de glosario para organizaciones de espacio abierto a nivel mundial,
• Una plantilla de incorporación,
• Una plantilla de API,
• Una plantilla de documentación.

Un año más tarde, después de establecer contactos y adquirir experiencia, me postulé como participante. La organización Metanorma vio mi experiencia de voluntariado y me seleccionó para GSoD'21. Y es de esa manera que me convertí en parte de la comunidad de código abierto en constante crecimiento.

Cómo empezar a contribuir al Open Source

Cuando comiences a contribuir, no te concentres solo en los resultados: concéntrate en el proceso.

Aquí hay algunos consejos para ayudarte a comenzar a contribuir:

Aprende Git y GitHub

Antes de encontrar repositorios en los que contribuir, adquiere conocimientos prácticos sobre los comandos de Git y la plataforma GitHub. Obten una comprensión básica de:

• Cómo bifurcar (fork) el repositorio
• Como hacer commits
• Cómo fusionar commits
• Cómo generar una solicitud de extracción (pull request)

Entre muchos otros conceptos de Git/GitHub, estos son algunos de los más importantes.

Si deseas obtener más información, aquí hay algunos recursos útiles:

• Git and GitHub - ¿Qué es el control de versiones y cómo funciona?
• La guía para principiantes de Git y Github

Navega a través de algunos proyectos

Ahora que estás familiarizado con las herramientas y el software, ¿cómo decides con qué proyecto comenzar?

Bueno, antes que nada, comienza con los temas que le interesan. Navega por github.com/topics/[tema de tu interés] para buscar algo en lo que le gustaría trabajar. Por ejemplo, si desea buscar proyectos relacionados con Python, puede usar esto: https://github.com/topics/python.

A menos que sea algo muy específico, deberías encontrar toneladas de proyectos relacionados con el tema elegido para comenzar con tus contribuciones.

Una vez que hayas encontrado un proyecto, ve a las ediciones para principiantes de ese repositorio. Para ello, escriba github.com/[propietario]/[repositorio]/contribute. Selecciona un problema para comenzar a contribuir.

Si has estado activo en GitHub, tu página de exploración te mostrará algunas recomendaciones seleccionadas basadas en sus contribuciones, estrellas o bifurcaciones anteriores.

Participa en programas open-source

Participa en los programas de código abierto que organizan las principales organizaciones. Si no como colaborador, entonces como voluntario para aprender, idear, contribuir y luego participar.

Por ejemplo:

• Google Summer of Code,
• Google Season of Docs,
• Outreachy

Explora abundantemente

El mayor punto ciego de las contribuciones de código abierto es no mirar más allá o no explorar.

Los proyectos de código abierto no se limitan a las contribuciones de código. Las otras formas de contribuir son:

Actualiza la documentación

Para cualquier proyecto, es importante tener un README extenso. Entonces, sumérgete en mejorar el LÉAME de tu proyecto favorito para que sea más fácil para otros.

Entonces, ¿cómo haces para hacer eso?

Bueno, para el proyecto Metanorma:

• Realicé las acciones mencionadas en la documentación después de descargar la versión local. Esto me ayudó a descubrir los pasos faltantes, los errores o cualquier fluctuación.
• A continuación, realicé un análisis cualitativo y cuantitativo de la documentación existente. Esto me ayudó a descubrir las URL que faltaban y las secciones difíciles de entender.
• Después de encontrar estas partes, construí una arquitectura de información adecuada. La arquitectura de la información de la documentación te ayudará a concentrarte en el contenido.

Ayuda con el diseño

Las organizaciones necesitan diseñadores para sus proyectos. Entonces, si eres diseñador, crea carteles, imágenes o carruseles para la organización de código abierto.

Sé un creador de la comunidad

El software de código abierto tiene que ver con la comunidad. Personas que se unen, codifican juntas, contribuyen juntas y mejoran el proyecto juntas.

Conviértete en la persona de la comunidad para esos proyectos de código abierto. Reune a los contribuyentes. Realizar diversas funciones con ellos:

• Asignar tareas
• Solucionar problemas
• Organizar reuniones
• Crear programas de embajadores
• Realizar talleres
• Crear boletines

Ayuda con la localización

Ayuda a construir los proyectos en idiomas con los que estes familiarizado. Supongamos que eres hispanohablante. Busca algunos proyectos en tus comunidades. Traduce los proyectos principales del inglés al español a fin de que el proyecto esté disponible para más personas en todo el mundo. Como es el caso de freeCodeCamp.

Proyectos de código abieto a los cuales contribuir

Esta es una lista de varios proyectos de código abierto que tienen una comunidad activa de personas que esperan contribuciones. Tienen problemas que van desde el nivel de principiante hasta el de experto.

• Supertokens: Supertokens es una alternativa auth0 de código abierto que te permite configurar la autenticación en menos de 30 minutos. El proyecto proporciona una implementación local que le otorga todos los derechos sobre la base de datos de sus usuarios. Para contribuir, siga su repositorio de GitHub, busca los problemas existentes, revisa su documentación y comience a contribuir.
• Nimble Edge: Nimble edge es una plataforma descentralizada que está llevando al mundo de la computación en la nube tradicional a la computación perimetral. El cambio de la computación en la nube a la computación perimetral permitirá que los dispositivos se comuniquen entre sí de manera inteligente, compartan cargas de trabajo y utilicen la nube en consecuencia. Para contribuir, sigue su repositorio de GitHub, esté atento a los problemas y comienza a contribuir.
• Dev library: Dev Library es la nueva plataforma de código abierto de Google que muestra contenido creado por desarrolladores externos utilizando cualquiera de las tecnologías de Google (Android, Angular, Flutter, Firebase, Google Cloud, Machine Learning). La plataforma está segmentada en áreas de productos que muestran proyectos de calidad a los que contribuir. Para contribuir, sigue cualquier proyecto de código abierto y profundiza con las contribuciones.
• Codetriage: Comienza a contribuir encontrando cualquier repositorio de código abierto de esta mina de oro.
• El proyecto Good Docs: The Good Docs es una comunidad de código abierto que crea plantillas para combatir la ansiedad de las páginas en blanco. La comunidad quiere crear plantillas para cualquier cosa y todo. Si crees que también tienes una idea de plantilla, únete a su canal de holgura. Para contribuir, sigue su repositorio de GitHub, únete a su canal de holgura y comienza contribuir.

También hemos visto un trabajo increíble de desarrolladores que utilizan las tecnologías de Google en Dev Library. Algunos crearon una aplicación clonada de Spotify usando Angular, otros crearon un proyecto para detectar melanoma (un tipo de cáncer de piel) usando imágenes de lesiones cutáneas, mientras que alguien creó una réplica del selector de imágenes de WhatsApp.

Y, por supuesto, freeCodeCamp en sí mismo es un proyecto de código abierto. freeCodeCamp puede ser tu plataforma de acceso para aprender y contribuir al código abierto.

Para terminar

Entonces, ¿qué piensas? ¿Es hora de comenzar a contribuir con el código abierto?

Mira lo que comparte Santosh Yadav, experto en código abierto en Angular y estrella de GitHub:

“Contribuir a Open Source me ayudó de maneras que nunca hubiera imaginado. Lo comencé como una forma de retribuir a la comunidad y obtuve el reconocimiento de la comunidad. Luego me convertí en Angular GDE y también en la primera estrella de GitHub de la India.

OSS me ayudó a aprender la tecnología en profundidad y me ayudó a conseguir un buen trabajo. Incluso trabajé como consultor durante un año y medio, y mi trabajo de código abierto me ayudó a conseguir clientes con facilidad.

Puede darte una buena vida a mi familia. Estuve viviendo de cheque en cheque durante 10 años antes de comenzar Open Source, y cambió mi vida”.

Estas historias nos cuentan cómo las contribuciones de código abierto pueden cambiar nuestra trayectoria profesional. No importa cuál sea tu perfil de trabajo, cs buena idea comenzar a contribuir a proyectos de código abierto.

En este post, me gustaría compartir las mejoras que hice a su proceso de construcción. Estas mejoras no son específicamente al framework Phoenix y quizás cambien la forma en que te aproximas a la integración continua.

Pero primero, algo de contexto.

¿Qué es el Framework Phoenix?

Phoenix es un framework web con algunas propiedades muy interesantes. Con Phoenix, puedes crear aplicaciones web interactivas enriquecidas sin escribir código del lado del cliente.

Puede hacer esto usando una función llamada LiveView que envía actualizaciones en tiempo real desde el servidor para actualizar el HTML del navegador del cliente.

Podemos crear una página que muestre los últimos tweets sobre un tema, en tiempo real, con bastante facilidad.

Aquí hay un ejemplo:

defmodule TimelineLive do
  use Phoenix.LiveView

  def render(assigns) do
    render("timeline.html", assigns)
  end

  def mount(_, socket) do
    Twitter.subscribe("elixirphoenix")
    {:ok, assign(socket, :tweets, [])}
  end

  def handle_info({:new, tweet}, socket) do
    {:noreply,
     update(socket, :tweets, fn tweets ->
       Enum.take([tweet | tweets], 10)
     end)}
  end
end

El framework está escrito en el lenguaje de programación Elixir.

Fue creado por José Valim. Se parece mucho a Ruby, pero tiene una semántica muy diferente. Elixir se ejecuta en una máquina virtual (VM) Erlang, e impulsa proyectos como Discord y se utiliza en empresas como Heroku.

¿Cómo reproducir las compilaciones?

El Framework Phoenix usa Acciones de GitHub en su proceso de compilación. Como muchos grandes proyectos, tienen un conjunto de pruebas unitarias que necesitan ejecutar en cada contribución de los usuarios.

Sin embargo, aquí no es donde se detienen sus esfuerzos de prueba. También tienen un conjunto de pruebas de integración. Phoenix usa un ORM para comunicarse con varias bases de datos y las pruebas de integración garantizan que ningún cambio interrumpa la integración con cualquiera de las 3 bases de datos compatibles.

Este es un patrón común. Tener una gran cantidad de pruebas unitarias que sean fáciles de ejecutar y un puñado de pruebas de integración más lentas, pero más completas, es una excelente manera de evitar que se introduzcan errores en el proyecto.

Sin embargo, Phoenix Framework lleva esto aún más lejos, ya que también necesitan admitir varias versiones del lenguaje Elixir y un puñado de versiones de Open Telecom Platform (OTP).

Esto empieza a parecer complejo. Tenemos que probar cada cambio con todas las combinaciones de lo siguiente:
Bases de datos (Postgres, MySQL MSSQL)
Elixir (versión actual y anterior)
OTP (versión actual y anterior)

Esto empieza a parecer complejo. Tenemos que probar cada cambio con todas las combinaciones de lo siguiente:

• Bases de datos (Postgres, MySQL MSSQL)
• Elixir (versión actual y anterior)
• OTP (versión actual y anterior)

Es relativamente fácil configurar esto en Acciones de GitHub, pero ¿cómo ejecutarías estas pruebas localmente?

Instalar todo esto sería mucho pedir, por lo que los contribuyentes tienden a confiar en las Acciones de GitHub para probar estas combinaciones. Sin embargo, si todos tienen que confiar en enviar cosas a GitHub, y ver si las pruebas pasan, entonces el desarrollo se ralentiza.

¿Cómo arreglamos esto?

¿Cómo unificar las ejecuciones de pruebas?

Aquí es donde me involucré. Trabajo en Earthly Technologies como defensor de los desarrolladores de código abierto. Tenemos una herramienta de compilación de código abierto bastante interesante, y aunque ocasionalmente contribuyo directamente al proyecto, mi trabajo es ser el punto de contacto entre la comunidad que usa la herramienta y el equipo que trabaja en ella.

Había oído hablar de este problema de reproducibilidad que estaba teniendo el equipo de Phoenix. Pensé que podría ayudar a escribir un script de compilación que podría usarse tanto en Acciones de GitHub como para un flujo de trabajo de desarrollo local. Así que me puse a trabajar en un PR (Pull Request).

Ejecutando las pruebas localmente

Lo que terminé creando, ligeramente simplificado, es esto:

setup:
   ARG ELIXIR=1.10.4
   ARG OTP=23.0.3
   # Pull a Docker Image to Run Build Inside Of
   FROM hexpm/elixir:$ELIXIR-erlang-$OTP-alpine-3.12.0
   ...
 
integration-test:
    FROM +setup
    COPY . .
    # Pull In Dependencies
    RUN mix deps.get 
    # Start Up Service Dependencies
    WITH DOCKER --compose docker-compose.yml 
        # Run Tests
        RUN mix test --include database 
    # Stop Service Dependencies
    END

Este es un Earthfile. Está compuesto por varios objetivos, como setup y integration-test. Los objetivos pueden tener dependencias entre ellos. Puede usar la herramienta de línea de comandos earthly para ejecutar cualquier objetivo y cada uno se ejecuta en un contenedor Docker. La contenerización nos permitirá ejecutar la compilación donde elijamos.

Este ejemplo ejecuta la prueba de integración integration-test dentro de un contenedor Docker hexpm/elixir con la versión especificada de Elixir y OTP instaladas.

Antes de ejecutar las pruebas con mix test --include database, usamos Docker compose para iniciar todas las dependencias necesarias:

 WITH DOCKER --compose docker-compose.yml
        RUN mix test --include database
 END 

El archivo de Docker compose luce así:

version: '3'
services:
  postgres:
    image: postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: postgres
  mysql:
    image: mysql
    ports:
      - "3306:3306"
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
  mssql:
    image: mcr.microsoft.com/mssql/server:2019-latest
    environment:
      ACCEPT_EULA: Y
      SA_PASSWORD: some!Password
    ports:
      - "1433:1433"	

Estas son las bases de datos que necesitamos para probar Phoenix.

Ahora podemos ejecutar las pruebas de integración en la línea de comando así:

>  earthly -P +integration-test

Y si queremos probar una versión diferente de Elixir, podemos especificar la versión como argumentos de compilación:

 > earthly -P --build-arg ELIXIR=1.11.0 --build-arg OTP=23.1.1 +integration-test

Hay otras formas de lograr esto. Una combinación de makefile y dockerfile también habría funcionado. La clave es sacar la lógica de compilación de un formato específico de GHA y convertirla en algo que se pueda ejecutar en cualquier lugar.

Cómo ejecutarlo en Acciones de GitHub

Para usar este mismo proceso dentro de Acciones de GitHub, lo único que tenemos que hacer es ajustar nuestro yaml de Acciones de GitHub para usar Earthly para la canalización de compilación y estamos listos.

  integration-test-elixir:
    runs-on: ubuntu-latest
    env:
      FORCE_COLOR: 1
    
    strategy:
      fail-fast: false
      matrix:
        include:
          - elixir: 1.11.1
            otp: 21.3.8.18
          - elixir: 1.11.1
            otp: 23.1.1
    steps:
      - uses: actions/checkout@v2
      - name: Download released earth
        run: "sudo /bin/sh -c 'wget https://github.com/earthly/earthly/releases/download/v0.4.1/earthly-linux-amd64 -O /usr/local/bin/earthly && chmod +x /usr/local/bin/earthly'"
      - name: Execute tests
        run: earthly -P --build-arg ELIXIR=${{ matrix.elixir }}  --build-arg OTP=${{ matrix.otp }} +integration-test

Ahí vamos, ahora podemos ejecutar nuestro proceso de compilación localmente, sin ninguna configuración de entorno compleja. También podemos ejecutar el mismo proceso de compilación en nuestra máquina de desarrollo sin necesidad de instalar nada excepto Earthly. Esto facilita el acercamiento de nuevos contribuyentes al proyecto.

Resultado final

Finalmente, con la ayuda del equipo Phoenix, obtuve la aprobación de este cambio y el proyecto Phoenix ahora tiene una manera fácil de probar e iterar en su canal de compilación localmente. ¡Y ni siquiera escribí ningún código de Elixir! Puede encontrar más detalles en el PR.

Gracias por leer este artículo. Si deseas obtener más información sobre Earthly, puedes encontrar mucha aquí. Y si deseas mi ayuda en la construcción de tu proyecto de código abierto, házmelo saber.

Traducido del artículo de Adam Gordon Bell - How I Contributed to a Major Open Source Project Without Writing Any Code

Existe una secta bastante progresista del mundo del desarrollo de software llamada comunidad de código abierto.

Esta comunidad cree que la mayoría de la gente sería mucho más feliz y haría mucho más trabajo si dejara de construir cosas que otra persona ya ha construido y ofrecido para su uso gratuito. Quieren que te quedes con sus cosas.

Además de existir sin que tengas que mover un dedo, las herramientas y el software de código abierto tienen algunas ventajas claras. Especialmente en el caso de proyectos bien establecidos, es muy probable que otra persona ya haya solucionado los errores más molestos por ti.

Gracias a la facilidad con la que los usuarios pueden ver y modificar el código base, también es más probable que un programa haya sido retocado, mejorado y asegurado a lo largo del tiempo.

Cuando muchos programadores contribuyen, aportan sus propios conocimientos y experiencias. Esto puede dar lugar a un producto mucho más sólido y capaz que el que puede crear un solo programador.

Por supuesto, al ser tan variados como las personas que los construyen, no todos los proyectos de código abierto son iguales, ni se mantienen con la misma seguridad.

Hay muchos factores que afectan a la idoneidad de un proyecto para su caso de uso. He aquí algunas consideraciones generales que constituyen el buen punto de partida a la hora de elegir un proyecto de código abierto.

Cómo elegir un proyecto de código abierto

Como requisitos fundamentales, un buen proyecto de software es confiable, fácil de entender, tiene componentes actualizados y seguridad. Hay varios indicadores que pueden ayudarte a realizar una valoración sobre si un proyecto de código abierto cumple con estos criterios.

Quiénes lo usan

Tomado en contexto, el número de personas que ya utilizan un proyecto de código abierto puede ser un indicador de su calidad.

Si un proyecto tiene cien usuarios, por ejemplo, es lógico que alguien haya intentado utilizarlo al menos cien veces antes de que tú lo encontraras. Así, según la antigua costumbre de "no sé qué hay en esa cueva, ve tú primero", es más que probable que esté bien.

Puedes sacar conclusiones sobre la base de usuarios de un proyecto mirando las estadísticas disponibles. Dependiendo de su plataforma, estas pueden incluir el número de descargas, revisiones, problemas o entradas, comentarios, contribuciones, forks o "estrellas", sean las que sean.

Evalúa las estadísticas sociales de plataformas como GitHub con un grano de sal. Pueden ayudarte a determinar la popularidad de un proyecto, pero solo de la misma manera que las aplicaciones de reseñas de restaurantes pueden ayudarte a saber si debes comer en Foo's Grill & Bar.

Dependiendo de dónde esté Foo's Grill & Bar, de cuándo haya abierto y de la probabilidad de que la gente esté cerca de él cuando le llame el inevitable antojo de carne, tener veintiséis críticas puede ser una buena señal o una terrible.

Aunque no se espera que un proyecto que aborda un caso de uso o una tecnología muy desconocida tenga cientos de usuarios, tener unos pocos usuarios activos es, en tal caso, un motivo de confianza.

La verificación externa también puede ser útil. Por ejemplo, los paquetes que se incluyen en una distribución del sistema operativo Linux (distro) deben ajustarse a normas estrictas y someterse a una verificación. Elegir un software incluido en los repositorios por defecto de una distribución puede significar que es más probable que sea seguro.

Tal vez uno de los mejores indicios para buscar es si el equipo de desarrollo de un proyecto está utilizando su propio proyecto. Busca problemas, discusiones o publicaciones en el blog que muestren que los creadores y encargados del mantenimiento del proyecto están utilizando lo que ellos mismos han construido. Lo que se conoce como "comer tu propia comida de perro" o "dogfooding", es un indicador de que el proyecto probablemente esté bien mantenido por sus desarrolladores.

Quiénes lo construyen

El principal enemigo del buen software de código abierto suele ser la falta de interés. Las partes implicadas en un proyecto de código abierto pueden marcar la diferencia entre una biblioteca de éxito inmediato y una utilidad respetada a largo plazo. Múltiples responsables comprometidos, incluso haciendo contribuciones en su tiempo libre, tienen una tasa de éxito mucho mayor para mantener un proyecto y generar interés.

Los proyectos que despiertan un gran interés suelen contar con el apoyo de una comunidad de colaboradores y usuarios, que a su vez los hace crecer.

Los nuevos colaboradores pueden ser aceptados activamente, hay guías claras que explican cómo ayudar, y los responsables del proyecto están disponibles y son accesibles cuando la gente tiene preguntas inevitables.

Algunas comunidades tienen incluso salas de chat o foros donde la gente puede interactuar al margen de las contribuciones. Las comunidades activas ayudan a mantener el interés, la relevancia y la calidad del proyecto.

De forma menos orgánica, un proyecto también puede sostenerse a través de organizaciones que lo patrocinan. Los gobiernos y las empresas con intereses financieros también son promotores del código abierto, y un proyecto que goza del uso del sector público o del respaldo financiero tiene un incentivo añadido para seguir siendo relevante y útil.

¿Qué tan vivo está?

La regularidad y la frecuencia de la actividad de un proyecto de código abierto es quizás el mejor indicador de la atención que probablemente se presta a su seguridad. Mira las publicaciones, el historial de confirmaciones, los registros de cambios o las revisiones de la documentación para determinar si un proyecto está activo. Dado que los proyectos varían en tamaño y alcance, a continuación se indican algunos aspectos generales en los que hay que fijarse.

El mantenimiento de la seguridad es un esfuerzo continuo que requiere un seguimiento y actualizaciones regulares, especialmente para los proyectos con componentes de terceros. Estos pueden ser bibliotecas o cualquier parte del proyecto que dependa de algo externo a él, como la integración de una pasarela de pago.

Es más probable que un proyecto inactivo tenga código obsoleto o utilice versiones obsoletas de componentes. Para una determinación más concreta, puedes investigar los componentes de terceros de un proyecto y comparar sus parches o actualizaciones más recientes con las últimas actualizaciones del proyecto.

Los proyectos sin componentes de terceros pueden no tener actualizaciones externas que aplicar. En estos casos, puedes utilizar la actividad reciente y las notas de publicación para determinar el grado de compromiso de los responsables de un proyecto.

Por lo general, los proyectos activos deberían mostrar actualizaciones en los últimos meses, con un lanzamiento notable en el último año. Esto puede ser una buena indicación de si el proyecto está utilizando una versión actualizada de su lenguaje o framework.

También se puede juzgar el grado de actividad de un proyecto observando a los propios encargados de su mantenimiento. Los encargados del mantenimiento activo responden rápidamente a los comentarios o a los nuevos problemas, aunque solo sea para decir: "Estamos en ello".

Si el proyecto tiene una comunidad, sus responsables forman parte de ella. Puede que tengan un sitio web dedicado o que escriban blogs con regularidad. Pueden ofrecer formas de contactar con ellos directamente y en privado, especialmente para plantear problemas de seguridad.

¿Puedes entenderlo?

Disponer de documentación es un requisito básico para un proyecto que está destinado a ser utilizado por cualquier persona, además de su creador. Los buenos proyectos de código abierto tienen una documentación fácil de seguir, honesta y completa.

Disponer de una documentación bien redactada es una de las formas en que un proyecto puede destacarse y demostrar la consideración y dedicación de sus responsables.

Una sección de "Primeros pasos" puede detallar todos los requisitos y la configuración inicial para ejecutar el proyecto. Una lista precisa de temas en la documentación permite a los usuarios encontrar rápidamente la información que necesitan. Una definición clara de la licencia no deja lugar a dudas sobre cómo se puede utilizar el proyecto y para qué fines.

Son aspectos característicos de la documentación que está al servicio de sus usuarios.

Un proyecto que sigue buenas prácticas de codificación probablemente tenga un código tan legible como su documentación. El código que es fácil de leer se presta a ser entendido. Por lo general, tiene funciones y variables claramente definidas y con nombres adecuados, un flujo lógico y un propósito aparente. El código legible es más fácil de corregir, asegurar y construir.

¿Qué tan compatible es?

Algunos factores determinarán la compatibilidad de un proyecto con tus objetivos. Se trata de cualidades objetivas, que pueden determinarse mirando los archivos del repositorio de un proyecto. Entre ellos están:

• Código del lenguaje
• Tecnologías o frameworks específicos
• Compatibilidad de la licencia

La compatibilidad no significa necesariamente una coincidencia directa. Diferentes lenguajes de programación pueden relacionarse entre sí, al igual que diversas tecnologías y frameworks. Debes leer detenidamente la licencia de un proyecto para saber si permite su uso para tu objetivo, o si es compatible con una licencia que te gustaría utilizar.

Finalmente, un proyecto que satisface todos estos criterios puede no adaptarse a su caso de uso. Sin embargo, parte de la belleza del software de código abierto es que puedes beneficiarte de él haciendo modificaciones que se adapten mejor a tu uso. Si esas modificaciones hacen que el proyecto sea mejor para todos, puedes pagarle y pagarle contribuyendo con tu trabajo al proyecto.

Cuidado y alimentación adecuada para un proyecto de código abierto

Una vez que se adopta un proyecto de código abierto, es necesario prestar un poco de atención para asegurarse de que sigue siendo una ayuda para sus objetivos.

Aunque sus responsables se ocuparán de los archivos del proyecto, usted es el único responsable de su propia copia. Como todo el software, tu proyecto de código abierto debe estar bien mantenido para que siga siendo lo más seguro y útil posible.

Disponga de un sistema que le proporcione notificaciones cuando las actualizaciones de su software estén disponibles. Actualice el software con tiempo, tratando cada parche como si fuera vital para la seguridad, ya que puede serlo.

Tenga en cuenta que los creadores y encargados de mantener los proyectos de código abierto actúan, en la mayoría de los casos, sólo por la bondad de su propio corazón. Si tienes uno particularmente impresionante, es posible que sus desarrolladores pongan a disposición actualizaciones y parches de seguridad de forma regular. Depende de ti estar al tanto de las actualizaciones y aplicarlas rápidamente.

Como con la mayoría de las cosas en el software, mantener sus actualizaciones de código abierto regulares puede ser útil. Puedes utilizar submódulos, ramas o entornos de git para aislar tus modificaciones. Esto puede facilitar la aplicación de actualizaciones o la localización del origen de cualquier error que surja.

Así que, aunque un proyecto de código abierto no cueste dinero, caveat emptor, es decir, "Jimmy, si te regalamos un cachorro, es tu responsabilidad cuidarlo".

Traducido del artículo de Victoria Drake - How to Choose and Care for a Secure Open Source Project