Las redes sociales alcanzan el hospedaje de proyectos en fuente abierta

Comprenda el mundo de los sitios como GitHub y BitBucket

Los revolucionarios efectos de las redes sociales no pasaron por alto el mundo del desarrollo de software. Muchos servicios surgieron para respaldar la colaboración en proyectos en Internet, especialmente en el mundo del software de fuente abierta. Los conceptos como control de versión distribuido, derivación de rutina y solicitudes de obtención de cambios están modificando de alguna manera el proceso básico de desarrollo en grupo. Una de las redes sociales más populares de colaboración de software es GitHub, cuyo lema es "Codificación social". Obtenga más información sobre las redes sociales de desarrollo en el contexto de GitHub pero con principios aplicables a otros sitios, como BitBucket, e incluso a los sistemas internos de su organización.

Uche Ogbuji, Partner, Zepheira, LLC

Photo of Uche OgbujiUche Ogbuji es asociado en Zepheira donde supervisa la creación de catálogos web sofisticados y otras bases de datos considerablemente contextuales. Tiene una larga trayectoria como pionero en tecnologías web avanzadas, como XML, web semántica y servicios web, y en proyectos en fuente abierta, como Akara, una plataforma de fuente abierta para aplicaciones de datos web. Es técnico informático y escritor. Nació en Nigeria, y vive y trabaja cerca de Boulder, Colorado, EE. UU. Para obtener más información sobre el Sr. Ogbuji, visite su blog, Copia.



13-07-2012

Visión general

Los desarrolladores de software han sido los primeros en adoptar las redes sociales, por lo que no es sorprendente que estén surgiendo redes para abordar el mundo especial de colaboración entre desarrolladores y, especialmente, desarrolladores de fuente abierta. El mundo de fuente abierta cuenta, desde hace tiempo, con servicios de hospedaje para proyectos, el más conocido es SourceForge. Durante mucho tiempo, estos servicios fueron desarrollados, en gran medida, sobre principios "Web 1.0", los cuales quedaron algo obsoletos a medida que muchos otros desarrollos revolucionaban la manera en que las personas interactuaban en la web.

En el centro de la mayoría de los sitios de proyectos en fuente abierta estaban los sistemas centralizados de administración de código fuente (source-code management, SCM), como CVS y, más tarde, Subversion. Al mismo tiempo, surgía un nuevo tipo de SCM, denominado sistema de control (o revisión) de versión distribuido (o descentralizado) (distributed version control system, DVCS). La idea principal de los DVCS es que en lugar de tener un árbol de origen central y canónico, se ofrece un sistema de múltiples copias de trabajo. Esto significa que múltiples desarrolladores pueden colaborar en un proyecto, incluso si se conectan de manera muy esporádica.

Las interacciones entre estas copias de trabajo distribuidas se parecen un poco a las interacciones entre las personas en las redes sociales. Por lo tanto, los sitios de hospedaje de proyectos se desarrollan naturalmente entre conceptos de DVCS con características sociales, de acuerdo con el modelo de código compartido. En la actualidad, algunos de los DVCS más populares son Mercurial, Git y Bazaar, y cada uno tiene un conocido servicio estrechamente asociado, como BitBucket, GitHub y Launchpad respectivamente.

En este artículo, se ofrece información sobre sitios de hospedaje de proyectos basados en características de redes sociales y DVCS, con especial énfasis en GitHub. El lector debe contar con algunos conocimientos sobre sistemas de control de versión, pero no necesariamente sobre DVCS.

Conceptos básicos sobre la colaboración a través de DVCS

Al utilizar un DVCS para colaboración, una primer usuaria, lo llamaremos Alice, crea el repositorio de código y, luego, lo comparte quizás en primera instancia con un colega, Bob. Alice puede compartir su repositorio con otras personas en la misma máquina o lo puede pasar a un disco de almacenamiento, como también a través de una red. Bob clona su repositorio con un programa de DVCS compatible y ahora cuenta con un repositorio propio basado en el código de Alice. El repositorio de Bob se inicia con el mismo contenido que el de Alice, pero tiene identidad y ciclo de vida propios. Esta es la principal diferencia entre DVCS y los repositorios centralizados.

Clonar un repositorio es, de hecho, derivar un proyecto, debido a la identidad y al ciclo de vida independientes del nuevo repositorio. Solía existir una tendencia hacia una percepción negativa sobre la derivación de proyectos de software, en parte debido a los famosos ejemplos de derivaciones relacionados con fallas sociales de colaboración dentro de un proyecto. Uno de esos ejemplos fue la cisma en Emacs, el venerable y respetado editor de texto y el sistema de herramientas del programador. El proyecto XEmacs se convirtió en un proyecto de separación liderado por los disgustados ex desarrolladores de Emacs. DVCS ha eliminado el contexto social de la derivación y lo convirtió en una parte genérica del proceso de colaboración. Sin dudas, si Bob y Alice hubieran discutido y decidían seguir cada uno por su lado en el proyecto, en algún punto, podrían continuar a partir de una derivación pero posiblemente utilizarían la derivación como una parte natural de su cooperación.

