The ‘Foreseeable Future’ Ends with Knative’s CNCF Application

Well, well, well — after all that, it looks like the Knative project is poised to join the Cloud Native Computing Foundation (CNCF).

Back in 2019, Google caused a bit of controversy when Donna Malayeri, a product manager for Google Cloud Run and a member of the Knative steering committee at the time, wrote in an update that Google had “decided not to donate Knative to any foundation for the foreseeable future.”

This week, the Knative project opened a pull request to join the CNCF as an incubating project, officially ending said “foreseeable future,” with no reason offered as to what had changed in the interim. In a separate blog post, the Knative Steering and Trademark committees wrote that they were “very excited” about the news that Google had “just announced its intention to donate the Knative project.”

The Google blog post on the topic offers a brief history of the project, noting that it was first founded and released by Google in 2018, before it was “subsequently developed in close partnership with IBM, Red Hat, VMware, and SAP.” As for reasons behind the change of mind, again, mum’s mostly the word. The only passage that could even apply offers bland platitudes about open source:

“Finding a home in the CNCF secures Knative’s long-term future and encourages continuing and open innovation. This donation recognizes the adoption and investment in Knative from the community, and will encourage further multivendor innovation, broader education and training,” Google writes.

Chris DiBona, Google’s director of open source, offered the reason as summing up to “maturity” in one tweet:

That would take a lot of tweets! Short form is @eric_brewer and other folks coming to think it was the right time for this codebase (we had mentioned maturity a few years back).

— Chris DiBona (@cdibona) November 30, 2021

This, of course, is a far cry from what was said about a potential donation when we wrote about Knative’s independent future outside of a foundation in early 2020, when former steering committee member Jaice DuMars said in an Ask Me Anything (AMA) that donating Knative wouldn’t really offer the project or its users anything beyond what Google could offer.

“There’s a whole slew of assumptions about what the CNCF does and doesn’t do and I think that it’s a little bit dangerous to make those assumptions because if you assume that by donating you get these things, that’s not true. If we donated this project tomorrow, nothing would change in terms of governance,” said DuMars at the time. “CNCF would not make any changes. The only thing that would be different is that they would hold the copyright for the name Knative.”

It was right around this time that Knative actually adopted an elected steering committee, officially severing Google control of the project, which was perhaps the first step on the project’s way to independence. Without any specific public word on the reasoning, however, there’s only speculation to go by.

One such speculation may be that there was some pressure exerted on Google by those aforementioned “close partnerships” — IBM, Red Hat, VMware, and SAP — who could just as easily fork the project. With many of the original players in Knative having left Google for these other organizations, it seems like a distinct possibility that a forked version could be created and separately submitted to the CNCF, leaving Google to play with the original Knative by itself.

But again, that’s just speculation.

IBM, one of those partner companies, offered its own applause regarding the application, writing that the news was “a major step in the right direction for the future of Knative,” again laying out the basics of what it means to join an independent foundation, summing it up as “a win-win.”

Of course, you might find yourself wondering after all of this — what about Istio?

It is b/c Knative is a dead-end financially.

— Lawrence Hecht (@expoliticaljunkie@hachyderm.io) (@LawrenceHecht) December 1, 2021

This Week in Programming

• Docker to Get Single Sign-On: For you Docker Business users out there, it looks like Single Sign-on (SSO) is coming to Docker. The news of this upcoming feature briefly graced our RSS feeds before being pulled from the Docker blog, where somebody apparently jumped the gun on releasing the details. According to that now non-existent blog post, Docker SSO will enable users to authenticate with their organization’s standard identity provider, including “a number of popular SAML IdPs including Google, Okta, Azure Active Directory, and more.” Also, if things hold true to what was briefly published, Docker will begin (at some point) to invite a few “current Docker Business customers to preview Docker SSO before it is generally available in January 2022.”
• JetBrains Unveils its VS Code Competitor: JetBrains released Fleet, its lightweight code editor, this past week and many folks out there see it as the company’s direct competition to Visual Studio Code (VS Code). Fleet, they write, is “a lightweight editor but with a twist!” in that it “starts up as a full-fledged editor that provides syntax highlighting, simple code completion, and all the things you’d expect from an editor” but is also “a fully functional IDE bringing smart completion, refactorings, navigation, debugging, and everything else that you’re used to having in an IDE.” According to the blog post, Fleet works with multiple languages, is built using a distributed architecture that makes it work well with remote development, and works with JetBrains Space, which makes it “easy to start a remote server instance from a source repository, which can be customized using a Dockerfile.” Fleet also provides collaboration capabilities, allowing multiple developers to work together on a project. Right now, they say that the tool is in its “early days,” and so it’s available to those who apply to join the limited Fleet Explorer program.

pic.twitter.com/QJJl0PF6FI

— Cloud Native Yoda (@cloudnativeyoda) November 29, 2021

• AWS re:Invent’s Top News:  Hoo, boy! AWS re:Invent took place this week and if you haven’t been paying attention, you might find yourself hard-pressed to catch up. Lucky enough, Amazon put out a blog post briefly summarizing (and linking to) details for the top announcements of AWS re:Invent 2021. The blog post highlights more than 50 announcements made at the conference, with further links to The Official AWS Podcast and the fully overwhelming list of everything that’s new at AWS in 2021. Now, if you’d rather something a bit more curated, you can always check out The New Stack Newsletter, which offers some coverage from the week past, and keep an eye out in the week ahead for more that’s set to grace our pages.

“He’s making a list, he’s checking it twice!” 🎅

Maybe if Santa created a sorted list and used a binary search, he wouldn’t need to check it twice

— I Am Devloper (@iamdevloper) November 25, 2021

• How Goes eBPF’s Move to Windows? Earlier this year, we wrote about how eBPF was headed to Windows, as Microsoft announced at the time, and now the company offers an update on its progress. The extended Berkeley Packet Filter (eBPF), Microsoft writes, is “a well-known, but revolutionary, technology for providing programmability, extensibility, and agility” and the company says it has “achieved some significant milestones worthy of mention.” For example, recent months saw the creation of the eBPF Foundation, as well as a keynote and talk on the subject. More concretely, Microsoft notes the progress it has made on the eBPF for Windows project, which started out with “relatively few APIs available to eBPF programs, and no support yet for the de facto standard libbpf APIs,” and now has many, many more, including “some of the most used APIs and map types, to unblock key application scenarios.” In addition, Microsoft said it made sure that all eBPF for Windows hooks, helper functions, and libbpf APIs were fully documented, alongside documentation on how to create a new extension with hooks and helpers. Looking ahead, the company says it wants to enable other existing eBPF applications and projects to work on top of eBPF for Windows, as well as “to expand the set of eBPF program types and hook points to which they can be attached,” eventually making eBPF for Windows secure enough to be used in production.

Knative project is now proposed to join CNCF.
Like many Googlers, I wish this has happened way back when the community asked for it. Better late than never, and there's a lot to celebrate here!https://t.co/GOo3x8ELmN

— ahmetb (@ahmetb) November 30, 2021