Argumentos para ir a la fuente abierta


9

Pasé mi tiempo de inactividad en el trabajo este verano escribiendo un marco para facilitar mi trabajo diario. En resumen, carga un xml con marcado que define los bloques del sitio, su contenido y el estilo de estos (muy similar a html), maneja la carga de activos y tal.

Ahora estoy bastante satisfecho con la forma en que esto está ocurriendo, y he estado ansioso por lanzar algunos de mis códigos para uso público (y escrutinio). También estoy razonablemente seguro de que llena un vacío para la construcción rápida y sencilla de los sitios (o partes de ellos).

¿Cuáles serían los mejores argumentos para convencer a mi jefe/compañeros de trabajo de que publicar esto bajo una licencia de código abierto es una buena idea?

5

La OSI tiene una serie de buenos recursos con http://www.opensource.org/advocacy/case_for_business.php probablemente siendo el más relevante para usted.

Hay un montón de proyectos de código abierto y cuando popular, la mejor ventaja en mi opinión es tener correcciones de errores y mejoras aportadas de nuevo en el proyecto. Tiende a desarrollar únicamente las características necesarias para el caso de uso en su trabajo (existen excepciones por supuesto) y es bueno que otras personas trabajen en otras áreas del proyecto.

Dicho esto, las personas generalmente solo lo harán si tienen un uso para el proyecto ellos mismos y la sensibilización puede ser tan difícil como comercializar un proyecto comercial; probablemente solo unas pocas personas lo usen habiendo tropezado con el proyecto a través de una oscura búsqueda en Google!

Como tal, aunque hay muchas ventajas orientadas al desarrollo, incluso si no hay muchos (o ninguno) usuarios reales, se ve muy bien desde la perspectiva empresarial/empresarial que su organización respalde la publicación de proyectos bajo licencias de fuente abierta. Esto muestra cosas buenas para los empleados potenciales sobre la apertura de la organización.

Por lo tanto, si bien solo obtiene las grandes ventajas de código abierto con la báscula, existen otras menos obvias que comienzan a funcionar inmediatamente, es decir, crear un buen nombre para su empresa.


5
  • popularidad
  • contribución
  • Comunidad
  • El escrutinio público
  • nos veremos obligados a adherirse a las normas. (Que a su vez mejorar el producto)
  • de buena voluntad de

1

Creo que el quid de la razón de que el código abierto es una buena idea se debe a que la piscina junto a un recurso grande de personas por lo general trabaja de forma gratuita para crear algo útil y emocionante. Un sitio como Digg está generando más y mejores historias de las que el personal @ Slashdot podría porque la comunidad lo maneja. De la misma manera, un proyecto de código abierto podría hacer más que un equipo dedicado SI tiene un proyecto lo suficientemente emocionante como para atraer la participación. También hay muchos otros beneficios, como mejorar tu código y aprender en el camino.


1

Publicidad: Puede ejemplificar con el marco Ruby on Rails.

Fue creado para hacer las aplicaciones web 37signals. Abren fuentes, luego alguien vino y construyó twitter. ¡Imagina la publicidad que tuvieron de eso!


1

La contribución más importante de hacer que un producto sea de código abierto es que se vuelve instantáneamente más accesible para las personas.

También ayuda a las personas que están realmente interesadas en su trabajo a ver lo que ha hecho, hacer sugerencias para mejorarlo e incluso ayudarlo a veces. Además, contribuye con algo al vasto repositorio de software de código abierto y ayuda a la comunidad a crecer y aprender a su manera.


5

Las ventajas para su empresa son pocas. Todas las razones que otros han dado suponen un grado de popularidad que es ... poco probable. La mayoría de las personas de negocios se darán cuenta de que sin tener que pensar mucho al respecto, no encontrarán publicidad, apalancamiento, escrutinio público o mejora de herramientas, razón suficiente para tomar el "riesgo" de publicarlo como código abierto.

Dicho esto, este es el mejor contra el argumento de "riesgo" para que una empresa libere una herramienta interna como código abierto: si no es parte de su competencia central y se toma cuidado para que no suck recursos de la compañía (o exponer secretos/infraestructura de la compañía), realmente no hay riesgo. La compañía no pierde nada y gana un potencial para la ganancia —, incluso si ese potencial es pequeño.


4

He lanzado un par de paquetes desarrollados por la empresa como de código abierto. El tono básico:

Es más rentable o ventajosa para la empresa de liberar esta:

  • este paquete no es parte de nuestro negocio principal. No estamos regalando la receta a la salsa secreta.
  • obtendremos un cuerpo más grande de personas ejercitando el código, encontrando errores y de ese modo aumentando la calidad del código.
  • es probable que podamos encontrar algunas personas que contribuyan con el código de las características que puedan serle de utilidad.
  • buena herramienta de reclutamiento, parte 1: los buenos programadores se sentirán atraídos por nuestra organización ilustrada y amigable con los desarrolladores.
  • buena herramienta de reclutamiento, parte 2: podemos ver algunas personas en acción a quienes podríamos interesar reclutar.

Aquí hay dos paquetes independientes que se publicaron a través de este enfoque: