Knative governance update from the steering committee

Open source collaboration exemplifies the best aspects of contributors and companies uniting to solve difficult technical problems. And, at Google, we support thousands of projects, each with their own unique communities and challenges. Recently, the Knative Steering Committee came together to write a letter that distills this ethos, and we wanted to share it with you here.

***

Dear Knative Community,

Since the previous announcement on Knative ownership and stewardship, we’ve heard a lot of feedback from you, and the ecosystem at large. As a Steering Committee, our primary job is guiding the long-term success of the project, and this really means your success building great things with Knative. 

In order to accomplish that important goal, it requires everyone involved to be aligned on our values, what it means to be an active contributor, how you build progressive trust and responsibility, and fundamentally how we work together to build that success. The Kubernetes project explicitly defined these, and for us as a governing body, they strongly resonate. We will work to construct similar values and vet them across our community.

Trust is the heart of open source. And, clear governance is a means of building and maintaining that trust. It also provides clear signal to future contributors that joining the community is a good bet, and that everyone is visibly working toward the same goals. While there are always differences in approaches and ideas, the power of the community is its ability to collectively reconcile for the benefit of our user community first and foremost. This project is bigger than any one company or individual.

These aspirations are not enough. They will require rethinking how we structure project governance. The overarching goals of the project's governance will be:

• Create a clear and documented contributor ladder that recognizes both code and non-code contributions as valuable, and provides a means to obtain membership in governance bodies like the Technical Oversight Committee and Steering Committee based on those contributions.
• Allow the Steering Committee to oversee the usage and implementation of the Knative trademark, with the intent of limiting confusion for adopters, and providing assurances of implementation consistency. Google will provide the Steering Committee with a legal escalation path for enforcement when needed.
• Widen the contributor community to include additional vendors, end-users, and ecosystem stakeholders such that fair, representational governance organically prevents any one vendor from having a majority in any part of the project. To be clear, no one company should aspire to control outcomes, as that is inherently in conflict with the goal of community stewardship. Committee representation must be a reflection of the diversity of contributors, and also allocated fairly based on the people doing the work. This is of course a delicate balance, but one we intend to solve with community input.
• Develop the governance documents, community feedback, required tooling for metrics collection, and whatever else is necessary to enact these changes. Because the community we have now is ideally a small subset of the community we aspire to see in a year, we will target a one-year transition period to the new governance we define, similar to how the Kubernetes project moved from a bootstrap committee and charter to the new community-driven model. Building consensus is a painstaking process, so it is important to allocate enough time for all voices to be heard.

The most important takeaway here is that we are working together on this, and will do so with community input, in an inclusive way. This is the beginning of the process, and we want to go back to our roots and focus on the problems we are trying to solve for adopters of our work. Let's take this moment and rejoin our efforts to do great things together.

Respectfully yours,

Michael Behrendt (IBM), Brenda Chan (Pivotal), Paul Morie (Red Hat), Jaice Singer DuMars (Google), Ryan Gregg (Google), Donna Malayeri (Google), Tomas Isdal (Google)

Members, Knative Steering Committee

Improving Developer Experience for Writing Structured Data

Though we’re still waiting on the full materialization of the promise of the Semantic Web, search engines—including Google—are heavy consumers of structured data on the web through Schema.org. In 2015, pages with Schema.org markup accounted for 31.3% of the web. Among SEO communities, interest in Schema.org and structured data has been on the rise in recent years.

Yet, as the use of structured data continues to grow, the developer experience in authoring pieces of structured data remains spotty. I ran into this as I was trying to write my own snippets of JSON-LD. It turns out, the state-of-the-art way of writing JSON-LD is to: read the Schema.org reference; try writing a JSON literal on your own; when you think you’re done, paste the JSON into a validator (like Google’s structured data testing tool); see what’s wrong, fix; and repeat, as needed.

If it’s your first time writing JSON-LD, you might spend a few minutes figuring out how to represent an enum or boolean, looking for examples as needed.

Enter schema-dts

My experience left me with a feeling that things could be improved; writing JSON-LD should be no harder than any JSON that is constrained by a certain schema. This led me to create schema-dts (npm, github) a TypeScript-based library (and an optional codegen tool) with type definitions of the latest Schema.org JSON-LD spec.

