¿Cómo compartir el control de enlaces / dominios en un proyecto de código abierto con muchos colaboradores?

7

Estoy tratando de ayudar al proyecto Rebol a rediseñar su presencia en la web ahora que es de código abierto como Apache 2, ¡después de casi dos décadas de licencia propietaria!

El creador del idioma actualmente tiene el control de registro de los sitios rebol.com/.org/.net. Desea mantener el control del dominio rebol.com como una participación para su compañía Rebol Technologies (y sus restantes bases de código no abiertas). Pero ha indicado que está dispuesto a dejar que la comunidad se haga cargo de rebol.org y rebol.net , que son sitios que muestran su edad en la actualidad. Necesitan grandes revisiones en términos de organización / contenido / temática visual; y la propuesta actual es que .org se convierta en una biblioteca neutral similar a la de Wikipedia y en una biblioteca de módulos curada (con pocos enlaces salientes), mientras que .net sea una "red de desarrolladores" más sociable de diversos recursos de la comunidad.

Si bien se cree que el creador es benevolente, en realidad no puede ser un dictador benevolente para el proyecto, como él ha liberado en gran parte su interés en Rebol debido a una nueva carrera. Además, el cambio en la respuesta a las inquietudes de la comunidad ha sido históricamente en escalas de tiempo muy largas ... y, por lo tanto, han aparecido muchos sitios alternativos para llenar los vacíos.

La cuestión de cómo tomar el control del problema y lograr que la comunidad invierta en contenido alojado bajo los agradables nombres de dominio, en lugar de que cada uno vaya en una dirección diferente, es espinosa. A modo de comparación, realicé comprobaciones de nombres de dominio de WHOIS y un poco de investigación sobre los sitios principales para Ruby y Python.

ruby-lang.org

  • Nombre del administrador: Matsumoto.Yukihiro Matsumoto.Yukihiro
  • Organización de administración: Grupo de usuarios de Ruby

Parece que la fuente en ruby-lang.org se mantiene en GitHub. Si lo leo correctamente, hay 35 miembros del ruby organización GitHub , aunque no sé lo suficiente como para saber cuál de estas personas tiene acceso comprometido o cuáles son los controles y saldos.

No veo ningún enlace oficial que defina el "Grupo de usuarios de Ruby". Hay una organización sin fines de lucro llamada Ruby Central que parece ser una organización, pero las únicas participaciones que pude encontrar fueron algunas controversias. cuando el tipo Rails intentó evitar que las personas usaran el logotipo de Rails. ruby-lang.org parece no tener casi ningún comentario sobre la estructura legal.

python.org

Esto parece significativamente más formal, ya que tienen estatutos y puedes comprar tu camino hacia la estructura de votación con patrocinio ... o ser nominado / elegido por un miembro de la membresía existente.

Me gusta lo ligero y confiado que es el modelo Ruby. Pero si Matz fuera golpeado por un autobús, entonces, aparte de que las personas estuvieran tristes, ¿qué pasaría? ¿En qué manos caería ruby-lang.org? ¿Qué pasaría si la situación fuera ligeramente diferente, de modo que Matz fuera muy confiable en cuestiones técnicas, pero no hiciera un seguimiento para solucionar los problemas del sitio de manera oportuna?

Python parece tener esto más planificado, pero es bastante pesado. De acuerdo con Wikipedia, la Python Software Foundation se formó en 2001, tiene 124 miembros con Guido Van Rossum como presidente y ¡tenía un presupuesto de $ 750,000 en 2011!

Entonces, ¿cómo podría un proyecto con menos recursos administrar algo tan simple como un par de nombres de dominio, y cómo se resolverán las disputas de contenido? Hay un deseo de reiniciar la identidad ... pero sin algún tipo de contrato ejecutable probablemente no complacerá a las partes involucradas.

    
pregunta HostileFork 18.06.2013 - 19:18

2 respuestas

6

Tienes este problema dos veces. Una vez para el sitio web, y una vez para el código base para Rebol. Deberías usar la misma solución para ambos.

Es decir, la estructura que se crea para controlar lo que entra en el código base es también la estructura del sitio web. Las personas reales involucradas pueden ser diferentes. Pero si, como con Ruby, una persona está a cargo, esa persona debe estar a cargo de ambos. Si, como con Python, hay una organización oficial a cargo, esa organización debe estar a cargo de ambos. Si hay un desacuerdo entre las personas que manejan el sitio web y las personas que publican el código, debe ser obvio cómo resolverlo. (Incluso las personas más agradables tienen días libres, suponga que habrá argumentos).

