If you’ve been using open source software for any amount of time, then you’re well aware of the tangled web of dependencies often involved in such projects. If not, there’s any number of tools out there that explore just how interconnected everything is, and this week Google has jumped into the game with its own offering — an exploratory visualization site called Open Source Insights that gives users an interactive view of dependencies of open source projects.
Now, Google isn’t the first to get into the game of trying to uncover and perhaps untangle the dizzying dependency graph of the open source world, but the company argues that it is more so trying to lay everything out in a way that developers can see, visually, just how, well, hopelessly screwed they really are.
“There are tools to help, of course: vulnerability scanners and dependency audits that can help identify when a package is exposed to a vulnerability. But it can still be difficult to visualize the big picture, to understand what you depend on, and what that implies,” they write.
What if we prefer not to know how the sausage we are making is made? 🧐
— Rich Burroughs (@richburroughs) June 3, 2021
The Open Source Insights tool — currently “experimental” — gives users either a table or graphical visualization of how a project is composed, allowing them to explore the dependency graph and examine how using different versions of certain projects might actually affect that dependency graph. One of the benefits, Google notes, is that it allows users to see all this information “without asking you to install the package first. You can see instantly what installing a package — or an updated version — might mean for your project, how popular it is, find links to source code and other information, and then decide whether it should be installed.”
Currently, the tool supports npm, Maven, Go modules, and Cargo, with more packaging systems on the way soon. While topology and visualization are certainly difficult and this helps with that, as The New Stack analyst Lawrence Hecht notes, “that really only matters for software architects and when you are trying to de-bug an application or find a problem, not for everyday situations. In other words, this type of ‘point tool’ is useful for an artisan’s toolbook, but doesn’t need to be put into the Google product portfolio.”
If you are among the skeptical out there, don’t worry, you’re never alone when it comes to Google: just head on over to Hacker News and place your bets on how long this will last before ending up in the ever growing Google graveyard.
This Week in Programming
- Pour One Out for Stack Overflow: Now, not to be too dramatic about the whole thing – after all, Joel Spolsky says that the company “will continue to operate independently, with the exact same team in place that has been operating it, according to the exact same plan and the exact same business practices” — but Stack Overflow announced this week that it had been acquired by Prosus. Promises aside, the general reaction on sites like Hacker News is one of skepticism. One user, for example, characterizes Spolsky’s statement — “The entire company is staying in place: we just have different owners now” — as “somewhere on the spectrum of absolutely naive to willfully disingenuous.” Others offer anecdotes of the various times statements such as these have been made, only to be proven wrong time and again. At this point, only time will tell.
We used to think that software was eating the world, but now we know it’s actually private equity companies.
— Ron Miller (@ron_miller) June 3, 2021
- All That’s New from DockerCon 2021: Last week was a busy one for virtual conferences, with DockerCon 2021 running at the same time as Microsoft Build. In case you missed out, Docker has written up a concise summary of all that’s new, all of which it says “bolster security in a number of dimensions including scanning for vulnerabilities during different development stages and increasing team security by offering tools such as audit logs and scoped access tokens.” The announcements you may have missed last week include the Docker Verified Publisher program, Docker Development Environments, Docker Compose v2, Scoped Access Tokens, audit logs, updates to Docker Desktop, and more.
- Catch Up on Visual Studio Code: Last week, Microsoft held its second virtual Microsoft Build conference, and this week the company has offered up a recap of all the Visual Studio Code panels. Given how much we know you enjoy your Visual Studio Code, we thought this a pertinent one to share. And while we’re talking about VS Code, your favorite editor has also released local tunnel debugging with the Kubernetes extension this week, which makes it possible to “run your app’s microservices natively on your development machine, using the same development tools you have always used, while tunneling to a Kubernetes cluster where the rest of the application and the other services are running.” This makes it so that you can test and debug code on your local machine as if it were running on a Kubernetes cluster, something that might otherwise be difficult if not downright impossible. “The Local Tunnel Debug capability,” they note, “also sidesteps operational complexities, such as having to build Docker images and deploying to a cluster to see the changes.”
- Fuzz Testing Is a Go for Golang: While they say that native fuzzing won’t be ready for the Go 1.17 release as initially proposed, fuzzing is now in beta in the Go development branch, dev.fuzz. According to Katie Hockman, the developer behind the proposal, there are three main goals for offering a beta of the fuzzing feature. Much like with any beta, the Go team wants to identify and fix any issues, figure out if it’s actually effective at doing what it’s intended to do (finding bugs), and to determine whether or not the user interface is actually usable. Some caveats for those who want to participate in the beta: fuzzing may take up a lot of memory, affecting performance while it is running, and also may occupy several GBs of storage as well. While fuzzing is in beta, make sure to file an issue for any problems or ideas, and head on over to the #fuzzing channel in Gophers Slack to take part in the discussion.
- The GCC Slowly Backs Away from the FSF: Last up this week, an article over at DevClass takes a look at how GCC is now accepting contributions without FSF copyright assignment. “Developers who want to contribute to the GNU Compiler Collection but don’t feel like signing over copyright to the Free Software Foundation can get busy committing now,” they write, noting that GCC Steering Committee member David Edelsohn had notified contributors of the move, saying that the committee had “decided to relax the requirement to assign copyright for all changes.” There has been a bit of a brouhaha in recent months over the reinstatement of Richard M. Stallman to the FSF board, and DevClass cites this as a likely reason for this change. “They felt like an association with Stallman was not serving the best interests of the GCC developers and user community, given that the ‘GCC Steering Committee is committed to providing a friendly, safe and welcoming environment for all’ – something Stallman isn’t especially known for,” they write. “The updated copyright policy aligns with that notion, making it easier for those critical of the FSF and its recent decision to keep Stallman on its board of directors to stick with GCC.”
the future of software development pic.twitter.com/bFE9YCpHFp
— Ellen Körbes (@ellenkorbes) June 2, 2021