Scott McCarty

662 points
Akron, OH

At Red Hat, Scott McCarty is technical product manager for the container subsystem team, which enables key product capabilities in OpenShift Container Platform and Red Hat Enterprise Linux. Focus areas includes container runtimes, tools, and images. Working closely with engineering teams, at both a product and upstream project level, he combines personal experience with customer and partner feedback to enhance and tailor strategic container features and capabilities.

Scott is a social media start-up veteran, an e-commerce old timer, and a weathered government research technologist, with experience across a variety of companies and organizations, from seven person startups to 12,000 employee technology companies. This has culminated in a unique perspective on open source software development, delivery, and maintenance.

Authored Content

Authored Cheat Sheets and Downloads

Getting started with Kubernetes

Download Kubernetes e-book

In this downloadable e-book, Scott McCarty explains how Kubernetes is as elegant as a dump truck in solving common business problems. You'll learn the basics and how to

Authored Comments

That's very interesting. I believe what you're saying is that there are some contributions made to the non-open source version of the product. I think that is definitely cool, but it's not exactly what I'm tackling here. The only way to consume a consumption to the non-open source part would be to be a customer. That's great for scratching your own itch, and I think it's great GitLab let's customers do that. That's still valuable, and definitely better than completely proprietary source code.

That said, it doesn't help the upstream, so there's really no value capture for the individual doing the work. It's strictly a relationship between the buyer's company, and the vendor's company. It unblocks a use case, but the developer doesn't capture any personal brand value from doing that work, nor does the upstream project. That inherently limits it to a VERY small set of contributions. My guess is GitLab Enterprise is 99.9% written by GitLab employees, and only 0.01% contributions from customers.

Furthermore, I'll bet upstream GitLab looks quite similar. Per this link which I cited in the article, the vast vast vast majority of contributions come from GitLab employees: https://bit.ly/3oyEC7w This means that value creations is pretty much $1.01 dollars for every $1.00 spent.

On the other hand, with something like Linux or Kubernetes, every dollar an engineering team spends contributing is worth $20, $30, or even $50 in returns. That's the power of community driven development and the main difference between open core and proprietary software in general.

As for your new employer, I really like that model. Just to be clear, we are talking about a completely different model. This is not open core, this is open source. In this article, I'm specifically tackling the difference between open core and open source as a tool for doing differentiation. I think your new employer totally gets that open core isn't needed. In fact, I'd argue that the cloud services model is better differentiation and hence helps companies capture value better than trying an open core license.

I discuss that in this article which digs into 18 different ways to differentiate a downstream product from an upstream project: https://opensource.com/article/21/2/differentiating-products-upstream-suppliers