En el trabajo, hemos tenido la suerte de contratar mantenedores de código abierto para mejorar las bibliotecas que utilizamos.
Éstos son algunos de los proyectos que hemos hecho en el pasado:
- necesitábamos para integrar Quake 2 con wxWidgets. Contratamos a Vadim Zeitlin, un colaborador principal de wxWidgets. En menos de 4 días, construyó un widget wxQuake2 adaptando la versión de Windows de Quake 2.
- Más tarde, necesitábamos acceso portátil a bitmaps sin formato. Entonces volvimos a contratar a Vadim y trabajamos con él para producir una nueva API de mapa de bits sin procesar. Esto implicó un poco de trabajo de diseño, pero realmente nos gustó 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. Resultó que terminamos sin usar este código de inmediato, por varias razones técnicas. Pero otras personas han estado mejorando este código desde entonces, y esperamos usarlo algún día.
En otras palabras, la contratación de mantenedores de fuente abierta es muy similar a la contratación de cualquier otro tipo de contratista. Pero algunas cosas son un poco diferentes, también. Aquí hay algunos consejos basados en nuestras experiencias:
- Tendrá más suerte si quiere mejorar un proyecto existente y lanzar los cambios como de código abierto.
- En general, desea contratar miembros del equipo central. Tienen los mejores registros de seguimiento, son los más productivos y tienen las mejores posibilidades de conseguir que sus cambios se fusionen en sentido ascendente.
- Desea que sus cambios se fusionen en sentido ascendente. Si no lo haces, mantendrás un tenedor local, que es un dolor de cabeza.
- Antes de contratar, investigue. ¿Quién trabaja en las características que te interesan? ¿Son alguien con quien te gustaría trabajar? Lea las listas de correo y eche un vistazo al historial de control de versiones, y seleccione algunas personas para acercarse.
- Durante la fase de diseño, puede haber un poco de toma y daca. Los desarrolladores están mirando la salud más grande del proyecto, y usted está mirando las necesidades de un negocio específico. Esto ha ocasionalmente 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 hubiéramos elegido por nuestra cuenta.
Y lo más importante, no seas tímido. En cualquier proyecto de código abierto lo suficientemente grande, varios miembros del equipo central ya administrarán negocios de consultoría.En proyectos de código abierto más pequeños, generalmente encontrará varios colaboradores que desean para ejecutar negocios de consultoría.
Y si todavía duda en acercarse a alguien, siempre puede preguntar: "¿Conoces a alguien que esté interesado en que le paguen para trabajar en $ FUNCIÓN?" Si no están interesados, no los ha puesto en el lugar, y es posible que le digan a quién preguntar.
En general, nos ha impresionado la profesionalidad y la productividad de los mantenedores de código abierto, y recomendaría esta ruta a otros.
Esta es una pregunta bastante confusa. ¿Está contratado para arreglar algo y quiere subcontratarlo? ¿O simplemente ha encontrado un problema que cree que alguien más está mejor calificado para manejar? – NotMe
Tengo un problema que se puede resolver de más de una manera. Una forma sería implementar la función, pero no estoy calificado para hacer eso y no quisiera bifurcar el código. Subcontratación estaría bien, recomendar un contrato directo entre mi cliente y el hechicero abierto también está bien. –
"brujo abierto" ~ mago, mago ... genial error, también quiero contratar a un hechicero :-) – Johan