Construyendo comunidades OpenSolaris

OpenSolaris es una comunidad de comunidades, y la construcción de una comunidad de estas características es una tarea que requiere tiempo y esfuerzo. No hay otro modo. Arrojar un código por encima del muro y alejarse caminando es perder la oportunidad de lograr la participación de desarrolladores y usuarios de todo el mundo. Actualmente, la mayor comunidad de OpenSolaris se encuentra en opensolaris.org, pero incluso ella se compone de comunidades más pequeñas en forma de grupos comunitarios, proyectos y grupos de usuarios. Hay también otras comunidades incipientes puestas en marcha a partir de sitios web de mercados emergentes o incluso de distribuciones que no necesariamente han de tener conexiones directas con la operaciones de opensolaris.org. OpenSolaris ha dejado de ser una comunidad monolítica y basada en una geografía. Está creciendo y se diversifica globalmente.

A medida que Sun pasa de proyectos de desarrollo cerrado a abierto en opensolaris.org, o acaba de iniciar en abierto nuevos proyectos comenzando desde cero, mucha gente se pregunta, "¿cómo podemos construir una comunidad?", o "por qué debemos construir una comunidad?", o "¿cómo podemos crecer?" Bueno, aquí van mis respuestas a esas preguntas desde un punto de vista no técnico. La lista de temas siguientes no es necesariamente exhaustiva (ni tenemos necesariamente que hacer alguna de esas cosas especialmente bien), pero es un conjunto de temas a tener en cuenta por quien desee construir una comunidad de personas en torno a un proyecto.