Luego, considera cuidadosamente lo que más temes. ¿Temes que las personas vayan en diferentes direcciones y hagan cosas no relacionadas? Hacer que la contribución al sitio oficial sea su opción más fácil. ¿Tienes miedo de terminar con un sitio inconsistente? Asegúrese de que alguien tenga el control y pueda imponer una visión coherente. Tenga en cuenta que existe una tensión entre estos objetivos, "todo lo anterior" no es una respuesta posible. Averigua de qué tienes miedo y trata de abordarlo lo mejor que puedas.

No sé nada de la comunidad Rebol. Sin embargo, mi opinión a partir de sus comentarios es que en este punto es bastante pequeño y está fragmentado sin autoridad central. Por lo tanto, me preocuparía más sobre cómo involucrar a las personas que sobre cómo lograr que las personas logren una visión central. Pero eso es un sesgo general que yo personalmente aportaría a cualquier cosa.

Más consejos genéricos. Si eres una organización pequeña, hazlo simple. El dictador benevolente es común por una buena razón. Pero en una situación como la tuya, en la que no sabes quién va a mejorar, podrías considerar la Monarquía Constitucional. Para inspirarte, considera cómo Perl hace todo el asunto de la calabaza. A pesar de que Larry Wall no está profundamente involucrado en el desarrollo del día a día, para cada lanzamiento de Perl, él designa a alguien para que esté a cargo. Si hubiera un gran problema (aún no ha sucedido, que yo sepa), él podría anularlo y nombrar a otra persona.

El fundador de Rebol podría estar convencido de jugar este papel. Un ejemplo de modelo podría ser: "Como último recurso, me reservo el derecho de poner a otra persona a cargo en cualquier momento. Espero nunca hacerlo. Cualquiera que se presente y no sea objetable obviamente tendrá la responsabilidad que quiera y parezca "Una vez que hay un sentido de quién está haciendo cosas activamente, ese grupo debería encontrar una manera de rotar la responsabilidad regularmente".

Como pensamiento final, te dejo con esto. Si logras involucrar y mantener a las personas correctas involucradas, funcionará sin importar cómo lo organices. Si involucra a las personas equivocadas, se derrumbará sin importar qué tan bien lo organice. Mi impresión es que "las personas adecuadas" tienden a ser personas que quieren hacer las cosas, se preocupan por hacerlo bien, no tienen ego por hacerlo a su manera y no intentan crear feudos. Buena suerte para encontrarlos y animarlos a sentirse como en casa.

    
respondido por el btilly 22.06.2013 - 05:28
4

Compartir en secreto puede ser útil para proporcionar acceso a un secreto (como una contraseña) de una manera que varias personas deben acepta acceder a ella. Esto podría ayudar con el problema de "Matz es golpeado por un autobús": una persona a cargo usa el secreto a diario, mientras que un grupo de personas puede obtener acceso si algo le sucede al líder. (Por supuesto, si un número suficiente de ellos se deshiciera, todavía podrían tomar el control del dictador, pero ... ¿en serio?) Como una idea descabellada ... alguien podría implementar un intercambio secreto en Rebol (con cuidado, debe ser seguro, ya que se le confía el secreto) y luego podría cumplir la doble función de ser una copia de seguridad del secreto y ser uno de los programas de demostración en rebol.org. Lo bueno de hacerlo de esta manera es que todos los codificadores de Rebol pueden verificar el sistema, está en el idioma que conocen.

Otros pensamientos: Creo que debería hacer bien en pensar cómo va a financiar los dominios y otra infraestructura pública. Me parece que quienquiera que esté pagando por la infraestructura, en última instancia, la controla, por lo que podría ser algo a tener en cuenta. Por ejemplo, si el creador proporciona los dominios, parece que en última instancia tiene control sobre la existencia de los sitios. Tal vez eso puede estar involucrado en la configuración.

También puede encontrar algunos pensamientos interesantes en este ensayo de Eric Raymond , particularmente esta parte . Él habla allí sobre las diferentes maneras en que los proyectos de código abierto obtienen a sus "propietarios", ya sea que sean el desarrollador original o un sucesor.

Algunas otras comunidades a las que puedes echar un vistazo para obtener ideas:

Debian:

Debian es probablemente más grande de lo que estás pensando, pero aquí hay un par de enlaces rápidos con respecto a su estructura organizativa: Acerca de Debian y Organización

Perl: @btilly mencionó la estructura organizativa de Perl, y resulta que su dominio parece estar bajo el control de un individuo (¡quién no es Larry Wall!): Whois ; sitio web . Además, puede consultar enlace y enlace . Se siente (para un rezagado como yo) que la Fundación Perl ha logrado reunir varias partes sin destruir sus diferencias. Por ejemplo, PerlMonks parece haber sido un sitio independiente y ahora ha sido "asimilado por la Fundación Perl" según su pie de página.

    
respondido por el andyg0808 22.06.2013 - 10:29

Lea otras preguntas en las etiquetas