El repositorio de OpenTF ya está disponible públicamente

• OpenTofu es una herramienta OSS para construir, modificar y versionar infraestructura de forma segura y eficiente
• Puede gestionar tanto proveedores de servicios populares ya existentes como soluciones personalizadas internas
• Usa el enfoque de Infrastructure as Code, que describe la infraestructura con una sintaxis de configuración de alto nivel y permite versionar, compartir y reutilizar los planos de un centro de datos como si fueran código
• Ofrece una etapa de planning que genera un plan de ejecución antes de llamar a apply, para revisar de antemano qué acciones realizará OpenTofu sobre la infraestructura
• Crea un Resource Graph de todos los recursos y proporciona visibilidad sobre las dependencias de la infraestructura al paralelizar la creación y modificación de recursos que no tienen dependencias
• Permite aplicar conjuntos de cambios complejos con una intervención humana mínima, y mediante el plan de ejecución y el grafo de recursos se puede verificar qué se cambiará y en qué orden
• Se ofrecen Nightly Builds para probar los cambios más recientes de main, y son compilaciones experimentales que no están destinadas a uso en producción
  • Cada nightly build se elimina después de 30 días
  • La información de la compilación más reciente está disponible en https://nightlies.opentofu.org/nightlies/latest.json
• Las vulnerabilidades de seguridad o posibles vulnerabilidades deben reportarse siguiendo la Security Policy
• El acceso al registro se bloquea para países de origen específicos, y los detalles siguen la Registry Inclusion Policy
• La licencia es Mozilla Public License v2.0

[GN⁺]

Opiniones en Hacker News

• Como muchos lo habían pedido, finalmente hicimos público el repositorio y de ahora en adelante seguiremos desarrollándolo de forma abierta.
  Nos tomó algo de tiempo, pero pueden ver los detalles en el anuncio: https://opentf.org/fork
  Gracias por todo el apoyo hasta ahora; esperamos que participen en las discusiones o contribuyan en el repositorio.
  El método de contribución, que también se discutió bastante en HN, quedó definido como DCO: https://developercertificate.org
  Si tienen preguntas, puedo responderlas. Trabajo en Spacelift y, hasta que pase a estar liderado por un comité, soy el Technical Lead interino del OpenTF Project.

  • Si eres el líder técnico del proyecto OpenTF, me da curiosidad cómo se fusionan cambios como estos:
    https://github.com/opentffoundation/opentf/pull/36/commits

• Creo que todo este proceso es bastante interesante. HashiCorp sabía muy bien que una licencia se aplica no al “proyecto” en sí, sino a una versión del proyecto, y aprovechó eso para maximizar los ingresos de sus productos empresariales.
  La comunidad también sabía que, una vez que se le asigna una licencia a una versión específica, eso no se puede revertir, y que si se bifurca desde el punto en que se aplicó esa licencia y se crea su propio “nuevo” proyecto por versión, se puede mantener como open source.
  Será interesante ver cómo evoluciona esto, y parece que se convertirá en un caso de estudio sobre licencias de software en el futuro. Tengo expectativas sobre qué será de OpenTF a largo plazo.

  • En cuanto al impacto en la comunidad y la respuesta, se parece más a la separación entre Hudson y Jenkins. Aunque el tema de la licencia es distinto: https://en.wikipedia.org/wiki/Hudson_(software)
    Siento que Oracle casi siempre está involucrado en este tipo de cosas, pero en Terraform, sorprendentemente, no fue así :D
  • No hay razón para distinguir entre una “licencia aplicada a una versión del proyecto” y una “licencia aplicada al proyecto en sí”. HashiCorp tenía derecho a cambiar la licencia hacia adelante, y cualquiera tenía derecho a seguir usando o bifurcar versiones anteriores. De hecho, eso es lo que pasó aquí.
  • Históricamente, también podría ser interesante revisar la base de código de Hudson/Jenkins.

