Novedades técnicas sobre PySimpleGUI

 (github.com/PySimpleGUI)
4 puntos por GN⁺ 2023-12-11 | 1 comentarios | Compartir por WhatsApp
  • Tras finalizar su intento de comercialización, PySimpleGUI eliminó los componentes de licencia y seguridad del código de PySimpleGUI 5 y volvió a publicarse en GitHub y PyPI como PySimpleGUI 6 con licencia LGPL3
  • La versión más reciente puede instalarse con python -m pip install PySimpleGUI, y también es posible instalar directamente por pip la versión anterior 4.60.5.1, la rama master de GitHub o una release específica como 6.1
  • PySimpleGUI se presenta como un wrapper de bibliotecas GUI como tkinter, que simplifica y compacta la estructura de un SDK GUI mientras ofrece personalización detallada, sin requerir experiencia previa en programación de interfaces gráficas
  • La versión 6.2 incluye la corrección del bug de Window.settings_save, salida inline de imágenes en Multiline, psgupgrade, selección programática de nodos en Tree, temporizadores de cadena "H:M:S" en Window.start_timer y configuración del color de borde en Frame
  • El proyecto se mantiene sin aceptar pull requests, y aunque su futuro a largo plazo es incierto, el autor afirma que seguirá escribiendo código y ordenando el ecosistema

Reapertura como open source de PySimpleGUI 6

  • PySimpleGUI intentó comercializarse, pero no logró generar los recursos necesarios para sostener el proyecto al nivel esperado
  • En febrero de 2025 se anunció el cierre de PySimpleSoft y la continuidad del soporte hasta finales de 2025, y después quedó pendiente decidir qué hacer con el código, la documentación y los repositorios
  • El código de PySimpleGUI 5 se publicó en GitHub y PyPI tras eliminar los componentes de licencia y seguridad
  • La nueva versión publicada usa licencia LGPL3
  • El curso de Udemy se ofrecerá gratis por un tiempo, y el código de cupón es 033334A16163C571B739

Cómo instalarlo

  • Instalar la versión más reciente v6 desde PyPI:
    • python -m pip install PySimpleGUI
  • Instalar la versión anterior 4.60.5.1:
    • python -m pip install PySimpleGUI==4.60.5.1
  • El código más reciente del repositorio de GitHub puede instalarse directamente:
  • Para instalar una release específica de GitHub, cambia master por el número de release:
  • También puede hacerse una instalación local después de clonar o descargar el repositorio:
    • python -m pip install .

El papel de PySimpleGUI

  • PySimpleGUI es un wrapper de tkinter y otras bibliotecas GUI
  • Convierte un SDK GUI en una estructura más simple y compacta, a la vez que ofrece personalización detallada
  • Se presenta como una herramienta que no requiere experiencia previa en programación de GUI
  • El ejemplo del README construye una app de ventana interactiva solo con Text, Input, Button, Window, un bucle de eventos, window.read() y window.close()
  • La documentación está disponible en Docs.PySimpleGUI.com

Forma de desarrollo y perspectiva a largo plazo

  • Se explica que PySimpleGUI se ha desarrollado de una manera más cercana a un producto propietario que a un proyecto open source tradicional
  • No se aceptan pull requests
  • Aunque el futuro a largo plazo no está claro, el autor dice que actualmente disfruta escribir código y ayudar
  • Describe la experiencia de PySimpleGUI como una experiencia “once-in-a-lifetime” en la que pudo ver lo que otras personas construyeron