Construcción de la comunidad
  1. Planificación y construcción: Lo primero importante consiste en asumir que construir una comunidad es un proceso cíclico de planificación e implementación activas. Algunas personas se muestran reacias a este concepto, porque consideran que las comunidades deben crecer orgánicamente. No obstante, sospecho que la mayoría de las comunidades crece realmente sobre la base de participantes activos que directamente enganchan a otras personas y gestionan los recursos de diversas fuentes, como empresas, fundaciones y particulares. También creo que el concepto de construcción de una comunidad se basa fundamentalmente en dos principios básicos: (1) comunicaciones abiertas y (2) desarrollo abierto. Básicamente, trabajar sin tapujos y hablar sin tapujos. Y si realmente se desea crecer mucho, hay tres cosas que deben hacerse realmente bien: (1) hablar con mucha gente todo el tiempo, (2) incluir a esa gente en el trabajo propio y (3) ofrecer los medios necesarios para que esa gente pueda contribuir creando y compartiendo su trabajo con otros. El mismo proceso de trabajo ayuda a construir la comunidad porque genera más comunicaciones y más trabajo. Y todo en torno a un proyecto. Pero toda construcción activa comienza con un plan. Escriba uno. Comience la construcción. Actualice el plan. Repita el proceso.

  2. Transparencia: Salga al exterior. No se puede construir una comunidad desde detrás de un muro. Conversaciones, listas, código fuente, binarios, documentación, herramientas, personas, infraestructuras, obras de arte -- haga aflorar todo esto para que cada persona tenga una buena oportunidad de participar y contribuir. Si no hay nada que recoger, nadie recogerá nada y no habrá forma de construir una comunidad. Y si se limita a hablar dentro, nadie de fuera sabrá siquiera que existe. Es el único gran error que cometen las gentes de Sun. Tratan de vivir en dos mundos. Y no se puede. Hay que decidirse. Se es abierto o no se es.

  3. Participación: Las comunidades se basan en la participación directa y en la construcción de relaciones de confianza. Esto significa que la gente se gana en función de sus contribuciones y que hay expectativas en cuanto a oportunidades y apertura. También se puede contemplar esta cuestión como la distinción entre una comunidad y un programa. La mayoría de los programas tienen un único sentido que, por lo general, va de la empresa al mercado. Pero las comunidades tienen dos sentidos (en realidad tienen muchos) y sirven tanto para ir como para venir. Y luego está que la participación supone actuar, no hablar. Están los que hay que dirigir y aquellos otros cuya voz se oye por encima de la de los demás. La credibilidad se gana a partir del trabajo con el que se contribuye a la comunidad, no con el cargo con el que se le conoce en la empresa. Si desea que la gente se reúna a su alrededor, deberá asumir este concepto y facilitarles la participación.

  4. Contribuciones: Defina las contribuciones que pretende conseguir. Ofrezca categorías especiales y ejemplos específicos y espere que la comunidad le devuelva más ejemplos y más cosas de las que haya podido pensar (ese es el auténtico objetivo). Aquí va una lista de las contribuciones en las que han participado los miembros de la comunidad OpenSolaris -- códigos, scripts, pruebas, ayudas, presentaciones, grupos de usuarios, gestión de conferencias, portales de idiomas, traducciones, cursos universitarios, gráficos, publicidad, materiales de formación, screencasts, vídeos, sitios web, wikis, evangelización, documentación, artículos, blogs, podcasts, procesos de desarrollo, tutoriales, métodos de introducción de datos, información, herramientas de compresión de lenguaje, herramientas de SCM, reescritura cerrada de binarios, sistema de seguimiento de defectos, shells, distribuciones, libros, puertos, gestión de asuntos públicos, etc. Aunque muchos de estos temas son técnicos, otros no lo son y la mayoría no implican el uso de código kernel. En otras palabras, piense en la cantidad de contribuciones que desea impulsar y deje que la lista crezca sin trabas. Más tarde, cuando las cosas comiencen a llegar, destaque a las personas que están contribuyendo. Siempre es bueno llamar la atención sobre las contribuciones de los demás, pero hágalo de forma discreta. En la mayoría de las comunidades, cada uno sabe quien contribuye de verdad porque el trabajo habla más alto que las palabras y, por lo general, los contribuyentes suelen trabajar codo con codo y sin trabas. Pero a nadie le molesta que le den las gracias de cuando en cuando.

  5. Presentaciones: El mayor problema con la mayoría de presentaciones técnicas es que son dolorosamente largas y se centran demasiado en la descripción de la propia tecnología. Eso está bien para una clase o una sesión de tutoría interactiva, pero el acto de construir una comunidad no tiene nada que ver con la tecnología. Va de personas. Así que explique la tecnología, desde luego, pero céntrese más en cómo conseguir que los desarrolladores y los usuarios participen y contribuyan, a la tecnología y a la comunidad, y en cómo hacer que todos se beneficien de sus ventajas. La mayoría de las presentaciones técnicas tienen una diapositiva al final en la que se enumeran las listas a las pueden adherirse. No es suficiente. No puede ser algo en lo que pensar después. Debe ser el núcleo.

  6. Conferencias: Tiene que asistir a conferencias. Sun incluye varias conferencias, pero también necesita acudir a eventos que no sean FOSS de Sun. Todos tienen valor pero todos son diferentes. Por otra parte, no siempre siente que está presente en las conferencias. Participar en las sesiones, charlas de pasillo, BOF y fiestas es tan importante como asistir a la presentación de documentos oficiales. Sólo el hecho de estar allí ya es importante. Necesitará una mezcla de interacciones cara a cara y en línea para crear un sentimiento de comunidad. Y no hay que perder la oportunidad de tener una charla rápida y chispeante. La mayoría de las buenas conferencias ofrecen estas oportunidades. Y permiten añadir grupos de usuarios a la lista de conferencias. Vaya a ellas, inícielas o haga las dos cosas. Si empieza con un grupo de usuarios, es preferible hacerlo en un bar, una cafetería o un sitio parecido. Comience de forma breve y sociable y deje que las presentaciones técnicas crezcan lentamente a medida que las demás personas vayan aportando sus experiencias al grupo. Y no crea que siempre tiene que tener una gran presentación técnica con 100 personas en la sala cada mes. No es realista. Pueden ser sesiones técnicas trimestrales con encuentros mensuales en un bar para comer o tomar una cerveza y tratar los temas en una lista de correo entre reuniones. Comience de forma breve y busque la forma de construir una tradición a través de experiencias repetidas. Con el tiempo, se desarrollará pronto una cierta cultura que es el pegamento que mantendrá unido el grupo de usuarios.

  7. Proceso de desarrollo e infraestructura: Si se dispone a construir una comunidad, debería invertir más tiempo en averiguar la infraestructura física que necesitará para dar apoyo a todas las personas que quiere. ¿Se va a escalar? ¿Qué proceso de desarrollo se necesita para aceptar contribuciones? ¿Qué prueba se necesita? ¿Ofrece una caja de arena para hacer experimentos? ¿Qué herramientas son necesarias para albergar los artefactos del proyecto? ¿Quién tiene acceso? Todo esto depende de si se quiere acoger a opensolaris.org o a otro sitio, y si se está ejecutando un grupo comunitario, un grupo de usuarios o un proyecto de desarrollo. Los contribuyentes al código final más alto será siempre un grupo pequeño, pero son justamente esos chicos los que tienen que descubrir las herramientas que van a hacer falta. Sin embargo, los no codificadores deberían participar en esos debates, al menos parcialmente, de forma que la infraestructura se construya para acomodar una amplia variedad de contribuciones.

  8. Liderazgo, gobernabilidad, cultura: ¿Cuáles son los valores de la comunidad? ¿Qué estructura social tendrá? ¿Cómo se gestionará la propia comunidad? ¿Cómo se tomarán las decisiones? ¿Cual es su modelo de liderazgo? ¿Cómo va a llamar la atención de los contribuyentes? ¿Cómo resuelve los conflictos? Estas son las preguntas a la que deberá hacer frente cada vez que un grupo numeroso de personas se reúna para colaborar juntas en algo. Cuando se es pequeño, esto se puede gestionar fácilmente en la propia cabeza, pero cuando se crece a nivel mundial es necesario documentar el comportamiento que se desea fomentar y fijar algunas normas sobre cómo manejarlo. No tiene que ser persuasivo y burocrático, pero la gente necesita saber lo que se defiende y lo que se espera. Tal vez un solo líder fuerte sea apropiado, pero puede ser necesario considerar otras opciones para distribuir mecanismos de liderazgo. Busque en otras comunidades como Mozilla, Linux, Apache, Ruby, Java y BSD para ver ejemplos. En realidad, hay otras muchas pero estas son algunas de las comunidades con software de código abierto más grandes.

  9. Universidades: Si se quiere crecer es necesario volver a la escuela y pasar el tiempo con los jóvenes. Ponga su proyecto delante de estudiantes y profesores universitarios de los mercados emergentes en primer lugar. Comience por India y China por razones obvias. Pero sin olvidar los mercados ya establecidos. Las visitas a las universidades son probablemente la forma más sencilla de garantizar que el proyecto tiene posibilidades de sobrevivir en el futuro. Descuidar las universidades no es una opción. Necesitan tener una prioridad absoluta. A propósito, esta será probablemente la parte más divertida de las operaciones de construcción de la comunidad.

  10. Global: Construya la comunidad con una perspectiva global en la mente. ¿Dónde están los desarrolladores que estarían interesados en su proyecto? Vaya allí. A menudo. Cuando se va a nivel global, sin embargo, uno se interesa por todo tipo de idiomas y asuntos culturales que relentizarán el proceso. Es de esperar que ocurra. Busque gente que pueda ayudar a construir la comunidad en un lugar determinado, y trabaje luego por conectar varias ubicaciones entre sí. No va a tener "una" comunidad alrededor del mundo, de modo que no espere que nadie le siga sin más (ni siquiera que le entiendan). Tendrá muchas comunidades y cada una expresará sus propias experiencias de formas bien distintas. Su trabajo consiste en animarlos para que sean tan independientes como sea necesario, pero también en ayudarles a conectar con otras regiones para que puedan participar en una comunidad destino. Por cierto que no es nada fácil. Pero es necesario. Y puede ser una fuente de contribuciones verdaderamente innovadoras a medida que se van desarrollando los mercados emergentes.

  11. Marketing: Conozca a su gente de marketing. Pueden ayudarle a dar a conocer oficialmente su proyecto en conferencias o en operaciones de prensa y análisis o en reuniones con clientes. Y pueden ofrecer una perspectiva sobre cuestiones importante que se le pueden haber escapado, como marcas comerciales, mercadotecnia, lanzamientos, noticias, filtraciones y perturbaciones del mercado. No necesita saber lo que dice la prensa sobre usted, ¿verdad? ¿Le ayudaría exponerse más? ¿Qué cuestiones de marketing competitivo observa que no tiene? Asimismo, participe en los programas especiales que Sun ejecuta ocasionalmente, como las pruebas de codificación y los eventos. Sun cuenta con otros desarrolladores de programas y sitios web que dan la bienvenida a todos los contenidos y participantes. Aproveche los recursos globales de la compañia en este sentido. Por cierto, la humildad y la honestidad son las mejores técnicas para hacer una comercialización de código abierto efectiva. Recuerde siempre que usted sabe cómo anunciar sus proyectos.

  12. Promoción: Es algo mucho mayor que el marketing y algo diferente también. No se trata de disciplinas específicas de marketing, como pueden ser publicidad, comercialización, mercadotecnia, relaciones públicas o AR. Por el contrario, es un compromiso directo y sin filtrar a un nivel que conduce a la participación y la contribución activas. Va de la construcción de una comunidad por medio de comunicaciones abiertas. Ahora incluye personal de marketing, por supuesto, pero también ingenieros y gestores de proyectos y a cualquier otra persona que quiera involucrarse. Y además usted es el mejor promotor de su trabajo, por lo que necesita asumir la responsabilidad directa de comunicarse en la forma que mejor pueda. Es posible que aproveche otros recursos, pero no deja de ser el responsable último de su propia línea de fondo que, en este caso, significa el crecimiento de su comunidad y la promoción de su tecnología. No se limite a dejar esta función en manos de otro y marcharse. Participe.

  13. Asuntos legales: En su mayoría son temas internos de Sun como la apertura de los códigos y las herramientas cerrados. Pero incluso ahora que se han abierto, es necesario considerar las marcas comerciales, copyright, acuerdos con los contribuyentes, concesión de licencias, análisis de fuentes, etc. Estas cosas no ayudan necesariamente al crecimiento de la comunidad, pero pueden impedir que las cosas se disparen si no se les presta la debida atención. Conozca a sus abogados. Hábleles de las necesidades de la comunidad y pídales que le enseñen la realidad de la ley. En este punto, la información debe ir en ambos sentidos.

  14. Gestión de proyectos: A medida que su comunidad vaya creciendo es seguro que contendrá múltiples proyectos de ingeniería y actividades de usuarios de todo el mundo. ¿Quién ejecutará estas operaciones tan complejas? ¿Quién gestionará el plan y mantendrá actualizados las cifras y los planes de trabajo? ¿Quién le advertirá de la organización política que encontrará con toda seguridad? Por lo tanto, es posible que quiera cazar junto a un buen gestor de proyectos que le facilite las cosas. Al igual que los ingenieros se basan en el código abierto para construir la comunidad, los gestores de proyectos deberían hacer lo propio. Si se mira el proyecto desde un contexto lo más amplio posible, podrá apreciar que toca muchas disciplinas diferentes, tanto dentro como fuera del muro, y que afecta al modo en que construye su comunidad.

  15. Pasarlo bien: Para terminar, construir una comunidad es un ejercicio social en última instancia donde la gente debería pasarlo bien mientras participa. Quiere atraer a la gente a su comunidad, ¿verdad? Quiere animar a la gente para que se quede, ¿verdad? Pues haga que se lo pasen bien. Ofrezca a la gente la posibilidad de divertirse y se divertirá.