• Dicen que “están consultando con varios expertos legales sobre el nombre, y que por el uso de ‘TF’, OpenTF también podría no ser el nombre definitivo”.
  Es interesante que el simple hecho de incluir TF en el nombre pueda causar problemas.
  Fuente: https://github.com/opentffoundation/opentf/issues/273#issuecomment-1706947318

  • Me enteré de que el posible punto de conflicto aquí es una marca denominativa.
    Para más detalles, ver https://en.wikipedia.org/wiki/Wordmark
    Soy fundador de env0 y colidero la iniciativa OpenTF.
  • Desde el principio pensé que debían usar xenoform en vez de terraform. Por ejemplo, algo como OpenXenoform y el comando xf.
  • Por una razón similar, YP pasó a ser NIS.
    https://en.wikipedia.org/wiki/Network_Information_Service

• Quisiera pedir dos cosas. Primero, estaría bueno que ofrecieran un paquete de registro standalone tanto para módulos como para proveedores. Lo único que conozco es Artifactory, pero en entornos que usan Nexus no quiero tener que correr otro software de repositorio grande.
  Lo segundo está relacionado: me gustaría que fuera más fácil bifurcar módulos de proveedores. No me convence el flujo actual de compilar localmente y copiar manualmente binarios para distribuirlos a colegas, o esperar a que acepten un PR, especialmente cuando upstream exige firmar un CLA.

  • ¿Podrías explicar un poco más la primera petición? Si lo que quieres es un binario autocontenido para ejecutar un registro privado de proveedores/módulos, existen algunos proyectos open source de ese tipo, y también hicimos una prueba de concepto para distribuir proveedores mediante registros OCI como DockerHub o GitHub Container Registry.
    Los registros OCI encajan bastante bien con este caso de uso: https://twitter.com/opentforg/status/1696913055576387599
    Esta prueba de concepto pronto derivará en un RFC público.
    Sobre la segunda petición, me da curiosidad si tienes en mente algún flujo de trabajo ideal.
    Trabajo en Spacelift y, hasta que pase a estar liderado por un comité, soy el Technical Lead interino del OpenTF Project.

• Debieron haberlo llamado “terrafork”.

  • OpenCorp también podría funcionar. Terraform es solo un producto: https://news.ycombinator.com/item?id=37393844

• Se ve bien. Estoy esperando https://github.com/opentffoundation/roadmap/issues/8 para poder probarlo.
  Puedo compilar desde el código fuente, pero si es posible preferiría usar builds de release.

• Le di una mirada rápida y la documentación se ve excelente. Habiendo trabajado un poco con la estructura interna de Terraform, me parece una mejora bastante grande para desarrolladores que quieran trabajar en esta base de código.
  Ofrece una visión general completa muy buena para empezar. Buen trabajo.

  • No sé exactamente a qué documentación te refieres, pero la mayoría de los documentos no cambiaron mucho respecto del repositorio original, salvo las partes relacionadas con marcas comerciales.
    Si la documentación mejoró, el mérito debería ir para los desarrolladores de Terraform Core.
    Trabajo en Spacelift y, hasta que pase a estar liderado por un comité, soy el Technical Lead interino del OpenTF Project.

• Esto es totalmente tangencial, pero el logo se ve bastante raro con ese azul oscuro sobre un fondo oscuro.
  El contorno blanco tampoco es lo bastante grueso, así que cuando se superpone con el fondo oscuro los píxeles se notan mucho.

  • Definitivamente es una discusión menor de diseño, pero también se parece al logo de TensorFlow, así que por un momento pensé que era un grupo independizando el proyecto de Google.

• ¿Alguien tiene un diff de cómo difiere esta base de código respecto del último commit de Terraform con una licencia “segura para seguir usando”?
  No entiendo bien qué tuvieron que cambiar realmente por la polémica y el cambio de licencia.

  • GitHub tiene una función de “compare”. La diferencia entre el punto desde el que hicimos el fork y el main actual puede verse aquí: https://github.com/opentffoundation/opentf/compare/8a085b427b74ce3829500a59508b77465f1bbef0...a7d8cdd3eeaac968765c6819222606add3720ecf

• El logo en la página de GitHub parece necesitar mejoras sobre fondos oscuros. En particular, las letras oscuras tienen un contorno claro que se ve como un desborde de alfa y deja aliasing.