Funciones y correcciones de la versión 6.2

  • La 6.2 incluye una corrección del bug de Window.settings_save
  • Se añadió la capacidad de hacer “print” inline de imágenes en el elemento Multiline
  • La función para actualizar a la última release de mantenimiento volvió a integrarse en PySimpleGUI
    • Puede usarse la Home Window o la línea de comandos psgupgrade
    • Se pueden revisar las notas de la release e instalar la nueva versión
  • Se corrigió el bug #5750, en el que un evento de Graph entraba en un bucle infinito al recibir un evento de write_event_value
    • La corrección limpia la bandera de botón en tiempo real
    • Se indica que el alcance del cambio está limitado a la condición del elemento Graph, por lo que el riesgo de regresión es bajo
  • Se añadió el parámetro select_node_keys a Tree.update, lo que permite seleccionar nodos del árbol de forma programática como si fuera una selección del usuario
  • Se corrigieron la función y el parámetro echo_stdout_stderr de Multiline
    • Solo hace echo si stdout o stderr fueron redirigidos a ese elemento
    • Esta función no realiza la redirección directamente
  • La corrección #6686 resolvió un problema por el cual el botón Calendar chooser borraba campos que solo debían limpiarse en el momento en que window.read devolvía el resultado
  • La Home Window muestra el número de versión de la release de mantenimiento y se movió la ubicación del botón de instalación
  • Al llamar a Window.start_timer, ahora puede especificarse el temporizador con una cadena "H:M:S"
  • Se añadió soporte para solo scroll horizontal en el elemento Column desplazable
  • El elemento Frame ahora incluye los parámetros border_color, border_width_no_relief para configurar el color del borde
    • Si no hay una configuración separada, el color del borde de Frame usa por defecto el color del elemento de texto
  • La sección de referencia de llamadas de la documentación se actualizó para la release 6.2

Drag and drop y proyectos relacionados

  • Se explica que drag and drop era una función deseada desde hace mucho tiempo, y que se encontró una manera de implementarla en el espacio de código del usuario sin modificar el código de PySimpleGUI
  • psgdnd es un nuevo paquete que añade drag and drop a PySimpleGUI
    • Puede instalarse y usarse con pip
    • Hay más información y ejemplos en ese repositorio
  • psgdnd 6.0.1 fue publicado en PyPI y funciona en Windows
  • La versión 6.0.2 en GitHub incluye las correcciones necesarias para Linux
  • Aún no se conoce el estado del soporte para Mac
  • En el repositorio PSGMicroPython se añadió código para interactuar con microcontroladores basados en MicroPython
    • Funciona en Raspberry Pi Pico y ESP32
    • También podría funcionar en otras placas
    • Se presenta como código útil, no como un proyecto grande o robusto

Prototipo de PSGWeb

  • PSGWeb es un prototipo que ejecuta PySimpleGUI en una ventana del navegador
  • Funciona con la mayoría de los programas demo
  • Si se antepone psgweb.us a la URL de una aplicación PySimpleGUI en GitHub, se intentará ejecutarla
  • PSGWeb fue creado como parte de un trabajo mayor de PSG 5, pero no se publicó
  • No hay planes de lanzar o expandir este prototipo

Postura sobre el uso de IA

  • El autor usa LLM para buscar y resumir documentación, consultar errores, investigar y adquirir conocimiento
  • No usa LLM para escribir código
  • Explica que la razón es simplemente que le gusta escribir código
  • También señala que no abrió el proyecto a pull requests porque prefería escribir el código por sí mismo antes que dejar que otros lo hicieran
  • Sobre si PySimpleGUI sigue siendo relevante en la era de la IA, considera que basta con que cada día la gente descubra e instale PySimpleGUI y que al menos una persona lo use
  • El autor dice que le cuesta imaginar crear aplicaciones de Windows sin PySimpleGUI
    • Explica que recientemente construyó un analizador de bus para un proyecto de computadora de protoboard 6502 usando dos Raspberry Pi Pico y una app de PySimpleGUI
    • También comenta que fue fácil crear con PySimpleGUI una app frontend para controlar herramientas en Windows

Historia del proyecto y problemas de financiamiento

  • PySimpleGUI comenzó en 2018 como código de una sola vez creado porque se necesitaba una GUI para un prototipo de reproductor multimedia
  • El objetivo era envolver Tkinter de una forma más lineal e intuitiva para que funcionara rápido, incluso sin experiencia en frameworks GUI orientados a objetos
  • El autor lo subió a GitHub sin experiencia en Python ni en open source, y lo abordó más como una startup que como un proyecto open source tradicional
  • Línea de tiempo:
    • Julio de 2018: Version 1
    • Junio de 2019: Version 4
    • Enero de 2020: los problemas de financiamiento se volvieron una preocupación principal y se mencionó la comercialización
    • Noviembre de 2020: anuncio del curso de Udemy y adición de una solicitud pública de ayuda
    • Diciembre de 2021: lanzamiento del curso
    • Febrero de 2024: lanzamiento comercial de Version 5
    • Abril de 2026: Version 6
  • El Announcements Issue de GitHub se usó como una especie de blog para dejar registro del proyecto, y creció a más de 1,700 entradas
  • Para facilitar la lectura, se publicó una instantánea en la pestaña Announcements 2018-2024 de la documentación
  • Trabajar full time en open source generó una presión financiera inmediata y constante
  • El patrocinio y las donaciones alcanzaron, en su mejor momento, alrededor de 150 dólares al mes a través de GitHub Sponsors y Buy Me a Coffee
  • El curso de Udemy, con 61 lecciones y 11.5 horas de contenido, llegó por un breve periodo a alrededor de 2,000 dólares al mes al principio, pero luego cayó por debajo de 100 dólares
  • Ninguna de las dos vías fue suficiente para sostener el proyecto a largo plazo

