- El proyecto WiX Toolset introdujo la política de Open Source Maintenance Fee (costo de mantenimiento de código abierto) para asegurar su sostenibilidad a largo plazo
- El código fuente se ofrece gratis según la licencia, pero la política de costo de mantenimiento aplica a la mayoría de las acciones, como registrar issues, escribir comentarios y descargar nuevas releases
- En particular, si se usa este proyecto para generar ingresos, es obligatorio pagar este costo de mantenimiento
- El pago puede realizarse convirtiéndose en GitHub Sponsor
- Organización pequeña (menos de 20 personas): $10/mo
- Organización mediana (20-100 personas): $40/mo
- Organización grande (más de 100 personas): $60/mo
- Los detalles de la política pueden consultarse en el sitio oficial de Open Source Maintenance Fee
2 comentarios
En la práctica, es igual a RHEL.
Opiniones de Hacker News
Me gusta esta innovación. La idea básica es que nadie quiere que esto se vuelva de código cerrado, el código está disponible libremente para todos y cualquiera puede usarlo como quiera, porque el costo adicional de distribuir el código es prácticamente cero. Pero los mantenedores no quieren dárselo gratis a las empresas como si fuera caridad. Su tiempo es limitado, así que es natural que quieran algún retorno si están contribuyendo a una actividad que genera ingresos. No pasa nada si este esquema no se puede hacer cumplir perfectamente. Ahora los mantenedores tienen la libertad de responder a los reclamos con un “si quieren que nos importe, paguen”. Las empresas que pagan obtienen cierto nivel de soporte, y los usuarios comunes siguen teniendo la misma experiencia. Solo las empresas que ignoren esta advertencia enfrentan las consecuencias, y es especialmente útil cuando apelan con cosas como “muchos usuarios importantes se verán afectados”. Si de verdad lo necesitan, entonces corresponde pagar. Ahora que aumentan el código, los reportes, etc. generados por IA, me parece una solución bastante limpia para un problema frecuente en el código abierto
Tengo sentimientos encontrados sobre esta parte. No soy usuario de WiX, y esto es una opinión general sobre el tema. Nadie puede ser obligado a mantener un proyecto de código abierto. Todas las correcciones son voluntarias. Ninguna empresa puede obligar a aceptar un PR o a hacer determinado trabajo. Los desarrolladores de FOSS a menudo se estresan, pero si no hay incentivo económico, simplemente pueden decir que no. Puede haber quejas, pero no existe obligación de arreglar el problema. El modelo de patrocinio al final se siente como convertir FOSS en un modelo de negocio. Entonces deja de ser FOSS. La esencia de FOSS es que cualquiera pueda copiarlo, modificarlo y convertirlo en un negocio. Eso es algo que aceptaron en la mayoría de las licencias. Puede que mi opinión no sea popular, pero no creo que haga falta estallar de ira por este tema
Quisiera señalar dos lados negativos de esta política. Primero, podría dificultar atraer más contribuidores. Puede aparecer una estructura de dos niveles entre contribuidores pagados y no pagados. Puede surgir resentimiento del tipo “yo hago correcciones de bugs gratis mientras otros ganan dinero”. Segundo, en el momento en que entra dinero, la relación se vuelve más transaccional. Si se recibió dinero, aparecen exigencias y trabajo asociado. Claro, el modelo de voluntariado también tiene problemas de sostenibilidad
No me parece tan innovador. Es básicamente pasar de dar el producto gratis a venderlo. O sea, se siente como operar un negocio común y corriente
Creo que sería mejor permitir que cualquiera pague por una funcionalidad o soporte que quiera, y mantener el código como cerrado hasta cierto umbral. Ese umbral podría tomar meses o años según el interés y los ingresos. Al final se liberaría como código abierto. Si no, todos terminan esperando que otra persona pague. Claro, habría que diseñarlo bien para evitar demasiados forks, pero parece totalmente viable
Yo entendía que varios proyectos de código abierto ya aplicaban algo así. Pensaba que el caso del consultor que mantiene Busybox era de ese tipo, aunque quizá entendí mal la situación
Esto no tiene nada que ver con Wix, el creador de sitios web; aquí se está hablando de WiX Toolset
“El toolkit que te permite crear las experiencias de instalación de Windows más potentes. ¡Open source desde 2004!”
Gracias. Al principio pensé que era Wix. Wix sí hace muchas librerías de React Native de muy buena calidad
Hace unos meses me topé con esta política por casualidad mientras evaluaba un instalador para mi proyecto de código abierto. Si el código fuente está bajo una licencia de la OSI, no tengo problema con vender binarios. Pero me hizo ruido esta frase en el README: "Para la sostenibilidad a largo plazo de este proyecto, el uso de WiX Toolset requiere una cuota de mantenimiento de open source. El código fuente se ofrece libremente bajo licencia, pero todas las demás funciones, como crear y comentar issues, participar en discusiones y descargar releases, también están sujetas a la cuota de mantenimiento. En otras palabras, el uso con fines de lucro requiere una cuota de mantenimiento". Como es un concepto difícil de explicar en una frase corta, puedo interpretarlo de buena fe. Pero resumirlo como “si es para ganar dinero, paga” puede generar más malentendidos. Según la licencia MS-RL, si lo compilas tú mismo y lo usas, no hay restricciones aunque sea con fines comerciales, así que esto se siente como una especie de táctica para “asustar” y convertir a los usuarios comerciales en patrocinadores. Entiendo las dificultades que viven los mantenedores de código abierto, pero este enfoque no me resultó éticamente convincente. Por eso descarté usar WiX, aun cuando no soy un usuario comercial
Esto es una declaración clara de que no quieren dar soporte gratis a usuarios comerciales. Dijiste que la explicación no es clara, pero la frase que citaste dice explícitamente que “el código fuente puede usarse libremente bajo la licencia”
Las startups o pequeñas empresas con poco presupuesto toman proyectos open source, los compilan ellas mismas, los convierten en artefactos de distribución y los mantienen por su cuenta. Cuando alcanzan cierto tamaño, tiene más valor pagar por soporte oficial que gestione todo ese proceso. Esta política busca empujar a las empresas a pagar soporte oficial cuando no quieren asumir el riesgo de soporte directo que implica usar solo binarios open source
De verdad no es fácil explicar esta idea en una sola frase corta. Las expectativas sobre los proyectos open source son demasiado distintas. Si tienes sugerencias sobre cómo mejorar el texto, con gusto las escucho
Como yo lo veo, si representas a una organización con fines de lucro y quieres pedir algo, entonces para conversar tienes que pagar. Si la comunicación busca un beneficio comercial, entra en el esquema de pago
Si lees los comentarios del issue en GitHub, el equipo parece bastante razonable. Según entiendo, solo quieren dinero cuando realmente hay ingresos de por medio. Si de verdad eres un desarrollador solo o un producto muy temprano, probablemente no les importe tanto. También tienen una página de patrocinios
Esto va sobre la página de https://opensourcemaintenancefee.org/ en sí. Solo se ve bien en modo oscuro; en modo claro casi no se puede leer. Tampoco se puede abrir un issue en el repositorio. Tal vez el autor vea este comentario aquí (poco probable)
¡Ah, con razón había que pagar la cuota de mantenimiento para abrir un issue! Es broma
Oh, sí era un problema serio. Ya quedó corregido gracias a un contribuidor random
Si fuera el equipo legal de mi empresa, al ver una EULA (acuerdo de licencia de usuario final) como esta, en vez de pagarte simplemente nos diría que dejemos de usar la herramienta de inmediato. Creo que la mayoría de las empresas reaccionaría así. Quizá desde la perspectiva del mantenedor eso esté bien, pero yo siempre he defendido que si quieres mantener open source y a la vez restringir el uso comercial, entonces pongas AGPL. AGPL es casi veneno para las empresas. Ninguna empresa en la que he trabajado permitiría usar código AGPL en un producto comercial. Después de eso, puedes vender una licencia comercial de pago
Los proyectos de código abierto muchas veces funcionan como caridad y bajo un sistema de honor. Los contribuidores obtienen reconocimiento, y las empresas que lo usan obtienen ganancias. Es un modelo donde ambos lados ganan y que indirectamente también beneficia a la humanidad. Personalmente —quizá de manera ingenua— creo que esa caridad podría revertirse de forma más directa y clara a toda la humanidad. Por ejemplo, cuando un proyecto se publique bajo una licencia abierta, las empresas que ganen dinero usándolo podrían donar alrededor de 1% de sus ingresos a un fondo global, algo como “Decentralized Universal Kindness Income” (DUKI). Las empresas que lideran las contribuciones podrían recibir el privilegio de quedar exentas de toda o parte de la donación, de modo que mantengan cierta ventaja incluso si otras grandes empresas usan eso para competir (por razones como esa Redis también cambió su licencia). Los contribuidores recibirían más reconocimiento y prestigio a nivel mundial, y las empresas donantes no solo podrían aprovechar ampliamente los recursos open source, sino también ganar reputación desde el lado del marketing. Podría ser mucho más competitivo que una empresa enfocada solo en maximizar ganancias. A esto yo lo llamo la “licencia DUKI”. La idea central es agregar una sola condición de reparto de beneficios a la licencia MIT. Lamentablemente no tengo la influencia para hacer marketing de esto, y no sé si los mantenedores y fundadores clave que lideran el ecosistema open source lo aceptarían
Dice algo como: “El código fuente se ofrece libremente bajo licencia, pero crear issues, comentar, participar en discusiones y descargar releases, así como todas las demás actividades, requieren cumplir con la cuota de mantenimiento”, y me sorprendió que incluso incluyera las descargas de releases. No soy abogado, pero me parece que eso entra en conflicto con la propia licencia. En concreto con la parte que dice que “cada contribuidor otorga una licencia de copyright no exclusiva, mundial y libre de regalías para distribuir, usar y modificar la obra y sus derivados”. Así solo se genera más confusión y, en la práctica, obliga a automatizar la creación de forks que espejen las releases. De hecho, ya ofrecen esos GitHub Actions en el repo
La cláusula de la licencia que citas solo significa que tienes derecho a copiar, modificar (o compilar) y distribuir ese código. No existe la obligación de distribuir también los binarios. De hecho, este tipo de esquema es bastante común. Las licencias open source casi siempre aplican solo al código fuente. También es válida la observación de que eso incentiva forks o espejos automáticos, pero para los desarrolladores de software clonar y compilar por cuenta propia siempre ha sido algo fácil y natural. Antes también era normal copiar el código fuente directamente y usarlo, y por eso FOSS se volvió popular. Más que un “escape”, eso es la esencia misma de FOSS
Totalmente de acuerdo. Pero en la realidad no ocurrió así. La mayoría de las empresas consideró que nuestra cuota de mantenimiento era lo suficientemente razonable y prefirió recibir soporte oficial sin asumir el riesgo de mantener o forkar el proyecto
Tal vez no entiendo el “hype” de este tema. La licencia no cambia, ¿solo significa que no te dan soporte si no pagas la cuota de mantenimiento? Si alguien reporta una vulnerabilidad, ¿WiX solo la parchea si quien la reporta pagó antes la cuota? ¿O si un usuario corporativo propone una buena idea de funcionalidad, simplemente la ignoran hasta que pague? Suena demasiado obvio. Los autores open source siempre deciden qué PRs aceptar y a qué issues prestar atención. Siempre pudieron cobrar por soporte. No veo qué tiene de innovador la cuota de mantenimiento. No lo digo para atacar. Me parece genial hacer herramientas bajo una licencia open source, y también es normal recibir financiamiento. Si un contribuidor se siente desplazado, siempre puede hacer un fork. No es un concepto nuevo. Claro, hacer un fork requiere bastante dinero y recursos humanos. Incluso una empresa del tamaño de Amazon seguramente preferiría pagarles a los autores originales para captar su atención. Hay casos como LibreOffice, io.js, OpenTofu y neovim. Si logras una bifurcación bien hecha como LibreCAD, también tiene mérito. io.js ayudó a que nodejs fuera más saludable, así que tuvo sentido. Ese es el poder de la comunidad y una gran ventaja del código abierto. Cualquiera puede contribuir con código, documentación, dinero, ideas, etc. Gracias a WiX por participar en la comunidad de esta manera, y ojalá les siga yendo bien
El instalador de WiX es una herramienta compleja y difícil de entender. La usaba solo porque era gratis. Si fuera de pago, usaría un producto comercial más sencillo y con mejor soporte. Rob Mensching había intentado monetizar con servicios de consultoría y soporte de $5,000 al año, pero supongo que eso no fue suficiente
Decir que “lo único valioso era que era gratis” puede aplicar para quienes solo querían una herramienta de instalación sin gastar dinero. Pero el mayor valor de WiX no está simplemente en ser gratis. WiX Toolset permite aprovechar el potencial de Windows Installer de una manera que ninguna otra herramienta de instalación ofrece. Si no necesitabas funciones complejas, claro que resultaba incómodo y con muchas carencias. Pero para problemas de instalación difíciles, esas funciones afiladas eran justamente necesarias. Sobre “monetizar con $5,000 al año en consultoría”, yo no gano simplemente $5,000 al año por WiX como tal. Ofrezco servicios personalizados de alto valor a través del programa “WiX Developer Direct”, aprovechando el conocimiento acumulado por mi equipo y por mí durante décadas sobre paquetes de instalación, además de las herramientas avanzadas de FireGiant. Damos office hours mensuales, garantías SLA, revisiones de código anuales, herramientas avanzadas y otros servicios de gama alta que los clientes valoran mucho. No es que eso no fuera suficiente, pero al ver recientemente el caso de XZ Utils, sentí de verdad lo grave que es el problema de sostenibilidad del código abierto. Así que quise buscar alguna salida, y Open Source Maintenance Fee me parece una solución bastante buena para proyectos como el mío. WiX Toolset es, por ahora, el primero en adoptar este modelo, así que también está sirviendo como campo de pruebas para experimentar, cometer errores y ver cómo funciona realmente. Hasta ahora, ha marchado muy bien
En realidad, WiX es una herramienta para escribir directamente en XML la estructura interna de base de datos que usa Windows Installer. MSI y Windows Installer son tan complejos que esa reputación existe, pero no es tanto culpa de WiX sino de que el formato MSI ya de por sí se parece a un “laberinto complejo” desde el origen
Yo pensaba que la licencia le pertenecía a MS, pero según el texto completo de la licencia, dice que “las releases binarias publicadas en GitHub y NuGet.org están sujetas a una EULA que exige el pago de la cuota de mantenimiento”. No soy abogado, pero entonces, si uno compila y distribuye por su cuenta, ¿no sería posible esquivar la cuota de mantenimiento? ¿Y hasta repartir esas compilaciones gratis?
El código no pertenece a Microsoft, sino a la .NET Foundation (la historia es larga). Compilar por tu cuenta para esquivar la cuota de mantenimiento está totalmente permitido en la práctica. Ahora solo te toca a ti hacerte responsable de 500 mil líneas de código. ¡Disfruta tu verdadero fork!
Según el README del repo, el código fuente es open source, pero las funciones de issues y releases del repo requieren pagar la cuota de mantenimiento