open-source - traduccion - open source ventajas y desventajas
¿Por qué su empresa no contribuye con el código abierto? (16)
¿Qué pasa con una empresa que no tiene desarrolladores? Tal vez no son un grupo de software, y están utilizando OSS para ahorrar dinero, al estilo de un grupo basado en la web que usa LAMP, pero nunca modifica ninguno de los componentes.
Contribuir al código abierto puede tener muchas formas: trabajar con seguimiento de incidencias, parches, desarrollo posterior, documentación, financiación, etc. Suponiendo que su empresa utilice proyectos de código abierto, ¿cuál es la razón más importante por la que no contribuye a la comunidad? ?
Contribuimos con parches y correcciones de errores.
Sin embargo, en general no iniciamos nuevos proyectos. Realmente no tenemos los gastos generales para apoyar tal proyecto. Desafortunadamente, no puede simplemente publicar un tarball en un sitio web y esperar que extraños agreguen características a su código. Se necesita trabajo para construir una comunidad.
Contribuimos de nuevo al código abierto en la única situación en la que sería una locura pura no hacerlo. Cuando arreglamos errores, siempre nos aseguramos de que sean empujados hacia arriba.
Como digo, sería una locura no hacer eso y tener la alternativa de mantener un tenedor.
En mi opinión, el mayor problema es que la mayoría de las empresas están haciendo desarrollo para proyectos. Si un proyecto desarrolla algo que vale la pena publicar como código abierto, el compromiso de mantenimiento solo puede darse hasta que el proyecto finalice. Después de eso, no hay más recursos disponibles para nuevos desarrollos, soporte de la comunidad, corrección de errores, etc. Esto generalmente significa una muerte lenta para el "producto" de código abierto.
Además, algunas empresas están ansiosas por ver las relaciones públicas por lo que publican, y esto generalmente significa pasar por todos los procesos de publicaciones. Esto es algo que en general abruma a los ingenieros y programadores.
Lógica de negocios.
Si comienzo a construir un proyecto donde utilizo el código fuente para un proyecto de FLOSS en lugar de solo una biblioteca, entonces necesito desarrollarme teniendo en cuenta dos factores: los cambios en el código para que haga lo que quiero y los aspectos que se le permitiría lanzar al mundo.
En general, no es tan difícil hacer esto, pero si los plazos son ajustados, entonces no voy a perder el tiempo eliminando nuestras extensiones propietarias.
La empresa para la que trabajo produce software propietario y nuestro software es altamente especializado y es nuestra principal ventaja competitiva sobre todas las demás empresas de nuestra industria. No puedo imaginar por qué Open Source no es algo que alentamos.
Lo hacemos, estamos fundados en código abierto, pero creo que somos especiales;)
De todos modos, esto no es como una respuesta verdadera a su pregunta, sino una respuesta a las "preguntas" en las otras respuestas, supongo. Hay muchas formas de contribuir al código abierto. Claro que puedes contribuir con el código , pero la otra cosa que puedes aportar es dinero donando. Jeff Atwood (uno de los fundadores de SO) hizo esto hace un par de meses en un sistema de sistema wiki que conozco.
Cuando trabajé para mi startup anterior, le dimos a WatiN $ 300. Esta es una contribución, y probablemente sea una contribución mejor (y al menos más económica) que tener uno de nuestros codificadores tratando de descubrir el modelo de código y el estándar de codificación, etc., detrás de WatiN y luego corregir algunos errores y proporcionar un parche.
Pero la TERCERA manera de "contribuir" a su proyecto de código abierto favorito es más sutil, pero a menudo es la mejor manera definitiva de contribuir, que es brindarle atención, como acabo de hacer con WatiN a través de ese enlace.
Estoy dispuesto a recibir $ 100 por que alguien que lea esta respuesta revise el enlace a WatiN, lea sobre el proyecto y descárguelo y comience a usarlo en sus propias suites de prueba. ¡Y deberían hacerlo ya que WatiN es un gran proyecto de código abierto y Jeroen el tipo detrás de él es realmente útil!
Eso también está contribuyendo. ¡Ayudando a su proyecto de código abierto favorito a llamar la atención diciéndoles a los demás lo genial que es!
Los desarrolladores nos cuestan dinero. El código abierto no nos cuesta dinero. Por lo tanto, si empezamos a dar tiempo a los desarrolladores para trabajar en software de código abierto, el código abierto pierde su ventaja competitiva y también podemos llamar a MS, ya que al menos podemos definir cuánto dinero nos cuesta por adelantado.
Tiempo del desarrollador / recursos del equipo, y la "idoneidad" de contribuir código de vuelta.
Lo que significa que, si realizamos modificaciones en un proyecto OSS, a veces los cambios no son necesariamente apropiados para contribuir de nuevo al proyecto. Esto puede deberse a los derechos de propiedad intelectual, pero en realidad, la razón más común es que simplemente no anticipamos que otras personas requieran tales modificaciones específicas al software en la forma en que lo hemos hecho. En términos generales, dichos parches no tienen sentido para enviarlos al equipo que desarrolla el proyecto OSS.
En otros casos, estos cambios podrían enviarse como un parche a los desarrolladores del proyecto OSS, pero esto requeriría limpiar / reformatear el código, separar los datos de la compañía privada del parche, etc. Por lo general, si estamos usando software OSS en Al principio, no nos importan esas cosas, porque la mayoría del software OSS está algo sucio en términos de calidad del código (es decir, no hay casos de prueba, estándares de codificación, documentación, etc.). Por lo tanto, el tiempo requerido para limpiar nuestras correcciones sucias a un código ya sucio suele ser más tiempo de lo que queremos gastar para el factor de altruismo aquí.
Dicho esto, he trabajado en empresas que contribuyeron de nuevo a proyectos de OSS cuando fue necesario, y aquellos que no hicieron contribuciones monetarias a algunos proyectos de OSS o distribuciones.
En nuestro caso, producimos software extremadamente personalizado para las circunstancias específicas de una oficina estatal. Por eso, nuestro software no tiene utilidad para nadie más. Al ser una oficina estatal, tampoco tenemos la libertad de "donar" tiempo o dinero.
En teoría, podríamos abrir algunos de nuestros documentos, pero nuevamente la falta de demanda lo convertiría en nada más que un gesto vacío.
Los programadores nos cuestan dinero, pero contribuir al código abierto no genera un centavo de ingresos.
Obteniéndolo legalmente. En serio, incluso como un gran contribuyente al software de código abierto, como una gran empresa, la burocracia es un asesino. (Hope Legal no lea esto :)
Nuestra gerencia no entiende la fuente abierta. No estoy seguro de que nuestro jefe comprenda que estamos usando OSS para el desarrollo.
En la última vez, nuestro jefe quería lanzar algunas cosas como código abierto, pero el paquete debería incluirse con un contrato de soporte, por lo que no creo que realmente sepa lo que significa Open-Source.
Entonces, en una frase: no devolvemos el código abierto porque nuestra administración no entiende el concepto detrás del código abierto.
Actualización: ahora tenemos un producto OS, pero nuestra administración no lo entiende hasta hoy. En realidad, lo hicimos, porque algunos de nuestros clientes hablaban de código abierto (y realmente quería decir gratis ).
¡Contribuimos y estamos muy orgullosos de ello!
http://hg.nuxeo.org/opensocial se trata de nuestra contribución a Nuxeo de Leroy Merlin.
Ok, no genero un centavo de ingresos, pero realmente no cuesta más. Y cuando las personas contribuyan a nuestro código (parches, correcciones de errores, extensiones), este será un código que no nos costará nada.
Además, nuestra contribución se incluye ahora en la función principal de Nuxeo, por lo que ahora nos beneficiaremos de la integración certificada por nuestro proveedor de nuestro código.
A pesar de que le devolvemos el código abierto como parches de código, y la liberación de software de código abierto, puedo entender por qué otras compañías no lo hacen. Porque "no tiene ningún beneficio" :)
No estoy seguro de que contribuir con dinero sea la mejor manera de ayudar al software OpenSource. Cuando Jeff Atwood aportó unos $ 5000 a un proyecto de OpenSource, el responsable del proyecto se mostró agradecido ... pero si recuerdo bien, no estaba muy seguro de qué hacer con él.
Los desarrolladores que contribuyen a los proyectos de OpenSource no reciben un pago por hacerlo. Lo hacen porque les gusta, quieren probarse algo, etc., pero el dinero nunca es la causa, ya que saben que probablemente no ganen ni un centavo. En el mejor de los casos, pueden atraer la atención que luego puede generar ingresos (piense en nuevos empleadores, más tráfico en su blog, etc.)
Ahora, no digo que no se debe contribuir, pero creo que las contribuciones monetarias no son tan eficientes como se podría pensar, las empresas tienden a pensar que su modelo (capitalista) se extiende naturalmente a todo lo que les rodea:
En mi opinión, un proyecto OpenSource se beneficia más de parches / informes de errores que de contribuciones monetarias directas, siendo las excepciones el sitio web / repositorio del proyecto o las reuniones de financiación para los principales contribuyentes para que puedan debatir cara a cara cuando sea necesario. pero aunque esto cuesta dinero, esto no está dando directamente dinero.