LibreOffice - Roles and responsabilities - OpenOffice

Firstly, let's go to see the case of LibreOffice, these are the different roles:

QA Tester
        Triage, prioritize and do in-depth analysis of bug reports and feature requests
        Do manual testing and test reporting
        Take part in localization QA.


UX/Visual Designers
        Design provides the visual basis for any tool.
        Transport usability, quality and emotions.
        Improving LibreOffice by visual means, inside the office suite, in user interaction and at any place where the product.
   
Localizers
        Help localize the LibreOffice user interface
        Help files into his language

Documenters
        Work on user guides and LibreOffice's built-in help system as part of the LibreOffice documentation team.
        Writing and reviewing are a key part of the workflow.
        Recruiting people to help out in other ways: screenshot production, indexing...

Marketers
        Attend FOSS events as part of an official Foundation Team.
        Publicize LibreOffice and The Document Foundation in media, at fairs and other events, etc.
        Take part in creating content and coordinating activities for special marketing initiatives.
        Work on research (such as marketing and feature research for future versions, usability research, etc.) 

Developers
        Work on code for the LibreOffice code base and extensions.
        Work on bug-fixing and submitting patches.

Web Admins
        Maintain and develop LibreOffice and Document Foundation online infrastructure: websites, servers, etc.

Donate
        Making a donation to help fund the community's work.

On the other hand, in Apache OpenOffice we can find

Observer
        Views, but does not change project resources.
        Read-only access to most project resources.
        Read-only access to web content and source code (CVS).
        Submits issue to issue tracking (IssueZilla)
        Subscribes and posts to project mailing lists.

Developer
        Contributes directly to project -- source code and HTML.
        Gains write access to most project resources.
        Write access to HTML, news utility, files utility, CVS, Issuezilla.
        Mailing list privileges the same.

Content Developer
        Contributes directly to project's web content (HTML).
        Gains write access to project's HTML, news utility, files utility, and Issuezilla.
        Mailing list privileges the same.

Project Owner
        Defines the project's overall mission, direction, methodology, and community make-up.
        Gains administrative access to all Project functions.
        Grants members requested permissions on project.
        Administers all project mailing lists and is default moderator on all lists.
        Administers Issuezilla.
        Project Owner role supersedes any other roles you may hold on a project.

It is important to note that LibreOffice seems to have a model of roles more detailed and richest, and with some specify role, like QA testers, Marketers, and Localizers.

References:
[0] LibreOffice - Get involved
[1] Apache OpenOffice Roles

R Governance Model

The purpose of this entry is to show whether the governance model of R project is a cathedral in the direction of Raymond's classic "Bazaar" article and based on meritocracy community. Let's go to analyze the following aspects of governance model: Overview, roles and responsibilities, support, decision making process, and contribution process.

    Overview
   
    The project objectives is to implement the R programming language, which is a language and environment for statistical computing and graphics. It is a GNU project and is available as Free Software under the terms of the Free Software Foundation's GNU General Public License. The copyright holder is by Robert Gentleman and Ross Ihaka for the first source code and after the R Core Team was added.
And how users can become involved with the development of the project, the starting point is R Developer Page with documentation about project development. 
       
    Roles and responsibilities
   
    The current R is the result of a collaborative effort with contributions from all over the world. R was initially written by Robert Gentleman and Ross Ihaka—also known as "R & R" of the Statistics Department of the University of Auckland.
    There is a core group with write access to the R source code, currently consisting of 22 members[3][4].
    Besides, there are many others that contributed by donating code, bug fixes and documentation.
   
    The R Foundation is a not for profit organization that holds and administers the copyright of R software and documentation. The principal organs of the “R Foundation” are: The general assembly, the board, the auditors, and the court of arbitration.
   
    The business transactions of the general assembly include:

1. Election and dismissal of the members of the board.
2. Election and dismissal of the auditors.
3. Acceptance of activity report, statement and estimates of account.
4. Release of the board.
5. Determination of membership fees.
6. Approval or rejection of proposed changes to these statutes.
7. The decision to terminate the “R Foundation”.
8. Discussion of and decisions on other topics of the agenda

The board of the organization consists of at least four persons:

1. Either a president and a vice-president or two presidents of equal rights
2. A secretary general.
3. A treasurer

The main board responsibilities:

1. Preparation of activity report, statement and estimates of account.
2. Preparation of and call for general assemblies.
3. Management of all assets.

There are two auditors who routinely check business and accounting of the organization and report to the general assembly.
   
    There is a Court of Arbitration to resolve the disputes.
   
    Support
   
        There are four general mailing lists devoted to R: R-announce, R-packages, R-help, and R-devel. Additionally, there are several specific Special Interest Group mailing lists. And to satisfy geographic or regional (or subject) needs, some R users have formed "R User Groups".
   
    Decision making process
   
    Court of Arbitration decides with majority vote, the chairman decides in case of a draw due to abstention.
        In particular, membership terminated process could be by the death of a person, by voluntary withdrawal and by an affirmative vote of a two-thirds majority of the ordinary members.
   
    Contribution process
   
The core team is the only that has access to the source code.

The R-devel list is intended for questions and discussion about code development in R, and the starting point to begin contribution.
   
Ordinary members have a vote in the general assembly. New ordinary members shall be admitted only by a majority vote of the existing ordinary members. Another role is supporting member, that could be any person or legal entity.
   
