Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Apache Project Maturity Model assesses whether or not a project complies with each element in the following seven categories: code, licenses and copyright, releases, quality, community, consensus building, and independence. There are no intermediate levels: a project either complies with an element or it does not. The following sections address Taverna's status regarding each element of the model.

NOTE: Numbers in brackets ([ ]) refer to footnotes on the Apache Project Maturity page, and are reproduced at the bottom of this document.

Code

 

...

...

  • CD10:
  • The project produces Open Source software, for distribution to the public at no charge. [1]

...

...

    • Apache Taverna ...

...

  • CD20

...

  • :

...

  • The project's code is easily discoverable and publicly accessible.

...

...

    • Apache Taverna ...

...

  • CD30

...

  • : The code can be built in a reproducible way using widely available standard tools.

...

    • Apache Tavera ...

...

...

  • CD40

...

  • : The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.

...

    • Apache Taverna ...

...

  • CD50

...

  • :

...

  • The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance. [2]

...

...

 

    • Apache Taverna ...

...

Licenses and Copyright

...


...


Releases

...


...


Quality

...


...



Community

...


...


Consensus Building

...


...


Independence

...

...


Footnotes from

...

Apache Project Maturity Model

...


[1] "For distribution to the public at no charge" is straight from the from the ASF Bylaws at http://apache.org/foundation/bylaws.html.

[2] See also LC40.

[3] It's ok for platforms (like a runtime used to execute our code) to have different licenses as long as they don't impose reciprocal licensing on what we are distributing.

[4] http://apache.org/legal/resolved.html has information about acceptable licenses for third-party dependencies 

[5] In Apache projects, the ASF owns the copyright for the collective work, i.e. the project's releases. Contributors retain copyright on their contributions but grant the ASF a perpetual copyright license for them. 

[6] See http://www.apache.org/dev/release.html for more info on Apache releases 

[7] The required level of security depends on the software's intended uses, of course. Expectations should be clearly documented. 

[8] Apache projects can just point to http://www.apache.org/security/ or use their own security contacts page, which should also point to that.

[9] In Apache projects, "consensus" means widespread agreement among people who have decision power. It does not necessarily mean "unanimity".

[10] For Apache projects, http://www.apache.org/foundation/voting.html defines the voting rules.

[11] Apache projects have a private mailing list that their PMC is expected to use only when really needed. The private list is typically used for discussions about people, for example to discuss and to vote on PMC candidates privately.

[12] Independence can be understood as basing the project's decisions on the open discussions that happen on the project's main communications channel, with no hidden agendas.