On 6 Jan 2015, at 17:28, Bertrand Delacretaz wrote:
> Hi,
>
> Creating such a model has been on my todo list for ages, and in a
> related discussion on board@ people seem to agree that having this can
> be useful.
>
> So let's start - here's my rough initial list of items:
>
> Code: open, discoverable, fully public history, documented provenance
> Quality: security, backwards compatibility, etc
> Contributions: welcome from anyone based on technical quality
> License: Apache License, dependencies must not put additional restrictions
> Community: inclusive, meritocratic, no dictators, clear documented path to
> entry
> Discussions and decisions: asynchronous, in a single central place, archived
> Decision making: consensus, votes if needed, technical vetoes in the worst
> case
> Independence: from any corporate or organizational influence
> Releases: source code only, notices, long-lived release format
>
> Related efforts, inspiration:
>
> http://osswatch.jiscinvolve.org/wp/2014/12/11/open-or-fauxpen-use-the-oss-watch-openness-rating-tool-to-find-out/
The SSMM (Software Sustainability Maturity Model)[1] incorporates "Openness" as
one of the sections, the others being "Reusability" and "Capability".
The Openness Rating is used to measure the Openness (or freedom) aspect of the
project.
The OR tool looks at a project from several dimensions:
• Legal – the conditions surrounding the project source code. Usually
defined within the licence terms.
• Standards – the data, communication and other standards used within a
project, for example, APIs, protocols, & documentation norms.
• Knowledge – the documentation, project information, decisions made,
communication archives and any other content related to the project.
• Governance – the structure of the organisation that defines who
participates in a project and the terms of participation. Includes decision
making, and any practical or policy limitations on participation.
• Marketplace – the ability for any organisation to build a business
around a project. Includes practical, legal and technological limitations to
building an open marketplace around the project.
Reuse is measured using the Reuse Readiness Rating [2], which incorporates some
technical elements.
Capability is measured using a subset of CMMI [3], which focusses on process
maturity.
The three sets of measures are combined to position projects on a scale from 0
(Seed) to 8 (Dispersal)[1].
For our purposes at ASF, we need to limit how much we cover and measure
depending on the aims we're trying to meet.
I think we also need to discuss whether we expect projects to undertake
self-evaluation and reflection, or whether we'd have a process of review
involving peers, mentors, shepherds etc.
(I presume we don't want to just make hoops for projects to jump through, but
instead provide useful tools that help both the projects and the ASF as a
whole.)
[1] http://oss-watch.ac.uk/resources/ssmm
[2] http://oss-watch.ac.uk/resources/reusereadinessrating
[3] http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
>
> http://rfc.zeromq.org/spec:16
>
> -Bertrand