Resultado de la comercialización y experiencia con licencias

  • El lanzamiento de la versión paga de Version 5 no fue una decisión repentina, sino algo discutido públicamente durante años en el README y en los anuncios
  • A comienzos de 2024 se lanzó la versión comercial después de agotar otras alternativas
  • El objetivo era mantener la accesibilidad, no levantar barreras
  • Se concluye que, aunque no funcionó bien en términos de sostenibilidad financiera, sí tuvo valor en términos de experiencia, aprendizaje y relaciones
  • Tras la comercialización, no se perdió a la mayoría de los usuarios y muchas empresas siguieron usando PySimpleGUI
  • El problema era lograr que las empresas compraran licencias
  • Se eligió una Hobbyist License en la que los usuarios aficionados y estudiantes podían usarlo gratis, mientras que las empresas debían pagar
  • En la práctica, la gran mayoría de los usuarios se identificó como aficionada
  • Decenas de miles de usuarios empresariales se registraron en el nivel gratuito, y no era raro que incluso en grandes empresas hubiera cientos de usuarios y solo unas pocas licencias pagadas
  • Aclara que no se arrepiente de haber ofrecido una opción gratuita
  • Su conclusión personal es que existe una fuerte expectativa cultural de que las herramientas y bibliotecas de Python sean gratuitas
  • El precio o las quejas no parecían ser el problema central; interpreta que la gente siguió usando PySimpleGUI, pero no sintió la obligación de pagar
  • Incluso unas condiciones de licencia claras no siempre cambiaban el comportamiento

