Apache OpenWhisk has a number of differences to other serverless platforms (as well as being open-source) including...

- Excellent "out of the box" runtime support including Node.js, Java, PHP, Swift, Python, any binary runtime (Go, Rust, etc..). - Custom runtime support using Docker images. Allowing custom images as the execution environment makes it easy to use (almost) anytime on the platform without needing this to come built-in. Custom images can be used to add large libraries or other resources. - Integrated API Gateway. Makes it simple to expose custom routes to functions. - Multiple built-in event sources including HTTP events, CouchDB, Kafka and more. Platform supports registering custom event providers to add any external data feed or event source. - Higher-order function composition patterns including sequences.

There are numerous open-source serverless platforms but OpenWhisk is the most mature and one of the only open-source platforms powering commercial serverless offerings, being used by IBM Cloud Functions, Adobe and Red Hat. It has used by IBM's offering with customers since early 2016.

Development is all public with the project being in the Apache incubation phase. Upcoming features being worked on include Swift 4 support, on-going k8s integration and better higher-order functional composition patterns. Check out the Github PRs and issues for details.

(Disclosure: OpenWhisk committer and IBMer).

I'd point out that supporting languages "out of the box" and having extensibility via docker images is more or less table stakes at this point.

A lot of the other things you listed are present in other FaaSes too in varying degrees.

No questioning that OpenWhisk was the first major opensource project in this space, though.

Docker extensibility is common in the open-source faas projects but not in any(?) of the commercial serverless offerings (Google, Amazon or Microsoft).

Runtime support (upload code not a container) is more common in the commercial offerings that most of the Docker-based faas frameworks, which use a container as the packaging.

OpenWhisk is more flexible than most of the platforms with respect to packaging IMO (Wanna deploy code? Great. Prefer containers? Sure. Wanna use code and a custom image? No problem!)

Event support is more common in the commercial offerings (as they have cloud services for you to use), whereas the "faas" framework seem more bare bones. You'll have to configure event integration manually. Same goes for API gateways.

OpenWhisk supports numerous open-source event providers with a extensible API for integrating new providers. This is more complete that lots of the other projects in this respect.

Over time these features will become default in all projects but there does seem a split in focus between the commercial offerings and "faas" frameworks at the moment. I'm biased :) but I think OpenWhisk has a comparible feature set to Lambda (having been around for over two years) whilst still benefiting from the open-source docker story.

> Even better if it is open source, in contrast to GOOG/AMZN/MSFT offerings!

Most of the Azure Functions codebase is actually open source under the MIT License: https://github.com/Azure/Azure-Functions

That's great but it would be good to know what's missing? Can I take that repo, deploy it and start selling FaaS?

I don't know the answer to that myself unfortunately. I know the entirety of the runtime itself is OSS and when you do local run/debug of a Function it's the same runtime that Azure uses.

It's not an apples to apples comparison though since OpenWhisk is intended to be self deployed.

I mentioned Functions here just because many folks don't know that most Azure SDKs, runtimes, tooling, etc are OSS by default.

That's the problem though. It doesn't matter much that it's open source if it is not usable in a sense that you can't easily deploy it yourself or repurpose, without committing (and paying) for the rest of Azure stack.