This page tracks the state of the OpenWhisk project against the Apache Project Maturity Model and its codified framework.


The project produces Open Source software, for distribution to the public at no charge. 1YES. The project source is licensed under the Apache License, version 2.0.
The project's code is easily discoverable and publicly accessible.

YES. Apache OpenWhisk source is available on public GitHub [OW-GitHub].

In addition, the project's GitHub repository links are available on the OpenWhisk Incubator's Status page [OW-Web-Status] and its web home page [OW-Web-Home].

CD30The code can be built in a reproducible way using widely available standard tools.YES.  The project uses a consistent Continuous Integration (CI), Continuous Delivery (CD) for all project repos. using standard tooling such as Travis and Jenkins, to automate and sequence code scanning, formatting, building and testing using standard tooling appropriate for each sub-project.  The general project build processes (both manual and automated) are documented as part of the project's release repository [OW-Repo-Release].
CD40The 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.YESThe project uses Git repositories [OW-GitHub] and releases are tagged in accordance with Apache policies which can be traced back to GitHub commits for each release period.  See "Release Process Methodology" on the Apache OpenWhisk Release repository [OW-Repo-Release] README for details.
CD50The 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. 2YES. The community has gone to great lengths to verify the provenance of all source code contributions and to continually maintain it through the review process for each Pull Request received via GitHub.  Several of the core repos. have also instituted a checklist that must be followed for each issue submission and pull request such that contributors and reviewers are reminded to verify that the identities of contributors are transparent, that they have signed Apache CLAs and contributions are reviewed and discussed by the community where they are significant to invite and allow for additional scrutiny.

Licenses and Copyright

The code is released under the Apache License, version 2.0.


All source files in all project repositories adhere to the Apache Release Policy. where every artifact distributed MUST contain only appropriately licensed code per Apache Licensing Policy and include a valid Apache version 2.0 license. The project's specific rules and policy for compliance (in accordance with Apache policy) are documented here

In addition, every repo. is required to run a license scanning utility  as part of all automated Travis builds (run for every Pull Request in Github). The README of the release repo. contains a table with hyperlinks to the corresponding repository's build file that executes the scancode utility during the Travis build process.  The scancode utility and its documentation can be found here: which uses configuration file that enforces the ASF license compliance policies here: ASF-Release.cfg.

LC20Libraries that are mandatory dependencies of the project's code do not create more restrictions than the Apache License does. 3 4

YES. OpenWhisk has no mandatory runtime dependencies.

The community has gone to great lengths to scan all donated code from its initial donations from respective sources, as well as ongoing contributions to assure they adhere to the ASF's documented 3rd party license policy here: and only allow compatible licenses listed under "Category A".  In addition, each repo. where a 3rd party source license has been identified, contains a "/licenses" sub-directory (e.g., OpenWhisk licenses folder) that has a file describing each software and its license both ack. the owner/author, but also to identify them to our project's users and show that we do not use restrictive licenses not approved by the ASF.

LC30The libraries mentioned in LC20 are available as Open Source software. YES.
LC40Committers are bound by an Individual Contributor Agreement (the "Apache iCLA") that defines which code they are allowed to commit and how they need to identify code that is not their own.

YES. A verified, filed CLA is filed for every contributor as clearly documented in each repository's file (e.g., the OpenWhisk main repo. file).

Specifically, all committers assure that all contributions, of any significance, are from persons who have been verified to have signed a valid Apache CLA. As noted in item CD50 (above), several of the core repos. have also instituted a checklist that must be followed for each issue submission and pull request such that contributors, reviewers and committers are reminded to verify that the identities of contributors are transparent and that they have signed Apache CLAs against published Apache lists.

LC50The copyright ownership of everything that the project produces is clearly defined and documented. 5YES. The copyright ownership is included in the NOTICE file of the each project repo. of OpenWhisk and published in the footer of every page of the website.