Licencia actual

  • El aviso de copyright es Copyright 2018-2026 PySimpleGUI. All rights reserved.
  • La licencia actual es LGPL3

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-11
Opiniones en Hacker News

  • En el trabajo tenía que registrar las horas trabajadas en Jira, pero no me gustaba tener el sitio web abierto todo el tiempo, y también era lento encontrar el issue en el que estaba trabajando, buscar el enlace para registrar tiempo y agregar un comentario.
    Quería una app de escritorio con la lista de issues asignados a mí y botones para agregar comentarios/horas trabajadas. Con Tkinter me costó bastante hacer que se viera bien, pero después de descubrir PySimpleGUI pude conectar hooks de la API de Jira y construir lo que quería; fue un buen proyecto para aprender desarrollo de UI.

    • Jira se siente tan universalmente lento que parece que mucha gente intenta evitarlo con herramientas personalizadas.
      Un amigo dijo que en un trabajo creó un cliente interno en Qt para tareas básicas de Jira, y cuando yo también tuve que usar Jira para seguimiento de trabajo, usé https://github.com/go-jira/jira para manejar cambios con varios scripts de consola.
    • Cuando dijeron que en mi trabajo iban a empezar a usar registro de tiempo en Jira, empecé a buscar un nuevo empleo.
    • Me pregunto si el código fuente de esta app está publicado en algún lado. Esta semana estoy pensando en hacer algo parecido, así que sería genial si pudiera simplemente apuntar una app ya existente a mi instancia de Jira.
    • Dudo que esto sea realmente aprendizaje de desarrollo de UI. No tengo claro si puede llevar a proyectos más exigentes o ampliarse hacia ellos.

  • Estos frameworks de GUI me entusiasman mucho. La experiencia de escritorio nativa es muy superior a una combinación de webviews, y el loop de eventos simplificado de PySimpleGUI y su enfoque de múltiples backends me parecen realmente novedosos.
    Eso sí, me pregunto por qué no hay más “GUI automáticas” que, con solo darles estructuras de datos y funciones, generen automáticamente una interfaz adecuada para manipularlas. Si mediante heurísticas eligieran si poner paneles en vertical/horizontal, una interfaz con pestañas o popups, podrían habilitar muchas funciones que son demasiado anidadas para una CLI y demasiado nativas para convertirlas en una webapp.

    • Un proyecto que podría interesarte: Gooey dice que “convierte casi cualquier programa de consola en Python 3 en una app con GUI con una sola línea”.
      https://github.com/chriskiehl/Gooey
    • En 2011 hice un generador automático de formularios para la web basado en argumentos de funciones, y más recientemente probé algo parecido en un toolkit de GUI basado en el lenguaje D.
      Puedes definir una estructura y pasarla a la función dialog, y esta genera automáticamente un cuadro de diálogo según los campos de la estructura; cuando el usuario presiona OK, llama a un callback. También puedes especificar qué widget usar mediante atributos personalizados; por ejemplo, si a un int le agregas @ControlledBy!VerticalSlider(0, 100), se convierte en un slider de 0 a 100 en lugar de un campo numérico. También puedes agregarlos a funciones de menú, como @menu("Search") Find(string text) { ... }, para generar automáticamente el menú y el cuadro de diálogo, y también hay un DataControllerWidget que llama al callback en cada evento de cambio. Hace algunos años escribí un artículo relacionado, pero el avance es muy lento: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...
      Me resulta lo bastante interesante como para querer dedicarle más tiempo, pero como no lo uso en mi trabajo principal, solo avanzo de a poco cuando tengo ganas de programar los fines de semana.
    • Algo que encaja con esa descripción existió hace décadas y se llamaba Naked Objects. No lo probé porque no me interesaba el ecosistema Java, pero parecía útil.
    • En Python, TraitsUI era una buena “UI automática”, y todavía cumple ese rol.

  • La estética de los ejemplos parece sacada directamente de los 90, como [0]. Es perfecta para prototipos o herramientas internas para gente que no puede usar una CLI, pero me pregunto qué hacer cuando se necesita una UI atractiva.
    En términos de rendimiento, una UI nativa siempre es buena, pero siempre me pareció más difícil de estilizar que una página web. Me pregunto cuál sería, en una GUI de Python, el equivalente a un conjunto de componentes estilizados que se vean elegantes sin mucho esfuerzo, como Flutter o SwiftUI.
    [0] https://raw.githubusercontent.com/PySimpleGUI/PySimpleGUI/ma...

    • Puede que sea cuestión de hacerlo bien o mal, pero en mi experiencia las UI “estilizadas” han sido una de las razones por las que mucho software termina siendo peor para muchos usuarios.
      Como mínimo, el estilo de UI predeterminado que ofrece el sistema operativo permite que la gente aprenda algo en una app y lo traslade a otra. Como no soy un diseñador de UI sobresaliente, es muy probable que los valores predeterminados del sistema operativo sean mejores que cualquier cosa que se me ocurra. Si a eso le sumamos la frase que marketing teme escuchar, “nuestro software se ve viejo”, el costo de desarrollo ya se dispara a un nivel difícil de manejar.
    • La vibra noventera en sí no está mal, pero esto ni siquiera encaja con el look de un sistema operativo de los 90. El fondo de los checkboxes está mal, la etiqueta de título superior está desalineada y la posición del botón Exit también es rara, así que en conjunto parece una UI mal diseñada.
      En los 90 también existía software así, pero no es la estética noventera a la que la gente suele referirse. Hubo mucho trabajo detrás del diseño de UI de Windows 95.
    • No entiendo cuál es el problema con el look de los 90. A mucha gente le gusta.
      Me molestan más los enormes espacios en blanco de las UI actuales, los botones que no parecen botones, las barras de desplazamiento que desaparecen y los menús hamburguesa.
    • Si la apariencia es la máxima prioridad, parece bastante difícil ganarle a una página web.
      La separación entre frontend y backend viene de base, y si más adelante hace falta, también permite acceso remoto. Si quieres usarla como una app nativa, basta con poner un botón “Open browser UI” en una pequeña GUI tipo Tkinter. Si el botón de ejecución agrega un token a la URL, también puedes protegerte de un daemon ejecutándose como otro usuario en la misma máquina, aunque nunca he visto que alguien lo haga así en la práctica.
    • El problema es que Tkinter, al menos en Windows, realmente está basado en widgets de los 90. Aunque cambies el tema de PySimpleGUI a SystemDefaultForReal, los widgets nativos de Windows tienen un aspecto moderno, pero Tkinter no se ha actualizado en absoluto y se ve fuera de lugar.

  • Se ve bien. Aunque esta biblioteca ya está madura y quizá sea difícil hacer cambios grandes, estaría bueno usar diccionarios en lugar de listas. Los diccionarios recientes de Python recuerdan el orden de inserción
    En un trabajo anterior hice algo parecido con un wrapper mucho más delgado sobre PyQt, y el código también era sorprendentemente poco. La diferencia clave era que manejaba juntos la configuración de propiedades/señales y el anidamiento de widgets. En vez de establecer propiedades en el constructor, tenía la ventaja de que, aunque después hicieras falta el nombre del widget para cambiar el texto, podías definir las propiedades en el cuerpo de la definición de la vista. Una sola función setup_view era toda la API, y era bastante práctica para crear GUIs simples rápidamente. Esta biblioteca también parece una buena alternativa, así que gracias por compartirla

    • Ese cambio llegó en Python 3.7 y ya es una función de más de 5 años
      https://docs.python.org/3/whatsnew/3.7.html#summary-release-...
    • Si miras la tendencia de los frameworks de GUI recientes, la separación entre layout y datos produce código mucho más limpio
      Es mejor dejar que el framework se encargue del data binding. Tanto la web como el escritorio van cada vez más en esa dirección. En lugar de modificar widgets directamente, hay que enlazar las propiedades de los widgets a un almacén de datos y hacer que se rerendericen automáticamente cuando cambien. Los ejemplos de entrada/salida de la página muestran algo parecido. Ya nadie usa getElementById()
    • Según la página de GitHub, dice que “simplificó la definición de ventanas usando listas y diccionarios, tipos de datos centrales de Python que entienden los principiantes”

  • Parece que se acerca a la facilidad de uso de VB6 o Delphi/Lazarus. Sin duda hay avances, y ahora con solo tener un constructor de GUI interactivo podría bastar con hacer #import de los formularios creados y usarlos directamente
    Hace unos años perdí muchísimo tiempo en un proyecto intentando usar WxPython junto con WxFormBuilder. Incluso un cambio pequeño en el formulario rompía todo el backend, y aunque escribí yo mismo un código delgado de conexión intermedia, al cambiar el tipo de un campo se volvió a romper todo. Me alegra que aquí parezca que eso no pasaría

  • Como alguien que desarrolla una aplicación GUI en Python [1], creo que el mayor problema al usar Python para apps de escritorio es el empaquetado
    Las herramientas existentes para crear binarios distribuibles dejan de funcionar en cuanto tienes más de unas pocas dependencias, o requieren hacks nada triviales. Incluso paquetes populares generan problemas difíciles, como imports ocultos faltantes o archivos de datos faltantes que ni sabías que existían. La carga dinámica de módulos también puede romperse cuando la sacas fuera de un entorno Python normal, como con PyInstaller o cx_freeze. No sé qué se podría hacer, pero quizá Python también necesite un estándar de empaquetado de programas ejecutables independientes que solo dependan del intérprete, como los JAR de Java

    1. https://github.com/FreeLanguageTools/vocabsieve
    • Python tiene zipapp, que está estandarizado y se parece a JAR: https://peps.python.org/pep-0441/
      Con herramientas como shiv o PEX puedes crear zipapps que incluyan las dependencias de la aplicación, pero si hay extensiones binarias el resultado sigue siendo específico de cada plataforma: https://github.com/linkedin/shiv#gotchas
      En mi programa de Python recomiendo a los usuarios instalarlo con pipx: https://github.com/pypa/pipx
      Si el público objetivo es mínimamente técnico, me parece la mejor opción. Evita los conflictos de versiones de pip install --user y el dolor de crear manualmente entornos virtuales por aplicación, y en general ofrece una experiencia de usuario decente. Si recomiendas pipx como método de instalación predeterminado, puedes esperar que la gente logre instalarlo. Mi programa tiene dependencias binarias, pero no GUI

  • Personalmente me gusta más CustomTKinter. Es mucho más elegante, con un aspecto tipo tema Material, y en Windows/Linux/macOS soporta tema claro/oscuro según la configuración del sistema

  • Sorprende que todavía nada haya llenado bien el vacío que dejó VB6 en el ámbito del desarrollo rápido de aplicaciones. El lenguaje en sí no era excelente, pero el punto fuerte de VB6 era su constructor de GUI con drag and drop

  • Estoy considerando ponerle una GUI a una herramienta que ya tiene una interfaz CLI bastante bien hecha, para que también puedan usarla personas que no usan Linux de escritorio. Parece que PySimpleGUI podría ajustarse justo a mis necesidades
    https://github.com/hiAndrewQuinn/finstem
    Mi herramienta tiene flags bien definidos para CSV, TSV y JSON. Me interesa saber si alguien tiene experiencia creando una GUI encima de una herramienta CLI completa existente, sin modificarla, y qué dificultades debería anticipar

    • Los motores de ajedrez son un buen caso de referencia. La parte de toma de decisiones es una CLI y se conecta a GUIs como WinBoard[0] o Arena[1]
      El motor y la GUI siguen protocolos como WinBoard o UCI[2], e intercambian comandos de texto por STDIN/STDOUT. La principal dificultad es la misma que se encuentra con multithreading: puede producirse un deadlock en el que la GUI y la CLI se queden esperando una a la otra. Por eso, ambos lados deben manejar la entrada/salida en hilos separados de la “lógica de negocio” para mantener la capacidad de respuesta. Otro problema común es que el manejo de pipes tiene particularidades según el sistema operativo, así que hay que prestar atención al flush de buffers y a las diferencias de API entre Linux/Mac/Windows
      [0] http://hgm.nubati.net/
      [1] http://www.playwitharena.de/
      [2] https://gist.github.com/DOBRO/2592c6dad754ba67e6dcaec8c90165...
    • Por ejemplo, basta con ver HandBrake. Es, en gran medida, una UI elegante para ffmpeg

  • No quiero sonar grosero, pero hay demasiado texto. En cada lugar donde se puede poner texto hay frases largas una tras otra y, aunque en general hay consistencia, no hay ni una sola captura relevante durante las primeras mil palabras
    Algo se siente fuera de lugar. Da la impresión de que quizá es un desarrollador joven y entusiasta, o que puso mucho texto para convencer a la gente de probarlo. El README incluso tiene una sección “about me” donde el autor se presenta. Un ejemplo sería bajar a cualquier punto del README, leer unos párrafos y luego intentar repetir lo que acabas de leer

    • Cada sección tiene un título claro. Si una sección no te interesa, basta con hacer un poco de scroll. Nadie te obliga a leer la sección “about me”
      Algunas personas disfrutan leer sobre una herramienta, en vez de tener la actitud de “cómo hago para leer la menor cantidad de palabras posible y ejecutarla lo más rápido posible”. Estás usando gratis una herramienta hecha por otra persona, así que sería mejor dejar de quejarte y permitirle expresarse como quiera
    • La suposición de “desarrollador joven y entusiasta” es incorrecta. En “About Me” [1] dice que escribe software desde los años 70 y que pasó la mayor parte de su carrera creando productos en Silicon Valley
      [1] https://github.com/PySimpleGUI/PySimpleGUI#about-me-
    • Solo le di una mirada por encima. No es un MVP de un producto para atraer inversionistas, sino una herramienta cuya documentación escribió la misma persona que la creó
      No quiero ser grosero, pero me pregunto si acaso te da miedo el simple hecho de tener que leer algo cuando no te lo dan masticado en un resumen paso a paso
    • Me parece una forma bastante grosera de expresarlo. En especial porque redujiste la razón de que haya tanto texto a solo una de dos posibilidades, y ninguna suena particularmente bien. Además, ni siquiera parece que esas razones sean correctas
      La misma idea se podría haber transmitido con algo como “si es un proyecto visual, siento que la descripción principal debería tener más capturas de pantalla”, sin incluir conjeturas insultantes
    • El problema podría ser haber llamado Simple al proyecto. Porque eso instala en la mente del lector una expectativa previa
      Si pones palabras como Smart, Open, Trusted o Secure en el nombre de un proyecto, es fácil que la gente señale que no alcanza el ideal del nombre. En cambio, nombres como C o BSD no tienen antónimos ni implicaciones, así que es difícil decir que “el lenguaje C no está a la altura de su nombre”