Registro de los cambios

En particular, es posible que Bob y Alice deseen realizar actualizaciones separadas a sus propios repositorios; quizás, Bob está trabajando en la interfaz del usuario y Alice está trabajando en la lógica central del programa. En algún momento, les gustaría reunirse y combinar los frutos de su trabajo. Habrán acumulado conjuntos de cambios separados en sus repositorios individuales. Un conjunto de cambios es una colección de actualizaciones realizadas a los archivos, la cual se registró en un momento al emitir un comando "confirmar" a través de DVCS.

En un sistema de control de versión centralizado, los conjuntos de cambios son confirmaciones realizadas en el repositorio principal, identificadas por números de revisión en aumento. La primera confirmación, realizada por Bob, podría ser la revisión 1.1, la segunda podría ser 1.2 y así sucesivamente. Esto no tiene sentido en el caso del DVCS, en el cual no hay un repositorio central y no se puede administrar de manera global el orden de los cambios, por lo que, en su lugar, a cada conjunto de cambios se le asigna un símbolo numeral, que está diseñado para ser exclusivo en todos los repositorios. Consulte la Figura 1 en la que se ilustra la clonación inicial y el progreso de los conjuntos de cambios individuales entre Bob y Alice. Los asteriscos marcan los puntos en los que los repositorios de Bob y Alice tienen el mismo estado (cuando Bob clonó su copia inicial del código de Alice).

Figura 1. Intercambio inicial con DVCS
Intercambio inicial con DVCS

Cuando Bob y Alice quieren combinar su trabajo, lo hacen mediante la negociación de conjuntos de cambios y la resolución de conflictos hasta que puedan obtener un nuevo repositorio que represente su trabajo combinado como lo desean. Para iniciar este proceso, Bob puede "obtener" los cambios del repositorio de Alice o viceversa. Nuevamente, la forma en que se realiza no importa y se basa exclusivamente en las circunstancias de su colaboración. Es posible que la dirección de obtención de cambios entre Bob y Alice se invierta de vez en cuando, posiblemente según su propia voluntad.

Mecánica de integración

Cuando Bob obtiene los cambios de Alice, el DVCS se aplicará a cada conjunto de cambios de Alice, en orden, para la versión local de Bob. Es posible que un conjunto de cambios provoque un conflicto, quizás si Bob y Alice modifican la misma línea en un algún lugar del archivo o si Bob actualiza un archivo que Alice quitó de su repositorio. En caso de conflicto, el software de DVCS podría solucionar una integración automática o podría requerir intervención de Bob para obtener el resultado integrado.

Una vez que Bob haya obtenido los conjuntos de cambios de Alice, podrá actualizar el resultado integrado a Alice. El DVCS procesará los conjuntos de cambios de Bob del último punto de integración y reconocerá que algunos de esos conjuntos de cambios pertenecen a Alice, los cuales ya se aplicaron al repositorio de Bob. Los símbolos numeral exclusivos son clave aquí para determinar la identidad de los conjuntos de cambios en este proceso. Cuando finaliza la actualización, Alice y Bob tendrán el mismo contenido en cada uno de sus repositorios. Consulte la Figura 2 en la que ilustra el proceso de obtención de cambios/integración/actualización. Tenga en cuenta que se crea un nuevo estado compartido entre Bob y Alice.

Figura 2. Integración de los conjuntos de cambios con DVCS.
Integración de los conjuntos de cambios con DVCS.

Este proceso tiene muchas variaciones y sutilezas, algunas son exclusivas para determinadas implementaciones de DVCS pero solo abordaré una de las cuestiones más comunes a las que se enfrentan los nuevos usuarios de DVCS.

Supongamos que en el proceso anterior, Bob se olvida de obtener los cambios de Alice antes de actualizar sus cambios en el repositorio de Alice. En este caso, el software de DVCS notará que Bob se bifurcó del último punto de integración con el repositorio de Alice. Uno de los principios básicos de DVCS es que el conjunto de cambios solo se aplica a un estado inicial conocido del punto del repositorio, denominado ancestro común. Debido a que los conjuntos de cambios de Bob existen con respecto al ancestro común desde que clonó por primera vez a partir del código de Alice, el DVCS retrocedería de hecho a ese estado antes de aplicar esos conjuntos de cambios. Esto establecería los conjuntos de cambios de Alice desde el ancestro común en una bifurcación separada, lo cual no es lo que Bob y Alice desearían habitualmente. Generalmente, el DVCS emite una advertencia en este caso sobre la operación de actualización y crea "múltiples encabezados". Bob podría abortar la actualización y, luego, obtener los cambios de Alice, lo que se integraría con los conjuntos de cambios de Alice en la misma bifurcación que la suya. El resultado de la obtención de cambios es una sola bifurcación que contiene los conjuntos de cambios de Bob y Alice obtenidos del ancestro común. En este estado, Bob puede realizar la actualización en los datos de Alice sin el problema de generar "múltiples encabezados".


Implicaciones sociales de las interacciones básicas de DVCS