The thinking was this: Just as IDEs (and, later, language server protocols for lightweight code editors) supercharge our developer experience with as-you-type error highlighting and code completions, we can supercharge the experience of writing those JSON-LD literals.

With IDEs and language server protocols, the write-test-debug loop was made much tighter. Developers get immediate feedback on the basic correctness of the code they write, rather than having to save sporadically and feed their code to a compiler for that feedback. With schema-dts, we try to take validators like the structured data testing tool out of the critical path of write-test-debug. Instead, you can use a library to type-check your JSON, reporting errors as you type, and offering completions for `@type`s, property names, and their values.


Thanks to TypeScript’s structural typing and discriminated unions, the general shape of Schema.org’s JSON-LD can be well-represented in TypeScript typings. I have previously described the type theory behind creating a TypeScript structure that expresses the Schema.org class structure, enumerations, `DataType`s, and properties.

Schema-dts includes two related pieces: the ‘default’ schema-dts NPM package which includes the latest Schema.org definitions, and the schema-dts-gen CLI which allows you to create your own typing definitions from Schema.org-like .nt N-Triple files. The CLI also has flags to control whether deprecated classes, properties, and enums should be included, what `@context` should be assumed by objects you write, etc.

Goals and Non-Goals

The goal of schema-dts isn’t to make type definitions that accept all legal Schema.org JSON literals. Rather, it is to make sure we provide typings that always (or almost always) result in legal Schema.org JSON-LD literals that search engines would accept. In the process, we’d like to make sure it’s as general as possible, without sacrificing type checking and useful completions.

For instance, RDF’s perspective is that structured data is property-centric, and the Schema.org reference of the domains and ranges of properties is only a suggestion for what values are inferred as. RDF actually permits values of any type to be assigned to a property. Instead, schema-dts will actually constrain you by the Schema.org values.

***

If you’re passionate about structured data, try schema-dts and join the conversation on GitHub!

By: Eyas Sharaiha, Geo Engineering & Open Source scheme-dts Project

Hey! Ho! Ten Years of Go!

Ten years ago, we announced the Go release here on this blog. This weekend we marked Go's 10th birthday as an open-source programming language and ecosystem for building modern networked software.

Go's original target was networked system infrastructure, anticipating what we now call the cloud. Go has become the language of the cloud, but more than that, Go has become the language of the open-source cloud, including Containerd, CoreDNS, Docker, Envoy, Etcd, Istio, Kubernetes, Prometheus, Terraform, and Vitess.

From our earliest days working on Go, we planned for Go to be open source. We knew that bootstrapping a new language and ecosystem was too large a project for one team or even one company to do alone. Go needed a thriving open-source community to curate and grow the ecosystem, to write books and tutorials, to teach courses to developers of all skill levels, and of course to find bugs and work on code improvements and new features. And of course we also wanted to share what we had created with everyone.

Open source at its best is about people working together to accomplish far more than any of them could have done alone. We are incredibly grateful to the thousands of people who have built up Go, its ecosystem, and its community with us over the past decade.

There are over a million Go developers worldwide, and companies all over the globe are looking to hire more. In fact, people often tell us that learning Go helped them get their first jobs in the tech industry. In the end, what we're most proud of about Go is not a well-designed feature or a clever bit of code but the positive impact Go has had in so many people's lives. We aimed to create a language that would help us be better developers, and we are thrilled that Go has helped so many others. Today we launched go.dev to be a hub for all Go developers to learn more and find ways to connect with each other.

As a thank you from us on the Go team at Google to Go contributors and developers worldwide for joining us on Go's journey, we are distributing a commemorative 10th anniversary pin at this month's Go Developer Network meetups. Renee French, who created the Go gopher for the release back in 2009, designed this special pin and also painted the mission control gopher scene at the top of this post. We thank Renee for giving Go so much of her time and a mascot that continues to delight and inspire a decade on.

As #GoTurns10, we hope everyone will take a moment to celebrate the Go community and all we have achieved together. On behalf of the entire Go team at Google, thank you to everyone who has joined us over the past decade. Let's make the next one even more incredible!

By Russ Cox, for the Go team