Perspectivas del fundador: conclusiones de OSCON – Comercio electrónico Alemania Noticias

Después de visitar OSCON y ver cómo otras empresas se involucraban en código abierto, decidí compartir algunas de las cosas más interesantes que aprendí con la comunidad en torno a Shopsys Framework: nuestros clientes, socios, fans, empleados, asesores, consultores e inversores.

En general, OSCON probablemente ha sido una de las mejores conferencias a las que he asistido, simplemente en términos de tener acceso a los desarrolladores. ¿Dónde más puedo encontrar y hablar con los cofundadores de MySQL/MariaDB, ElasticSearch, Apache Foundation y Acquia/Drupal? Aunque terminé saltándome algunos de los talleres, me aseguré de asistir a dos días de conferencias y, a continuación, se encuentran algunos de los puntos principales que me llamaron la atención y cómo podríamos aplicarlos mejor a nuestro propio marco.

Negocios en torno al código abierto

Monty Widenius, cofundador de MySQL (que se vendió a Sun por 1.000 millones de dólares con ingresos de 70 millones de dólares) y fundador de MariaDB, recomendó utilizar una licencia de fuente comercial para algunas partes del software en lugar de confiar en un código abierto + propietario (por ejemplo, dual Licencia). La BSL significa que el código está abierto y se convierte en software libre en circunstancias específicas (por ejemplo, después de 4 años). Después de una breve charla sobre SSFW, recomendó usar la licencia MIT para nuestra plataforma y la BSL para los módulos.

Monty lo puso en perspectiva así:
Si es una empresa de servicios, necesita 100 desarrolladores trabajando para clientes por cada 10 desarrolladores trabajando en el producto. Las valoraciones de esas empresas suelen ser el doble de los ingresos. Si es una empresa de software, entonces necesita ingresos de la venta de licencias; no importa si todo su software es propietario o de código abierto y solo 1/100 de los clientes terminan pagando. Las valoraciones de estas empresas suelen tener 10x sus ingresos + Y x base de usuarios.

Por otro lado, Carolyn, la experta en propiedad intelectual y licencias que trabaja en una empresa de software canadiense (que no quiso nombrar) sospechaba bastante de BSL, ya que no está aprobado por la fundación Open Source. Ella está de acuerdo con tener la plataforma bajo licencia MIT, pero recomienda mantener los módulos como propietarios ya que tienden a incluir la “salsa secreta” de una empresa (nuestro know-how particular). También recomendó usar tarifas anuales (tanto ilimitadas como limitadas, por ejemplo, por 3 a 5 años) en lugar de solicitar una tarifa única alta. Recomendó encarecidamente incluir los ingresos de las licencias en cualquier estrategia de inicio de código abierto, especialmente si tienen un mercado pequeño o de nicho. Por el contrario, un negocio de Linux de código abierto a menudo celebrado, Red Hat, tiene una gran ventaja y adopta el enfoque opuesto al marketing de nicho; en cambio, se basa en un gran ecosistema.

La incómoda licencia GPL

La licencia GPL es una de las licencias que menos gustan a sus usuarios (especialmente a los usuarios corporativos), sin embargo, es una licencia muy utilizada en proyectos comerciales de código abierto. Tiene un estricto copyleft con distribución limitada. No está claro cuál es la distribución (especialmente en términos de distribución interna dentro de las entidades corporativas). Además, GPL también causa problemas de adopción para las empresas más grandes: cada uso del código fuente de GPL debe ser aprobado por el departamento legal/IP. Por eso las empresas prefieren licencias permisivas como MIT, BSD o APL.

En resumen, los productores de software de código abierto con copyleft (GPL, OSL, AGPL, LGPL) (como MySQL, MariaDB, Magento, Oro) se benefician de estos problemas y suelen ofrecer otra licencia (como un modelo de licencia dual). Como resultado, las grandes empresas prefieren comprar una licencia comercial de un proveedor.