Referencias de OpenSolaris:

Constitución | Grupos comunitarios | Proyectos | Referencia dirigida a sitio web | Contribución | Valores | Proceso de desarrollo | Referencia de desarrollo | Promoción y grupos de usuarios | Contribuyentes de código

Libros sobre Open Source, concesión de licencias y desarrollo de comunidades:

The Cathedral and the Bazaar Eric Raymond | Innovation Happens Elsewhere Ron Goldman, Richard P. Gabriel | Open Source & Free Software Licensing Andrew M. St. Laurent | Open Source Licensing: Software Freedom & Intellectual Property Law Lawrence Rosen | Open Sources: Voices from the Open Source Revolution Oreilly | Open Sources 2.0 The Continuing Evolution Oreilly | Free as in Freedom Richard Stallman

Publicar actualización: 12/26/07, 12/27/07, 4/28/08, 5/16/08
Comments:

The Spanish community is moving fast as I can see even in their portal.
I hope the Italian one do the same... But it seems nobody is going to translate it. I'm thinking about maybe start doing it...

Posted by Pietro Zuco on June 03, 2008 at 05:08 AM JST #

hey ... well, that's cool. We are implementing a new site, so doing content work on it will be much easier. I'll let you know more very soon:
http://www.opensolaris.org/os/project/website/wiki_requirements/
http://opensolaris.org/jive/thread.jspa?threadID=62575&tstart=0

Posted by Jim Grisanzio on June 06, 2008 at 05:21 AM JST #

Post a Comment:
Comments are closed for this entry.
About


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks

No bookmarks in folder