On Product vs. Project

tags: DUX, Omer Bensaadon

This document will be part of a series I'm calling the "Knative Product Series," which will include musings/presentations/discussions viewing Knative from a product lense as well as thoughts on what Knative can teach us about the future of Open Source development. A lightweight schedule can be found here: The Knative Product Series

Background

Over the course of the last few months, there has been an unspoken shift in the way our community is thinking about Knative.

This change is a simple shift in mental model: a shift from Knative the project to Knative the product.

One could even chart this change along recent community actions: beginning with the acceptance of the UX WG and cresting with the conversations being had around the introduction of func.

The question we, as a community, ought to be asking ourselves is simple: who is the audience of our work? Are we building a project for vendors or a product for end users?

In this document I will further define these concepts in relation to Knative, discuss the implications of this shift, and how "formalizing" this shift could impact Knative's future.

Knative the Project

When viewed as a project Knative is the collaboration of many vendors in developing a core software capability. This core software (or spec) is then used by each vendor as the basis for a commercial offering.

The best analogy is something like the Linux kernel or glibc library. Many of the participants are focused on particular niches or components, but derive much of their value from offering product support or differentiation higher up the value chain.

Functionally, this is a (1) cost-savings and (2) flexibility-promoting measure. That is to say: if vendors can collaborate fruitfully with other organizations, even competitors, they can achieve (1) greater efficiency than building the features on their own and (2) a more flexible and resilient "pluggable" product.

The importance of project dominant marketshare

If the vendors who support a given project fail to achieve dominant marketshare in their space before the popularity of the project begins to decline you end up with a shrinking pool of vendors. Eventually, much of the community fades away and one vendor is left holding the bag, as in the case of Cloud Foundry.

On the other hand, if you can get enough vendors to "buy-in" to your OSS project, you can create a market in-and-of-itself. Major vendors adopt your spec and smaller vendors pop up to "plug-in" to your existing market to gain access to your users, offering pluggable products or services on the periphery in a virtuous cycle.

This cycle assumes away many things, like a functioning OSS bureaucracy.

Achieving this virtuous cycle can be done in 2 ways:

1. Be a dominant player, build out-sized partnerships relatively quickly (as in the case of Android, Google + Samsung).
2. Solve an important problem for end-users, build grassroots support (as in the case of Kubernetes).

Knative the Product

Solve an important problem, build grassroots support

Before I dive in, let's define product in general terms. A product is simply a named collection of business capabilities valuable to a defined customer segment.[1]

Therefore, to approach Knative with a product lense is to develop and nurture a base of users who will find Knative valuable for the business capabilities it enables.

This often requires product-related activities: deeply understanding users needs and motivation, identifying and exploiting strengths in a product over its competitors, establishing clear product marketing, etc.

Much of this work has begun in earnest with the UX WG's user interview efforts and will continue to evolve as we flesh out user personas and generally continuing work on this front.

I am not convinced we can create "the standard for Serverless workloads on Kubernetes" by treating Knative as a project. In my view, standards are not wrought by vendors "deciding" them (as has been made sufficiently clear thus far), they are wrought by users requesting vendors conform to the standard.

How does this relate to Knative?

If we were a single commercial vendor, and assuming we have bought into this perspective, the next steps would be clear: create outcomes that bring the objective of growing the base of users of Knative into focus.

But, of course, it's not that simple.

Since Knative is a collection of vendors and end-user contributors with a wide variety of different needs, agreeing on prioritized outcomes for Knative would be, at best, frought.

Therefore, my reason for writing this document (and others like it) is to align on the identity of Knative, and allow each member of the community to drive in a direction based on that understanding.

The diagram above, taken from James Clear's book "Atomic Habits"[2]

If Knative's community members can agree on the identity of our community, then we will build processes which naturally coalesce around that identity and thus drive outcomes which are symbiotically related to that identity.

This is best spelled out with an example: let's say that the Operator Working Group (WG) wants to make improvements to the Operator.

If the Knative's identity is that of a project, one would expect the WG to identify improvements requested by downstream vendors' customers and execute on those improvements, without concern for the needs of end-users of OSS Knative or other vendors.

However, if one views Knative as a product this thinking shifts, and this shift has already begun to take root. Take a look at this message in the #operations channel on Slack.

Instead of collecting requirements from customers or Technical Leads, we are shifting to thinking of Knative as it's own product with it's own end-users.

Take a different example, the recent func discussions have put a priority on "community defaults" for the pluggable components of the functionality and the Functions Task Force is ready to have the difficult conversations about what buildpacks we want to ship into the community version of func.

Compare this to the community's opinion on a Networking layer, where community defaults where never a priority. User interviews and site analytics have already shown that the "choose what you want" nature of this core functionality is a sincere challenge for many users who don't have an opinion on Networking.

I would even argue that internalizing Knative's identity as a product is what originally prompted the total re-structuring of the Knative.dev website, and other Working Groups are beginning to internalize the power that user interviews can have in building successful products.

I encourage the community to have this discussion writ-large, and would be curious what sorts of conclusions we come to.

What actions can we take?

This sort of goes against the whole ethos of my previous point (focusing on identity and not processes or outcomes) but I have included some concrete actions below:

1. A focus on community defaults.
2. A focus on community-building activities (such as hiring strong developer advocates and community managers).
3. A focus on design activities (ideally, with professional designers, not a product manager doing his best).
4. A stronger message from the Steering Committee that this is the sort of identity we wish for Knative to have (via some sort of vision or strategy document).
5. Engage with and train engineers in the Knative project to conduct their own user interviews.

Fin + Acknowledgements

Thank you to all of the folks who have generously donated their time to helping review early versions of this document, and to VMware for sponsoring my time spent thinking and writing about OSS.

References

[1] https://www.gartner.com/en/information-technology/glossary/product-digital-business

[2] https://jamesclear.com/identity-votes, this article has little to do with the point I am trying to make here as it focuses on individuals not organizations, but it's a helpful diagram nonetheless.