Istio Restructures Steering Committee to Avoid Single-Vendor Majority – InApps Technology 2025

While there are some who may never get over the fact that the Istio service mesh, originally created by Google and IBM, will not be handed over to the Cloud Native Computing Foundation (CNCF), the project took a big step this past week to assuage those who critiqued the project for being under a Google-majority control: Istio has introduced a new Istio steering committee.

According to the blog post, the new steering committee will consist of 13 seats, with four “elected Community Seats” and nine “proportionally allocated Contribution Seats,” a change they say “solidifies our commitment to open governance, ensuring that the community around the project will always be able to steer its direction, and that no one company has majority voting control over the project.” This final point is really the key to the announcement here, with them further and more explicitly clarifying later that “no single vendor, no matter how large their contribution, has majority voting control over the Istio project.” To this end, they write, they have “implemented a cap on the number of seats a company can hold, such that they can neither unanimously win a vote, or veto a decision of the rest of the committee.”

I remember all the backlash when it was announced that Istio would not join CNCF.
Oddly, when something like https://t.co/0JeNoDyzmx is announced, little talk is done about good things happening because neutrally, YES, it is a good thing!
Cheers to the @IstioMesh team!

— Raphael Fraysse (@la1nra) August 26, 2020

As for how those seats are allocated, the four Community Seats will consist of four representatives from four different organizations and will be chosen in an annual election. The nine Contribution Seats will be assigned to a minimum of three different companies “in proportion to contributions made to Istio in the previous 12 months,” with this year’s metric being merged pull requests. The Istio team compares its approach to Contribution Seats to that of Kubernetes, writing that “in Kubernetes, the mantra was ‘chop wood, carry water,’ and we similarly want to reward companies who are fueling the growth of the project with contributions.”

There is a keyword here — “companies” — that was picked up on by several commenters, including that of Kubernetes co-creator Joe Beda in a Cloud Native Computing Foundation technical oversight committee thread on the topic. Beda writes that “one big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors.” Beda further postulates that if someone leaves a job and therefore a company, they might have to give up their position on the steering committee, something he contrasts with Kubernetes’ “Community over product or company” value.

Amazon Web Services Matthew Wilson similarly took issue with this wording, tweeting his displeasure with the focus on corporate entities rather than individuals, with Knative co-founder Matt Moore seemingly echoing his concerns.

Another hill I will die on: attributing #OpenSource contributions (e.g., number of PRs merged) to companies (without recognition of the individual), and calculating the number of “seats” that a company “earns” based on that number, is a crappy way to build a community.

— Matthew S. Wilson (@_msw_) August 24, 2020

This is what you get when a company wants to “play community,” but treat its employees as interchangeable cogs.

Establishing trust in open source communities is so often underestimated and undervalued. It always makes me sad to lose a community member I have grown to trust.

— Matt Moore (@mattomata) August 25, 2020

Wilson further notes that the most meaningful open source contributions are often made by “committed individuals,” arguing that open source projects shouldn’t “be awarding huge kudos to companies for merely paying the bill, that is not cognitive labor.” The implication of this focus will be that “companies will be less likely to allow developers to spend work time dealing with governance issues,” tweets InApps Technology analyst Lawrence Hecht.

Nonetheless, Weaveworks CEO Alexis Richardson pointed out in his message to the CNCF Technical Operating Committee that Istio’s steering committee actually “highlights some benefits of [a steering committee] model,” including a steering committee’s broad application across a project rather than just a repo, its encouragement of diversity in having non-coding members, and its focus on “overall direction on behalf of end users and community (avoiding the open core problems we see in other cases).”

This Week in Programming

• Google Introduces Monthly Open Source Meetups: Google has announced Google Open Source Live, a series of virtual events starting on Sept. 3, with an event focused on “The new open source: Leadership, contributions and sustainability.” The events will include a live question and answer session as well as an “after party” of some sort. Sessions are scheduled out for the next calendar year, with Knative day, Go day, and a day for Kubernetes set to round out the year.
• A Look at Google’s Use of Go: For those of you who are Go-curious, the company has put out three new case studies about its own use of the language it started developing back in 2009. The studies look at how Google’s Core Data team replaced a monolithic C++ implementation with a Go-based microservice system, how Google built the Chrome Optimization Guide server, and moved the Firebase backend from Node.js to Go. Along with the new case studies, the company briefly outlines its other uses of the language, which it said started in 2011 with the launch of Go on App Engine and the beginning of it serving YouTube database traffic with Vitess.

submitted two PRs in the middle of a power outage ama

— oliver (@olix0r) August 22, 2020

• A Go 1.15 Recap: While we’re here, we have one penultimate Google-related bit, with the company offering a  recap of major improvements in Go 1.15, which was released earlier this month. The gist is that 1.15 brings “a slew of performance improvements” and compiler changes “reducing binary sizes by about 5%, and improving building Go applications to be around 20% faster and requiring 30% less memory on average.”
• Jetpack Compose Debuts in Alpha: Last Google-related tidbit for this week, the company released Jetpack Compose Alpha, a UI toolkit for building Android apps. Jetpack compose is a combination of some things you Android developers are already familiar with, such as Android Jetpack, which offers a suite of libraries, and the Kotlin programming language, which Google threw its weight behind recently and now says is used by “60% of pro-Android developers.” In addition to those, Jetpack Compose adds “the simplicity of declarative APIs for building UI,” alongside a set of canonical sample apps. If you’re interested in giving it a whirl, there’s a Compose Tutorial or a setup if you’re rearing to go, but don’t rear too hard — Compose isn’t recommended for full production use yet, as the team is working towards API stability and finish performance optimizations. Compose 1.0 is expected in 2021.

• GitHub Upgrades to Ruby 2.7: GitHub made the full move to using Ruby 2.7 in production in July and now the company has written up a retrospective on the process. According to the blog post, they had more than 11,000 warnings to fix in order to run a “deprecation-free” Ruby 2.7, and the team offers a peek into their strategy for doing so, which partly came down to setting up their 400,000 lines-of-code application to be dual-bootable in both Ruby 2.6 and 2.7 so they could “make backward-compatible changes, merge those to the main branch, and avoid maintaining a long-running branch for our upgrade.” GitHub also designed a process to reduce risks during deployment involving dual-builds and essentially doing a little bit at a time, with the full roll-out taking about two hours. “For any companies that are wondering if this upgrade is worth it the answer is: 100%,” they write. “Even without the performance improvements, falling behind on Ruby upgrades has drastic negative effects on the stability of your codebase.”

So about event-driven serverless architecture, what was i saying ? pic.twitter.com/BygARuCnLx

— Sebastien Goasguen (@sebgoa) August 23, 2020

Amazon Web Services and The Cloud Native Computing Foundation are sponsors of InApps Technology.

Feature image via Pixabay.