There is a posting guide with general instructions of how to use mail lists.
    
The project uses Bugzilla to manage bugs and subversion for software versioning and revision control system.
   
In conclusion, the governance model is a Cathedral composed by ordinary members, and base on meritocracy to be elected by the ordinary members. 
   
References:
[1] R project
[2] R Developer Page
[3] R Project Contributors
[4] R Foundation Members & Supporters
[5] Statutes of “The R Foundation for Statistical Computing”
[6] R bug

Modelo de gobierno en un proyecto de software libre

La variedad en proyectos de software libre es inmensa, superior sin dudas a los provectos de software privativo, la cuestión clara es que existe un modelo de gobierno en cada uno de ellos, pero cómo de homogenios o heterogenios son estos modelos es cuestionable. Lo cierto es que un marco de proyectos de software libre el estudio de estos es factible por ser un entorno abierto.

En los proyectos de software libre donde existe una base colaboradores importante, que no quiere decir muchos contribuidores, posiblemente hablamos a partir de 5. Existe siempre de manera implícita o explicita en el modelo de gobernanza un procedimiento para participar, proteger su trabajo y permitir compartirlo.

Los modelos de gobierno en los proyectos de software libre se mueven entre aquellos centralizados por una sola persona o organización, por ejemplo, Linux centralizado en Linux Torvald o proyectos como Emacs de GNU donde el desarrollo esta completamente controlado por la fundación GNU.
U otros constituidos como una meritocracia de sus miembros, por ejemplo, sería el proyecto R, completamente desarrollado por miembros "ilustres" de la comunidad y muy cerrado a la posibilidad de desarrollo. En el otro extremo de la apertura a la colaboración en comunidades de meritocracia, sería la fundación Apache con proyectos como Apache httpd.

Los proyectos de software libre suelen comenzar teniendo un modelo de gobernanza centralizado y cerrado a la participación, si lo comparamos con el software privativo ese es su modelo de gobernanza. Y a los largo de la evolución de los proyectos suelen ampliar sus grados de libertad de colaboración y su descentralización a modelos de meritocracia del los miembros de la comunidad. Pero es importante indicar que definir un modelo de gobernanza claro al inicio del proyecto es fundamental para que la comunidad alrededor del proyecto se dinamice y crezca.

El porqué unos proyectos evolucionan en una dirección de una comunidad gobernada por la meritocracia o mas abiertos a la participación es variado, desde la personalidad del líder o la organización gestora, hasta temas relacionados con el tamaño y perfil de los colaboradores, o evolución de la comunidad como la existencia de forks, o incluso razones asociadas al propio mercado, por ejemplo por una razón de posicionamiento como sería el caso de Android.

Establecido el modelo de gobernanza en un proyecto de software libre parece a primera vista que puede ser complicado llegar a tomar decisiones. Por ello en los modelos de gobernanza se tiene que documentar de manera explicita los procesos de toma de decisiones y quien aprueba cada una de las fases. En los procesos de toma de decisiones de las comunidades centralizadas parece más intuitivo, pero que ocurre en las comunidades gobernadas por meritrocacia. En algunos proyectos con este sistema, suelen tener un control débil sobre el proceso de toma de decisiones y permite de este modo a la comunidad de una manera consciente y mediantes mecanismos de votación la toma de decisiones. Donde podemos identificar dos modelos habituales de decisión:

• Consenso

      Ante una propuesta de un miembro de la comunidad, se analiza y debate por el resto de miembros, si la propuesta no es rechazada por ningún miembro de la comunidad durante un periodo de tiempo acordado, se considera tomada por consenso. Este consenso en algunos proyectos se categoriza como relajado(lazy), relajado mayoritario, consenso y unánime.
    

• Votaciones.

      Donde todos o parte de los miembros de la comunidad tienen derecho a participar en la discusión y en las votaciones. La votación suele utilizarse solamente para temas de bloqueo o en algunos caso legales.

Aunque las comunidades son en principio planas con miembros con los mismos derechos, la meritocracia evoluciona a tener miembros con un peso "moral" superior en la toma de decisiones dentro de la comunidad, conseguido por el numero y calidad de sus contribuciones.

Y que elementos debería tener un modelo de gobernanza:

• Roles y  responsabilidades: Es importante definir que diferentes roles pueden participar en el proyecto, si existe algún rol que sea responsable del proyecto o de parte, si existen comité. Hay que detallar las responsabilidades de cada uno de los roles.
• Soporte: Describe los procesos y canales de soporte para el usuario y colaborador. Es muy importante, ya que hay que tener en cuenta que los usuarios de hoy son los futuros contribuyentes.
• Proceso de toma de decisiones: Es critico conocer como se tomas las decisiones, que deber ser comunicado de manera clara y no ambigua.
• Proceso de participación: Se debe detallar la documentación, repositorios y todo lo que sea necesario para que un usuario que quiera participar lo pueda hacer.

Para finalizar es importante destacar que parece razonable pensar que un modelo claro de participación y comunicación, y por lo tanto su modelo de gobernanza, es básico para el crecimiento y sostenibilidad de un proyecto de software libre.

References:
[1] How the ASF works
[2] Mozilla Gobernance
[3] Governance Models
[4] Meritocratic Governance Model