This Week in Programming: Knative Adopts Elected Steering Committee, Severing Google Control

Google first released Kubernetes to the world in 2015, and with it started the cloud native movement as we know it today. With that 1.0 release, Google ceded control of the project and handed it over to the newly formed Cloud Native Computing Foundation (CNCF), a move that some argue has been cause for regret within the company and continues to taint its approaches to its other cloud native pursuits. Whether or not that argument is true, it tends to color the perception of many in the cloud native community around the company’s intentions with its other cloud native projects, such as the Istio service mesh and the Knative platform for running serverless workloads on Kubernetes.

In the case of Istio, for example, Google has avoided taking the same route as it did with Kubernetes, instead creating the Open Usage Commons to handle trademark considerations, with Istio as one of the founding projects, and shortly thereafter restructuring the steering committee to avoid a single vendor control. In essence, the Istio project worked to make clear that it was free of Google’s singular control, without ceding itself over to the CNCF, despite earlier promises to do so.

Earlier this year, we looked at a similar situation with Knative, wherein Google had clarified its position around the project, noting that it had “decided not to donate Knative to any foundation for the foreseeable future.” The announcement was met with hand wringing from some, who worried that the project’s majority control by Google would inhibit both its adoption and momentum, but the steering committee said at the time that it would be looking at different ways to open up control of the project and provide open governance without relying on handing over control to a separate foundation, such as the CNCF.

This week, reporting from Protocol indicates that Knative is following a similar path to Istio, with Google giving up direct control of the project. Protocol’s Tom Krazit writes that Google plans to “announce sweeping changes to the project’s governance structure” which will arrive in the form of “a steering committee structure in which no single vendor can hold more than two seats on a five-seat committee.” Moreso, the change moves seats on the steering committee from being explicitly connected to companies to individuals instead, with an expansion in the number of members possible for the future, which would then include end users as well.

The Knative project actually announced the changes weeks ago on Twitter, and steering committee member Brenda Chen noted that the momentum for this change began with those first in-person steering committee meetings in late 2019.

I felt it would be appropriate to share where all these governance ideas first began. In Dec 2019, we hung out in NY and discussed how we might grow the @KnativeProject community. Thank you to all the past and current steering members for helping kick start this effort! https://t.co/TU6z9O0INo

— brenda chan (@bsnchan_) September 24, 2020

With the article highlighting this change, conversation around the future of Knative has some renewed energy, though some still question what the hesitation is around handing over the project to the CNCF, which is seen as a de facto home for such cloud native open source projects

and yet …if @google ‘simply’ moved to the project to @CloudNativeFdn as so many open source cloud native project have done/ the governance question wouldn’t have been thorny at all.

Why is Google afraid of the CNCF for Knative is the real question that needs to be answered. https://t.co/drj2XgR68M

— Sean Kerner (@TechJournalist) October 8, 2020

While Google will retain trademark control over Knative for the time being, one steering committee member notes that even there, the company has relinquished its dominance, providing veto power to others involved. While this move may not appease those who see the CNCF as the only avenue forward for a successful cloud native open source project, it certainly is a step in the right direction, argues Evan Anderson, another steering committee member.

This Week in Programming

• A Look at the Future of Kotlin: Fans of the Kotlin programming language have a lot to look forward to in the year ahead, as the team has unveiled a public roadmap that details the biggest projects the Kotlin team is working on for the next six months. Updated every three months, the roadmap is, of course, a work in progress and collaborative, meaning you can ask questions in the linked YouTrack ticket or in the #kotlin-roadmap Slack channel (invites here). Some of the key features to look forward to include speeding up the change-test-debug cycle, rewriting the Kotlin compiler with a focus on optimizing for speed, parallelism, and unification (with pluggability coming later), improving the stability and performance of the Kotlin IDE, expanding support for server-side JVM, and even a Kotlin-to-WebAssembly compiler backend.
• Python 3.9.0 Is Here: The Python development community has announced the availability of Python 3.9.0, introducing some new string parsing methods, new operators for updating and merging dictionaries, type hinting for built-in generic types, and a new parser. But don’t take our word for it, check out what’s new in Python 3.9 and see for yourself. Also, don’t get too stoked about nearing Python 4, as the next release is actually Python 3.10, which actually has an alpha release ready in the wings. On a side note, for those of you lagging behind, Python 3.5 is no longer supported and there will be no more bug fixes or security patches for the 3.5 series, with Python 3.5.10 as the last release.

I’m gonna tell my kids that jQuery started the convention of using $, not PHP…

— I Am Devloper (@iamdevloper) October 7, 2020

• GitHub Boosts Code Scanning with Third-Party Tools: A little over a week ago, GitHub unveiled native code scanning and now the company has made two more announcements regarding third-party code scanning tools. These third-party tools extend GitHub’s native code scanning, which is powered by its own CodeQL static scanning engine. The tools are initiated with a GitHub Action or a GitHub App based on an event in GitHub, like a pull request, with GitHub’s code scanning API endpoint ingesting results using the open standard Static Analysis Results Interchange Format (SARIF). The 10 static analysis and developer security training first announced include Checkmarx, Codacy, CodeScan, DefenseCode ThunderScan, Fortify on Demand, Muse, Secure Code Warrior, Synopsys Intelligent Security Scan, Veracode Static Analysis, and Xanitizer, while the seven infrastructure as code and container scanning consist of 42Crunch, Accurics, Bridgecrew, Snyk, Trivy by Aqua Security, Anchor, and Snyk Container. To check them all out, give a visit to the GitHub Marketplace.
• GitHub Open Sources Its Docs: Because everything is just better open source, GitHub announced this week that its GitHub Docs are now open source. First launched in July, GitHub Docs is your one-stop shop for GitHub documentation, and now you can begin critiquing them and contributing to your heart’s content. “Everyone using GitHub has a different perspective on what works,” they write. “We want to make GitHub Docs articles work for all developers who are coming to them from different backgrounds. This is why we’re accepting contributions in many different ways.” For the interested, you can contribute directly on the site by opening a pull request right from the article, otherwise you can join a discussion, open an issue, or open a pull request regarding something you’d like to take on.

Dem stacks pic.twitter.com/wjclzxvHFv

— 2ftg (@2ftg1) October 7, 2020

• Cloud Native Coding with GitPod: We first introduced our readers to GitPod earlier this year, when the cloud native IDE went open source, and now the company is boasting a native GitLab integration that completes the standard trifecta of GitHub, GitLab, and Bitbucket. GitPod can automatically start a dev environment simply by prefixing a repository URL with gitpod.io/# and now, with its native Gitpod integration in GitLab’s UI, that feature is available to the 100,000+ organizations using GitLab. GitPod’s dev environments go beyond code IDE/editor to include things like compilers, build tools, code generators, databases, and application servers. If you’re thinking to yourself “This sounds a lot like GitHub Codespaces,” well, you’re not wrong — and here’s a comparison of the two.

Other Resources

These sites are not currently accessible from The New Stack site. Please paste the URL into your browser window:

Static Analysis Results Interchange Format: https://docs.oasis-open.org/sarif/sarif/v2.0/sarif-v2.0.html

The Cloud Native Computing Foundation is a sponsor of The New Stack.

Feature image via Ulrike Leone of Pixabay.