Proyecto destacado: Colosseum

Publicado por Russell Keith-Magee en 6 October 2017

Este artículo fue publicado originalmente en la lista de correo de Entusiastas BeeWare. Si deseas recibir actualizaciones periódicas sobre el proyecto BeeWare, ¿Por qué no suscribirse?

Cuando diseñas una aplicación de interfaz gráfica, ya sea para escritorio, dispositivos móviles o navegador, una de las tareas más fundamentales es describir cómo colocar widgets en la pantalla. La mayoría de los kits de herramientas de widgets usarán un modelo de empaquetamiento de cuadrícula o caja de algún tipo para resolver este problema. Estos modelos tienden a ser relativamente fáciles al comienzo, pero se desmoronan rápidamente cuando tienes necesidades complejas de diseño o cuando tienes diseños que necesitan adaptarse a diferentes tamaños de pantalla.

En lugar de inventar un nuevo modelo de cuadrícula o de caja, el kit de herramientas del widget Toga widget toolkit adopta un enfoque diferente, utilizando un esquema conocido para diseñar contenido: Cascading Style Sheets, o CSS. Aunque CSS es más conocido por especificar el diseño en las páginas web, no hay nada intrínsecamente específico de la web al respecto. Al final del día, es un sistema para describir el diseño de una colección jerárquica de nodos de contenido. Sin embargo, hasta la fecha, cada implementación de CSS está vinculada a un navegador, por lo que la percepción es que CSS es un estándar específico del navegador.

Ahí es donde entra Colosseum. Colosseum es una implementación independiente del navegador de un motor de renderizado CSS. Toma un árbol de "nodos" de contenido, como un DOM de un documento HTML y aplica instrucciones de diseño CSS para diseñar esos nodos como cuadros en la pantalla. En el caso de Toga, en lugar de diseñar los elementos <div> y <span>, diseñas objetos Box y Button. Esto le permite especificar diseños adaptativos increíblemente complejos para aplicaciones Toga.

Pero Colosseum como proyecto tiene muchos otros posibles usos. Se puede usar en cualquier lugar donde exista la necesidad de describir el diseño fuera del contexto de un navegador. Por ejemplo, Colosseum podría ser la piedra angular de un renderizador de HTML a PDF que no requiere el uso de un navegador. También podría usarse como una librería de pruebas e implementación de referencia para la especificación CSS en sí misma, proporcionando una forma ligera de codificar y probar los cambios propuestos a la especificación.

La implementación actual se basa en el proyecto de Facebook yoga: originalmente era un código portado de JavaScript a Python línea a línea. Sin embargo, yoga solo implementa la sección de Flexbox de la especificación CSS3.

Esta semana, comenzamos un gran proyecto: reescribir Colosseum para que sea un motor de CSS totalmente compatible. El trabajo hasta ahora se puede encontrar en la rama globo del repositorio Colosseum en Github. El primer objetivo es el cumplimiento de CSS2.1, con una implementación del modelo de caja de CSS tradicional y el diseño de flujo. Una vez que tengamos una implementación razonable de eso, buscaremos agregar diseños Grid y FlexBox desde el conjunto de especificaciones CSS3.

Esto es obviamente un trabajo grande. CSS es una gran especificación, por lo que hay mucho trabajo por hacer, ¡pero eso también significa que hay muchos lugares para contribuir! Elije un párrafo de la especificación CSS, construye algunos casos de prueba que demuestren los casos descritos en ese párrafo y envía un parche que implemente ese comportamiento!

Esto resalta por que tu apoyo financiero es muy importante. Si bien podríamos hacer esto completamente con un esfuerzo voluntario, vamos a progresar mucho más rápido si un pequeño grupo de personas pudiera enfocarse en este proyecto de tiempo completo. El apoyo financiero permitiría aumentar significativamente la velocidad de desarrollo de Colosseum y el resto de la suite BeeWare.

Si deseas que Colosseum y el resto de BeeWare se desarrollen hasta el punto en que puedan utilizarse para aplicaciones comerciales, considera apoyar a BeeWare financieramente. Y si tienes alguna idea para fuentes de financiación potenciales más grandes, por favor ponte en contacto.

2017 Google Summer of Code - Portar Cricket a Toga, en lugar de Tkinter

Publicado por Dayanne Fernandes en 25 August 2017

Después de casi 4 meses de trabajo en Google Summer of Code 2017, finalmente estoy completando mi propuesta. Cada migración de widget y cada commit / PR / Issues / discusión con mis mentores sobre Cricket, Toga y rubicon-objc fueron detallados en el Issue 58.

"Comer su propia comida para perros"

La mejor manera de demostrar que un producto es confiable para los clientes es usarlo. Por lo tanto, la forma de demostrar que Toga es una herramienta eficaz para construir una interfaz gráfica de usuario es construir una aplicación completa que la utilice.

Cricket es una herramienta gráfica que le ayuda a ejecutar sus suites de prueba. Su versión actual se implementa utilizando Tkinter como el marco de la interfaz gráfica principal. Entonces, ¿por qué no probar Toga dentro de otro producto de BeeWare? Eso es lo que he logrado durante mi trabajo de GSoC.

Resultados

La propuesta se centra no sólo en el puerto de Tkinter a Toga, sino en la asignación de los widgets necesarios para una aplicación real utilizando Toga. Para ayudarme a mapear esto he estudiado más sobre Tkinter, Toga, Colosseum, rubicon-objc, Objective-C, Cocoa y CSS.

El trabajo que hice durante GSoC se envió a través del PR 65, el informe en el Issue 58 y la demostración final se puede ver en este link. Había widgets utilizados en Cricket que no estaban listos todavía en Toga, por lo que era necesario hacer algunas mejoras en Toga para que pudiera usarlas en Cricket. En resumen, aquí hay algunos PR que contribuí para hacer mi trabajo en Cricket:

PR abierto enviado a Toga:

  • PR 201 : [Core][Cocoa] Refactoring of the Tree widget

PRs emergidos enviados Toga:

  • PR 112 : [Core][Cocoa] Enable/disable state for buttons, solved Issue 91
  • PR 170 : [Cocoa] Content and retry status for stack trace dialog
  • PR 172 : [Cocoa] Window resize
  • PR 173 : [Core][Cocoa] Button color
  • PR 174 : [Doc] Examples folder and button features example
  • PR 178 : [Doc] Fix tutorial 2 setup
  • PR 180 : [Doc] Update Toga widgets roadmap
  • PR 182 : [Cocoa] Update the label of the Stack trace button for critical dialog
  • PR 184 : [Core][Cocoa] Hide/show boxes widget
  • PR 188 : [Cocoa] Fix error on MultilineTextInput widget, solved Issue 187
  • PR 204 : [Core][Cocoa] Clear method to MultilineTextInput widget, solved Issue 203
  • PR 206 : [Core][Cocoa] Readonly and placeholder for MultilineTextInput widget
  • PR 208 : [Cocoa] Fix apply style to a SplitContainer widget, solved Issue 207

PRs emergidos enviados Cricket:

PRs emergidos enviados rubicon-objc:

  • PR 34 : [Doc] Add reference to NSObject

Tiquetes abiertos enviados a Toga:

  • Issue 175 : [Core] Add more properties for Label and Font widgets
  • Issue 176 : [Core] Add "rehint()" on the background of the widget after changing font size
  • Issue 186 : [Core] Set initial position of the divisor of a SplitContainer
  • Issue 197 : [Core] Get the id of the selected Tab View on the OptionContainer

Tiquetes cerrados en Toga:

Tiquetes cerrados que no reporté pero que resolví en Toga:

  • Issue 91 : API to disable buttons?
  • Issue 205 : adding MultiviewTextInput results in TypeError

Tiquete cerrado que reporté a Cricket:

  • Issue 59 : Run selected doesn't count/ runs every test selected in a test module, was fixed by me

Tiquete abierto que reporté a rubicon-objc Jonas Obrist repository:

  • Issue 1 : Seg Fault when iterate through a NSIndexSet using block notation

Planes futuros

Hay algunas características en Cricket que quiero ayudar a desarrollar en un futuro próximo, por ejemplo:

  • Un botón para actualizar todo el árbol de pruebas
  • Configuración de Cricket

Además, hay algunos problemas que quedaron después de la migración a Toga. Estos problemas se arreglarán en Toga en un futuro próximo, por ejemplo:

  • Una brecha entre la salida y los cuadros de error cuando no hay mensaje de salida
  • Ejecutar una prueba si el usuario haga clic en ella

Realmente creo que Toga será el framework oficial en Python para construir GUI para aplicaciones multi-plataforma, así que seguiré contribuyendo a este proyecto porque quiero usar en todas las aplicaciones que necesitaría una GUI.

Consideraciones finales

