open source - source - Pagar a los miembros del proyecto de código abierto por correcciones de errores y características

open source ventajas y desventajas (1)

En el trabajo, tuvimos buena suerte al contratar mantenedores de código abierto para mejorar las bibliotecas que usamos.

Aquí hay algunos proyectos que hemos hecho en el pasado:

Necesitábamos integrar Quake 2 con wxWidgets. Contratamos a Vadim Zeitlin, uno de los principales contribuyentes de wxWidgets. En menos de 4 días, construyó un widget wxQuake2 adaptando la versión de Quake 2 para Windows.
Más tarde, necesitamos acceso portátil a mapas de bits en bruto. Así que contratamos a Vadim nuevamente y trabajamos con él para producir una nueva API de mapa de bits sin formato. Esto implicó un poco de trabajo de diseño, pero nos gustó mucho la API resultante, y la usamos hasta el día de hoy.
En una fecha posterior, contratamos a otro de los colaboradores principales para mejorar el soporte de accesibilidad de wxWidgets. Al final resultó que, al final, no usamos este código por varias razones técnicas. Pero otras personas han mejorado este código desde entonces, y esperamos usarlo algún día.

En otras palabras, contratar a los mantenedores de código abierto es muy parecido a contratar a cualquier otro tipo de contratista. Pero algunas cosas también son un poco diferentes. Aquí hay algunos consejos basados en nuestras experiencias:

Tendrás más suerte si deseas mejorar un proyecto existente y lanzar los cambios como código abierto.
En general, desea contratar a miembros del equipo central. Tienen los mejores registros de seguimiento, son los más productivos y tienen la mejor oportunidad de fusionar sus cambios en el proceso.
Desea obtener sus cambios combinados en sentido ascendente. Si no lo hace, mantendrá una bifurcación local, que es un dolor de cabeza.
Antes de contratar, hacer un poco de investigación. ¿Quién trabaja en las características que te interesan? ¿Es alguien con quien te gustaría trabajar? Lea las listas de correo y observe el historial de control de versiones, y seleccione algunas personas para acercarse.
Durante la fase de diseño, puede haber un poco de dar y recibir. Los desarrolladores están considerando la salud general del proyecto, y usted está mirando las necesidades de un negocio específico. Esto ocasionalmente ha hecho que las negociaciones sean un poco más complicadas para nosotros, pero el resultado final ha sido típicamente un mejor diseño del que habríamos elegido nosotros mismos.

Y lo más importante, no seas tímido. En cualquier proyecto de código abierto suficientemente grande, varios miembros del equipo central ya dirigirán negocios de consultoría. En proyectos de código abierto más pequeños, generalmente encontrará varios colaboradores que desean dirigir empresas de consultoría.

Y si aún no está seguro de acercarse a alguien, siempre puede preguntar: "¿Conoce a alguien que esté interesado en que le paguen por trabajar en $ FEATURE?" Si no están interesados, no los ha puesto en el lugar y es posible que le indiquen a quién debe preguntar.

En general, nos ha impresionado el profesionalismo y la productividad de los mantenedores de código abierto, y recomendaría esta ruta a otros.

Tengo un problema por resolver que creo que tomará 4 días, pero si tuviera una solicitud de función ordenada y una versión instantánea, creo que podría hacerlo en uno. Superficialmente, esto crea un presupuesto de 3 veces mi tarifa diaria para que se aplique la función de solicitud.

Así que mis preguntas son: ¿alguna vez le pagó a un miembro del proyecto de O / S para que arregle algo por usted? ¿Funcionó bien? ¿Cómo le vendió la idea a su gerente / colegas y de dónde vino el dinero?

Lo más importante, ¿cómo te fue para preguntar bien? ¿Hay una etiqueta para estas cosas? ¿Es probable que los líderes del proyecto sean receptivos a la idea?

En caso de que sea importante, el software con la función que falta es un proyecto de JBoss, el hogar del código abierto profesional, y puedo reclamar los gastos ya que soy un contratista.