En la
última reunión de la comunidad Apache Ignite en Moscú, hablé sobre:
- Comunidad de código abierto;
- Poder y dinero en código abierto;
- Cómo convertirse en un contribuyente y un comprometidor, y por qué lo necesita.
El tiempo limitado del informe no me permitió dar más ejemplos, así que publiqué la versión extendida en Habré. Todo lo anterior se basa en mi experiencia personal y no es un puesto oficial de ninguna empresa u organización.
¿Qué es una comunidad?
Esto puede parecer obvio, pero aún así aclaremos lo que queremos decir con la comunidad. En primer lugar, estamos hablando de una comunidad en línea. Este es un tipo de plataforma para que las personas interactúen entre sí. Si una comunidad se dedica, por ejemplo, a la salud, la forma física y actividades similares, entonces su tarea puede ser apoyar a sus miembros. O una comunidad puede crear un bien público. Este es exactamente el caso con la comunidad de desarrollo de software de código abierto. Además, si desea desarrollar algún tipo de software, es poco probable que encuentre personas con puntos de vista similares, por ejemplo, en su aterrizaje o en la próxima entrada. Existen tales proyectos, pero generalmente como proyectos de estudiantes. Y la comunidad en línea borra las barreras entre continentes y zonas horarias, le permite encontrar más entusiastas.
Fundación Apache
La historia de Apache comenzó en 1999 con el servidor web HTTPD: un grupo de personas comenzó a desarrollar un servidor web, los usuarios comenzaron a acercarse a ellos, algunos de los cuales comenzaron a enviar parches porque querían mejorar algo en este producto o corregir errores. Los desarrolladores comenzaron gradualmente a asignar a los miembros más activos de esta comunidad el derecho a ingresar al repositorio, que ahora se denomina derechos de compromiso.
Aplicando el mismo enfoque para el desarrollo de código abierto, Apache se ha convertido en la organización (fundación) más grande, que desarrolla software de código abierto. La organización está dividida en 319 (hasta ahora) proyectos diversificados, de los cuales unos 200 son de nivel superior. No existe un proceso único para todos los proyectos, todos los participantes son voluntarios, su trabajo nunca es pagado por la organización.
Apache sin falta requiere que todos los proyectos tengan:
- Política legal;
- Políticas de uso de la marca;
- Votación sobre la adopción de comunicados;
- Uso de listas de correo;
- Seguridad de la información.
Incubadora Apache
Para construir una comunidad, todos los proyectos de Apache pasan por la Incubadora de Apache sin falta. Esta es una etapa intermedia en el desarrollo, ni siquiera del proyecto, sino de la comunidad que lo rodea. Nadie en Apache dictará qué tecnología usar. Además, ni siquiera preguntarán qué decisión elegir. El objetivo de Apache Incubator es construir una comunidad que tome decisiones juntas. Es muy importante que los participantes entiendan cómo y quién toma la decisión, dónde pueden hablar, dónde se escuchará su voz. Organizar un ASF ayuda al asociar un mentor al proyecto.
Proyecto Apache de nivel superior
Si un proyecto deja Apache Incubator, puede convertirse en un proyecto de nivel superior. Apache ayuda al proyecto a participar en conferencias, brinda toda la asistencia posible para promocionar la marca y apoya la infraestructura.
La comunidad del proyecto de nivel superior garantiza a los usuarios que:
- El código puede ser usado legalmente;
- Código de alta calidad;
- Se observa la seguridad de la información: por ejemplo, todas las versiones están firmadas;
- El proyecto siempre estará disponible para los usuarios.
Fuente abierta y poder
Ahora hablemos sobre el poder y el dinero, y cómo se toman las decisiones. Esto no siempre es obvio incluso para los miembros de la comunidad. Hay varios roles en el proyecto Apache y varias listas de correo corresponden a ellos:
- Usuario (usuario@proyecto.apache.org);
- Desarrollador (dev@project.apache.org);
- Committer (dev@project.apache.org);
- PMC (private@project.apache.org);
- Presidente de PMC (private@project.apache.org).
Además, ya puede crecer en el marco de Apache Software Foundation, convertirse en un mentor de un proyecto, ayudar a otros proyectos a construir una comunidad.
Cuanto mayor es el rol, menos personas lo desempeñan, es decir, se forma una pirámide invertida: la mayoría de los usuarios, menos PMC. Por lo general, todos están interesados en que los participantes crezcan y jueguen un papel más importante.
A diferencia de las empresas comerciales, donde el personal y el crecimiento están limitados por el presupuesto, el código abierto no tiene esto, nada limita el número de comisarios o PMC. El grupo se regula independientemente.
Usuario
Los usuarios somos todos nosotros. Seguramente cada uno de ustedes usa algún tipo de software de código abierto. Es importante para la comunidad que el usuario no solo use o brinde comentarios en forma de informes de errores o solicitudes de funciones, sino que también ayude a otros. Es decir, desde el punto de vista de la comunidad, un participante se convierte en usuario solo cuando se suscribe y responde a la lista de usuarios y ayuda a otros a dominar el producto, comparte su conocimiento.
Desarrollador / Colaborador
Si el usuario está listo para contribuir al proyecto, con la primera contribución se convertirá automáticamente en colaborador o desarrollador, estos son sinónimos. El contribuyente participa en un boletín informativo para desarrolladores que analiza todo lo relacionado con las contribuciones de la comunidad. Todos los desarrolladores influyen en la toma de decisiones de la comunidad, todos critican las decisiones y ofrecen alternativas.
Committer
Si la comunidad cree que la persona ha hecho una contribución suficiente, puede tener derecho a ingresar al repositorio, es decir, el número mínimo de revisores de su código se reduce a cero (aunque en Apache Ignite, los encargados del envío a veces siguen el análisis del código). Los comisionados firman un ICLA (
Acuerdo de licencia de contribuyente individual ). Sin embargo, también se puede firmar antes de recibir comisiones. El encargado recibe un buzón en apache.org y puede tomar decisiones relacionadas con cada contribución al proyecto.
Miembro de PMC
Miembro del PMC (Comité de Gestión del Proyecto) - Miembro del comité de gestión del proyecto. Este miembro de la comunidad ya ha hecho una gran contribución al desarrollo del producto y tiene derecho a tomar decisiones de desarrollo a largo plazo, controla el proyecto, monitorea muchos aspectos, en particular, la toma conjunta de decisiones. Ayuda a los miembros de la comunidad a llegar a un consenso. PMC tiene muchas responsabilidades en Apache, por ejemplo, puede votar para aceptar el lanzamiento. El emisor y el contribuyente también pueden, pero, a diferencia de ellos, PMC tiene una voz vinculante. El PMC puede proponer comisionadores o nuevos PMC.
Presidente de PMC
La Cátedra PMC es el puente entre Apache Software Foundation. Quizás el presidente de PMC no tiene mucho poder en comparación con el miembro de PMC. Pero debe resolver los problemas e informar a la Junta de Apache sobre el estado del proyecto.
Toma de decisiones: duocracia
Apache está dominado por el principio de duocracia (do-ocracy, de do - "do"). Cuanto más lo haga, más oportunidades tendrá que hacer, más influirá en el proyecto.
Si una decisión requiere una posición coordinada de todos los participantes, se vota. Dura al menos 72 horas para que todos puedan votar.
Los votantes ponen:
+1: "por la decisión".
0: "No me importa".
-1: "en contra de la decisión". En este caso, debe proponer algo más y explicar en detalle por qué vota en contra.
Hay otros tipos de votos:
0: "No me gusta mucho la idea, pero me queda bien".
-0: "No interferiré, pero es mejor no hacer esto".
-0.5: "No me gusta la idea, pero no puedo encontrar argumentos racionales en su contra".
++ 1: "Super, hagámoslo!"
-0.9: "No me gusta, pero si todos quieren, no pondré palos en las ruedas, adelante".
+0.9: "La idea es genial, me gusta, pero no tengo el tiempo / conocimiento para ayudar".
Consenso perezoso
Existe una política de toma de decisiones como el consenso vago o la aprobación a través del silencio. Este procedimiento también dura al menos 72 horas. Si una persona escribió explícitamente: "Quiero pasar esta decisión a través de un consenso perezoso", entonces, en tres días, incluso si nadie respondió, la decisión se considera aceptada por la comunidad.
Aprobación por mayoría y aprobación por consenso
La votación para la liberación es más activa: en este caso, es necesaria la aprobación de la mayoría de los miembros de la comunidad: tres votos obligatorios (del PMC) “a favor” y más votos “a favor” que “en contra”.
El consenso es la mejor opción: todos están a favor, con al menos tres PMC.
Veto
Un contribuyente calificado, generalmente un miembro de PMC, puede vetarlo. Vota -1 por modificar el código y escribe una explicación detallada. Nadie puede sortear tal solución para miembros de PMC. No puede vetar un lanzamiento, pero si la edición es muy pobre, por ejemplo, crea un agujero de seguridad o degrada el rendimiento, PMC puede votar -1. Y hasta que retire el veto, es imposible aplicar la edición.
Meritocracia
Otro principio cercano a la duocracia. Literalmente, "meritocracia" significa "el poder de los dignos". En código abierto, esto significa que si el usuario, como cree el grupo, ha hecho mucho por la comunidad, entonces es promovido a un compromiso. Puede preguntarse cuán justa es esta decisión, ¿es siempre absolutamente honesta y equilibrada? Esta es una decisión extremadamente subjetiva de todos los PMC en esta comunidad. En comunidades grandes, como Apache Ignite, esta política puede ser más o menos formalizada. Ciertas contribuciones humanas son importantes, asegúrese de participar activamente en el boletín para desarrolladores. Pero la "suficiencia" se determina individualmente por cada proyecto.
Un punto importante son las cualidades humanas del participante. La política de Apache establece explícitamente que se evalúa la interacción de la persona con otros participantes, cómo se comporta si no está de acuerdo con su opinión. Para que un miembro sea promovido a comisionado o PMC, otros PMC deben votar en la lista privada y no debe haber votos de "no".
Código abierto y dinero
Este importante tema aparece de una forma u otra: cómo ganar dinero con los productos de Apache Software Foundation. La organización proporciona la licencia más comercialmente amigable de todas las que existen. Puede vender productos basados en Apache o soporte para productos Apache, puede usarlos en productos comerciales.
Un requisito importante: siempre debe haber uso gratuito de los productos de Apache. Se gestionan independientemente de los intereses comerciales. Esto está siendo monitoreado por PMC.
El comisionado puede recibir dinero de una organización de terceros para contribuir al proyecto. El comisionado puede ser contratado por un tercero. Recientemente, los miembros de la comunidad
contaron en Habr cómo trabajan con la comunidad de código abierto Apache Ignite en Sberbank Technologies. Pero la Fundación Apache nunca paga a los comprometidos. Esta es una posición de principios. Para Apache, el responsable es siempre un voluntario y un individuo. Es decir, la empresa no puede participar en proyectos de Apache, solo un desarrollador puede hacerlo.
Por qué y cómo unirse al código abierto
¿Por qué vale la pena comenzar a contribuir a proyectos de código abierto?
Esta es una buena oportunidad para mejorar sus habilidades y ganar una reputación profesional. Las empresas comerciales aprecian participar en código abierto. Muchos desarrolladores famosos participan en varios proyectos, se convierten en comisarios y PMC.
¿Qué impide que las personas participen en código abierto?- "Necesitas ser una Olimpiada o un senior con 20 años de experiencia, de lo contrario no puedo hacerlo". De hecho, no. Apache Ignite es un proyecto complejo, pero incluso aquí puedes encontrar tareas simples. Por ejemplo, tickets y tareas fáciles para escribir documentación que están diseñados para describir mejor el proyecto. En ninguna parte de Apache dice que para convertirse en un committer, debe escribir código.
- "Necesito un inglés fluido, de lo contrario no puedo manejarlo". Los que participan en las listas de desarrolladores confirmarán: allí no es necesario que hables inglés con fluidez. Además, la comunicación escrita no es en absoluto en tiempo real, hay tiempo para pensar y escribir una respuesta equilibrada.
- "Si envío mi componente a código abierto, nunca podré volver a usarlo". En Apache, esto no es así. Puede continuar usando su componente en un producto comercial, simplemente existirá bajo la Fundación Apache bajo la licencia Apache.
- "Todos leerán lo que escribo en Internet". Incluso en la comunidad Apache Ignite, no todos leen lo que escribimos. Es como en una broma sobre el esquivo Joe: nadie puede atraparlo, porque nadie lo necesita. Estoy seguro de que mis amigos y familiares no leen lo que escribo en la lista de desarrolladores, porque no les importa.
- "Tomará todo mi tiempo libre". Esto es en parte cierto: la participación comunitaria es adictiva. Si comienza a participar en la discusión, tomará algún tiempo. Y a medida que crezca, tomará más. Cuanto más sepa, más podrá decir, más participará en la lista de usuarios y desarrolladores. Pero, de nuevo, no hay obligación para Apache. Cada uno regula su propia participación. Si puede hacer un parche, haga un parche. Y sin embargo, nadie te obligará. Incluso cuando una persona es nombrada comisionada, la carta de propuesta establece que no se requiere que participe más de lo que está dispuesto a dar.
Como empezar
Si desea participar en proyectos de Apache, necesitará una cuenta en Github, un buzón, registro en
Apache JIRA y, posiblemente, en el
Wiki . Cualquier comunidad tiene un artículo sobre
cómo contribuir para principiantes en Apache Ignite.
Es una buena forma de escribir una carta de bienvenida:
"¡Hola! Soy tal y tal. Quiero hacer ese boleto, mi apodo en JIRA es tal y tal " . Esta carta es importante en términos de asignar al usuario el rol de contribuyente.
Listas de correo
Para interactuar con otros miembros, Apache requiere el uso de listas de correo. A veces escucho descontento: ¿por qué tan anticuado? Hay un montón de chats, mensajeros instantáneos. Esto se debe a que cada miembro de los proyectos de Apache es voluntario. Puede tener su propia familia, un trabajo que no está relacionado con el código abierto, sus pasatiempos. No puede chatear en línea. Quizás pueda revisar el correo cada tres días. Y en tales situaciones, las listas de correo funcionan bien.
Además, no olvide que los miembros de la comunidad están dispersos por todo el mundo. Y hombre
a quien le haga una pregunta, puede estar en otro continente y responderá solo mañana.
Por lo tanto, paciencia y cortesía son esas cualidades que son muy importantes en la correspondencia en las listas de correo. Por ejemplo, en la comunidad Apache Ignite, los miembros experimentados nunca escribirán que no están de acuerdo con usted, escribirán que no están seguros de estar de acuerdo.
Carta de ejemplo:
Hola, □/200URAGENGOURGORAGEN, no estoy seguro de estar de acuerdo, porque ...La comunidad es más importante que el código.
Uno de los principios de Apache: la comunidad es más importante que el código. Esto significa que lo primero que pretende crear el proyecto Apache es una comunidad en torno a un proyecto de código abierto. Y entonces comienza la magia y aparece un buen código. Si no está de acuerdo con alguna carta, posponga durante 4 horas, vuelva a leer y posponga nuevamente. Entonces existe una gran posibilidad de que responda con moderación, sin presionar a los demás miembros de la comunidad con palabras descuidadas. Todos somos voluntarios, y si las personas no se sienten cómodas, comenzarán a irse, y para un proyecto de código abierto, este es un riesgo muy grave.
Recomendaciones de correspondencia
Son más o menos similares a los utilizados en la correspondencia comercial ordinaria. Si alguna oración se puede interpretar de manera incorrecta, se interpretará de manera incorrecta, especialmente considerando el tamaño de la comunidad. Todas las recomendaciones se reducen a tres principios básicos: ser positivo, constructivo y respetuoso.
Un ejemplo de una carta no tan buena:
Hola, □□□□□.
Esta solución me parece un poco fea.Un deseo de mí como miembro de la lista de desarrolladores: escribir letras cortas: tres párrafos o 7 oraciones. Todos somos expertos en tecnología y queremos dar tantos detalles como sea posible. Pero si hay demasiados, quizás esta sea una ocasión para escribir un artículo por separado.
¿Qué contrabandear?
Cada comunidad tiene una lista de lo que necesita en este momento. Ignite tiene una lista de entradas simples. Si encontró un error durante el uso y lo solucionó en su tenedor, entonces es muy posible crear un problema JIRA para este negocio, hacer una solicitud de extracción y escribir en la lista de desarrolladores.
Cómo pasar por la revisión de código
Si bien es nuevo en la comunidad, es poco probable que pueda determinar qué boleto es una prioridad. Puede tener sentido ponerse en contacto con la persona que acompaña al componente, su ayuda será muy importante para él. También puede preguntar en la lista de desarrolladores qué tickets son más importantes.
Si no hay respuesta, nuevamente recordamos que todos somos voluntarios. Puede ser una buena idea recordarle lo que propuso hacer en tres días.
En los proyectos de Apache, incluido Ignite, no hay un rol de gerente de proyecto que supervise el trabajo atrasado, por lo que también se pueden encontrar tickets irrelevantes allí. Se recomienda que primero escriba en la lista de desarrolladores y aclare.
Otra característica de Apache: en una empresa comercial, puede haber una política clara de que un empleado de cierto nivel puede acceder y editar documentación, pero un empleado de un nivel inferior no puede. No hay tal cosa en Apache. Si hay algo que prestar, no hay problema. Creo que en cualquier proyecto no tendrá problemas para obtener derechos de acceso, y no importa si la persona no es formalmente responsable.
Habla sobre el proyecto
La comunidad está muy asistida por artículos de productos. La propia Apache Software Foundation ayuda con las conferencias. , Apache Ignite. - use-case, . dev list.