Every project repository is required to have a NOTICE file that includes the copyright notice for the files in that repo.  The README of the release repo. contains a table with hyperlinks to the corresponding repository's NOTICE file for convenience and quick verification.  In addition, code donations of significance are noted in a CREDITS file located in the project root directory where applicable (e.g., see the CREDITS.txt file for the main openwhisk repo.).


RE10Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term. 6YES. Releases consist of source code that is archived and compressed (tar.gz)
RE20Releases are approved by the project's PMC (see CS10), in order to make them an act of the Foundation.YES.
RE30Releases are signed and/or distributed along with digests that can be reliably used to validate the downloaded archives.YES. SHA512 hashes are provided; a detached PGP signature is also provided.

The project website's Download page lists the component releases along with their hashes and PGP signatures (see Downloads - Apache Releases) along with instructions on how to verify the release artifacts in accordance with Apache policies.
RE40Convenience binaries can be distributed alongside source code but they are not Apache Releases -- they are just a convenience provided with no guarantee.

YES. Convenience binaries are produced as a natural artifact of the automated GitHub release process (where applicable) and are tagged to match an official Apache (Incubator) project release or otherwise identified as a development build with no official standing.

This naming and tagging are performed as part of OpenWhisk project's documented release processes [OW-Repo-Release].

For example, the Release page for the main OpenWhisk repo. is here: and shows a 0.9.0-incubating release that matches an officially voted Incubator project release. 

RE50The release process is documented and repeatable to the extent that someone new to the project is able to independently generate the complete set of artifacts required for a release.YES. The general project build processes (both manual and automated) are documented as part of the project's release repository [OW-Repo-Release].


QU10 The project is open and honest about the quality of its code. Various levels of quality and maturity for various modules are natural and acceptable as long as they are clearly communicated. YES. The community follows a process by which at least one "release candidate" is produced for each component and is offered for comment/feedback on the project developer email list [OW-Email-List-Dev] before producing an "official release" using Apache rules.

The project puts a very high priority on producing secure software. 7

YES. The project is motivated to quickly address security issues for its user base and treats fixes for security vulnerabilities as high priority tasks.

As proof point, the PMC and community addressed a security vulnerability identified by the startup PureSec, via our documented reporting process, in July of last year and worked with the Apache Security team to properly document and close the gap.  In addition, the project published a blog to the (user) community explaining the vulnerability in detail, its fix, along with advice on how to write "secure functions" which the project runs as "blackbox" code. See

QU30The project provides a well-documented, secure and private channel to report security issues, along with a documented way of responding to them. 8YES. A link to our security vulnerability reporting process page is published in the footer of every page of the website [OW-Web-Home].
QU40The project puts a high priority on backwards compatibility and aims to document any incompatible changes and provide tools and documentation to help users transition to new features.YES. The project is aware that its user base includes production deployments of the OpenWhisk project software and tooling. It strives to provide backward compatibility and/or to clearly document incompatible changes including using component CHANGELOG files on a per-release basis.
QU50The project strives to respond to documented bug reports in a timely manner.YES. The community works hard to raise awareness of community and user generated "bugs" as they are opened within component GitHub repositories as "issues" and have automated messages generated to both our Apache "issues" email list as well as our Slack #dev channel. [OW-Email-List-Issues], [OW-Community-Slack].


CO10The project has a well-known homepage that points to all the information required to operate according to this maturity model.

YES. The OpenWhisk project homepage [OW-Web-Home] provides all the relevant information.  This includes top-level pages containing:

All pages include a footer with links to the ASF, license and copyright disclaimers, Apache Events, Security, as well as Apache Sponsorship and "Thanks".

All pages include a header with media links to GitHub (OpenWhisk projects filter), Twitter, Medium, Slack, YouTube, SlideShare and StackOverflow.