Me gustaría agradecer a mis mentores Russell Keith-Magee y Elias Dorneles por guíarme y ayudarme tanto durante este período. La oportunidad de ser parte de esta comunidad fue un gran honor para mí, muchas gracias por aceptarme en este programa Russell Keith-Magee. Además, quiero agradecer a Philip James que hizo algunas reseñas en mis PRs y Jonas Schell quienes arreglaron un tema que envié a Toga.

2017 Google Summer of Code - Mejoras en Batavia

Publicado por Adam Boniecki en 23 August 2017

Con el programa Google Summer of Code 2017 llegando a su fin, es hora de resumir lo que hice durante el verano trabajando en Batavia.

Batavia es una parte de la colección de proyectos de BeeWare. Como todavía está en su primera etapa de desarrollo, por mi parte me ofreció implementar una serie de características que faltaban en Batavia, que van desde tipos de datos elementales, a través de la manipulación JSON y construcciones de lenguaje como generadores. Publiqué mi propuesta en este hilo de GitHub y lo mantuve actualizado con mi progreso semanalmente.

Ten en cuenta que al final de GSoC, hemos decidido divergir de la propuesta inicial y renunciar a la aplicación de contextlib en favor de la compatibilidad con Python 3.6, que usa op-codes de 2 bytes.

En general, fue una gran experiencia de aprendizaje y diversión. Muchas gracias a mis mentores Russell Keith-Magee y Katie McLaughlin, y a toda la comunidad de BeeWare.

2017 Google Summer of Code - Probando Toga / API de configuración

Publicado por Jonas Schell en 22 August 2017

Google Summer of Code 2017 está llegando a su fin. Después de tres meses de trabajo en el proyecto BeeWare, quisiera resumir mi trabajo y compartir mis experiencias.

"Ningún plan de batalla sobrevive al primer contacto".

Esta fue una de las primeras cosas que Russell me dijo después de que decidimos fundamentalmente reestructurar mi calendario y metas de GSoC propuestos. Durante el período inicial con la comunidad descubrimos que Toga era aún más difícil de probar como esperábamos. El estrecho acoplamiento entre el código independiente de la plataforma en Toga-Core y las implementaciones dependientes de la plataforma para (Windows, MacOS, iOS, Linux, Android, Django, ...) nos estaba dando problemas para escribir pruebas significativas.

Esperamos que Toga se convierta en un proyecto de tamaño decente, por lo tanto queremos que tenga una base sólida y bien probada. Por esta razón, decidimos que pasaría la mayor parte de GSoC para reestructurar Toga para que ejecutar pruebas resultara más fácil de hacer. Además de eso, también añadiría pruebas de implementación para comprobar si un backend dado se implementa de la manera correcta. Si terminara antes del final del verano, empezaría con mi propuesta de proyecto original.

La gran reestructuración de Toga

Con los nuevos objetivos y una nueva rama comencé el viaje para reestructurar el proyecto Toga para hacerlo más fácil de probar.

Después de hackear y probar diferentes cosas en una rama separada. Identifiqué que las dependencias entrelazadas de la plataforma son el problema principal. Para separar el módulo Toga-Core de sus implementaciones de backend decidimos usar el patrón de fábrica en lugar del modelo de herencia que teníamos antes. Ahora cada backend tiene su propia fábrica que produce los widgets adecuados para la plataforma en la que se está ejecutando. De esta manera tenemos una clara separación entre Toga-Core y el nivel de implementación. Las dependencias de la plataforma ahora están incluidas en el nivel de implementación.

