I think [1] is a good definition of the architectural pattern (outside of networking applications). It’s the one we use within the crossplane community [2]

[1] https://aws.amazon.com/builders-library/avoiding-overload-in...

[2] https://crossplane.io

disclaimer: I'm a maintainer on Crossplane.

OAM is an optional feature of crossplane - you don't have to use it if you don't want to

Good to know, at least that warm me up to crossplane further. The messaging might need update, including within the docs. I mean - crossplane is the OAM implement - coupled with OAM sprinkled all over docs, gave me very different impression.

This aside, I think crossplane work is interesting.

[disclosure: I started the crossplane project and ceo/founder at upbound]

If you look at the governance of Crossplane [1], you'll see the three original maintainers of Crossplane (all Upbound employees) will be bootstrapping the steering committee and have a 2 year term, 2 others are currently being added without upbound affiliation. We believe this bootstrapping period is important to ensure that the project remains true to its vision, and to build trust and rapport with new folks joining the project. After the bootstrap period ends, the community will vote new members in. This is the same way Kubernetes and the CNCF Technical Oversight Committee were bootstrapped.

Upbound will have a commercial solution around Crossplane, but our commercial goals are not at odds with creating a strong open source community with strong governance. For Crossplane to be successful it's going to take a village, this is why we're donating it to the CNCF.

[1] https://github.com/crossplane/crossplane/blob/master/GOVERNA...

I made a similar argument [1][2] about tipping the cloud computing market from vertical to horizontal integration. One important aspect of this transformation is to maintain the feel of an integrated cloud provider, and not let the customer/end-user deal with the cost of heterogeneity [3].

[1] https://www.youtube.com/watch?v=GOssXrkNYxM

[2] https://speakerdeck.com/bassam/opening-up-the-cloud-with-cro...

[3] https://crossplane.io

note also it has "k" in the name (despite it being at the end). So it's legit.

Hehe. We considered a nautical theme at one point but thought it was a bit overdone :-) (I’m a maintainer on rook)

> How does this work in a world where developer administer their own services?

in that world the developer plays admin too, and can configure crossplane as an admin.

+1 we really wanted to leverage the ecosystem and have something that is immediately familiar when we decided to use kube-apiserver (and etcd) for crossplane. I think the K8S resource model [1] goes well beyond container orchestration

[1] https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRf...

Yes, indeed. There appears to be an overlap in general principles (even in use-case example). From what it appears, KEP sig was "published/released" (not sure what is the right term here) on the GitHub 3 days ago, we did not see this. We will definitely reach out for further discussion.

hi bassam here (CEO @ Upbound). Our business model is still firming up, but we're thinking we would be hosting crossplanes among other things. We want the crossplane project to be community driven (and not vendor driven) and welcome other contributors (see our governance model).

Thanks for CrossPlane, this will work if you guys stay true to your mission. A frustrated cloud user. Personally I will support you guys and GitLab any day.

Thanks but aren't you worried about someone else hosting your product and competing with you.

Crossplane could be one package that customers would not want to use directly from a major cloud provider. You'd never trust AWS/Google/etc to really give equal footing to a competitor. Separately, I'd prefer to trust the company behind the open source software as opposed to some other upstart. So this model may really work.

One observation: Crossplane and Upbound seem a little too unrelated of names. Github has benefitted from being almost synonymous with git (admittedly, Github also created the opening for Gitlab at the same time).

Great response! Regarding naming we did not want to tie the company to a single project, not did we want the project to feel like a vendor driven project. So we went with different names completely :-)