# 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
](https://hackmd.io/BxyDXamfSJiGJpAHDI0RMA)

---
## 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](https://github.com/knative/community/issues/420) and cresting with the conversations being had around the [introduction of `func`](https://github.com/knative/community/issues/613).

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.

::: warning
DISCLAIMER: The Project and Product concept I introduce here is a spectrum. The many parts of Knative will fall somewhere along that spectrum.

That being said, the argument this document makes is to push towards Product on that spectrum.
:::

## 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.

::: spoiler "What makes it more flexible/pluggable?"
Collaborating with vendors who have different requirements usually means you need to approach things from slightly different perspectives. This means the result of your collaboration is usually more accepting of many different opinions, hence more flexible.
:::

### 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"](https://hackmd.io/EdKCKaFhRLuegL4rwE7wMA?view#Determine-baseline-community-builders-buildpacks-and-templates) 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](https://docs.google.com/presentation/u/1/d/10bmQ_hqWI4Zus_VtfvH1PPdXmsNUMDC6XNyz7L25ndc/edit) 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.