Las alternativas más nuevas a la licencia GPL, con menos molestias pero con copylefts estrictos, incluyen OSLv3, AGPLv3 y LGPLv3. OSLv3 tiene probablemente la definición más clara de distribución y obras derivadas. A diferencia de MIT/BSD/APL, las licencias GPL/OSL/AGPL/LGPL tienen otra ventaja para el productor: su software no se puede bifurcar y redistribuir sin publicar cambios.

Para aquellos de ustedes que no saben, Copyleft es la regla que cuando redistribuye el programa, no puede agregar restricciones que nieguen a otras personas el acceso a las libertades centrales del programa (de software libre, no en términos de dinero). Sin embargo, debe tenerse en cuenta que un programa que utiliza licencias copyleft no necesita ser publicado para caer bajo esta rúbrica. El copyleft se aplica solo al programa proporcionado y no a las modificaciones internas del software.

Pero las cosas se ponen aún más raras. El software bajo AGPL (versión modificada de GPLv3) tiene un requisito diferente: si ejecuta un programa modificado en un servidor, su servidor también debe poder descargar el código fuente correspondiente a la versión modificada que se está ejecutando. ¡Lo digo en serio! MongoDB y Shopware se encuentran entre varias empresas que actualmente utilizan esta licencia.

En una nota al margen: MariaDB usa GPLv2 porque está basado en MySQL que también usa GPLv2. Los productos adicionales (MariaDB Enterprise y MaxScale) se incluyen en BSL.

Diagrama de selección de licencia

Después de decenas de horas dedicadas a la investigación de licencias, he creado un diagrama de selección de licencia simple. Siéntase libre de usarlo para sus proyectos.

Enfoque de producto perfecto

Nunca comienzas con un producto perfecto: siempre lleva tiempo hacer que el software sea cada vez mejor y el viaje nunca termina. Como me dijo Iwo (vicepresidente de operaciones de ventas), Shopgate tenía una aplicación móvil totalmente fea y horrible en 2013 en comparación con lo que tienen hoy. Ahora Shopgate es uno de los líderes en lo que respecta a la industria de tiendas móviles.

PHP es el rey

Y, sin embargo, PHP apenas es un tema principal entre los discursos en conferencias. Tuve conversaciones con muchos desarrolladores y gerentes de proyectos (en OSCON, Shopify Unite, GenereteNY) y la mayoría me dijo que PHP es el lenguaje de programación más utilizado para back-end y núcleos de aplicaciones, especialmente en el segmento de comercio electrónico.

Mucha gente me dijo que PHP es una opción segura ya que ha estado aquí por más de 20 años y probablemente seguirá así durante las próximas décadas. Incluso en los EE. UU., la mayoría de los desarrolladores web son desarrolladores de PHP. Además, existe una mayor probabilidad de poder encontrar a alguien que pueda contratar que tenga un conocimiento avanzado de PHP, en comparación con .NET, Java o, especialmente, algunos lenguajes modernos promocionados como NodeJS, AngularJS, ReactJS, etc. Personalmente, yo Estoy firmemente convencido de que PHP es la mejor opción. Y entre los marcos PHP, Symfony y Laravel son los más conocidos y preferidos en los EE. UU. Para aplicaciones empresariales, Symfony es definitivamente la mejor opción.
A pesar de la popularidad de PHP, no hay duda de que algunos sitios de comercio electrónico modernos seguirán prefiriendo marcos JS para front-end y esto es algo a tener en cuenta al tratar con futuros clientes (la mayoría de la gente me dijo que apostarían por ReaccionarJS sobre todo).