Después de que la nueva estructura fuera clara porté Toga-Core así como los backends para el Cocoa, iOS y GTK. Hice esto en la rama de Toga (La gran reestructuración de Toga [WIP] # 185).

En la práctica, esto significaba que tenía que tocar manualmente casi todos los widgets de todos los backends para conectarlos al nuevo patrón de fábrica.

Desafíos

Toga habla con los frameworks nativos GUI, por lo tanto tuve que tener un buen entendimiento acerca de los principios y conceptos detrás de cada uno de estos marcos. A veces me sentía abrumado por la complejidad combinada de todas las partes que componen Toga. La siguiente es la lista:

  • Cada backend de Toga se envuelve alrededor de un marco existente y único. Para envolver el marco que tiene que entender el marco.
  • "Me encanta Python, ¿por qué tengo que entender Objetive C"? Para trabajar eficazmente en los backends de iOS y macOS, tenía que aprender los conceptos básicos del Objetivo C, aunque sólo fuera para leer los documentos de Apple.
  • Toga tiene un montón de partes móviles. Hay backends, marcos, librerías para hablar con backends, librerías para realizar el diseño de la interfaz de usuario y más. Me tomó una buena cantidad de tiempo para entender todas estas partes. Lo siguiente es sólo una visión general de los conocimientos recién adquiridos durante GSoC:
  • Rubicon-ObjC para hablar con los backends de iOS y macOS.
  • Colosseum para entender y solucionar problemas de diseño.
  • Módulo AST para realizar las pruebas de implementación.
  • El uso de patrones de diseño
  • Cómo estructurar grandes proyectos.
  • Leer y entender grandes y complejos pedazos de código.

Otro trabajo que realicé

Futuro trabajo por hacer

  • Todo mi trabajo se encuentra en el PR "La gran reestructuración de Toga [WIP]". Después de que los backends que faltan, a saber, Windows y Android, se incluyan, todo se puede emerger con la rama master. Tenemos que esperar a los backends que faltan, porque el nuevo esquema es incompatible con las versiones antiguas y no pueden coexistir.
  • La API de configuración de mi propuesta original no se ha terminado debido a las razones mencionadas anteriormente. Tengo un primer borrador de trabajo y seguiré trabajando en él después de GSoC en este Pull Request.

"Shout out"

Me gustaría dar las gracias a Russell Keith-Magee por ser un Mentor impresionante y por todo el tiempo que invirtió en mí durante GSoC. También quiero agradecer a la comunidad BeeWare por ayudarme cuando alguna vez tuve un problema. ¡Gracias!

Un nuevo yak para el rebaño: BeeKeeper

Publicado por Russell Keith-Magee en 31 July 2017

Escribir suites de pruebas es una habilidad que es una parte vital del entrenamiento de los programadores. Aprender a escribir buenas pruebas le ayuda a escribir un código más robusto y asegura que cuando haya escrito un código que funcione, siga trabajando durante mucho tiempo en el futuro. También puede ayudarle a escribir mejor código en primer lugar. Resulta que el código bien diseñado, con alta cohesión y bajo acoplamiento, también es fácil de probar - por lo que escribir código que sea fácil de probar casi siempre dará como resultado una mejor calidad total del código.

Un paso importante en la "nivelación" de su experiencia de pruebas es comenzar a usar un servicio de integración continua o CI. Un servicio de CI es una herramienta que ejecuta automáticamente su suite de pruebas cada vez que alguien realiza un cambio o cada vez que alguien propone un cambio en forma de una solicitud de PR. El uso de un servicio de CI garantiza que su código siempre pase su suite de pruebas - no puede introducirse accidentalmente en un cambio que rompe una prueba, porque obtendrá una notificación de advertencia roja grande.

Un CI es un servicio tan importante que muchas empresas sólo existen para proporcionar CI-as-a-service. El proyecto BeeWare ha utilizado, para diversos proyectos, TravisCI y CircleCI. Ambas herramientas proporcionan niveles gratuitos para proyectos de código abierto y han patrocinado generosamente BeeWare con actualizaciones de capacidad en varias ocasiones.

Sin embargo, BeeWare ha tenido una relación interesante con los servicios comerciales de CI. Esto es por dos razones.

En primer lugar, nuestros conjuntos de pruebas, especialmente para VOC y Batavia - toman mucho tiempo para ejecutarse. Estos dos proyectos requieren pruebas que inician y cierran repetidamente las máquinas virtuales (para Java y JavaScript, respectivamente), y no importa cuánto se optimice el código que se está probando, el tiempo de inicio y apagado de una máquina virtual eventualmente se acumula. También necesitamos ejecutar nuestras suites de prueba en múltiples versiones de Python - en la actualidad, soportamos Python 3.4, 3.5 y 3.6, con 3.7 en el horizonte. También hay cambios sutiles en versiones micro que pueden requerir pruebas.

Hemos sido capaces de acelerar las prueba, dividiendo la suite de pruebas y ejecutando partes de la suite en paralelo, pero eso nos obliga a enfrentarnos al segundo problema. Los servicios comerciales de CI suelen operar en un modelo de suscripción; mayores suscripciones que proporcionan más recursos simultáneos. Sin embargo, nuestro patrón de uso es muy inusual. La mayor parte del año, recibimos un goteo lento de solicitudes de PRs que requieren pruebas. Sin embargo, un par de veces al año, tenemos un gran sprint, y tenemos una avalancha de contribuciones durante un corto período de tiempo. En PyCon EE.UU., hemos tenido grupos de 40 personas presentando parches - y todos ellos necesitan sus PRs probados por CI. Y el tiempo es un factor - los sprints sólo duran un par de días, por lo que un rápido cambio en las pruebas es esencial.

Si tuviéramos que suscribir a los niveles de suscripción de nivel superior de CircleCi y TravisCI, todavía no tendríamos suficientes recursos para soportar un sprint - pero estaríamos masivamente sobre abastecidos en recursos durante el resto del año. También tendríamos que pagar $ 750 o más por mes por este servicio, que es un presupuesto que no podemos permitirnos.

Así que tuvimos un problema. Para ejecutar nuestra suite de pruebas de manera eficaz, necesitábamos recursos paralelizados masivamente para ejecutar una suite de pruebas rápidamente; y en ciertas épocas del año, necesitamos un número extremadamente grande de estos recursos.

También teníamos otras tareas automatizadas que queríamos realizar. Queríamos hacer linting del código (comprobación automatizada de estilo de código) antes de que se probara un PR. Queríamos verificar la ortografía de la documentación. Y queríamos que estas tareas se retroalimentaran en GitHub como comentarios automatizados y marcadores de estado de revisión de código específicos, informando a los colaboradores no sólo de que se había producido un problema, sino de qué problema y dónde estaban en su código.

También queríamos administrar las compilaciones de pipeline - no tiene sentido hacer una prueba completa de varias versiones de Python una vez que haya establecido que las pruebas están fallando en una versión. Y no hay punto en hacer pruebas en absoluto si hay problemas de estilo de código.

También queríamos hacer cosas que no eran sólo pruebas. Queríamos verificar que se firmaron acuerdos de contribución. Queríamos automatizar el despliegue de sitios web y documentación.

Lo que teníamos no era sólo un problema de CI. Era un problema donde queríamos ejecutar automáticamente código arbitrario, de manera segura, en respuesta a un evento GitHub.

He estado tratando de encontrar un servicio de CI que pueda satisfacer nuestras necesidades durante más de un año. Pero durante el último año, algunos pensamientos comenzaron a congelarse en mi cabeza.

  • Amazon proporciona una API (EC2) que le permite arrancar máquinas de complejidad variable (hasta 64 CPUs, con casi 500 GB de RAM) y pagar por minuto para ese uso.
  • Docker proporciona las herramientas para configurar, lanzar y ejecutar código de manera aislada
  • Amazon también proporciona una API (ECS) para controlar la ejecución de los contenedores Docker.

No hay nada específico acerca de AWS EC2 o ECS tampoco - se podría utilizar Linode y Kubernetes, o Docker Swarm o Microsoft Azure ... simplemente se necesita tener la capacidad de filtrar fácilmente las máquinas y ejecutar un contenedor Docker. Después de todo: un conjunto de pruebas es sólo un contenedor Docker que ejecuta un script que inicia su suite de pruebas. Una revisión de linting es un contenedor de Docker que ejecuta un script que lints su código. Una verificación de acuerdo de contribuyente es un contenedor de Docker que comprueba los metadatos asociados con una solicitud de extracción.

Todo lo que necesita es un sitio web que puede recibir las notificaciones de eventos de GitHub e iniciar los contenedores de Docker en respuesta.

A principios de julio, me encontré entre trabajos, y pronuncié la fatídica pregunta: "¿Cuán difícil podría ser?" Y así, hoy, estoy anunciando BeeKeeper - el propio servicio de CI de BeeWare.

BeeKeeper se despliega como un sitio web de Heroku, escrito con Django. Después de configurarlo con las credenciales de Github y AWS, escucha los webhooks de Github. Cuando se detecta una solicitud de pull o Push, BeeKeeper crea una solicitud de generación; que la solicitud de construcción inspecciona el código en el repositorio en busca de un archivo de configuración beekeeper.yml. Ese archivo de configuración describe el pipeline de tareas que se van a realizar, y para cada tarea, el tipo de máquina que se debe usar, las variables de entorno que se requieran y la imagen de Docker que se utilizará.

BeeKeeper también permite al administrador del sitio describir qué recursos se utilizarán para satisfacer las compilaciones. Una tarea puede decir que necesita una instancia de "Alta CPU"; pero la instancia BeeKeeper puede determinar lo que significa "alta CPU" - ¿es 4 CPUs o 32? ¿Cuándo esas máquinas son coladas hacia arriba, cuánto tiempo se les permitirá sentarse inactivo antes de ser apagado de nuevo? ¿Cuántas máquinas deben estar permanentemente en el grupo de trabajo? ¿Y cuál es el límite superior de las máquinas que se iniciará?

Una herramienta complementaria para BeeKeeper es Waggle. Waggle es una herramienta que prepara una definición local de una tarea para que pueda ser utilizada por BeeKeeper - compila la imagen de Docker y la carga en ECS para que pueda ser referenciada por tareas. (Se llama "Waggle" porque cuando las abejas obreras descubren una buena fuente de néctar, regresan a la colmena y hacen una 'danza' que le dice a otras abejas cómo hacer para encontrar esa fuente).

También hemos proporcionado un repositorio llamado Comb (nombrado después del peine de miel, las abejas del lugar almacenan todo el néctar que encuentran) que define las configuraciones de la tarea que una instancia de BeeKeeper puedo usar. Hemos proporcionado algunas definiciones simples como parte del repositorio base de Comb; cada implementación de BeeKeeper debe tener uno de estos repositorios propios.

Todavía hay mucho trabajo por hacer, pero ya estamos usando BeeKeeper con Batavia y VOC, y la próxima PyCon AU sprints será nuestra primera en condiciones de alta carga. Algunos cálculos de respaldo prevén que por alrededor de $50, podremos proporcionar suficientes recursos de CPU para cada ejecución de prueba para completar su ejecución en 10 minutos o menos, soportando un sprint de decenas de personas.

Aunque BeeKeeper fue escrito para satisfacer las necesidades del proyecto BeeWare, es una herramienta de código abierto disponible para cualquier persona. Si desea tomar BeeKeeper para darle una prueba, vaya a los sprints, o revise el código en GitHub.

BeeKeeper también es un ejemplo del tipo de producto que vería más si el desarrollo de BeeWare se financiara a tiempo completo. Fui capaz de construir BeeKeeper porque tenía un par de semanas de descanso entre los trabajos. No hay fin para las herramientas y bibliotecas como BeeKeeper y Waggle que podrían ser construidas para soportar el proceso de desarrollo de software - todo lo que falta son los recursos necesarios para desarrollar esas herramientas. Si desea ver más herramientas como BeeKeeper en el mundo, considere la posibilidad de unirse al proyecto BeeWare como miembro financiero. Cada pedacito ayuda, y si podemos alcanzar a una masa crítica de patrocinadores, podré comenzar a trabajar en BeeWare a tiempo completo.

Una solicitud de ayuda

Publicado por Russell Keith-Magee en 5 April 2017

Hace unos 4 años, hice el primer commit con Cricket - la primera herramienta que eventualmente se convertiría en parte de la suite BeeWare. Desde entonces, el proyecto BeeWare ha crecido para abarcar soporte para plataformas móviles, dos implementaciones alternativas de Python y un conjunto de widgets multi-plataforma, así como las herramientas de desarrollo que iniciaron el proyecto originalmente.

Durante la mayor parte de este tiempo, BeeWare ha sido un esfuerzo voluntario. Inicialmente, fue un proyecto en solitario; sin embargo, en el último año en particular, el número de personas que han contribuido a BeeWare ha crecido rápidamente. Más de 300 personas han hecho contribuciones a las diversas herramientas y librerías de BeeWare, debido, al menos en parte, a las Monedas de Desafío que hemos estado ofreciendo en los sprints.

Cabe destacar el equipo de 7 personas que se han unido al proyecto como apicultores, ayudando a compartir la carga de mantenimiento del proyecto. No puedo agradecer a estas personas lo suficiente - sin su ayuda, no se habría logrado tanto progreso durante el último año.

Tu debes haber notado que en los últimos meses, el progreso ha sido especialmente rápido. Esto se debe a que, durante los últimos seis meses, el desarrollo de BeeWare ha sido parcialmente financiado por empleadores muy complacientes en Jambon Software. Mi contrato con Jambon me permitió pasar largos periodos de tiempo pagados para trabajar en BeeWare - y, no es sorprendente, es posible hacer un enorme progreso como resultado. Los últimos 6 meses han visto:

  • Amplias mejoras a Batavia y VOC;
  • Un backend Android para Toga;
  • Un backend de Django para Toga, permitiendo que las aplicaciones de Toga se implementen como aplicaciones web;
  • Un backend de Winforms para Toga, permitiendo que las aplicaciones de Toga funcionen en Windows con un aspecto moderno;

Desafortunadamente, mi contrato con Jambon está llegando a su fin - lo que significa que mis contribuciones a BeeWare volverán a ser lo que mi tiempo libre permite.

Esto también significa que la tasa de progreso también se ralentizará. Todavía hay mucho por hacer: hay un montón de la librería estándar de Python para portar a Batavia y VOC; Toga necesita un mucho más amplio soporte de widgets; Colosseum necesita ser extendido para que sea compatible con el modelo de caja CSS completo, no sólo CSS3 Flexbox; y las herramientas que lo iniciaron todo - Cricket, Bugjar, Duvet, y otros - todos necesitan ser portados a Toga.

Me gustaría poder trabajar en BeeWare a tiempo completo. Sin embargo, la simple realidad es que a menos que pueda encontrar una manera de pagar por este trabajo, sólo será capaz de contribuir en mi tiempo libre.

Así que - esto es un llamado para ti - la comunidad de Python. Si estás entusiasmado con la perspectiva de tener acceso a Python en plataformas móviles, o te gustaría escribir aplicaciones en Python que tengan interfaces de usuario completamente nativas - Necesito tu ayuda.

Por sólo US $ 10 al mes, puedes unirte al proyecto BeeWare como miembro y ayudar a que este sueño se convierta en realidad. Si puedo encontrar 1000 personas en la comunidad de Python que quieran estas herramientas y estén dispuestos a apoyar financieramente su desarrollo, puedo comenzar a trabajar en BeeWare a tiempo completo. Por supuesto, este objetivo es aún más fácil si las empresas se involucran y patrocinan en los niveles más altos.

Si puedo encontrar a más de 1000 personas, entonces mucho más es posible. La opción obvia sería contratar a otros desarrolladores con experiencia para ayudar con el trabajo. La idea de tener a otros para compartir ideas durante el proceso de desarrollo es muy atractiva. Sin embargo, también podemos usar esto como una oportunidad para hacer un bien social.

Durante algún tiempo, he tenido una oferta abierta para ser mentor a cualquiera que quiera involucrarse con la contribución de Coódigo Abierto usando el proyecto BeeWare. Sin embargo, no mucha gente ha podido tomar seriamente esta oferta, porque el tiempo requerido para tomar seriamente la oferta es prohibitivo. Me gustaría poder extender mi oferta a algo más que una relación casual de tutoría. Me gustaría poder contratar - y pagar - uno o más desarrolladores junior para el proyecto BeeWare, y enfocarme en dar esa oportunidad a personas de demografía subrepresentada.

Aún son los primeros días para BeeWare. El apoyo financiero significa un progreso más rápido. Más widgets. Mejor documentación. Más de todo lo que has visto hasta ahora de BeeWare. Si puedo encontrar financiación a tiempo completo para mí -o mejor aún, para mí y para un equipo pequeño-, no tengo dudas de que la suite BeeWare se convertirá en una alternativa viable para proyectos comerciales en muy poco tiempo. Lo mejor de todo, seremos capaces de hacer esto sin tener que renunciar a los ideales del movimiento de código abierto.

Estoy emocionado por lo que le depara el futuro a BeeWare. Espero que nos acompañes en este viaje.

(Y si tu estás pensando en registrarte, y vienes a PyCon US en Portland este mes de mayo, déjame dejar una pista suave ... inscríbete ahora. Vale la pena #cryptic)

Ven al sprint con nosotros en PyCon US 2017

Publicado por Katie McLaughlin en 1 February 2017

Los boletos para PyCon US 2017 han sido regalados. ¡Esperamos ver a todos los que lleguen a la conferencia en el stand 103!

¿Quieres ir al @PyCon, no puede permitírselo? @PyBeeWare tiene 2 entradas para regalar. Envía un correo electrónico a contact@beeware.org y cuéntanos por qué quiere estar allí!

— PyBee (@PyBeeWare) 30 e Enero, 2017

PyCon US 2017 se está llevando cabo en Portland, Oregon del 17 al 25 de mayo, y está destinado a ser otra increíble conferencia.

Por segundo año consecutivo, el equipo BeeWare estará en el sitio con un stand en el salón de exhibiciones, junto con otros proyectos de Código Abierto del mundo Python.

Con este stand, tenemos dos entradas para la conferencia. Esto incluye:

  • acceso a la recepción de apertura
  • 3 días de conferencias, salón de exposiciones/feria de trabajo
  • desayunos, pausas, almuerzos y bolsa de swag

La cosa es que tanto Russell como yo, ya nos hemos registrado.

Por lo tanto, queremos darte un boleto.

Sí a ti.

Si tu puedes llegar a Portland en los días de la conferencia, queremos darte nuestro boleto gratis.

¿Qué queremos a cambio?

Sólo un poco de tu tiempo.

El equipo Bee estará ayudando al personal de nuestro stand, pero también nos gustaría ver (y dar!) charlas, así que ayudarnos mientras estamos corriendo fuera del puesto sería encantador. (Además, y estoy segura de que Russell estaría de acuerdo, sólo ayudando en la cabina te ganas una moneda)

Además, nos encantaría que te quedaras a los famosos Sprints de código. Estos se celebran en los cuatro días posteriores al evento, mientras las personas se encuentran aun en la ciudad. Tomaremos café, almorzaremos y tendremos acceso a una habitación llena de mesas, sillas y cantidad copiosa de tomas de corriente, y escribiremos código para los diferente proyectos. Estaremos haciendo un sprint de BeeWare donde estaremos asesorando y ayudando a los colaboradores principiantes a ganar su primera moneda brillante de desafío

¿Esto suena como algo que te interesa?

Por favor, envíanos un correo electrónico!

¡Cuéntanos acerca de tí! Quién eres, qué haces, por qué quieres ir a PyCon y lo que te interesa de Python.

Necesitamos asignar nuestras entradas con anticipación, así que envíanos un correo electrónico antes del 12 deFebrero, 2017

Si tiene alguna pregunta solo pregunta a mi o a Russell!

¡Nos encantaría verte allí! ✨

[Este artículo ha sido publicado en glasnt.com/blog]

Dinero, dinero, dinero

Publicado por Russell Keith-Magee en 10 December 2016

En PyCon AU 2015, y de nuevo en DjangoCon US 2015, di una charla titulada "Dinero, dinero, dinero: Escribiendo software, en un mundo de hombres ricos". La charla fue un resumen de los problemas relacionados con uno de los mayores problemas que veo frente a la comunidad de código abierto: cómo proporcionar los recursos que se necesitan para desarrollar y mantener el software del que nosotros, como comunidad, dependemos. Esto significa proporcionar mantenimiento y apoyo a proyectos establecidos, grandes y pequeños; sino que también proporciona un ecosistema donde las nuevas ideas pueden ser incubadas, desarrolladas y maduradas hasta que presenten alternativas atractivas o beneficios significativos sobre las ofertas de fuentes cerradas.

Han pasado casi 18 meses desde que presenté esta charla, pero el problema persiste. No he estado solo al notar y llamar la atención sobre este asunto, tampoco. Nadia Eghbal fue encargada de redactar un libro para la Fundación Ford titulado Caminos y puentes resaltando las necesidades crónicas en infraestructura que subyacen a gran parte de la economía moderna. Eric Holscher (mantenedor de Read the Docs) escribió sobre los problemas que tuvo para recaudar fondos, a pesar de que el servicio que él ofrece corresponde a una parte ampliamente utilizada - posiblemente indispensable - del ecosistema Python.

Sin embargo, a pesar de esta atención, todavía no llega a estar tan cerca de la atención que debería tener. Y es una cuestión que es de gran importancia para mí, ya que el proyecto BeeWare está buscando formas de financiar el desarrollo necesario para pasar de una "interesante demostración técnica" a una "solución técnica convincente".

Hace unos meses, se sugirió que publicara una entrada en el blog para acompañar la presentación del video. Me arrastré los pies al hacer esto, hasta que el trabajador colaborador de BeeWare y simpático chico 'Elias Dorneles' se ofreció a tomar mis notas y convertirla en una transcripción.

Así que aquí está. Dinero, Dinero, Dinero: Escribiendo software, en un mundo de hombres ricos. Si tienes alguna pregunta, desacuerdo, peticiones para presentar esto en tu conferencia, o simplemente una oferta genérica de una bolsa de dinero en efectivo, puedes contactarme en: russell@keith-magee.com.

Transcripción

Hola, soy Russell Keith-Magee, si ya has oído hablar de mí, probablemente sea por mi trabajo en el proyecto Django; He sido un miembro del equipo central durante casi 10 años, y presidente de la Fundación de Software Django desde 2011.

Uno de los grandes retos del proyecto Django - y cualquier gran proyecto para el caso - ha sido asegurar la seguridad de su desarrollo futuro.

Mi trabajo diario es como CTO y co-fundador de TradesCloud. Somos un software como servicio para los comerciantes - plomeros, electricistas, carpinteros y similares. TradesCloud depende de una serie de proyectos de código abierto - Django, Apache, memcache, muchos otros. Así que tengo un interés comercial en la continuidad de estos proyectos de código abierto - pero ciertamente no tengo los recursos para financiarlos a todos por mí mismo.

También tengo un interés declarado en los problemas de interfaces gráficas, especialmente en lo que se refiere a las herramientas de desarrollo. Tengo grandes visiones de lo que me gustaría hacer con este proyecto, y he recibido algunas grandes contribuciones de la comunidad, pero todavía es en gran medida mi propio trabajo. Mi start-up sería capaz de hacer un gran uso de estas herramientas si estuvieran maduras.

También soy un mantenedor de algunos proyectos más pequeños, como el envoltorio Python para la API Xero. Comencé el proyecto porque tenía una picazón. Pero ahora he abierto el proyecto, lo que significa que he heredado una tarea de mantenimiento. He aceptado la ayuda de un par de personas - sobre todo Matthew Schinkel y Aidan Lister, que han hecho un gran trabajo. Pero si soy honesto, la carga de mantenimiento de PyXero excede el tiempo que puedo dedicarle razonablemente.

Entonces, tengo intereses creados en el software libre. Tengo un interés como productor de un proyecto exitoso con un alto perfil; como productor de un pequeño proyecto con muchos usuarios pero poco incentivo personal; y como productor de proyectos más pequeños con casi ningún perfil pero grandes planes. Todos estos proyectos tienen diferentes necesidades de recursos, reflejando su madurez como proyectos.

También tengo intereses como consumidor de software libre, tanto en términos de software en el que confío para desarrollar mis propios proyectos, como en términos de mi interés comercial en el mantenimiento a largo plazo de herramientas y plataformas. Necesito estos proyectos para seguir desarrollándose, sobrevivir y prosperar.

Sobre la base de mi experiencia, me gustaría hacer una audaz afirmación:

A falta de otras limitaciones, dados recursos equivalentes, el enfoque de software libre produce resultados de ingeniería mucho mayores que el enfoque de código cerrado.

La frase clave es "dado recursos equivalentes". La mayoría de los proyectos de software libre no se desarrollan usando nada cercano a recursos "equivalentes".

En algunos casos, esto es una bendición disfrazada - sin importar el proyecto, tener escasos recursos es un excelente crisol para quemar lo innecesario y dejar sólo el metal base. Pero no siempre es una bendición.

El camino moral alto está lleno de cadáveres de nuestros aliados

Hable con cualquier desarrollador de software libre prominente, y entre las historias de éxito, también escuchará algunos problemas consistentes - que tienen grandes ideas y grandes planes, pero no hay tiempo para ejecutarlas; que están a punto de quemarse debido a las presiones de mantener su proyecto; o que han tenido otra discusión de lista de correo con alguien que no entiende por qué no dejo todo para ayudarles a solucionar su problema. Y hay muchos ejemplos.

OpenSSL es el software que maneja prácticamente todas las conexiones "seguras" en Internet, y sin embargo, solo hasta el descubrimiento de Heartbleed -una vulnerabilidad crítica que envió a Internet en un remolino - pudo encontrar financiación para pagar a los mantenedores.

Otro ejemplo - GnuPG - Werner Koch casi se declaró en bancarrota tratando de apoyar a GPG - un proyecto que muchos otros dependen de la confianza en su proceso de lanzamiento. Fue rescatado, en la puerta de las muerte, por la iniciativa Infraestructura principal de la fundación linux.

Estos son ejemplos que terminaron con fondos; pero no todos los finales felices.

Tomemos el ejemplo de Capistrano. Herramienta de gestión de configuración muy popular alrededor de 2007-8, mantenido por Jamis Buck. En 2008, citando el agotamiento y el mantenimiento general, él renunció a apoyar a Windows, diciendo que "Windows puede ser el gorila de 800 libras en la habitación, pero no es mi gorila, y no está en mi habitación". Este fue un movimiento increíblemente impopular; pero incluso con esa reducción, Jamis se quemó en 2009, abandonando Capistrano, y una serie de otros proyectos, sin mantenedores.

La cosa es - que esta es una comunidad que tiene un montón de dinero en efectivo. En el gran esquema de cosas, el desarrollo de software es una industria bien financiada. Si las empresas pueden encontrar dinero para mesas de futbolín y bolas de bolas meditativas, deben ser capaces de encontrar recursos para ayudar a mantener el software en el que han basado su éxito. Y si estás en el extremo receptor del problema - un desarrollador de software libre - puede ser realmente frustrante.

Para mí, esta es la gran pregunta sin respuesta del movimiento del software libre: cómo reconciliar la discrepancia entre la clara demanda de un producto de software y la capacidad de convertir esa demanda en el tiempo y los recursos necesarios para atender esa demanda.

Software libre: Sueño vs Realidad

Aunque la teoría dice que cualquier persona puede contribuir a un proyecto de software libre, en realidad, cada proyecto de cualquier significado tiene líderes. En el nivel más básico, es quien tiene el "bit de commit". Y usted necesita ese liderazgo, especialmente cuando se trata de algo relacionado con el diseño. La mordaza corriente es que un camello es un caballo diseñado por comité. Las peores API que tratamos diariamente son las que fueron diseñadas por comité. Necesitas a alguien con gusto corriendo el espectáculo.

Pero hay un problema más grande - la extensión del compromiso que los usuarios tienen con un proyecto. Aquí hay un experimento para probar mi punto. Estamos en una habitación llena de usuarios de Python. Django es un proyecto de software libre.

  • ¿Quién en esta sala ha encontrado un error en Django, o tiene una pequeña cosa que les gustaría ver arreglada en la API de Django?
  • ¿Quién ha convertido esa pequeña cosa un informe de error de Django?
  • ¿Quién ha enviado un parche a Django para esa arreglo?
  • De aquellos, quienes han tenido ese parche emergido?

Note

Cuando esto se hace delante de una audiencia en vivo, en cada pregunta, hay menos gente levantando sus manos

Productos vs Proyectos

Entonces, ¿qué está pasando aquí? Bueno, refleja 2 maneras diferentes de mirar un pedazo de software - proyectos y productos. Y es una cuestión de perspectiva personal - mi proyecto puede ser su producto, y viceversa.

Cuando veo algún código como un proyecto, es un cuerpo de código en el que estoy contribuyendo a un objetivo mayor. Estoy dispuesto a gastar recursos enfocados en las necesidades de otras personas con la esperanza de que sus necesidades ayudarán a mejorar el proyecto como un todo. Estoy dispuesto a hacer esto porque obtengo ganancias personales, como un perfil público mejorado; o si la herramienta está muy cerca de mi trabajo; o donde sé que puedo hacer una contribución sustantiva.

Pero cuanto más lejos me alejo de mi "trabajo", y cuanto más difícil es hacer una contribución, menos inclinado estoy a querer contribuir al proyecto. La mayoría de las veces, es un producto que estoy usando, con las verrugas y todo. Si un producto tiene errores, trabajaré alrededor de ellos, o encontraré una alternativa, en vez de navegar por el proceso de contribución y contribuir con un parche.

En el caso de un producto, las libertades proporcionadas por el software libre son un poco como la libertad de expresión - es una libertad que definitivamente quiero, es reconfortante saber que está ahí, pero no paso todos los días asegurándome de explotar plenamente esas libertades. Hay personas que lo hacen - manifestantes, defensores de posiciones sociales controvertidas - y un día, dadas las circunstancias adecuadas, podría unirme y ayudarles. Pero la mayoría de las veces, sólo quiero ser pragmático, y seguir con la vida.

Esta dicotomía entre la teoría y la práctica es también la razón por la que comentarios como "Parches bienvenidos" se hacen en las listas de correo de software libre. Por un lado, es completamente correcto. Cualquiera puede contribuir, y en la mayoría de los proyectos los parches son bienvenidos. Pero la mayoría de la gente no mira un nuevo proyecto de código abierto como una oportunidad para participar y contribuir. La mayoría de la gente sólo quiere usar el maldito software.

Y se puede argumentar que es porque la gente se está centrando en la interpretación equivocada de "libre", y no han "capturado el espíritu del software libre". Lo cual es 100% cierto, pero totalmente contraproducente como una posición. Cualquier persona que ha hecho cualquier trabajo de diseño UX sabe que si los usuarios están cometiendo un error consistentemente, culpar al usuario no te lleva a ninguna parte. Usted estaba a cargo de lo que el usuario experimentó, y cometieron el "error" debido a una desconexión cognitiva fundamental.

E incluso si todo el mundo obtuvo el mensaje correcto - vamos a ser realistas - no funcionaría de todos modos. El mítico hombre-mes nos mostró que no podemos entregar un proyecto más rápidamente o mejor, arrojando más personas en él. 9 mujeres no pueden hacer un bebé en 1 mes - un proyecto no sólo necesita recursos - que necesita los recursos adecuados, en las cantidades adecuadas. Y en última instancia, eso significa que los proyectos deben encontrar una manera de obtener los recursos que necesitan para ser autosostenibles.

Por lo tanto, eso significa que si queremos que el software libre se mantenga y mantenga bien, necesitamos encontrar una manera de financiar su mantenimiento.

Valor de uso vs Valor de venta

Hace 18 años, Eric S Raymond publicó un ensayo titulado "La Catedral y el Bazar". Este ensayo catalizó el inicio del movimiento de código abierto - una redefinición del "software libre" para dejar claro que la apertura, no el precio, era la propiedad importante. Lo que no es tan bien recordado es que "La Catedral y el Bazar" no es el único ensayo escrito por Raymond en ese momento. Publicó otros 2 ensayos poco después - "Homesteading the Noosphere", sobre la organización social y las motivaciones detrás de los proyectos de software libre, y "The Magic Cauldron", sobre la economía del software libre.

Una de las distinciones clave que Raymond destaca en ese ensayo es la diferencia entre el valor de uso y el valor de venta.

El valor de venta de un producto es su valor como un producto vendible - literalmente, por lo que usted lo vende.

El valor de uso de un producto es su valor económico como herramienta, como multiplicador de productividad. Este es el beneficio económico que el usuario obtendrá del producto.

Lo importante es que los dos no están necesariamente conectados. En un entorno de fabricación tradicional, el foco está en el valor de venta, ya que por lo general está vinculado al costo de fabricación - el costo de las piezas y los materiales.

Pero la mayoría del software no se produce para el valor de la venta - es en casa el software producido para el valor de uso. En el caso del software libre, el valor de "venta" para el software libre es 0. Pero eso no significa que no hay valor de uso, y el problema es averiguar cómo explotar el valor de uso que existe dentro de una organización como un canal de monetización.

¿Entonces cuales son tus opciones?

Bueno, puedes vender mercancía. Y aunque esto es relativamente fácil de hacer, seamos honestos - no vas a financiar un imperio de software vendiendo camisetas.

Puede hacer que los usuarios paguen por la documentación. Escribe un libro, y haz que los usuarios lo paguen.

Desafortunadamente, el pequeño secreto sucio de la escena de la escritura de la tecnología es que nadie se vuelve rico escribiendo libros de tecnología. Son recursos increíblemente valiosos para la comunidad, son ideales para rellenar tu currículum, pero no son grandes como flujo de ingresos.

Un área que si paga bien es la de entrenamiento. Los empleadores están dispuestos a pagar mucho dinero por los cursos de capacitación; si usted puede juntar un taller intensivo de 3 días, usted puede venderlo una y otra vez.

Puede producir su oferta. El código fuente sigue siendo gratuito, pero un instalador simple y fácil de usar cuesta dinero. Esto funciona muy bien cuando cuando lo que tienes es un producto claramente identificable - como una interfaz gráfica de desarrollo - IDE.

Un modelo específico de generar un producto es Software como servicio - SaaS - dar el código de forma gratuita, pero pagar por la conveniencia de tener a alguien más para administrarlo por usted. Cualquier software de código abierto de la web es un buen ejemplo de esto - puede instalar el software en sus propios servidores, pero honestamente, a menos que tenga una razón, usted utiliza la solución alojada de alguien más y deja que ellos cuiden sus servidores por usted.

Pero, SaaS sólo es viable si se puede ofrecer como un servicio - lo que significa que es realmente sólo viable para la web. Y, como las tecnologías como docker comercializan el despliegue, es posible que incluso este flujo de ingresos se evapore.

Entonces, ¿qué más se puede vender?

Usted puede vender el acceso a los desarrolladores. Si eres el mantenedor de un proyecto, estás en la mejor posición para brindarle soporte o depurar problemas complejos, lo que significa que estás en una posición privilegiada para vender soporte y consultoría. Honza Král <https://twitter.com/honzakral> de ElasticSearch llama a esto el modelo de negocio "Ghostbusters" - "¿A quién vas a llamar?"

Puede vender el acceso al software. Trolltech hizo esto con Qt; Riverbank todavía hace con los enlaces de PyQt. La biblioteca en sí es GPL - pero si quieres usarla en un proyecto de código cerrado, puedes hacerlo, por un alto cargo. Esto tiene la ventaja de que obliga a los intereses comerciales a pagar por lo que están utilizando; pero también desincentiva el uso comercial a pequeña escala - si estoy escribiendo una nueva herramienta, y me veo obligado a elegir entre el código abierto de mi herramienta o un precio de $ 1000, probablemente elija un juego de herramientas diferente.

También puede entrar en el negocio de proporcionar certificaciones y garantías - código de auditoría para garantizar la calidad o compatibilidad, proporcionando garantías sobre el arreglo de errores, y certificar que las personas son expertos en el uso del producto. Esta es una parte importante de los modelos de negocio de RedHat, los paquetes de auditoría, asegurándose de que todos interactúan como se esperaba, asegurando que las actualizaciones de seguridad están disponibles y cumplen con los mismos estándares y certificando a los administradores del sistema.

Este es un conjunto de productos que atrae a la "empresa" de gama alta de la ciudad - y es un segmento lucrativo del mercado. Pero esos clientes tienden a sólo necesitar estas garantías para ciertos tipos de software - en términos generales, software "aburrido". Su sistema operativo, sus base de datos - son piezas de software que necesitan ser sólidas en una empresa. Su barra de herramientas de depuración - no tanto, a menos que tal vez sean ofrecidas como parte de un conjunto/paquete de herramientas.

Socavar tu propuesta de valor

Otro problema con muchas de estas fuentes de ingresos es que si se ejecuta bien su proyecto, muchos de ellos se descartan - o por lo menos se ven severamente reducidas.

Si haces algo realmente fácil de usar, acabas de eliminar la necesidad de libros y cursos de formación, o, por lo menos, movido el terreno a cursos "avanzados", que son más difíciles de escribir y tienen un público más pequeño.

Django vio esto de primera mano - la documentación de Django era reconocida por lo buena desde una temprana etapa, y como resultado, era muy difícil conseguir que los editores aceptaran proyectos de libros de Django - porque la documentación era demasiado buena y estaba socavando el mercado para libros. Se ha tardado mucho tiempo, y sobre todo la auto-publicación, para obtener buenos libros Django disponibles para la venta.

Si usted tiene una lista de correo del proyecto, donde la comunidad responde a las preguntas de forma gratuita, y es una lista de correo saludable y sensible ... ¿por qué pagaría por el apoyo?

Si su software está bien diseñado, es modular, y esas interfaces están bien documentadas, y necesito una modificación - ¿por qué no acabo de escribir el modulo yo mismo?

Ahora, Ok - estoy exagerando. Hay razones legítimas para pagar por el apoyo o para traer un consultor incluso si las interfaces están limpias y bien documentadas. Pero mi punto es que cuanto mejor haces un trabajo como ingeniero de software libre, se hace más difícil hacer el caso de negocio para tu flujo de ingresos, porque la propuesta de valor se vuelve menos obvia.

Y si no está socavando directamente su propuesta de valor, todavía puede socavarle indirectamente, porque cuanto más tiempo gasta dinero, menos gasta haciendo lo que el dinero paga. Administrar un programa de certificación lleva tiempo. Escribir y ofrecer cursos de capacitación toma tiempo. La consultoría puede ser lucrativa, pero desarrollar un pipeline de ventas lleva tiempo. Y si usted está consultando, usted necesita cerciorarse de que el pipeline de las ventas esté lleno, que significa que usted va a errar en el lado de tomar más trabajo que menos ... que significa que usted acaba de cerrar la puerta en el el tiempo que tiene disponible para trabajar en código abierto.

También debe tener cuidado de que en la venta de su caso de negocio, no socave su proyecto principal. Si cada pregunta difícil en la lista de correo se responde con "Podemos responder por una tarifa", va a sonar como un shill.

Si un proyecto dice que necesita dinero para asegurarse de que nos mantenemos al tanto de los problemas de seguridad ... usted tiene que ser muy cuidadoso cómo lo dice, porque la interpretación fácil es "bueno, el proyecto debe ser inseguro, porque no están en la parte superior de la seguridad ahora ".

Una cuestión de escala

También hay una cuestión de escala. Python, Django - estos son grandes proyectos con grandes comunidades. Hacer un caso de negocio para Python o Django no es demasiado difícil. No trivial, pero posible. Pero ser el mantenedor de un proyecto más pequeño - como, digamos, Django Debug Toolbar - se espera seriamente que escriban y vendan un libro sobre Debug Toolbar? ¿O capacitación y certificación en su uso?

Los proyectos más pequeños no son menos importantes para la vitalidad del ecosistema general de Django, pero estos proyectos no tienen las mismas oportunidades para la recaudación de fondos que los proyectos más grandes.

También es importante darse cuenta de que no todos los productos tienen todas estas oportunidades de ingresos. Un IDE puede volverse un producto más fácil de mercadear; una librería de desarrollado probablemente no puede. Diferentes proyectos necesitarán diferentes mezclas de flujos de ingresos.

¿Tienes que vender algo?

Ok - pero podemos hacer esto sin vender nada en absoluto?

El software libre se deriva de un imperativo moral - así que podemos financiar el desarrollo a través del altruismo y el patrocinio? Bueno, es más difícil, pero hay pruebas de que se puede hacer.

Crowdfunding y recompensas

Una opción que ha visto mucha actividad recientemente es crowdfunding. Plataformas como Kickstarter e Indiegogo proporcionan un camino a un grupo de personas para lanzar y contribuir a un objetivo.

La comunidad de Django tiene un par de ejemplos de proyectos de crowdfunding muy exitosos, cada uno levantando decenas de miles de dólares (Django Migrations, Multiple Template engines, django.contrib.postgres, Django Rest Framework). Pero - si le preguntas a las personas que hicieron estos proyectos, no hicieron dinero en estos proyectos. La cantidad de tiempo de ingeniería que se invirtió en estos proyectos superó (con creces) el dinero recaudado.

Otra idea que se escucha regularmente es la idea de recompensas de la resolución de problemas (Bug Bounties) - la asignación de un precio para resolver un error específico. Esto es realmente sólo otra forma de crowdfunding - ¿Quieres arreglar un error específico o implementar una nueva característica? Contribuye con el dinero. Si tu realmente lo deseas - contribuye más. Y eventualmente alguien tomará el cebo y arreglará el error o implementará la característica.

Es un modelo atractivo - pero también tiene problemas - más notablemente, quién recibe el pago. ¿Pagas por líneas de código escrito? Esto ignora la contribución de los revisores del código. ¿Qué tan importante es escribir código comparado con revisar código o con encontrar un error?

Pero el mayor problema que veo con los enfoques de crowdfunding es que están en conflicto con el establecimiento de un ingreso laboral. Si te estás contratando a ti mismo, cuanto más corto sea el compromiso, mayor será tu tarifa por hora. Esta es una cobertura contra el desempleo al final del contrato. Si estás organizando un Kickstarter, es mejor tener un objetivo pequeño, claramente definido y claramente alcanzable. Así que lo puedes hacer en un mes o dos de trabajo.

Esto significa que necesitas para cobrar tu tasa de corto plazo con el fin de garantizar los ingresos a largo plazo. Pero también es de tu interés tener un objetivo de recaudación de fondos bajo, para que la campaña sea realmente exitosa. Si es demasiado alto, podría asustar a posibles patrocinadores. También significa que la comunidad paga una prima por cualquier característica nueva, que no es el mejor uso de los ya escasos recursos comunitarios.

Becas, Patreon

Ok - si deseas ingresos a largo plazo, es necesario mirar a compromisos a más largo plazo. Eso significa que deja de buscar fondos para proyectos específicos y empiezas a buscar financiación para la persona, con becas.

Estoy incluyendo a Patreon en esa lista porque es efectivamente "crowdsourced patronage". No estás pagando por una cosa específica - estás pagando para que "sigas haciendo lo que estás haciendo".

En los últimos 10 meses, Django ha estado utilizando este modelo. Contratamos a un desarrollador a finales del año pasado. El desarrollador - cuyo nombre es Tim Graham - es responsable de mantener las ruedas del proyecto engrasadas.

Desde un punto de vista técnico, este ha sido un éxito rotundo. Tim ha hecho un gran trabajo con el manejador de tiquetes (Issue Tracker), y los tiempos de respuesta en las revisiones de Pull Requests son más bajos.

La parte difícil ha sido recaudar el dinero para pagarle.

Hicimos una recaudación de fondos al principio del año específicamente para financiar al becario; esa campaña ha recaudado algo más de $ 50.000. Eso no es un cantidad pequeño de dinero - pero no es tampoco mucho cuando estás hablando de un empleado de tiempo completo. Vamos a necesitar hacer otra recaudación de fondos muy pronto si queremos que la beca continue.

Casi todos están de acuerdo en que ha sido dinero bien gastado, pero convertirlo en donaciones ha sido un trabajo duro.

Patrocinio corporativo

Otro otro enfoque para recaudar dinero es abrazar al diablo, e ir a los proveedores comerciales. Los intereses comerciales tienen dinero, así que ¿por qué no deberían pagar por ello? Esto puede ser muy exitoso bajo ciertas circunstancias - pero tienes que ser capaz de hacer un caso de negocio para el propietario corporativo.

OpenStack es un gran ejemplo de esto. ¿Por qué Rackspace, HP, Redhat, Ubuntu están interesados en OpenStack? Porque venden productos que se benefician de la mercantilización del entorno de alojamiento. Al hacer que sea barato y fácil de controlar las implementaciones en la nube, aumentan el tamaño del mercado para el alojamiento en la nube, lo que significa más dinero para su negocio principal - ya sea directamente (como Rackspace), o indirectamente (como RedHat, porque los servidores en la nube todavía necesitan sistemas operativos).

Node.js es financiado por Joyent por razones similares - Joyent está haciendo una apuesta a largo plazo, en la que si es más fácil desarrollar el software para la web, más gente escribirá dicho software , aumentando el mercado para los servicios de Joyent.

Sin embargo, Node.js es también un recordatorio sobre los problemas asociados a los intereses corporativos - ¿qué sucede cuando la comunidad y el patrocinador corporativo no están de acuerdo con la dirección del proyecto? Bueno, obtienes divisiones del proyecto, como la división io.js. El dinero corporativo puede corromper. Debemos tener cuidado de que la gobernanza del proyecto sea independiente de la fuente de financiamiento.

Tener un solo "jefe" corporativo también pone el proyecto en riesgo si ese "jefe" corporativo pierde interés. Django estaba originalmente bajo el ala de la World Company. Eventualmente, ese interés disminuyó, y el apoyo corporativo se acabó.

Venture funding

La otra respuesta corporativa que se escucha es ir a buscar dinero/capital de riesgo/inversión. Y hay algunos ejemplos de gente haciendo esto. Meteor, por ejemplo, está financiando su desarrollo con dinero de un fondo de riesgo. Tienen mucho dinero para contratar a ingenieros, diseñadores - lo que necesiten.

¿Qué me pone nervioso sobre este modelo? Hemos estado aquí antes. ¿Quién recuerda aquí a Eazel? Para aquellos que no recuerdan, a finales de los 90, Eazel fue una empresa dot-com fundada para desarrollar el gestor de archivos Nautilus. Y, tenemos 2 años de código abierto. Y entonces estalló la burbuja, y la compañía se estropeó. Ahora, lo bueno es que todavía tenemos el código. Pero sería mejor tener el código en desarrollo activo.

Desarrollo de una cultura de patrocinadores

Y otra vez, toda esta discusión está sucediendo en una industria donde las valuaciones del mil millones de dólares están dando vueltas alrededor.

Grandes partes de nuestra industria, se basan en software libre - pero los que tienen más capacidad para contribuir, en muchos casos, no están contribuyendo.

Algunos lo están haciendo - hay algunas empresas que dan grandes cantidades de nuevo a las comunidades de código abierto. Pero también hay un montón de empresas que no retribuyen.

E incluso muchos aquellos que si retribuyen dan la ayuda que son capaces de dar, que no es necesariamente la ayuda que se necesita. La Django Software Foundation recibe regularmente ofertas de alojamiento gratuito o subvencionado de proveedores de alojamiento. Y no me malinterpreten - esto es genial, e increíblemente útil.

Pero lo que realmente necesitamos es alguien en la nómina para revisar los errores. Anteriormente en el ciclo de vida de Django, necesitábamos que la gente escribiera nuevas grandes características. Estamos en una constante necesidad de diseñadores gráficos, artistas, escritores de tecnología. Necesitamos personas que sepan cómo hacer administración de sistemas, y el alcance comunitario. Y no necesitamos 400 personas donando 1 hora; necesitamos 10 personas muy específicas donando 40 horas.

Cuando ocurre un desastre, organizaciones como la Cruz Roja piden donaciones. Y por lo general dicen "por favor darnos dinero, no latas de comida o mantas". ¿La razón? El dinero puede comprar lo que se necesita. No puedes controlar lo que la gente dona, e incluso si la gente dona exactamente lo que se necesita, hay una enorme tarea logística de inventariar lo que se ha donado, y llevarlo donde se necesita.

Los proyectos de software libre son iguales - requieren recursos. Algunas empresas donan en especie, y eso es genial, pero rara vez es lo que se necesita, y es fácil distraerse averiguando qué hacer con todos los recursos que se han donado, pero no tienen un uso inmediato.

Y tristemente, al igual que con las organizaciones benéficas - muchas empresas no donan en absoluto. Y no estoy diciendo que estas compañías están siendo deliberadamente maliciosas en no financiar el código abierto - si algo, nosotros como comunidad les hemos fallado porque no les hemos ayudado a ayudarnos.

Lo más importante, no tenemos un mecanismo para que sea fácil gastar dinero, y sea fácil recibir dinero. El estado actual de las cosas demuestra claramente que no es suficiente que haya mucho dinero en una comunidad - hay que crear el mecanismo para que donar ese dinero sea tan obvio y sin fisuras como sea posible, y hay que tener a alguien para direccionar ese dinero donde se necesita.

Una comunidad modelo que creo que hace esto realmente bien es la comunidad de Wordpress. Wordpress es software GPL. Hay libros, videos, blogs sobre cómo escribir plugins y temas de Wordpress, lo mismo que para cualquier comunidad de software de código abierto. Pero también hay libros, videos y blogs sobre cómo hacer un negocio escribiendo plugins y temas de Wordpress. Wordpress es GPL. Y por lo tanto, también lo son todos los complementos. Tienen una tienda donde puedes comprar complementos (y obtener los gratuitos), e instalarlos fácilmente en tu instancia de Wordpress.

El ecosistema de Wordpress ha aceptado fundamentalmente el hecho de que el dinero necesita ser parte de la ecuación, y al hacerlo han creado una industria que se autofinancia, y esto, diría yo, es una de las razones principales del éxito de Wordpress como una plataforma.

Una propuesta polémica

En ese sentido, me gustaría hacer una propuesta polémica.

¿Qué pasaría si PyPI fuese una fuente de ingresos? ¿Qué sucedería si, al registrar una aplicación con PyPI, pudieras especificar un precio: por instalación, o por versión, o por aplicación o por mes. Cuando hago "pip install", el coste se agrega a mi cuenta PyPI, y recibo un cargo mensual en mi tarjeta de crédito; y que se pasa de nuevo a los proyectos de desarrollo.

Si hemos de creer en las estadísticas de PyPI, Django se descarga de PyPI más de 1 millón de veces al mes. Si hubiese un peaje de 10 centavos de dólar en cada descarga, eso recaudarían $ 100,000 por mes - suficiente para pagar 10 desarrolladores a tiempo completo bien pagos, o una cantidad considerable de diversidad, alcance, DjangoGirls y apoyo de la comunidad.

También podrías aprovechar la información de la dependencias de PyPi para pagar un porcentaje hacia estos proyectos. Si está escribiendo un proyecto que depende de otro, podría optar por pasar parte de sus ingresos hacia este proyecto. O bien, solicitar que los flujos proporcionen un "peaje".

Y luego están las mayores dependencias de todos: PyPI y Python. Si PyPI tomara un pequeño recorte de los ingresos recaudados, eso podría ayudar a pagar por el desarrollo y mantenimiento de PyPI - y potencialmente Python también.

También puede tomar parte del dinero recaudado y ponerlo en un grupo de desarrollo, por lo que si hay un nuevo proyecto que necesita un poco de efectivo de arranque para empezar, o un proyecto establecido que necesita alguna ayuda para una gran tarea (como una actualización de Python 3 ), la comunidad en su conjunto puede fácilmente canalizar dinero hacia ese proyecto.

¿Qué pasa con las personas que no tienen dinero? Bueno, podemos ofrecer pases gratis. ¿Estás en un evento de DjangoGirls? Utilice este código promocional para obtener acceso gratuito.

Todavía puede regalar su software sin costo alguno. Y todavía es software libre - todavía estás entregando Python, así que todavía vas a obtener la fuente. Probablemente podrías incluso hacer que el proceso de inscripción sea completamente opcional. Todo lo que estaríamos haciendo es pavimentar el mecanismo - lo que facilita recaudar un peaje en la forma fácil en que utilizas un software.

No estoy diciendo que nada de esto sea fácil de implementar. Completamente aparte de cualquier reto técnico y solucionando los detalles, es un cambio filosófico grande para la comunidad, y ése es un asunto mucho más grande. Pero esta pregunta filosófica sobre el dinero es una discusión que nosotros, como comunidad necesitamos tener.

Lo que tenemos aquí es una tragedia de los comunes. Todo el mundo está de acuerdo en que este software es bueno. Todo el mundo sabe que el software debe mantenerse. Pero, ¿por qué una empresa individual debería asumir la carga económica de financiar el mantenimiento cuando sus competidores obtienen el beneficio de forma gratuita?

Aprende de la MPAA y RIAA: Haz que sea fácil hacer lo correcto

Para mí, la lección clave de la industria de la música y el cine de los últimos 20 años es que si usted hace más fácil hacer lo correcto, la gente hará lo correcto. Si tu puedes hacer simple y sin problemas para una gran empresa deslizar tu tarjeta de crédito y que te cobren $ 100 al mes por usar todo este software de código abierto que se ha desarrollado, lo harán. Sí, la gente hará trampa. No te preocupes por ello, siempre y cuando la trampa no sea más fácil que hacer lo correcto.

La mayor razón por la cual esto no está sucediendo ahora es que no es obvio lo que es lo "correcto". Podrías donar a la DSF o PSF ... pero es un poco complicado de organizar, y no está claro a dónde va el dinero ... Podrías inscribirte para soportar a algunos Patreons, o inscribirte para un programa de la recompensas ... pero no todo el mundo está allí, y los que están no ganan realmente lo suficiente para ganarse la vida, y no quiero sólo aportar dinero para cerveza.

Entonces, ¿qué vamos a hacer? La respuesta corta es "No sé". Probablemente no existe una solución mágica. Me gustaría pensar que un canal de monetización en PyPI funcionaría, pero seré el primero en admitir que podría no ser la respuesta, o que puede haber problemas que no he previsto.

Pero creo firmemente que esta conversación sobre el dinero es una conversación que tenemos que tener. El software libre como movimiento tiene más de 30 años de antigüedad. El código abierto casi 20. Hemos superado los obstáculos técnicos. Incluso estamos conquistados los obstáculos políticos. Ahora es el momento de abordar la forma en que hacemos de esta una industria sostenible a largo plazo, no sólo los intereses comerciales que se aprovechan de la ingenuidad de una corriente de voluntarios de ojos azules.

En realidad voy a tomar otra posición ligeramente controversial, y no voy a tomar preguntas en este punto, por dos razones - en primer lugar, porque este tipo de charla son un imán para "Tengo un comentario, no una pregunta"; y también porque este no es un tema donde yo tenga las respuestas.

Esta es una discusión que necesitamos tener como comunidad - y estoy ansioso por tener esa discusión - no sólo en esta etapa.

Hola sitio web

Publicado por Russell Keith-Magee en 4 July 2016

¡Bienvenido al nuevo sitio web del proyecto BeeWare!

El sitio web original BeeWare fue escrito hace un par de años, cuando BeeWare era todavía un proyecto altamente experimental. El viejo sitio web era un asunto de una sola página, con proyectos individuales que mantenían su propia identidad web. Con el tiempo, el número de colaboradores ha crecido, el número de subproyectos ha crecido y el número de miembros del equipo central se ha triplicado.

A medida que el proyecto BeeWare crecía en complejidad, el antiguo sitio web ya no estaba a la altura de las necesidades del proyecto, por lo que el equipo central se tomó un tiempo fuera de trabajar en BeeWare, y reescribió el sitio.

El nuevo sitio web utiliza Lektor, una herramienta generadora de sitios web estáticos escrita por el conocido Pythonista`Armin Ronacher`_. Esto nos permite seguir hospedando el sitio web con Github Pages, pero nos da la flexibilidad para definir una base de datos clara para los muchos tipos de contenido que necesitamos administrar.

Aunque estamos lanzando el sitio hoy, no está completo. Todavía hay contenido que necesita ser escrito, y el estilo que necesita ser arreglado. Sin embargo, creemos que el nuevo sitio es mejor que el anterior, y por lo tanto no vale la pena retrasar el lanzamiento por más tiempo.

Esto también le da a la comunidad BeeWare una gran oportunidad de contribuir. Si encuentras algo que falta en el sitio, o algo que crees que podría ser mejor expresado o diseñado mejor, todo el sitio está disponible en GitHub. Haz un Fork (Bifurca) el repositorio, realiza el cambio que piensas que se necesita y envía un Pull Request (contra la rama Lektor - no master). Todas las contribuciones son bienvenidas, y al igual que con todas las contribuciones de BeeWare, las contribuciones del sitio web hacen que el solicitante sea elegible para recibir una exclusiva Modena de Desafío de BeeWare.

Esperamos que disfrutes del nuevo sitio; si tienes algún comentario, nos lo puedes hacer saber con un ticket o en nuestro servidor Discord.

Consejos para convertirse en un colaborador principal

Publicado por Russell Keith-Magee en 5 June 2016

En PyCon EE.UU. 2016, Philip James se convirtió en un colaborador principal de BeeWare!

Escribió algunos de sus pensamientos sobre el proceso en su artículo Consejos para convertirse en un colaborador principal.

Katie McLaughlin, consiguió su compromiso en DjangoCon Europa 2016, seguido con una publicación propia, describiendo su camino a convertirse en una colaboradora principal.

Para aquellos que aspiran a convertirse en colaboradores de proyectos de código abierto, es útil escuchar cómo otros llegaron allí.

RSS Feed

Archivo