DVCS aporta gran flexibilidad al proceso pero los proyectos deberían sobreponer algún flujo de trabajo más amplio al uso básico, especialmente a medida que más gente participa, con diferentes funciones y niveles de interacción. Por lo general, habrá un repositorio reconocido, el cual comienza a parecerse al repositorio centralizado anterior pero solo de manera casual. La derivación simplemente es fácil y habitual, y existen repositorios regularmente numerosos dispersos entre las personas que tienen algún interés en el proyecto, y es solo por convención que los participantes evitan el caos. Este es el caso especial de los proyectos en fuente abierta, en los que cualquier persona puede clonar u obtener cambios del repositorio principal. El líder o los líderes del proyecto identificarán su repositorio principal y otorgarán permiso a los colaboradores confiables para que actualicen los cambios.

La solicitud de obtención de cambios

En un proyecto en fuente abierta sólido no todos los contribuyentes son colaboradores confiables. La mayoría de los sitios clásicos de hospedaje de proyectos tenían identificadores de parches que acompañaban a los identificadores de problemas. Cualquier persona puede enviar un parche para un proyecto, el cual, luego, se rastrea mientras un desarrollador principal lo examina y, quizás, interactúa con la persona que lo envía, con el fin de realizar cambios. Finalmente, el parche se puede aplicar al repositorio principal del proyecto.

Debido a la naturaleza del DVCS y a la administración minuciosa de los conjuntos de cambios, existe la posibilidad de mejorar un poco el proceso. En especial, el sistema anterior de envío de parches, con frecuencia, perdía el historial particular de los cambios que generaban el parche. Con DVCS, el contribuyente puede obtener los cambios del repositorio principal, desarrollar sus propios cambios en su repositorio de trabajo, realizar la confirmación habitual y, luego, enviar los conjuntos de cambios obtenidos para que se revisen y discutan. Este proceso se comenzó a conocer como solicitud de obtención de cambios o "pull request". De hecho, el contribuyente solicita que un desarrollador principal obtenga cambios del repositorio de trabajo con los cambios propuestos y, luego de la discusión para mejorar los cambios, actualice esos conjuntos de cambios en el repositorio principal.

En los sistemas como GitHub, la característica de obtención de cambios (consulte Recursos) se trata de establecer una interfaz cómoda en el flujo de trabajo de la nominación de un repositorio para iniciar una solicitud de obtención de cambios, la discusión de los cambios propuestos y, luego, la aplicación de los conjuntos de cambios obtenidos en un repositorio objetivo.

Seguidores y popularidad

Ninguna red social está completa sin algún sistema para que las personas puedan seguir a otras y sin el concurso de popularidad que se genera. Los principales sitios de DVCS no son diferentes. Puede decidir seguir a un desarrollador o un proyecto si descubre que sus proyectos son interesantes, y el desarrollador recibe una notificación sobre esto y puede elegir seguirlo a usted también. El vocabulario puede variar, por ejemplo, en GitHub, se "sigue" a una persona pero se "observa" un proyecto, aunque el concepto es parecido al de Twitter y Facebook, con una dinámica social similar. Por ejemplo, las impresiones surgen de la influencia de un desarrollador o la solidez de un proyecto a partir del recuento de seguidores, y esto puede jugar un papel en la dinámica social que se podría superponer con DVCS, como qué derivación "gana" en la derivación mordaz.


Conclusión

El software de fuente abierta se ha desarrollado en gran medida y se ha convertido en una parte importante del panorama tecnológico global. Este crecimiento se ha tratado esencialmente de trabajo arduo pero también de personalidades y apoyo. Me gustaría poder decir que en el caso de las redes sociales que intentan representar el proceso de colaboración de fuente abierta, lo importante es el código y todo lo demás es secundario. Desafortunadamente, no se puede sacar lo social de una red social. Si participa en sitios como GitHub, al seguir su interés en una red social, ya sea como usuario, contribuyente de un proyecto o como líder de su propio proyecto, es importante comprender el flujo de trabajo de la herramienta subyacente, como así también las insinuaciones e implicaciones sociales que acompañan el intercambio de bits.

Las sugerencias habituales se aplican a la red social: comuníquese con las personas como lo haría personalmente, evite ser sensible y esté preparado para ignorar los conflictos personales no productivos, y, sobre todo, genere su mejor código que atraerá seguidores e incluso a contribuyentes. Los sitios como GitHub facilitan un inicio lento antes de que, quizás, comience a colaborar más en grandes proyectos. Espero que este artículo lo ayude a comprender la generación emergente de sitios de hospedaje de proyectos.

Recursos

Aprender

Obtener los productos y tecnologías

  • GitHub es un popular sitio de hospedaje de proyectos donde los repositorios de códigos se administran con el DVCS de Git .
  • BitBucket es un sitio de hospedaje de proyectos que está estrechamente asociado con el DVCS de Mercurial, pero también es compatible con Git.
  • Acceda al software de prueba IBM (disponible en DVD o para descargarse) y experimente con su próximo proyecto de desarrollo en código abierto, mediante el software destinado especialmente para desarrolladores.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=825095
ArticleTitle=Las redes sociales alcanzan el hospedaje de proyectos en fuente abierta
publish-date=07132012