Welcome to Tech Talk.
Today's topic is open source and how you identify the next big project, taking it from an idea to a business proposition.
Joining me is Nadhan, the Red Hat Guy, who's going to explain how we get there.
Glad to be here, Dan.
And I would just paraphrased that as the "next open thing".
What does that mean?
So it is more about what is emerging.
The open source community is a community of innovation, continuous innovation.
But it all starts with an established, sustainable model.
We-- talking from a Red Hat perspective --we have products.
So these are the products that have been tested, secured and available for enterprise-level consumption today.
And just like any other company, there is engineering behind these products that are going on.
And just to give a quick inside preview into what are the other units in Red Hat
before getting to the point of identifying the next open thing in the community.
So we have the sales and services.
So that's 101--nothing secret about that.
And of course, we have customers who are consuming that.
So basic business model, even from a startup standpoint, right?
So products, sales and services, servicing our customers.
So these are the ones who have graduated from the open source into a product.
Absolutely.
Now, we could, in theory, just lie low and say "Life is good.
Let's continue." But that's not Red Hat.
That's not the Red Hat that you know, Dan.
And that's not the Red Hat, all of you know.
So what gives?
What's different?
That's where the CTO Office comes in.
So the Office of the CTO, one of the teams is actually all about emerging technologies.
Now, you might remember, in the open source community, at any point of time--
how many projects do you think are going on in the community at any point, Dan?
Take a guess.
Within Red Hat or in general?
In general?
Oh, gosh.
Thousands.
How about millions?
That's the number of projects that are going on.
So what emerging technologies does is, identifies select projects.
You talked about the next big thing and the next open thing.
How do we zero in on that?
And we will get through that.
But the job is really to identify those select projects.
And then what happens is-- when we see projects that are actually of interest, that have the potential,
that are innovative, that kind of leading us towards what the world needs.
Well, going forward, it gets the attention of products and engineering.
You're pretty perceptive there, Dan.
So that arrow is significant because that's the intake path for what is the next product that we add to the portfolio.
Well, one thing also is, is the here we show that customers are providing dollars to drive that, but they're also driving ideas.
Absolutely.
So this is not just the engagement with the community.
There are-- so great point, Dan, again.
Because what I have seen when working with customers is-- of course, there is,
enterprise I/T, the lines of business, who are interested in the products that are available for consumption.
But then there are those in the experimental mindset, the research and development, the CTO office--in the customer's enterprise.
The CTO typically is more interested in what's coming than what's available today.
That's keeping lights on, innovating, enabling businesses--all of the above.
But CTOs are usually about "What should I be thinking about?" when it comes to their enterprise?
That's why they are interested in not only working with us,
but suggesting, "Hey, we like where this project is going, but how about...?" You know, a variation to that.
So we absolutely engage directly with customers as well, and that's what feeds into the products.
So you can walk us through that process, where it starts with needs and then goes forward?
Need is the right word.
So let's think about how does this come about again. Maybe it is the million and one -- the next project after the million.
How does that come about?
So let me give you an example of what I mean by "need".
So take Kubernetes, for example, how it started.
How did you think Kubernetes started, Dan?
Your perspective on that.
Well, it started as an internal project at Google.
Fair point.
And then?
They decided that it would be in their best benefit to adopt it-- have it be adopted by the open source community.
Like everyone should be thinking, by the way.
Hint, hint.
Okay! And then, I suppose, Red Hat picked up interest as well and said, "Hey, maybe this is going to be the next big thing."
Great point! That's how that is exactly how Kubernetes started.
I remember a few years back, nobody was talking containers, nobody was talking Kubernetes.
Cloud existed, but we were not talking containers.
That was a phase.
So it found its way in here.
The need was identified to standardize,
to actually make sure that there are developers, operators-- they are able to work on a common platform.
And that intersection, DevOps-- all of that came about.
But then, we are in a world where there is a different need.
Containers are not just for the data center, not just for the cloud.
The edge devices.
So where do you think that is going, Dan?
If someone were to tell you, we need one?
What comes to mind when you think about edge devices?
Well, they generate a lot of data, for one thing.
And be able to send that data back to a data center is costly.
And they also have a lot more compute capacity than they used to.
Nowadays you can have some processing done locally and not even involve the data center.
In other words, what Dan is saying, guys, is that, the edge device is a computer in its own right.
So if data center computers need container platforms, why should we leave the edge devices out?
But they're going to have a security thing going on there as well.
It's a bit different than the normal situation in a datacenter.
Remember, I said we were the "Enterprise Open Source" software company?
That's where we come in again.
But you cannot just take the data center, the cloud container platform, and deploy it on the edge device.
Going back a few years, the mobile device, we were talking about form factors and so on.
So light footprint.
That's why the containers on the edge is a need that has surfaced, despite the adoption of Kubernetes overall.
Take MicroShift, for example -- next.redhat.com is where you would find all the projects that we are working on.
The CTO Office of Emerging Technologies is working on-- MicroShift is one of them.
Ah, so that's going to be an edge-centric container.
Yes.
And which, by the way, already got the attention of product and engineering. Hint, hint-- it's coming.
So that's exactly it-- a great example.
But just establishing the need is not good enough.
You need people.
You need contributors.
You need collaborators who actually work with each other.
It's not just about "my code is the only code". You need to work in the community.
So that need--the next step is actually the contribution.
And what this tells us is there is genuine interest and outcome-based understanding of why we need containers on the edge.
This, by the way, is just one example.
There are many such examples.
I'm just trying to give some life to that cycle.
So even with contributors, we actually need--
let's say there are, maybe a couple of companies, five contributors from each company doing it.
So you're talking not just about volunteers, but companies as contributors.
Actually, yes.
Because, Red Hat, we have paid employees whose job it is to work the open source community.
The same is true at IBM!
Yes.
And there's there's a good reason why!
And that's why you actually need that leadership support and sponsorship, that this is a good thing to do.
And open source is actually gaining that adoption industry-wide.
And that really helps.
So need/contribution.
What's next?
Just because there are contributors.
Okay, IBM and Red Hat have contributors in the open source community.
Google? Thank you very much!
But if it is not adopted beyond our companies, then why should we focus on it as a product?
So the third aspect here is adoption.
I would give an example.
When we do workshops for, let's say Ansible-- this is pre-COVID days when we were doing it in person.
Sometimes we do certain meet-ups and so on in a brewery and so on.
But for Ansible, it is like the
U.S. Bank Stadium in Minneapolis, the Toyota Stadium in Dallas.
What's that telling you?
There is adoption of that particular project, which is now a product, by the way, from an automation perspective.
It can-- so that is just an example.
It is not just contribution, it is adoption.
So when the CTO Office actually sees there is need, there is contribution, there is adoption -- the full cycle.
That's what sends a signal with these customer conversations that "Hey, that could be the next open thing."
Well, before we close, I would like you to give one comment about how our viewers could get involved in this.
You mentioned the communities.
How can they get involved in the next big thing?
Actually, just go to next.redhat.com.
You can actually see the emerging technologies we are working on.
That's the best place to start.
And for every project, the lead contributor-- the engineer who is actually working it from a Red Hat standpoint --is listed there.
So you know who is actually taking the lead.
Go there, guys.
That's next.redhat.com.
That's really a cool idea.
And if you'd like to see, maybe we can see some of those people here on the next Tech Talk.
Absolutely.
Hey, Red Hat associates-- hint, hint!
Okay, that's great!
Let's go ahead and wrap with that.
And before you leave, be sure and leave a like and subscribe.
If there's other topics you'd like to see on Tech Talk, be sure to also drop a comment below.