Containers / Development / Technology

This Week in Programming: Google Tackles the Tragedy of the Open Source Commons

12 Dec 2020 6:00am, by

As part of its involvement in the recently announced Open Source Security Foundation (OpenSSF), Google has penned a blog post outlining one of the first steps it will take as part of this group, with an attempt at finding critical open source projects.

“Open source software (OSS) has long suffered from a ‘tragedy of the commons’ problem,” they write. “Most organizations, large and small, make use of open source software every day to build modern products, but many OSS projects are struggling for the time, resources and attention they need.”

So as a way to address this problem, and help fund those projects that need funding, Google is releasing the Criticality Score project. The project gives projects a criticality score (a number between 0 and 1) that is “is derived from various project usage metrics” such as “a project’s age, number of individual contributors and organizations involved, user involvement (in terms of new issue requests and updates), and a rough estimate of its dependencies using commit mentions.” From there, you can also add your own metrics, if you see fit. And, of course, as with anything that assigns a score, this is the first area some see fit to nitpick.

A Hacker News thread on the topic offers an easily readable list of the top ten projects for a number of languages, and others find similar faults there as well. Abhishek Arya, one of the project’s creators, points out that the project is still in its initial phases and welcoming feedback on “any ideas on metrics we can use.” Arya also notes that the project is currently limited to ranking open source projects hosted on GitHub, but “will be expanding to our source control system in the near future.”

“Though we have made some progress on this problem, we have not solved it and are eager for the community’s help in refining these metrics to identify critical open source projects,” the blog post announcing the project concludes.

Oh, and if you happen to be, as cited in the popular XKCD comic on the topic, that “random person in Nebraska” who has been thanklessly maintaining one such critical project for the past couple of decades, Google encourages you to reach out and request some assistance directly.

This Week in Programming

  • GitHub Gets Dark Mode (And Some Other Stuff):  In what likely amounts to some of the biggest news of the week for you more stereotypically cave-dwelling developer types, GitHub finally released dark mode in public beta, which you can enable in your settings, at this week’s GitHub Universe. Dark mode aside, GitHub made a number of announcements this week, all of which can be found in this succinct summary, updating and adding onto a number of features. GitHub Sponsors, for example, are now taking payments from companies, not just individuals, and the launch comes with a dozen corporate sponsors signing on at launch. GitHub Discussions, meanwhile, is now available in beta to all public repositories, as is the beta of dependency reviews, and pull request auto-merges will be available as a public beta on public repositories next week, as well as private repositories on Team and GitHub Enterprise Cloud plans. Then, later this month, GitHub Actions will get a number of new features, including protected environments and required reviewers, which adds a step where jobs attempting to deploy to an environment are automatically paused and reviewers are notified. This will be made available in beta for private repositories on GitHub Enterprise Cloud and all public repositories. Similarly, workflow visualization, deployments, and deployment logs will enter public beta for everyone on GitHub. Finally, GitHub introduced GitHub Enterprise Server 3.0, which will launch on December 16, and “brings built-in CI/CD and automation capabilities to the platform with GitHub Actions and Packages,” as well as adds support for GitHub for mobile.
  • Mirantis to Take Over Dockershim Support: Mirantis, the company that bought a large swath of Docker last year, has said it will take over support of Kubernetes dockershim, writing that “the rumors of dockershim’s demise have been greatly exaggerated.” We covered this topic last week, you might remember, and little has changed since then, except that “Mirantis and Docker have agreed to partner to maintain the shim code standalone outside Kubernetes, as a conformant CRI interface for the Docker Engine API.” This means that the Mirantis Container Runtime (MCR) will be CRI compliant and available as open source. They note that, as has been pointed out in numerous forums, “for most people, the deprecation of dockershim is a non-issue.” For others, “it will just require a small configuration change,” which they will provide.

  • Docker Engine Adds Cgroups V2 Support, Docker Desktop 3 Arrives: The latest version of Docker Engine adds several new features, including support for cgroups V2, improvements to the API, client and build experience, and the move of multiple features out of experimental. Cgroups, along with namespaces, is the Linux core of containers, and V2 of cgroups arrived in 2016, changing how groups are managed and adding support for imposing resource limitations on rootless containers. With the arrival of support for V2 in the runc container runtime, support has also been added to Docker, and the company notes that “this change in turn has allowed Docker to graduate rootless from experimental to a fully supported feature.” For further details, check out the blog post, and head to the change log for all the changes arriving with Docker Engine 20.20. While we’re talking about Docker, Docker Desktop 3.0 has arrived and it should take you less time to update this time around, as updates will simply add on to the previous version, rather than coming as a full installer. At the same time, Docker is getting rid of its Stable and Edge channels and putting everything into one stream. If you’re still interested in getting early access to those preview features, take a look at joining the Docker Developer Preview Program.
  • Rust Holds A “Foundation Conversation”: This past week has been host to what the Rust team has dubbed “The Foundation Conversation,” building on its announcement earlier this year that it planned on creating a foundation after Mozilla restructured and laid off many employees who had been working on the language. The conversation came in the form of a number of Q&A periods and live broadcasts, as well as the interactive creation of a Rust Foundation FAQ. That, by the way, is one of the first answers in said FAQ — the foundation will be called the “Rust Foundation,” which the team says it founded because they “simply didn’t find an organization that we felt was aligned with our community goals.” As for funding for such a foundation, they say they will have news on that front next month. If you have thoughts about the creation of a Rust Foundation, the team also asks that you fill out a survey on the topic. By the time you read this, it will be too late for most of the Q&A sessions, but some will be available on the Rust YouTube channel.

  • Kotlin Revamps Its Docs: JetBrains, the company behind Kotlin, has said that it is revamping the Kotlin documentation and it wants you to give it a try. The new documentation will be mobile friendly, with better navigation and structure, as well as the all-important dark mode. As with anything, they would like your feedback on the new revamped documentation, which you can turn on here. To view the old format, you’ll need to go to the usual link in another browser or incognito window, to dodge the cookie that sets your preference to the new version. You can also revert to the old docs if you like.

A newsletter digest of the week’s most important stories & analyses.