Attached to this message is a proposed new project - Apache OpenWhisk.
The text of the proposal is included below. Additionally, the proposal
is in draft form on the Wiki, where we will make any required changes:
We look forward to your feedback and input.
- Sam Ruby
/OpenWhisk is an open source, distributed //Serverless/
platform able to execute application logic (Actions) in response to
events (Triggers) from external sources (Feeds) or HTTP requests
governed by conditional logic (Rules). It provides a programming
environment supported by a REST API-based Command Line Interface (CLI)
along with tooling to support packaging and catalog services. /
*Champion**: *Sam Ruby, IBM
*Mentors**:* Felix Meschberger, Adobe; Isabel Drost-Fromm, Elasticsearch
Serverless computing is the evolutionary next stage in Cloud computing
carrying further the abstraction offered to software developers using
Container-based operating system virtualization. The Serverless paradigm
enables programmers to just “write” functional code and not worry about
having to configure any aspect of a server needed for execution. Such
Serverless functions are single purpose and stateless that respond to
event-driven data sources and can be scaled on-demand.
The OpenWhisk project offers a truly open, highly scalable, performant
distributed Serverless platform leveraging other open technologies along
with a robust programming model, catalog of service and event provider
integrations and developer tooling.
Specifically, every architectural component service of the OpenWhisk
platform (e.g., Controller, Invokers, Messaging, Router, Catalog, API
Gateway, etc.) all is designed to be run and scaled as a Docker
container. In addition, OpenWhisk uniquely leverages aspects of Docker
engine to manage, load balance and scale supported OpenWhisk runtime
Serverless functional code within Invoker compute instances, using
OpenWhisk's containerized design tenants not only allows it to be hosted
in various IaaS, PaaS Clouds platforms that support Docker containers,
but also achieves the high expectation of the Serverless computing
experience by masking all aspects of traditional resource specification
and configuration from the end user simplifying and accelerating Cloud
In order to enable HTTP requests as a source of events, and thus the
creation of Serverless microservices that expose REST APIs, OpenWhisk
includes an API Gateway that performs tasks like request routing,
throttling and logging.
Serverless computing is in the very early stages of the technology
adoption curve and has great promise in enabling new paradigms in
event-driven application development, but current implementation efforts
are fractured as most are tied to specific Cloud platforms and services.
Having an open implementation of a Serverless platform, such as
OpenWhisk, available and governed by an open community like Apache could
accelerate growth of this technology, as well as encourage dialog and
Having the ASF accept and incubate OpenWhisk would provide a clear
signal to developers interested in Serverless and its future that they
are welcome to participate and contribute in its development, growth and
In addition, there are numerous projects already at the ASF that would
provide a natural fit to the API-centric, event-driven programming model
that OpenWhisk sees as integral to a Serverless future. In fact, any
project that includes a service that can produce or consume actionable
events could become an integration point with OpenWhisk-enabled
functions. Apache projects that manage programming languages and (micro)
service runtimes could become part of the OpenWhisk set of supported
runtime environments for functions. Device and API gateways would
provide natural event sources that could utilize OpenWhisk functions to
process, store and analyze vast amounts of information immediately
unlocking the potential of fast-growing computing fields offered in
spaces as IoT, analytics, cognitive, mobile and more.
OpenWhisk is an open source community project which seeks to adopt the
Apache way through the course of the incubator process and foster
collaborative development in the Serverless space.
Currently, the OpenWhisk project's source repository is in GitHub using
its associated project tooling, but we believe the open Apache
processes, democratic project governance, along with its rich developer
community and natural integrations with existing projects provide the
ideal fit for the technology to grow.
Serverless will only reach its full potential and avoid fragmentation if
it is grown in an environment that Apache can offer.
The OpenWhisk project was published as an open source project within
GitHub (_https://github.com/openwhisk_) under the Apache v2.0 license in
February 2016. The project consists of the “core” platform repository
(https://github.com/openwhisk/openwhisk) code along with its family of
repositories that include a “catalog” of OpenWhisk system and utility
The project also includes repositories for:
* Docker SDK for user-created “blackbox” (Action) runtimes
* Graphical Command Line Tutorial (using NodeJS)
* Packages for popular service integrations (i.e., JIRA, Twilio,
Slack, Kafka, RSS, etc.)
Issue tracking and project governance (milestones, epics) are also
managed through *GitHub* *Issues* and visualized through *ZenHub*. All
“pull” requests, once passing automated tests run by *TravisCI*, are
reviewed by “core” contributors with “write” privileges. IBM has also
setup private staging servers to “stress” test the platform performance
under load and over extended periods of time before being merged into
the main code branch. As part of the incubation process we would make
these staging tests public and have them be run by Apache.
Currently, the project is not officially versioned and is considered an
“experimental beta”, but is marching towards milestone 10 that aligns
with what is considered to be a “beta” the end of October and another
milestone 11 end of November 2016 which is considered “GA” content for
the “core” platform. Again, we would very much like to adopt an Apache
community system for deciding on milestones, constituent epics
(features) along with dates a versioning plan and communicate
effectively using email lists, IRC and a project homepage (which is
In addition to the OpenWhisk core runtime, the API Gateway components of
the projects are published in a separate GitHub project
(https://github.com/adobe-apiplatform/apigateway) under the MIT license.
The API Gateway components were initially released in August 2015. These
components include functionality for:
* Request validation
* Request tracking
* Load Balancing
The OpenWhisk project firmly believes in meritocracy from its inception.
Issue, Feature and code submissions, to fix, improve or optimize the
platform code, tooling and documentation, as well as contributions of
new SDKs, Packages, Tutorials, etc. have all been welcomed after
successful community input, consultation and testing. Contributions can
be made by anyone as long as integration and staging (including stress
and performance) tests pass. We are looking forward to talented
individuals to progress the success of OpenWhisk and an open Serverless
ecosystem surrounding it. It would be a pleasure to invite strong
contributors to become committers in the project areas where they have
shown a consistent track record.
OpenWhisk has made significant effort to build a community using all
possible media and social outlets as possible, always asking for
interested developers to join and contribute.
The following outlets have been created to engage the public in as many
ways as we could conceive. Every single of these sources is monitored
continually via OpenWhisk code that triggers events and messages to
appropriate developer Slack channels where we seek to respond and engage
as quickly as we can.
* /Twitter/: https://twitter.com/openwhisk
* /Slack/: https://dwopen.slack.com/messages/openwhisk/
* /StackOverflow/: http://stackoverflow.com/search?q=OpenWhisk
* /dwAnswers/ (developerWorks):
* /Blog site/: https://developer.ibm.com/openwhisk/blogs/
* /Google//group/: https://groups.google.com/forum/ - !forum/openwhisk
IBM has sought to promote OpenWhisk at every logical event worldwide
where we are able.
* */Events and Meetups/*:
o 20+ past events, 6 planned through YE 2016 /(across 12 countries)/
o Event calendar: https://developer.ibm.com/openwhisk/events/
* */Stats/* (GitHub):
o 43+**contributors: https://github.com/orgs/openwhisk/people
o /Contribution Graphs/:
o 623 <https://github.com/openwhisk/openwhisk/stargazers> /(and
growing ~10-20 per week on average):
The following core developers, along with their credentials, are
proposed; each have been committers within OpenWhisk since its initial
* Stephen Fink, sjf...@us.ibm.com <mailto:sjf...@us.ibm.com>, original
* Rodric Rabbah, rab...@us.ibm.com <mailto:rab...@us.ibm.com>,
project's developer who has deepest knowledge who has been with the
project since its inception.
* Markus Thommes, markus.thoem...@de.ibm.com
<mailto:markus.thoem...@de.ibm.com>, project build and deployment
expert for all roles and environments (Mac, Linux, etc. either
* Jeremias Werner, jerew...@de.ibm.com <mailto:jerew...@de.ibm.com>,
tooling and integration expert. Understands all the build and
runtime dependencies / external projects OpenWhisk relies upon.
* Perry Cheng, pe...@us.ibm.com <mailto:pe...@us.ibm.com>, Performance
and stress testing guru.
We have looked, from the earliest days of developing OpenWhisk, at
Apache as a model for building a strong developer community and worked
to adopt its spirit and its best practices. From the outset, we have
wished to have enough interest and momentum in order to have a robust
pool of developers in order to adopt an Apache governance model for
meritorious acknowledgement of committer and core contributors who can
bring external knowledge to further grow the project.
We see immediate chances to leverage Apache projects such as Kafka,
Camel, MQTT, ApacheMQ, etc. Wherever there is a collector, funnel or
router of message data that can directly or indirectly generate events,
we intend to link to OpenWhisk as an even provider. These and other
projects are listed below and are just, we hope, “scratching the
surface” of integration points for Serverless enabled applications.
In addition, we should note that we see immediate interest in leveraging
the Apache relationship with the Linux foundation to integrate with the
OpenAPI specification (f.k.a., Swagger) and seek to standardize API
gateways that follow that spec. to formalize endpoints for services that
can produce events.
OpenWhisk and its initial group of committers along with the community
currently supporting the project will continue to promote and look for
ways to engage new developers and provide linkage to other compatible
open source projects. Serverless computing has a significant future in
Cloud computing and an open source implementation of a platform, as
OpenWhisk embodies, must success to provide competition and
interoperability and provide a rich foundation for new Serverless
technologies to rely upon.
/*Inexperience with Open **Source*/
OpenWhisk, as you can deduce from its name, has been an open source
project from its public debut in February 2016. As soon as a the
initial code, developed within IBM research, was viable and provided the
functionality expected of a Serverless platform, the project team open
sourced it and sought to build an open community to evolve it. Most all
current all current project team members have strong experience
developing within open source projects with meritorious governance
models. In fact, several of the current team members are committers on
other Apache projects and are excited to reach out to and align with
other project communities within Apache.
The current list of committers includes developers from two different
companies. The current set of committers are geographically distributed
across the U.S., Europe and China. All committers are experienced with
working in a distributed environment and utilize many messaging and
collaboration tools to continually communicate with each effectively to
develop and review code regardless of location.
Additionally, the current project members are very focused on addressing
comments, feedback and issue or feature requests as soon as we are
able. In fact, we utilize OpenWhisk itself to intelligently notify
project developers with the correct knowledge or expertise of any public
posting to any community outlets (listed above).
*Reliance on Salaried **Developers*
All of the initial developers are currently salaried by either IBM or
Adobe. With increasing awareness and interest in Serverless
technologies, we expect this to change due to the addition of volunteer
contributors. We intend to promote and encourage participation whenever
interest is shown in the project to build a robust community.
*Relationships with Other Apache **Products*
Some possible project intersections or potential connections are listed
below. We hope to identify many others through the course of incubation.
* *Kafka*, http://kafka.apache.org/project, OpenWhisk has plans to use
Kafka for an intelligent “message hub” service that can channel
events to OpenWhisk triggers.
* *Camel*, http://camel.apache.org/message-bus.html, Any message bus
naturally carries message data that may carry events direcly or be
used indirectly to derive events that devlopers can link to
* *ActiveMQ*, http://activemq.apache.org/, Again, a widely used
message server, that supports MQTT and AMQP, which can provide
trusted event data to OpenWhisk.
Some additional projects we would like to explore any connection with
* *CouchDB*, _https://projects.apache.org/project.html?couchdb_:
OpenWhisk already supports use of CouchDB for its own storage needs
(Actions, Bindings, etc.); however, there may be more integrations
possible as we develop a package manifest to describe OpenWhisk
entities reposited in document stores as pseudo-catalogs.
* *Mesos*, _https://projects.apache.org/project.html?mesos_: in
effect, OpenWhisk also manages a “pool of nodes” that can run
various Actions (functions). It would be interesting to see if any
overlap or sharing of node resources could be achieved.
* *Spark*, _https://projects.apache.org/project.html?spark_ : As with
Mesos, OpenWhisk nodes could be leveraged to perform distributed
data-processing with Spark.
and many others that we hope the community will help identify and
prioritize for development work.
*AN Excessive Fascination with the Apache **Brand*
The developers of OpenWhisk share a high appreciation of the Apache
Software Foundation, and many have been active as users, contributors or
committers to other Apache projects.
The main expectation for the developers is not the Apache brand, but the
project governance and best practices established by the ASF, access to
the Apache community and support and mentorship through senior Apache
OpenWhisk offers a comprehensive set of documentation (primarily in
Markdown) for all parts of the project from installation and deployment
(locally, remotely, distributed) on various platforms in order to get
developers “up and running” as quickly as possible on multiple platforms
(Mac, Windows, Ubuntu). In addition, OpenWhisk goes to great links to
document its architecture and programming model and provide guided
tutorials for the CLI. All SDKs and Packages that can be installed,
besides installation and use cases descriptions, often include videos
and blogs. OpenWhisk is dedicated to providing the best documentation
possible and even has volunteers’ submissions for translations in some
The project is comprised of multiple repositories all under the primary
openwhisk name. All initial source that would be moved under Apache
control can be found in GitHub (by repository) here:
* */Primary Repositories:/*
+ primary source code repository including run books, tests.
+ Catalog of built-in system, utility, test and sample
Actions, Feeds and provider integration services and catalog
* */Client (SDK) repos.: /*
+ /Swift-based client SDK for OpenWhisk///compatible with
Swift 2.x and runs on iOS 9, WatchOS 2, and Darwin.
+ CocoaPods Podspecs repo for ‘/openwhisk-client-swift/’.
+ This is an SDK that shows how to create “Black box” Docker
containers that can run Action (code).
* */Package repos.: /*
+ / In-progress/, Push notifications to registered devices.
+ /In-progress/, Integration with Twilio.
+ /In-progress,/ Integration with JIRA events.
+ Integration with RSS feeds.
+ /New, In-progress/, Integration with Kafka
+ /In-progress/, deploy a Slackbot with the capability to run
OpenWhisk <https://github.com/openwhisk/openwhisk> actions
* */Ecosystem repos.: /*
+ Place to submit interactive tutorials for OpenWhisk, its CLI
for learning the OpenWhisk CLI.
+ This is a prototype extension for Visual Studio Code that
enables complete round trip cycles for authoring OpenWhisk
actions inside the editor.
* /*API Gateway repos.:*/
+ The main API Gateway repository containing basic
configuration files and a Dockerfile to build all modules
into a single container.
+ Module to validate the incoming API requests with support
for OAuth 2.0, OAuth 1.0, and API-KEYs.
+ Support for Throttling & Rate Limiting
+ Syncs config files from Amazon S3, Google Drive, Dropbox,
Amazon Cloud Drive reloading the API Gateway with the updates
+ API request caching. This module manages multiple cache
stores ( i.e. Redis cache, in-memory cache )
+ Performant asynchronous logger used for capturing usage data
based on the incoming API traffic
+ ZeroMQ Adaptor for the API Gateway
+ Logging module for ZeroMQ
+ AWS SDK for NGINX
+ HMAC support for Lua with multiple algorithms, via OpenSSL
*Source and Intellectual Property Submission **Plan*
The OpenWhisk project code, documentation, samples (for all
repositories) have been fully authored under the Apache 2 license with
a comprehensive CLA requirements enforced for all committers from its
inception. The code has been fully screened and evaluated to assure its
code consists of original contributions not encumbered by any license
that would be incompatible with Apache.
This repository is the primary repository for the OpenWhisk platform; it
contains the implementations for all its component services, CLI and
* /tooling and runtime dependencies/:
o */Note/*/: all dependencies are to latest version unless noted
* /Build and Deployment Tooling:/
o ansible <https://github.com/ansible/ansible>v2.*
<https://github.com/ansible/ansible/releases> : GNU GPL
+ Primary Runbook (playbooks) tooling for deployment with
configurations for multiple target environments
o git <https://git-scm.com/> : GPL 2
+ Command line for automation of “pulling” OpenWhisk
repositories’ code from Git repos. Installed by misc.sh
o zip <http://packages.ubuntu.com/trusty/zip> : Info-ZIP
<http://www.info-zip.org/license.html> (BSD style)
+ Tooling for decompressing files packaged in compressed ZIP
<http://www.info-zip.org/Zip.html> format. Installed by
o python-pip <https://pypi.python.org/pypi/pip> : MIT
+ Python installer. Installed by pip.sh
o jsonschema <https://pypi.python.org/pypi/jsonschema> : MIT
+ Python Library. JSON schema validation. Installed by pip.sh
o argcomplete <https://pypi.python.org/pypi/argcomplete/1.4.1> :
+ Python Library. Bash tab completion for ‘argparse’.
Installed by pip.sh
Oracle Binary Code
+ Oracle Java 8 Installer (_Ubuntu PPA archive_), Installed by
<https://launchpad.net/software-properties> : GNU GPL v2
+ Manage your own PPAs
<https://launchpad.net/ubuntu/+ppas> for use with Ubuntu
APT. Installed by ansible.sh
o gradle <https://gradle.org/> 3.0
+ Build tool.
Apache 2 <https://github.com/gradle/gradle/blob/master/LICENSE>
+ Gradle wrapper tool. Installed by gradle-wrapper.properties
o One-JAR <http://one-jar.sourceforge.net/> : One-JAR license
+ package a Java application together with its dependency Jars
into a single executable Jar file. Used by
o npm <https://www.npmjs.com/> : Artistic License 2.0
+ Node Package Manager (NPM), core/nodejs6Action/Dockerfile
* /Application Services:/
o docker-engine <https://www.docker.com/products/docker-engine>,
v1.9, moving to v1.12 : Apache 2
+ Runtime for Docker containers. Installed by docker.sh
o docker-py <https://github.com/docker/docker-py> v1.9, Apache 2
+ Python API client. Installed by ansible.sh
o ntp <http://www.ntp.org/> : NTP
<https://www.ntpsec.org/license.html> (BSD 3-clause)
+ Network Time Protocol service started to sync. peer-computer
times. *Note*: UTC is default for all hosts. Installed by
o CouchDB <http://couchdb.apache.org/> : Apache 2
+ JSON document database. /Vagrant / User installed./
o Consul <https://github.com/hashicorp/consul> v0.5.2
+ Consul <https://www.consul.io/> Key-value data store.
Installed by services/consul/Dockerfile.
* Runtime Libraries:
o Scala <https://github.com/scala/scala/> v2.11
Scala (3-clause BSD <https://en.wikipedia.org/wiki/BSD_licenses>)
+ Primary language for OpenWhisk. Specifically:
<https://github.com/scala/scala/>, 2.11.6. Installed by
(referenced by build.gradle
o Node <https://nodejs.org/en/> v0.12.14
libraries. See core/nodejsAction/Dockerfile
for a complete/current list.
o Node <https://nodejs.org/en/> v6.2
+ The NodeJS6 Runtime. It also includes many NPM libraries.
a complete/current list.
o Python Runtime, v2.7 (Python Std. Library
<https://docs.python.org/2.7/library/index.html>) : Python
+ Python based Docker Images are used in a few places. For
example, seee core/ActionProxy/Dockerfile
addition, it is referenced by the Python CLI which is being
deprecated as it is being replaced by a Go language CLI.
o Java 8 JRE
+ Java Language Runtime (Oracle Java 8 JDK). Referenced by
o Akka <http://akka.io/> 2.47
Libraries for Scala 2.11 : Apache 2
+ Specifically the following: “com.typesafe.akka:” modules are
used: akka-actor, akka-slf4j, akka-http-core,
akka-http-spray-json-experimental. Installed by build.gradle
o _argcomplete_ <https://pypi.python.org/pypi/argcomplete> : Apache
+ Python library. Bash tab completion for argparse. Installed
o _httplib_ <https://docs.python.org/2/library/httplib.html> :
+ Python library. HTTP protocol client. Installed by .
o jsonschema <https://pypi.python.org/pypi/jsonschema> : MIT
+ Python library. Installed by tools/ubuntu-setup/pip.sh
o spray (source) : _Apache 2_
+ Scala libraries for building/consuming RESTful web services
on top of Akka. Installed by _build.gradle_
Specifically but not limited to: spray-caching, spray-json,
spray-can, spray-client, spray-httpx, spray-io, spray-routing.
+ Java logging library. Installed by _build.gradle_
o org.apache.* Libraries : _Apache 2_
+ Including: _org.apache.commons_
org.apache.httpcomponents:httpclient. See _build.gradle_
for current list and versions.
+ Including low level HTTP transport component libraries:
_httpclient_, . See whisk/_common_
current list and versions.
o _urlparse_ <https://docs.python.org/2/library/urlparse.html> :
+ Python library for URL string parsing. Referenced
o _swagger-ui_ <https://github.com/swagger-api/swagger-ui/> 2.1.4
: _Apache 2_
* /atypical license text/
dynamically generate documentation from a Swagger-compliant
API. See core/controller/_Dockerfile_
* /Optional Services and Tooling:/
o _Cloudant_ <https://cloudant.com/> : Apache 2
+ /(Optional)/ Database service. User may connect to instance
from README. CouchDB can be used otherwise.
o _Eclipse IDE_
Public License (EPL)
+ Tooling, IDE. /(Optional)/. OpenWhisk supplies a .project
files for the Eclipse IDE.
o _emacs_ <https://www.gnu.org/software/emacs/> : _Emacs GPL_
+ Tooling, Editor. /(Optional) /Installs Emacs editor.
Installed by _emacs.sh_.
* /Swift3 Runtime Dependencies/:
o The following Python libraries are installed in
o _Python 2.7 : _Python_
+ _Python Std. Library_
o _python-gevent_ <http://www.gevent.org/> : MIT
+ Python proxy support.
<https://pypi.python.org/pypi/distribute/0.6.49>/ : /_PSF_
<https://opensource.org/licenses/Python-2.0> (or ZPL)
+ Supports the /download/, /build/, /install/, /upgrade/,
/uninstall/ of Python packages. See:
<http://pythonhosted.org/distribute/>. /Note: this is a fork
o _python-pip : MIT_
+ PyPA recommended tool for installing Python packages.
o _python-flask_ <https://pypi.python.org/pypi/Flask> : BSD
+ Python proxy support.
o _clang_ <http://clang.llvm.org/> : _NCSA Open Source_
+ 'C' Library. Apple compiler front-end for ‘C’ (LLVM back-end).
<https://launchpad.net/ubuntu/trusty/+package/libedit-dev> : BSD
+ Linux, BSD editline and hostry library.
<https://launchpad.net/ubuntu/trusty/+package/libxml2-dev> : MIT
+ Linux, Gnome XML library.
: _Unicode_ <http://www.unicode.org/copyright.html>
+ Linux, Unicode support library.
o Kitura <https://github.com/IBM-Swift/Kitura> : Apache 2
+ Web framework and web server that is created for web
services written in Swift.
o Kitura dependencies : BSD (BSD-like)
+ Linux libraries including: autoconf, libtool,
_libkqueue-dev, _libkqueue0, libdispatch-dev, libdispatch0,
<https://github.com/apple/swift-corelibs-libdispatch> : _Apache
+ Enables Swift code execution on multicore hardware.
* Openresty - Licensed under the 2-clause BSD license -
* NGINX License - http://nginx.org/LICENSE
* Luajit - MIT License - http://luajit.org/luajit.html
* PCRE - BSD license - http://www.pcre.org/licence.txt
* NAXSI: GPL - is not compiled with the Gateway API code. Instead The
API Gateway project contains instructions for developers on where to
get NAXSI code (under GPL)
* ZeroMQ / ØMQ - Linked Dynamically in separate module
* libzmq - LGPL license with SPECIAL EXCEPTION GRANTED BY COPYRIGHT
HOLDERS - https://github.com/zeromq/libzmq
* czmq - High Level C binding for libzmq - MPL v2 license
Please note that the file
makes use of the Java javax.crypto.* libraries to implement
encrypt/decrypt functions. Primarily this is used to encrypt/decrypt
user keys or secrets when being passed or stored between or by
Resources that infrastructure will be asked to supply for this project.
Over the course of the incubator we would like to develop staging and
playground server environments for testing and developer experience. The
following environment would be desirable for an initial staging (and
* */CI /**/Test /**/Cluster requirements/**/:/*
o 3 VMs ,Catalog (CouchDB/Cloudant), Router (Nginx), Registry
o 2 VMs, Master (Controller + Consul), Message Bus (Kafka)
o 10 VMs, Invokers
o Each VM assumes 4 CPUs, 8GB Memory, 80GB additional storage
o Scripts that invoke Ansible playbooks for *build*, *deploy*
(run) and *clean* are provided.
o The various architectural components are started via Docker
containers (either natively, within a single Vagrant VM, or
across multiple, designated VM roles) using user configured (or
defaulted) endpoints and (guest) authorization credentials.
o In addition, the user/developer may choose to use the default
ephemeral CouchDB (via Docker container) for the OpenWhisk
catalog or switch to use a native CouchDB or a remote Cloudant
In addition, we would like to host a VM with a Node.js server that
provides Command Line Tutorials, along with demo samples.
Initially, we would start with the following recommended initial podling
We would add more as we transition off exiting mailings lists and
through the course of incubation.
As a community we would like to keep the master repository as well as
issue tracking on GitHub. We will be working closely with ASF Infra.
team to implement all the required pieces like ensure to send push and
issue notifications through ASF controlled mailing lists. During
incubation we will work closely with Infra to support GitHub master
repositories. We also understand that we have to support a way of
providing patches, which does not require a GitHub account for
contributors who are not willing or not able abide by GitHub’s terms and
conditions. It is our understanding that this approach has been signed
off by Greg Stein, ASF’s Infrastructure Administrator.
If we need to adapt our repo. paths to conform to Apache guidelines (and
perhaps necessitted by a move the the Apache named repo.) It is
conventional to use all lower case, dash-separated (|-|) repository
names. The repository should be prefixed with incubator and later
renamed assuming the project is promoted to a TLP.
If we need to move the project codebase from its existing GitHub repo.
as part of incubation, we would like to preserve the directory names as
they appear today and adopt the “apache” as part of the URI path as we
have seen other projects adopt.
This would mean all existing repositories which are now of the form:
would now take the form:
* and so on ...
We would like to explore the possibility of continuing to use GitHub
issue tracking (as project milestones, epics and features are all nicely
tracked via ZenHub boards) as we understand that this may now be
possible. We will provide any linkage or support for JIRA issue tracking
if that is required in order to track any “pull” requests within GitHub.
We would like to preserve our existing automated TravisCI automated
testing from GitHub. The project uses a continuous CD/CI process
currently that we would like to continue to support via multiple stages
that run progressive stress and performance tests that are also automated.
The following is the proposed list of initial committers, email address
[, GitHub ID)]:
* Stephen Fink, sjf...@us.ibm.com <mailto:sjf...@us.ibm.com>, _sjfink_
* Rodric Rabbah, rab...@us.ibm.com <mailto:rab...@us.ibm.com>,
* Markus Thommes, markus.thoem...@de.ibm.com
* Jeremias Werner, jerew...@de.ibm.com <mailto:jerew...@de.ibm.com>,
* Perry Cheng, pe...@us.ibm.com <mailto:pe...@us.ibm.com>, _perryibm_
* Philippe Sutor, psu...@us.ibm.com <mailto:psu...@us.ibm.com>,
* Christian Bickel, cbic...@de.ibm.com <mailto:cbic...@de.ibm.com>,
* Carlos Santana, csant...@us.ibm.com <mailto:csant...@us.ibm.com>,
* Matt Rutkowski, mrutk...@us.ibm.com <mailto:mrutk...@us.ibm.com>,
* Vincent Hou, s...@us.ibm.com <mailto:s...@us.ibm.com>, _houshengbo_
* Daisy Guo, guoyi...@cn.ibm.com <mailto:guoyi...@cn.ibm.com>,
* David Liu, david....@cn.ibm.com <mailto:david....@cn.ibm.com>,
* Paul Castro, cast...@us.ibm.com <mailto:cast...@us.ibm.com>,
* Nicholas Speeter, nwspe...@us.ibm.com <mailto:nwspe...@us.ibm.com>,
* Carsten Ziegeler, cziege...@apache.org
<mailto:cziege...@apache.org>, cziegeler <https://github.com/cziegeler>
* Chetan Mehrotra, chet...@adobe.com <mailto:chet...@adobe.com>,
* Bertrand Delacretaz, bdelacre...@apache.org
* Dragos Dascalita Haut, ddas...@adobe.com <mailto:ddas...@adobe.com>,
Although this list of initial committers appears long, OpenWhisk is a
complete platform which consists of many services supporting many
environments, programming languages and integrations. This diversity in
needs is reflected by the size of the initial committers group.
OpenWhisk also supports an end user ecosystem including CLI, Tooling,
Package Catalog, “curated” Packages, samples, etc. along with the
intention of tying in API gateway (e.g., OpenAPI) and other event source
We hope to add many more committers who provide expertise and the
various areas OpenWhisk uses to efficiently provide an exceptional
Serverless platform with compelling content.
Additional TBD during the proposal process
Additional TBD during the proposal process.
OpenWhisk would ask that the Apache Incubator be the sponsor.