{"id":2738,"date":"2026-10-30T16:48:43","date_gmt":"2026-10-30T15:48:43","guid":{"rendered":"https:\/\/moevec.org\/blog\/?p=2738"},"modified":"2026-10-30T16:48:43","modified_gmt":"2026-10-30T15:48:43","slug":"colaboracion-abierta-wikipedia-software-libre","status":"publish","type":"post","link":"https:\/\/moevec.org\/blog\/colaboracion-abierta-wikipedia-software-libre\/","title":{"rendered":"Colaboraci\u00f3n abierta: lo que ense\u00f1an Wikipedia y el software libre"},"content":{"rendered":"

La colaboraci\u00f3n abierta permite que personas distintas propongan mejoras a un trabajo compartido. Para que esas contribuciones formen algo \u00fatil, hacen falta decisiones sobre revisi\u00f3n, integraci\u00f3n y desacuerdos. Wikipedia y Linux ofrecen ejemplos con reglas propias. MEE los examina para pensar el reconocimiento de aportes, sin presentar la apertura como garant\u00eda de calidad o ausencia de autoridad.<\/p>\n

La catedral y el bazar: una met\u00e1fora con condiciones<\/h2>\n

En The Cathedral and the Bazaar<\/em><\/a>, Raymond contrapone estilos de desarrollo a partir de Linux y de su experiencia con fetchmail. El historial del ensayo recoge una presentaci\u00f3n en 1997 y su incorporaci\u00f3n al libro de 1999. La versi\u00f3n consultada incluye revisiones posteriores; conviene diferenciar esos documentos antes de atribuirles una fecha \u00fanica.<\/p>\n

El bazar de Raymond no se limita a invitar a cualquiera a trabajar. Su apartado sobre condiciones previas considera la existencia de algo que pueda probarse y las capacidades de coordinaci\u00f3n y comunicaci\u00f3n. Es una argumentaci\u00f3n del autor desde experiencias de software, no un experimento que pruebe un m\u00e9todo superior para toda clase de organizaci\u00f3n.<\/p>\n

La lectura de MEE es que una invitaci\u00f3n necesita un objeto comprensible: qu\u00e9 se est\u00e1 intentando hacer y qu\u00e9 puede aportar quien llega. Abrir una convocatoria sin materiales ni forma de respuesta puede dejar la participaci\u00f3n en una promesa. Proponemos concretar una primera tarea y explicar c\u00f3mo se examinar\u00e1 antes de pedir un compromiso mayor.<\/p>\n

Benkler: compartir recursos tambi\u00e9n requiere reglas<\/h2>\n

En el cap\u00edtulo tercero de The Wealth of Networks<\/em>, de 2006<\/a>, Benkler analiza producci\u00f3n entre pares basada en recursos compartidos. La coordinaci\u00f3n descrita no depende \u00fanicamente de \u00f3rdenes de una empresa o de precios por cada tarea. Al explicar los comunes, distingue adem\u00e1s formas de acceso y regulaci\u00f3n: compartir no equivale necesariamente a permitir cualquier uso sin condiciones.<\/p>\n

MEE recoge esa distinci\u00f3n para preguntar qu\u00e9 se puede utilizar, modificar o integrar en un proyecto. El permiso para consultar un recurso y la decisi\u00f3n sobre una contribuci\u00f3n no son id\u00e9nticos. Una comunidad necesita explicar ambos. Si intervienen licencias, deben revisarse sus condiciones concretas; esta entrada no ofrece una autorizaci\u00f3n general para reutilizar materiales ajenos.<\/p>\n

Tambi\u00e9n proponemos evitar la idea de que colaborar exige tener la misma motivaci\u00f3n. Inter\u00e9s por aprender, utilidad de una tarea o compromiso con un prop\u00f3sito pueden ser razones distintas. La pregunta de dise\u00f1o es c\u00f3mo se acuerda una contribuci\u00f3n concreta y qu\u00e9 puede esperar quien la realiza. No corresponde atribuir altruismo o beneficio econ\u00f3mico a toda persona que participa.<\/p>\n

Gobernanza de Wikipedia: argumentos y herramientas distintas<\/h2>\n

La pol\u00edtica de consenso de Wikipedia en ingl\u00e9s<\/a> describe un proceso continuo que considera argumentos, objeciones y reglas del sitio. No reduce la decisi\u00f3n a contar apoyos. Tambi\u00e9n contempla formas de pedir otras opiniones y resolver desacuerdos. Es documentaci\u00f3n del funcionamiento previsto, no una prueba de que toda discusi\u00f3n termine bien.<\/p>\n

Su p\u00e1gina sobre administradores<\/a> distingue herramientas y responsabilidades de conducta de la autoridad para imponer una preferencia de contenido. Esa separaci\u00f3n ayuda a entender por qu\u00e9 editar en una enciclopedia abierta no significa que cualquier versi\u00f3n deba permanecer. Las decisiones siguen sujetas a reglas y a \u00e1mbitos de responsabilidad.<\/p>\n

Para MEE, el ejemplo invita a describir qu\u00e9 decisi\u00f3n toma cada funci\u00f3n. Moderar una conducta, comprobar una fuente y elegir una redacci\u00f3n no son tareas intercambiables. Proponemos que un procedimiento explique d\u00f3nde se plantea una objeci\u00f3n y qu\u00e9 informaci\u00f3n debe acompa\u00f1arla. La existencia de una herramienta de control no deber\u00eda presentarse como reconocimiento autom\u00e1tico de mayor valor personal.<\/p>\n

\"Varias
Las contribuciones compartidas necesitan reglas, revisi\u00f3n y formas de resolver desacuerdos.<\/figcaption><\/figure>\n

Linux: proponer c\u00f3digo no equivale a integrarlo<\/h2>\n

La gu\u00eda de env\u00edo de cambios del kernel Linux<\/a> pide describir el problema, justificar la soluci\u00f3n y atender la revisi\u00f3n. Tambi\u00e9n orienta a localizar destinatarios y mantenedores pertinentes. El proceso muestra que una aportaci\u00f3n abierta necesita ser comprensible para quienes la examinan; su env\u00edo no garantiza aceptaci\u00f3n.<\/p>\n

Esta documentaci\u00f3n permite hablar de contribuciones y revisi\u00f3n, sin afirmar que todo el proyecto funcione como una votaci\u00f3n universal. Tampoco basta una etiqueta de meritocracia del c\u00f3digo para explicar todas sus decisiones. MEE propone mirar el procedimiento concreto: qu\u00e9 se solicita, qui\u00e9n revisa y c\u00f3mo se responde a los problemas detectados.<\/p>\n

La lecci\u00f3n que proponemos trasladar es limitada: una contribuci\u00f3n deber\u00eda incluir informaci\u00f3n suficiente para ser examinada. En una comunidad editorial, eso puede significar aclarar una fuente, una correcci\u00f3n o el alcance de una propuesta. La analog\u00eda no convierte la revisi\u00f3n de un texto en desarrollo de software ni demuestra que sus reglas puedan copiarse sin adaptaci\u00f3n.<\/p>\n

C\u00f3mo preparar una contribuci\u00f3n que pueda revisarse<\/h2>\n

MEE propone empezar por una tarea delimitada. Describe qu\u00e9 problema observas, qu\u00e9 cambio sugieres y qu\u00e9 parte puedes asumir. Incluye la informaci\u00f3n necesaria para que otra persona lo examine sin adivinar tu intenci\u00f3n. Si no entiendes el formato, pide una orientaci\u00f3n concreta: una comunidad que invita a colaborar necesita poder explicar sus requisitos de entrada.<\/p>\n

Ejemplo hipot\u00e9tico:<\/strong> una persona encuentra un dato desactualizado en un documento com\u00fan. En lugar de sustituir varias p\u00e1ginas, presenta el pasaje, una fuente y una correcci\u00f3n acotada. El grupo puede revisar cada elemento y pedir aclaraciones. El caso no promete aceptaci\u00f3n: muestra una forma de hacer discutible el aporte y de conservar razones cuando se modifica.<\/p>\n

La revisi\u00f3n tambi\u00e9n es una contribuci\u00f3n. Quien se\u00f1ala una duda deber\u00eda explicar qu\u00e9 necesita comprobarse y por qu\u00e9 importa para la tarea. Proponemos distinguir un problema verificable de una preferencia de estilo o de una descalificaci\u00f3n personal. Si el desacuerdo persiste, conviene que exista una v\u00eda conocida para pedir otra revisi\u00f3n o cerrar la decisi\u00f3n con razones.<\/p>\n

El mejor argumento en contra: apertura con barreras y exclusi\u00f3n<\/h2>\n

La objeci\u00f3n m\u00e1s fuerte es que poder enviar una propuesta no garantiza tener una oportunidad real de participar. Los formatos, el tiempo necesario y el acceso a orientaci\u00f3n pueden dificultar la entrada. Esta es una preocupaci\u00f3n de dise\u00f1o que MEE considera pertinente; no una medici\u00f3n de exclusi\u00f3n atribuida aqu\u00ed a cada proyecto citado.<\/p>\n

Ejemplo hipot\u00e9tico:<\/strong> un grupo acepta aportes nuevos, pero solo explica sus decisiones en conversaciones dif\u00edciles de localizar. Una persona que ya conoce a sus miembros entiende qu\u00e9 se espera; otra abandona sin saber c\u00f3mo corregir su propuesta. La regla de acceso formal sigue abierta, pero el grupo necesita revisar d\u00f3nde publica instrucciones y c\u00f3mo responde a las dudas.<\/p>\n

MEE propone atender esa objeci\u00f3n sin exigir que se acepte cualquier entrega. Puede mantenerse un criterio de calidad y ofrecer instrucciones visibles, explicaciones de rechazo y tareas de aprendizaje. El procedimiento necesita revisar si sus exigencias son pertinentes. Tambi\u00e9n debe poder reconocer l\u00edmites de capacidad: abrir m\u00e1s solicitudes de las que se pueden atender merece una respuesta clara.<\/p>\n

La reputaci\u00f3n puede orientar una consulta, pero no sustituye las razones sobre el trabajo presentado. Proponemos evitar que una trayectoria convierta cada preferencia en una regla indiscutible. La revisi\u00f3n de una aportaci\u00f3n nueva deber\u00eda poder explicar su decisi\u00f3n con informaci\u00f3n pertinente y permitir corregir errores. La apertura se examina en esas pr\u00e1cticas, adem\u00e1s de en la invitaci\u00f3n inicial.<\/p>\n

\"Una
La apertura de un proyecto convive con responsabilidades concretas de coordinaci\u00f3n y mantenimiento.<\/figcaption><\/figure>\n

La lectura de MEE de la colaboraci\u00f3n abierta<\/h2>\n

Para MEE, reconocer aportes requiere hacer visibles tareas, criterios y responsabilidades. La colaboraci\u00f3n abierta puede ofrecer una v\u00eda de participaci\u00f3n que necesita cuidado y revisi\u00f3n. Los ejemplos de Wikipedia y Linux muestran procedimientos espec\u00edficos; no un modelo sin autoridad, conflictos o costes. La pregunta \u00fatil es qu\u00e9 decisiones puede comprender y discutir quien llega.<\/p>\n

Proponemos conservar espacios para proponer, aprender, revisar y rectificar. Eso exige explicar qu\u00e9 se acepta, qui\u00e9n responde y c\u00f3mo se resuelve un desacuerdo. Son orientaciones editoriales para el dise\u00f1o de una comunidad. Esta entrada no anuncia cuentas, permisos, repositorios colaborativos o sistemas de reconocimiento ya operativos en MEE.<\/p>\n

Qu\u00e9 puedes hacer t\u00fa<\/h2>\n

Lee las reglas actuales del proyecto al que quieres aportar y elige una tarea que puedas describir. Aclara qu\u00e9 parte realizaste y qu\u00e9 ayuda necesitas. Si coordinas, revisa si una persona nueva puede encontrar instrucciones y recibir una respuesta comprensible. Ante un rechazo, pide razones sobre la contribuci\u00f3n y conserva la posibilidad de aprender o rectificar.<\/p>\n

Preguntas frecuentes<\/h2>\n

\u00bfUn proyecto abierto funciona sin responsables?<\/h3>\n

La apertura no permite concluirlo. Los ejemplos citados tienen procedimientos y responsabilidades concretas para revisar cambios o atender conductas. MEE propone explicar qu\u00e9 decide cada funci\u00f3n y c\u00f3mo puede revisarse una objeci\u00f3n. La posibilidad de contribuir no equivale a que toda propuesta se integre ni a una ausencia de autoridad o reglas.<\/p>\n

\u00bfTener m\u00e1s reputaci\u00f3n hace correcta una propuesta?<\/h3>\n

Una trayectoria puede orientar a qui\u00e9n consultar, pero necesita acompa\u00f1arse de razones pertinentes para la tarea. MEE propone examinar la contribuci\u00f3n, la informaci\u00f3n que la sostiene y las objeciones. La reputaci\u00f3n no convierte cualquier preferencia en una regla ni elimina la posibilidad de error. Una decisi\u00f3n deber\u00eda poder explicarse y corregirse.<\/p>\n

\u00bfMEE aplicar\u00e1 exactamente las reglas de Linux o Wikipedia?<\/h3>\n

Esta entrada examina ejemplos y propone criterios para discutir una comunidad. No anuncia que se hayan copiado sus reglas ni que existan cuentas o mecanismos colaborativos operativos. Cada proyecto tiene tareas y condiciones distintas. Cualquier dise\u00f1o de MEE necesita explicar su alcance, sus responsabilidades y sus l\u00edmites antes de presentarlo como disponible.<\/p>\n

Contenido educativo. No es asesoramiento financiero, fiscal ni legal. Consulta a un profesional de tu pa\u00eds.<\/p>\n

Para seguir aprendiendo<\/h2>\n