¿En quién confías para manejar mejor los proyectos de código abierto, corporaciones u organizaciones sin fines de lucro?

Creo que su mejor opción es aplicar la confianza en un proyecto por proyecto en lugar de una capa genérica de confianza o desconfianza en el estado con o sin fines de lucro de la organización que ejecuta el proyecto. Cada proyecto se gestiona de la manera en que lo es por una razón. Algunos prosperan mejor en fundaciones, algunos administrados por la corporación. Publico proyectos en ambos canales. Muchos comienzan en github.com/yahoo, algunos de ellos reciben contribuciones para Apache Software Foundation, OpenStack Foundation u otras fundaciones, y otros no. En su mayor parte, el éxito y la “confiabilidad” del proyecto se basan en las personas que más se preocupan por el proyecto, y menos en el modelo de gobernanza. Pero esa es una afirmación que haría en el código que publico, no en todo el código fuente corporativo abierto. Además, es posible que no compre mi reclamo.

Cuando una empresa publica un proyecto de código abierto, ciertamente puede tomar el código, bifurcarlo, modificarlo, usarlo, etc. Por lo tanto, está prácticamente desbloqueado y es de uso gratuito. El problema es que los encargados del proyecto son los guardianes de lo que se incluye en el repositorio oficial. Sus contribuciones pueden o no ser aceptadas en el flujo ascendente, y no depende de usted a menos que sea un responsable. En algunos casos, las compañías permitirán que los que no son empleados se comprometan, en algunos casos pueden no permitir esto. Depende un poco de la intención de la compañía con el proyecto en primer lugar. Si su intención es construir un negocio de licencias en torno al código, querrán controlar el proyecto. Esto significa que puede bifurcar el código, pero no puede obligarlos a tomar sus cambios.

Mientras que cuando una empresa dona el código a una fundación de código abierto (sin fines de lucro), el modelo de gobierno de la fundación se hace cargo. Una vez más, puede bifurcar el código y hacer lo que quiera con él. Pero si desea incluir sus cambios en el repositorio oficial, tendrá que convencer a un confirmador de que sus cambios son buenos. En este caso, los encargados son personas a quienes el proyecto ha confiado el código, y como equipo es probable que trabajen para diferentes compañías. En muchos casos no es tan diferente. Sin embargo, en algunos casos, es posible que su jefe no quiera que contribuya a un proyecto que ejecuta su competidor, pero está bien contribuir al proyecto si está en una base. Entonces, si quiero lograr que contribuyas a mi proyecto, y sé que a tu jefe no le gusto, tendría un incentivo para poner mi proyecto en una base y obtener tus contribuciones de esa manera.

En su mayor parte, los encargados de código abierto han intentado operar de manera independiente de la firma en su cheque de pago. Las personas que realizan cambios en los proyectos más importantes en código abierto, lo hacen por la creencia profesional de que esos son los cambios de ingeniería correctos que deben realizarse, y por lo tanto, en los casos ideales, no debería importar tanto. Sin embargo, en realidad, o al menos en algunos casos, existe la percepción de que los detalles de empleo de un responsable son un factor. Por esta razón, algunas compañías contribuyen con su código a una fundación de código abierto para quitar esa objeción de la mesa y poner el proyecto en manos neutrales de las personas en la fundación (muchos de los cuales trabajan en corporaciones de todos modos).

Por lo tanto, realmente depende más del proyecto. Para algunos, la fundación proporciona un excelente lugar para promover y fomentar el desarrollo abierto y neutral. Para otros proyectos, no es tan importante.

Creo que depende de la empresa y el proyecto. Algunas compañías tienen mejores registros que otras. A menudo, una empresa puede lanzar un proyecto, pero luego dejar que una organización independiente sin fines de lucro lo administre para permitir que otros (incluidas otras corporaciones) contribuyan.

Creo que la Fundación Eclipse fue una de esas organizaciones independientes sin fines de lucro: fue creada por IBM para administrar Eclipse.

Las organizaciones sin fines de lucro detrás del código abierto incluyen el Proyecto Apache y Mozilla .

Sin embargo, algunas compañías han demostrado ser buenos administradores de varios proyectos de código abierto. Algunos que vienen a la mente son Apple y Google, y los antiguos Sun Microsystems, así como numerosas distribuciones comerciales de Linux.

Una empresa con la que las personas de código abierto tendrían un problema real sería Oracle: han cerrado una gran cantidad de proyectos de código abierto de Sun.

No importa mucho, siempre y cuando la gente siga la ética del software libre.

Para ser concretos, GCC es un proyecto FSF, y la mayoría de sus contribuyentes son profesionales a quienes las corporaciones les pagan por trabajar a tiempo completo o medio tiempo (que aceptan pagarle a su chico para que trabaje en software libre con una ética de software libre). Muchos otros proyectos de software libre (kernel de Linux, Firefox, …) son similares (con algunas empresas que pagan para que trabajen en él).

No ‘confío’ en las corporaciones con fines de lucro por defecto. Siempre trato de ser consciente de cómo me usarán como producto. Y si estoy dispuesto a aceptar eso.

No ‘confío’ en las organizaciones sin fines de lucro, porque a menudo pienso que carecen de una cierta actitud profesional. Especialmente cuando está dirigido por voluntarios.

En cuanto a sus preguntas. No creo que haya una diferencia real en la confiabilidad. Si alguno de ellos va a una dirección no deseada, siempre hay otra parte que tomará la fuente y comenzará su propia sucursal.

Por ejemplo, mira OpenOffice de Oracle vs LibreOffice.