The Open Governance Index: Results for The R Project

Just over two weeks ago, I invited readers to complete the Open Governance Index (OGI) Questionnaire regarding The R Project. The OGI evaluates several facets of governance in open source projects (OGI publication). The OGI questionnaire is reproduced below, and each question is linked from the table of useR responses.

The table below presents the median useR response for each criteria versus other open source projects, as reported by VisionMobile. Governance of The R Project scored more ‘open’ than Android, but less ‘open’ than the other seven projects.

Brian Ripley’s talk last week at useR! 2011 was illuminating here. Brian was explicit that The R Project is governed by a “self-perpetuating oligarchy”, a group with “a lot of power” (as opposed to money, he quips), and that “R was principally developed for the benefit of the core team.” Yet, in more recent development, the R Core members have generally acted altruistically. Though I am agnostic regarding best governance practices, I think the R Core philosophy, as conveyed during Brian’s talk, is conflicting with some facets of the Open Governance Index.

R versus Other Projects

In total, 9 useRs completed the questionnaire. The raw responses are listed below.

The OGI attempts to assess only objective criteria of open source governance. That is, the questionnaire was not intended to collect opinion. Hence, there were several unexpected discrepancies in the responses. The cause of these disagreements may be due to unclear questions, respondents who guessed, or because governance of The R Project has some ambiguous aspects. In one case, a respondent simply selected the most ‘open’ response for each question, which is clearly incorrect.

Raw OGI useR Responses

The Open Governance Index Questionnaire

source_code – 1. Is source code freely available to all developers, at the same time?

• 4. Yes
• 3. No – discriminates with regard to developers, source code, or time
• 2. No – discriminates with regard to two of the above
• 1. No – discriminates with regard to all of the above

license – 2. Is source code available under a permissive OSI-approved license?

• 4. Yes – approved license and permissive (e.g. Apache, BSD, MIT)
• 3. Yes – approved license and weak copyleft (e.g. Eclipse Public License, GNU LGPL v2/v3)
• 2. Yes – approved license and strong copyleft (e.g. GNU GPL v2/v3)
• 1. No – unapproved license/proprietary license

support_mechanisms – 3. Developer support mechanisms – Are project mailing lists, forums, bug-tracking databases, developer documentation and tools available to all developers?

• 3. Yes – developer support mechanisms open to all developers
• 2. No – developer support mechanisms are limited, e.g., restricted access to bug-tracking database
• 1. No – there are poor developer support mechanisms

roadmap – 4. Is the project roadmap publicly available?

• 4. Yes – full roadmap available, with explicit call for contributions to the roadmap
• 3. Yes – roadmap information available but no call for contributions or similar
• 2. No – no formal roadmap exists, but there are committer or contributor requests to bug-tracking software
• 1. No

decision_making – 5. Transparency of decision mechanisms – Are project meeting minutes publicly available to understand decision-making in the project?

• 4. Yes
• 3. Yes – there is some information, but it is hard to find and doesn’t appear comprehensive
• 2. No – but the intent is to provide more information and make the process more open
• 1. No

access_total – 6. Computed Field:
[source_code] + [license] + [support_mechanisms] + [roadmap] + [decision_making]

acceptance_process – 7. Transparency of contributions and acceptance process – Is the code contribution and acceptance process clear, with progress updates of the contribution provided (via Bugzilla or similar)?

• 4. Yes – contributions and acceptance process are clear, with progress status of contributions provided
• 3. Yes – contributions process and acceptance process are clear, but no progress status of contributions provided
• 2. No – contributions process only, with progress status of contributions provided
• 1. No – contributions process only, no progress status of contributions provided

contributor_identity – 8. Transparency of contributions to the project – Can you identify from whom source code contributions are provided?

• 4. Yes – there are good project statistics that provide this information
• 3. Yes – but you must manually find and collate the information from various project sources
• 2. No – although you may be able to find this information by checking the copyright notices attached to each file/contribution
• 1. No

commit_access – 9. Accessibility to become a committer – are the requirements/process to become a committer documented and is this an equitable process, i.e., can all the developers potentially become committers?

• 3. Yes – the process is documented and accessible to all developers
• 2. No – the process is vague/unclear so we do not know if it is accessible to all developers
• 1. No – commit access is restricted to specific users/members of the Project only

committer_identity – 10. Transparency of committers – Can you identify who committers to the open source project are? i.e., those developers that have the authority to ‘commit’ source code to the baseline

• 3. Yes – there are good project statistics that provide this information
• 2. Yes – but you must manually find and collate the information from various project sources
• 1. No – this information is not provided

contribution_license – 11. Does the contribution license require a copyright assignment, or copyright license and/or patent license?

• 4. Yes – project requires a copyright assignment and patent grant
• 3. Yes – project requires a copyright license and patent grant
• 2. Yes – project requires a copyright license/’sign-off’ process
• 1. No – no contribution license

development_total – 12. Computed Field:
[acceptance_process] + [contributor_identity] + [commit_access] + [committer_identity] + [contribution_license]

trademarks – 13. Are trademarks used to control how and where the platform is used via enforcing a compliance process prior to distribution?

• 2. No – You can freely distribute the code and use the project trademark without completing formal compliance requirements
• 1. Yes – code must go through a formal compliance process prior to distribution to other parties

go_to_market – 14. Are go-to-market channels for application derivatives constrained by the project in terms of approval, distribution, or discovery?

• 4. No
• 3. Yes – restricted by approval, distribution, or discovery
• 2. Yes – restricted by two or more of approval, distribution, or discovery
• 1. Yes – restricted by all, i.e., approval, distribution, and discovery

derivatives_total – 15. Computed Field:
[trademarks] + [go_to_market]

member_rights – 16. Is the formal community structure flat or tall, i.e. tiered rights depending on membership status

• 2. No – there is no formal membership or discrimination between the rights of members and non-members from a development/access perspective
• 1. Yes – there are tiered rights depending on membership status

criteria_total – 17. Computed Field:
[access_total] + [development_total] + [derivatives_total] + [member_rights]