Otros problemas en pocas palabras

  • GraphQL se destacó como una alternativa muy prometedora a REST para el enfoque de microservicios y ha sido desarrollado por Facebook. Shopify, con su admirable extensibilidad, también apuesta por GraphQL. Incluso abrieron su ejecutor de procesamiento por lotes de consultas para GraphQL (ver aquí) y hay paquetes para Symfony.
  • Elastic (anteriormente Elasticsearch) es una empresa de más de 300 empleados totalmente distribuida sin oficinas. Su principal canal de comunicación es, lo adivinaste, ¡el correo electrónico! Envían cientos de correos electrónicos todos los días, pero han desarrollado una serie de filtros para Gmail y cada nuevo empleado comienza con ese conjunto de filtros. Cada discusión sobre el producto tiene lugar en GitHub y es pública (incluso si la discusión fue por videoconferencia, la resumen), lo que ayuda a agilizar la comunicación. Usan y recomiendan planes de lanzamiento basados ​​en el tiempo programados en días determinados (versión principal cada 6 meses, versión secundaria cada 6 semanas). Buscan y contratan desarrolladores solo de la comunidad de código abierto de Elastic. Nota al margen: Elasticsearch es de código abierto bajo la licencia permisiva APL2. Los ingresos provienen principalmente de su versión Cloud As-A-Service y sus otros productos (Beats, Kibana, etc.)
  • Monty Widenius (MySQL/MariaDB) recomienda que todas las empresas de sistemas operativos lancen antes, lancen con frecuencia y cumplan sus promesas.
  • Daniel Byrnes (Software Freedom Law Center) presentó algunos casos civiles de los últimos años en los que la Corte Suprema de EE. UU. negó las demandas de los propietarios de patentes (especialmente el caso Alice y el caso Symantec). A partir de estos casos, podemos predecir que las patentes de software se volverán aún más vulnerables con el tiempo.
  • Algunas personas recomendaron investigar GraphQL y el marco Slim en nuestra discusión sobre «microservicio» del SSFW.


FLOSS vs estrategia comercial adecuada

La percepción del código abierto como un software de código abierto gratuito (FLOSS) como solía ser al principio se ha ido por completo. De todos los proyectos nuevos en los últimos años, tengo la sensación de que el código abierto juega solo una pequeña parte de su estrategia comercial. Simplificado, hay tres estrategias:

  • licencia dual/núcleo abierto: una versión del producto es de código abierto y el producto típicamente mejorado o sus partes adicionales son propietarios o tienen licencia con algunas limitaciones. – por ejemplo, Magento, OroCommerce, MariaDB, MongoDB
  • pago por computación: el producto es de código abierto y el negocio se centra en el tiempo de computación (como servicio/nube), por ejemplo, Elastic, CoreOS, Crate.io
  • empresa de servicios: el producto es de código abierto y los ingresos provienen de implementaciones, soporte, consultas, actualizaciones, etc., por ejemplo, Acquia (principal desarrollador de Drupal)

Atención de las grandes casas de software

La presencia de grandes casas de software como IBM, Oracle, DELL, Google, Microsoft, etc. fue realmente alucinante. Fueron los patrocinadores principales, pero hicieron un esfuerzo notable para ser también oradores (su enfoque no siempre da en el blanco, por supuesto). Lo hablé con algunos asistentes y me dijeron que el código abierto se considera una alternativa muy factible a cómo se crearán los productos de software en el futuro. Ya sea que lo crea o no, el código abierto está recibiendo mucha atención y está en la mira de las grandes casas de software tanto como el software como servicio o la nube. Pero también está claro que muchas casas de software no saben cómo lidiar con esta transición, por lo que podemos esperar que probablemente haya muchas adquisiciones en los próximos años.

Nota al margen: el gobierno de EE. UU. ha aprobado una ley reciente que establece que al menos el 20 % de todo el software entregado debe ser de código abierto.

Resumen

Todas las conferencias que visité esta primavera (OSCON, Generate & Shopify Unite) me brindaron mucha inspiración, me presentaron a grandes personas y nuevas oportunidades de networking, y me ayudaron a aprender mucho sobre el futuro en evolución del código abierto. Pero me encantaría saber lo que piensas. ¿Cómo percibe el código abierto y qué tendencias ha observado?

Autor: Petr Svoboda, fundador de la Marco ShopSys

Deja una respuesta

Tu dirección de correo electrónico no será publicada.