CO20The community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project.YES. We endeavor to welcome all Contributors and encourage involvement on our community. This is clearly stated front-and-center on our project Wiki [OW-Confluence-Wiki], as well as on our Documentation page which includes a section specifically for Contributors.
CO30Contributions include not only source code, but also documentation, constructive bug reports, constructive discussions, marketing and generally anything that adds value to the project.YES. The community welcomes contributions in all these forms and takes them gratefully with respect.
CO40The community is meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.YES. This is stated prominently on our [OW-Confluence-Wiki] and linked from our website.
CO50The way in which contributors can be granted more rights such as commit access or decision power is clearly documented and is the same for all contributors.YES. This is stated prominently on our [OW-Confluence-Wiki] and linked from our website.
CO60The community operates based on consensus of its members (see CS10) who have decision power. Dictators, benevolent or not, are not welcome in Apache projects.

YES. We have people who have been long time contributors and have a good context on various design aspects. However all changes are done via consensus and not seen any case where any decision was forcefully taken

CO70The project strives to answer user questions in a timely manner.YES. Several channels are monitored for user and developer questions, including the "dev" list, Stack Overflow, Slack, and Twitter.

 Consensus Building

CS10The project maintains a public list of its contributors who have decision power -- the project's PMC (Project Management Committee) consists of those contributors. YES. The list of mentors and committers are accurate and maintained as part of the project's roster in Whimsy ( and is also linked from the project incubation status page.
CS20Decisions are made by consensus among PMC members 9 and are documented on the project's main communications channel. Community opinions are taken into account but the PMC has the final word if needed.

YES. All significant project decisions are made on the project's mailing list (; with votes that include results tallies that contain the number of votes from contributors and binding votes from mentors, committers and PMC members when applicable.

CS30Documented voting rules are used to build consensus when discussion is not sufficient. 10YES. The community attempts to achieve consensus based using discussions based in the project email list and seeks to positively resolved conflicts informally without a formal email list vote when possible. 
CS40In Apache projects, vetoes are only valid for code commits and are justified by a technical explanation, as per the Apache voting rules defined in CS30.YES. Please note that community, so far, has not needed to exercise a veto.
CS50All "important" discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions 11 that affect the project are also documented on that channel.

YES. All significant project-related discussions happen on and are directed to the project's mailing list.  Alternate communication channels, such as Slack and GitHub issues, are at times used to quickly iterate on topics, but issues having wider impact are moved to "dev" list discussions. All community web conferences are posted and call minutes are documented on the wiki, as are longer term design discussions.




The project is independent from any corporate or organizational influence. 12

YES. We now have a diverse set of people contributing to the project which belong to different companies (or act individually).  Specifically, the project has moved beyond IBM which "helped charter the project". This is evident from the Git contributions and activity dating back to the most recent 12+ months. In addition, the community has created Jenkins pipeline "Playground" (PG) builds which encourage independent testing of all contributions assuring independence from any single provider.


Contributors act as themselves as opposed to representatives of a corporation or organization.

YES. Contributors for known corporations have proved their independent thinking against agreed-upon uses cases and examples in furthering the code on-behalf of the project and community as a whole. The project independence is evident from consensus building among members of the project, on this same "dev" list, who put forth proposal and seek comments.  In addition, the community gives enough time to build consensus and make a decision (based on the silent assent) just like most of Apache projects do.



The Apache OpenWhisk projects Incubator Status page:


The Apache OpenWhisk project's home page under


Apache OpenWhisk Project Wiki


A filtered list of all Apache OpenWhisk project repositories on public GitHub can be found using the following URL:


The Apache OpenWhisk project's main repository that contains all core Serverless platform code, services and functional test suites.


The Apache OpenWhisk project's repository that provides project release methodology in accordance with Apache policies.




Apache OpenWhisk project community slack domain (linked on the header of project website)

Including channels such as:

  • #general - for general project discussions
  • #dev - for development related issues and changes


  • The example used in creating this page was the Apache FreeMarker Project Maturity Model as it was the the most recent project to reference it, as part of a successful graduation vote, at the time of initial  authoring.
  • No labels