DEV Community: Cameron Miller

World premiere: our new Cooking with Tidelift children’s book

Cameron Miller — Tue, 01 Sep 2020 14:59:39 +0000

Today is the day we are officially launching the first-ever Tidelift book. But rather than starting with a 300+ page O’Reilly-esque tome on the intricacies of open source license policy management, we decided to start modestly.

We wrote a children’s book.

It’s called Cooking with Tidelift. You can download it instantly as an ebook for your Kindle, iPad, or other favorite electronic book reader. In these weird, homebound pandemic times, maybe it will provide an interesting way to share your work with your children. Or if you don’t have kids at home, read it to your dog before bed, or share it with your nieces and nephews over Zoom.

Plus, if you register to speak with one of our open source experts, we'd be happy to send you an actual hold-it-in-your-hands book and Cooking with Tidelift apron to pair with it!

These are weird times. And weird times call for weird things like a children’s book about open source.

The story behind Cooking with Tidelift

So how did we come to write a children’s book?

Over the past year, I have spoken with a lot of people who develop applications for large enterprises using open source. In fact, almost all businesses are now using open source in some capacity for application development because of benefits like increased flexibility, greater developer satisfaction, lower total cost of ownership, and faster time to deployment.

Nevertheless, open source is not perfect, and I’ve heard several themes over and over during these conversations. Here are a few of them:

My organization requires someone to provide support and maintenance for open source components.
The reports we get from open source scanner tools are overwhelming and are slowing down developer productivity.
These scanning reports are good at identifying issues, but don’t help with resolution.
My organization needs help dealing with the complexities of open source license identification and policy enforcement.
In fact, offloading open source complexities from developers’ plates in general, whether they are security, licensing, or on-going maintenance concerns, is the overarching theme of almost all of my conversations.

Today, great developers are in high demand, and the difference between keeping top developers and losing them to a competitor can come down to how good the organization is at eliminating monotonous, automatable, or simply boring tasks—so developers can stay focused on the interesting and compelling work that really matters to them—and the organization.

Managing the open source components that comprise the bulk of most modern applications can be tedious, frustrating, and technical work. Throughout this past year, I’ve spent a good part of my time helping non-technical employees understand the intricacies of how to manage open source software components effectively.

One way of explaining the importance of a managed open source approach seemed to really resonate: comparing the best practices for managing open source development in professional environments to the best practices for commercial food production.

Simply put, open source components are like the ingredients of a recipe. As we know, open source allows you to start with building blocks rather than developing from scratch, much like cooking in the kitchen. Apart from some extreme farm-to-table restaurants, we don’t start a chicken sandwich by raising the chicken, growing the wheat, and harvesting the lettuce. We start by purchasing the ingredients from a store.

When preparing food at the commercial level however, we can’t simply wander into the backyard and start picking ingredients. If this food is going to be consumed by hundreds to thousands to millions of consumers, we need to start with known-good ingredients, and we need assurances about the quality and safety of those ingredients if we are going to put them in the food we make for our customers.

And that’s where we got the idea for Cooking with Tidelift.

So we wrote the story and hired the talented children’s book illustrators Ashley and Joel Selby to bring it to life. Hopefully this provides you with a way to teach your kids, friends, partners, grandparents—or co-workers—the basic concepts behind managed open source, and the importance of securing and maintaining the open source components you rely on.

Most of all, I hope it brings a smile to your face during these crazy times.

Fill out the form here to instantly receive your ebook!

Why scanning isn't enough

Cameron Miller — Thu, 09 Apr 2020 15:27:09 +0000

Developers today can choose from millions of free open source components, enabling them to build applications faster than ever before. But with great power comes great responsibility. While drinking from the open source firehose is great during the initial development phase, before deploying any code to production, a responsible developer will need to know the open source packages they’ve selected aren’t going to cause pain later. When making choices for which components to bring in, it is smart to ask questions like these:

Is there an active community keeping the project maintained?
Is it secure?
Is it licensed in a way that complies with our policies?
And how accurate and complete is that license information, anyway?

Enterprise organizations, especially those distributing software or in highly regulated industries, often—for good reason—care deeply about ensuring the safety and security of the code that they deploy. While the benefits of open source are undeniable, there are certain risks that must be considered when pulling code off the Internet.

Yet only 9% of organizations have an official policy in place for bringing open source components into their apps.

The need to ensure open source components were secure and properly licensed led to the rise of a set of tools that scan code for problems and vulnerabilities. Many large organizations today have licenses for at least one or more software composition analysis tools, “scanners,” that alert them to security or licensing issues with their open source components.

For the most part these tools cover one function: they identify the issues.

But when it comes to fixing the issues identified by the scanners, that is another story. Between false positives and “alert fatigue,” conflicting information about vulnerabilities, no easy way to resolve many issues (because by definition it’s not code you wrote in the first place), and yet another web UI for devs to check before deploying code, scanners can slow down releases and cause developers headaches.

Think about scanners through the metaphor of a trip to the doctor. Imagine that you are at the doctor’s office for your annual checkup. At the end of the appointment, your doctor hands you a report that lists out everything wrong with you. She turns to you and says, “Well, Bob, you’re not looking too good. You have high cholesterol, your kidneys are shutting down, and your big toe...looks like you're going to lose it. Now...go get yourself better!”

Where do you even start?

Similarly, say you get handed a list of problematic open source packages from your favorite scanning tool—what do you do with it?

You can try to address some things yourselves, if you happen to have the particular expertise (i.e. Go, JavaScript, etc.). You probably already spend 35% of your time managing code issues anyway, so this might feel normal. And if you’re not in a position to get those changes merged into the upstream community repository, prepare to maintain your own branch of every package you do this for—for the rest of time.
You can bug the package maintainers on the public GitHub repo—maybe they’ll even respond? Just remember that 74% of open source maintainers have difficulty finding time to work on their projects, and in most cases they aren’t being compensated for their work, so your urgency isn’t their urgency.
You can hire an outside consultant to come in and fix things for you—expensive, not particularly scalable, and this approach may leave you with a new fork you are now on the hook to maintain.

Or you can do what most organizations do—rank issues by severity level, address the “most important” things first, and ignore the rest.

At the end of the day, getting a diagnosis of your problems simply is not enough.

You still need the right treatment plan—including preventative maintenance—so these sorts of issues come up less in the future.

The best way to ensure the health of your open source supply chain and pass your scans is to proactively start addressing security, licensing, and maintenance concerns earlier in the process. That’s why many forward-thinking organizations are avoiding these sorts of developer headaches by shifting left and ensuring open source components are secure, properly licensed, and well maintained earlier into the development process.

Thinking back to our doctor’s office metaphor, if our goal is to be healthy, when I go to the doctor, I want them to give me a clean bill of health and send me on my way. Even though the doctor may have medication to help me with my high blood pressure and bad cholesterol, I can never expect to be healthy unless I change my ways, exercising and consuming less junk!

The same can be said when building applications with open source components. When it comes time to write production-ready code, developers should start with known-good open source from the beginning—stable components with strong communities that won’t fall into disrepair.

Scanning by itself simply isn’t enough. While an important and necessary precaution, scans still leave the burden of the “staying healthy” work on the developers. Knowing about vulnerabilities is good, especially when there is an available fix or a reliable project maintainer committed to getting you one, but this is more often the exception than the rule.

Keep scanning your code, but make sure you have tools and services—like the Tidelift Subscription—that help ensure your open source components are healthy before you even get to the scanner. You’ll have happier developers, and you’ll get better, more reliable applications even faster.