¡Hola! Mi nombre es Dmitry Pavlov, trabajo en , y también soy un comprometido y participante de PMC en Apache Ignite y colaborador en Apache Training. Recientemente hice una presentación sobre el trabajo de un comprometidor en la reunión de código abierto de Sberbank. Con el desarrollo de la comunidad de código abierto, muchas personas comenzaron a tener cada vez más preguntas: cómo convertirse en un confirmador, qué tareas realizar y cuántas líneas de código se deben escribir para obtener este rol. Cuando pensamos en los comprometidos, inmediatamente imaginamos personas omnipotentes y omniscientes con una corona en la cabeza y un volumen de “Código Limpio” en lugar de un cetro. ¿Es tan? En mi publicación, intentaré responder todas las preguntas importantes sobre los confirmadores para que puedas entender si realmente los necesitas.
Todos los recién llegados a la comunidad de código abierto piensan que nunca se convertirán en comprometidos. Después de todo, para muchos, este es un rol prestigioso que solo se puede obtener por mérito especial escribiendo una tonelada de código. Pero no es tan simple. Echemos un vistazo al confirmador desde la perspectiva de la comunidad.
¿Quién es un comprometido y por qué es necesario?
Cuando creamos un nuevo producto de código abierto, siempre permitimos a los usuarios usarlo y explorarlo, así como modificar y distribuir copias modificadas. Pero cuando se produce una distribución incontrolada de copias de software con cambios, no recibimos contribuciones al código base principal y el proyecto no se desarrolla. Aquí es donde se necesita el confirmador, que tiene derecho a cobrar las contribuciones de los usuarios al proyecto.
¿Por qué convertirse en un comprometido?
Comencemos con el hecho de que comprometerse es una ventaja para un currículum, y para los principiantes en el campo de la programación es una ventaja aún mayor, porque a menudo, cuando solicitan un trabajo, solicitan ejemplos de código.
La segunda ventaja indudable de comprometerse es la oportunidad de comunicarse con los mejores especialistas e incorporar algunas ideas interesantes del código abierto a su proyecto. Además, si conoces bien un determinado producto de código abierto, puedes conseguir un trabajo en una empresa que lo admita o lo utilice. Incluso existe la opinión de que si no participas en el código abierto, no llegarás a puestos altos en tu carrera.
Además de los beneficios en términos de carrera y empleo, comprometerse en sí mismo es placentero. Eres reconocido por la comunidad profesional, ves claramente el resultado de tu trabajo. No como en algunos desarrollos corporativos, donde a veces ni siquiera entiendes por qué mueves campos hacia adelante y hacia atrás en XML.
En las comunidades de código abierto puedes conocer a los mejores especialistas como Linus Torvalds. Pero si no eres así, no pienses que no tienes nada que hacer allí: hay tareas de diferentes niveles.
Bueno, también hay ventajas adicionales: los confirmadores de Apache, por ejemplo, reciben una licencia gratuita de IntelliJ Idea Ultimate (aunque con algunas restricciones).
¿Qué hacer para convertirse en un comprometido?
Es simple: sólo necesitas comprometerte.
Si cree que no hay tareas para usted en los proyectos, está equivocado. Simplemente únete a la comunidad que te interesa y haz lo que necesite. La Apache Software Foundation tiene una organización separada con requisitos para los comprometidos.
¿Qué problemas tendrás que resolver?
Los más variados: desde el desarrollo hasta la redacción de pruebas y documentación. Sí, sí, la contribución de los testers y documentadores de la comunidad se valora al igual que la contribución de los desarrolladores. Hay tareas no estándar, por ejemplo, ejecutar un canal de YouTube y contarles a otros usuarios cómo utiliza un producto de código abierto. Por ejemplo, la Apache Software Foundation tiene una organización separada , donde se indica qué asistencia se requiere.
¿Necesito escribir una característica importante para convertirme en un confirmador?
No. Esto no es del todo necesario. El confirmador no tiene que escribir toneladas de código. Pero si escribiste un artículo importante, será más fácil para el comité de gestión del proyecto evaluarte. Contribuir a la comunidad no se trata solo de funciones, programación y pruebas. Si escribe una carta y habla de un problema, ofrezca una solución razonada; esto también es una contribución.
Es importante entender que comprometerse se trata de confianza. Personas como usted deciden si convertirlo en un comprometido o no en función de su visión de usted como una persona que aporta beneficios al producto. Por lo tanto, usted, a través de sus acciones y hechos en la comunidad, necesita ganarse esta misma confianza.
¿Como comportarse?
Sea constructivo, positivo, educado y paciente. Recuerde que en código abierto todos son voluntarios y nadie le debe nada a nadie. No te responden; espera y te recuerda tu pregunta en 3 o 4 días. No siempre te responden; bueno, el código abierto es voluntario.
No le pidas a nadie que haga algo por ti o por ti. Los miembros experimentados de la comunidad tienen instinto para estos “mendigos” e inmediatamente se vuelven alérgicos a aquellos que quieren imponerles su trabajo.
Si recibe ayuda, es genial, pero no abuse de ella. No deberían escribir: "Chicos, arreglen esto, de lo contrario perderé mi bonificación anual". Es mejor preguntar dónde debe ir a continuación y decirnos qué ha descubierto ya sobre este error. Y si promete actualizar el wiki en función de los resultados de la solución del problema, la probabilidad de que le respondan aumentará significativamente.
Finalmente, lee y aprender .
¿Cómo contribuir si no eres un committer?
Los proyectos suelen utilizar un esquema RTC, donde primero todo pasa por una revisión y luego los cambios se fusionan en el maestro. Con este esquema, absolutamente todo el mundo se somete a revisión, incluso los comprometidos. Por lo tanto, puedes contribuir exitosamente a un proyecto sin ser un comprometido. Y para que sea más fácil ser seleccionado como nuevos participantes, puede asesorar a nuevos participantes, compartir conocimientos y crear nuevos materiales.
Diversidad: ¿beneficio o daño?
Diversidad: según lo entiende la Apache Software Foundation, se trata, entre otras cosas, de la afiliación de varias empresas a un proyecto de código abierto. Si todos están afiliados a una sola organización, cuando se pierde el interés en el proyecto, todos los participantes rápidamente lo abandonan. La diversidad proporciona un proyecto estable a largo plazo, experiencias diversas y una amplia gama de opiniones de los participantes.
¿Por amor o por conveniencia?
En los proyectos opensource hay dos tipos de personas: los que trabajan en una organización que contribuye a este producto, y los que trabajan aquí por amor, es decir, voluntarios. ¿Cuál es más productivo? Normalmente, los participantes que apoyan el producto desde la organización contribuyente. Simplemente tienen más tiempo y una motivación clara para llegar al fondo de la verdad, están centrados en la tarea y más cerca del usuario.
Quienes lo hacen “por amor” también están motivados, pero de otra manera: tienen ganas de estudiar el proyecto, de hacer del mundo un lugar mejor. Y son precisamente estos participantes los que son más estables y orientados a largo plazo, porque aquellos que llegaron a la comunidad por iniciativa propia es poco probable que la abandonen en un día.
¿Cómo encontrar un equilibrio entre productividad y estabilidad? Hay dos opciones. La primera opción: cuando el participante trabaja en una empresa que participa oficialmente en este proyecto de código abierto y hace algo adicional en él, por su propio interés, por ejemplo, apoyar a los recién llegados. La segunda opción es una empresa que haya experimentado una transformación de código abierto. Por ejemplo, cuando los empleados trabajan en el proyecto empresarial principal cuatro días a la semana y el resto del tiempo trabajan en código abierto.
Comprometido: ¿ser o no ser?
El compromiso es un tema bueno y útil, pero no debes esforzarte específicamente en convertirte en un comprometido. Este rol no está basado en código y no demuestra su conocimiento. Lo único que importa es la experiencia, es decir, el conocimiento y la experiencia que se obtienen estudiando el proyecto, profundizando en él y ayudando a otros a resolver problemas.
Fuente: habr.com