Chris Aniszczyk is the Executive Director of the Open Container Initiative. In this podcast, recorded at the Open Source Leadership Summit in 2018, Chris speaks to me about the role of container standardization, what's coming next with the OCI, and how open source collaboration changes at scale. Also on this podcast, Kubernetes graduates in the Cloud Native Computing Foundation (CNCF), how companies like Red Hat create products such as OpenShift using projects under the CNCF and elsewhere, and the need to tailor approaches for individual open source communities.
Listen to podcast MP3 [00:19:17]
Listen to podcast OGG [00:19:17]
[Transcript]
Gordon Haff: We talked at the last Open Source Leadership Summit. We're going to review a little bit about what has changed since then, where things stand right now, but I'm going to spend most of this podcast talking with Chris about the role that OCI plays and the broader landscape in how the sorts of things that the Open Container Initiative does plays into open source more broadly.
Chris Aniszczyk: I can give a little bit of an update about where we are with OCI. For folks who aren't familiar, we founded OCI a little over two and a half years ago with the express purpose of bringing some very basic, minimal container standards to prevent an issue at the time where people feared that we would have multiple competing container run‑times that were diverging.
If you built a container for one system and tried to move clouds or something, you'd have to rebuild everything. Essentially, it would kill portability, it would kill the whole momentum around us pushing forward cloud‑native and container‑computing forwards.
The OCI was founded with Docker, Core OS, Red Hat, Microsoft, a lot of the major cloud providers, AWS, Google, and so on, to build these minimal standards. We've, in my opinion, been very successful. It's taken a little while, but mid‑last year, we had our first 1.0 release.
It's been great to see that finally happen, which basically blessed two specific ‑‑ we call them "specifications." We are somewhat of a standards body, but more of a modern standards body, is the best way I like to describe it. We're very much a code‑first organization, when it comes to things with trailing specs.
We coalesced around two specifications. One was the run‑time, which is how do you execute a start‑stop lifecycle of a container, and then the image spec, which is the underlying image format of how a container is packaged.
We hit 1.0, and every major cloud provider and any company that is running containers is adhering and taking advantage of the OCI specification. It's been a great journey to see the adoption happen naturally. I'm very stoked to see that.
In terms of what's going on for this year, recently we just announced...Every year we have elections around our Technical Oversight Board. The OCI TOB is responsible for adding projects, making any crazy changes in directions, and so on.
We had a bit of a shuffling, and now, of those nine members, we have folks from Red Hat, Microsoft, Docker, IBM, Google, and even the honorable Greg KH from the kernel team are on the Technical Oversight Board. It's great to mix of folks there.
We're also adding some new members in the coming weeks. Some different cloud providers in China and a container project called Kata Containers is joining. We'll be adhering and supporting OCI within that project.
In terms of what's next, let's see. There's a lot of discussion in the OCI community to add something called a "distribution specification." Now that we've nailed the run‑time and image bits, how do we fetch containers? How do we distribute them?
There's a lot of different container registries out there. They all have similar APIs, but there's been a bit of incompatibility between them. The community is proposing to take parts of the Docker V2 registry API spec that's already there, make some improvements, get the final input from the community, and bless that as a specification.
Gordon: Thanks. That was great rundown of where we are. I'm going to take things up maybe 20,000 feet now and talk about the philosophy here and how it pervades open source more broadly.
You talked about the specific motivations behind starting OCI, but let's take that up a level about what's the general problem in open source that OCI was trying to address that may exist in other places, as well?
Chris: If you saw Jim's keynote today, the whole interest around open source collaboration sustainability. When you're dealing with a lot of different companies, a lot of mutual self‑interests, you do need a neutral setting where they can all come together, collaborate in software, and agree to a set of rules and ensure that there is a fair playing field for everyone.
OCI, and even other open source foundations under the Linux Foundation like CNCF, help guarantee that for projects and companies. That there is a fair playing field, so one company doesn't take advantage of another.
It's business at the end of the day. It's all mutual self‑interest, everyone's out for themselves. Foundations like OCI exist to ensure that things are fair and that projects are supported in a neutral way. I think that's a problem space that OCI and other efforts apply in the Linux Foundation.
Gordon: In some ways, these are, at least, potential problems that are growing out of scale and out of success, that when open source was a fairly small thing and a relatively small set of communities, everyone knew each other, and this kind of thing wasn't as big a problem.
At one level, open source, generally, has certainly helped. You'll never solve the collaboration problem, people are people. It's certainly helped the collaboration problem in general, but it seems as if we're seeing that there needs to be more process around collaboration, open source, that things like OCI can address.
Chris: To me, it's all about fairness. Humans and businesses innately want things to be fair and will call things out otherwise. Foundations and efforts like the OCI help establish those rules, so companies feel comfortable collaborating. It's all about establishing that initial level of trust. If people and companies trust each other within the projects, good work will happen.
The other thing that Jim also alluded a little bit today in his keynote was open source has done extremely well. We've come a long way since those Linux days, "Microsoft's the evil empire," all those fun jokes you had. Microsoft's a huge adopter of open source now. It's incredible to see how the company has changed.
We have this cool effort within the Linux Foundation called The Automotive Grade Linux, where a bunch of companies ‑‑ Toyota and so on ‑‑ are getting together to collaborate, to bring open source to vehicles and cars. It's a whole new industry being impacted by open source.
We're going to see other let's call them "industry verticals," for lack of a better word, starting to embrace and take advantage of open source. I spend a small portion of my job helping companies, through the Linux Foundation, come and learn how to build an open source program or how to build an open source strategy for the company.
I'm seeing industries out of left field, that you're like, "Why is film interested in open source? Why is pharma?" They really want to do something with open source?
It's just incredible to see that interest in other verticals out there, where companies are like, "Look, let's find ways to collaborate." A lot of the stuff that we do isn't how we're generating our business value, it's some commodity that we need to get our business done. Let's collaborate on that and then focus on the business value.
That's the trend I think you'll continue to see in the future.
Gordon: This seems to be the really dramatic change over the last few years. I'm writing this book on open source. Historically, there was so much attention being paid to things like licenses, to things like being able to view source code, to having free distribution, that kind of thing. Originally, there wasn't much attention paid to this coordination and collaboration.
Chris: Licensing and all that is table stakes. That's a requirement to get the gears going for collaboration, but there's whole aspects around values, coordination, governance. One of the hacks that we came up with ‑‑ at least, in the Cloud Native Computing Foundation, in CNCF ‑‑ was not to prescribe one explicit governance model for projects.
We give them the choice to craft their own, as long as it's transparent and fair. I think that's the reality, that each open source project is different. They have their own unique needs. Like the Tolstoy principal for open source, "Each project is unhappy in its unique own way." You trying to prescribe one way for them to solve things, potentially leads to ruin, in my opinion.
I think the whole custom crafting of governance and allowing projects to evolve that over time as they grow has been a great thing, a lesson learned for us.
Gordon: Looking forward, the OCI, this idea of creating a standard syscall layer, if you would, for other aspects of the open source world, where are some things, if you look out there, that there's benefits to a similar type of approach?
Chris: That's a great question. Obviously, in OCI I mentioned the distribution of containers as a specific problem that we want to standardize, and within the OCI context further than that. I'm not sure where things will go. There's been discussions around maybe standardizing the way containers are built. There's many different ways to do that.
Outside of OCI, I don't know. I think there's been [laughs] many efforts within this industry to standardize on certain things. It's a mixed road of failure and successes. Some of us may remember the LSB ‑‑ [laughs] Linux Standard Base ‑‑ and where that went.
The idea was noble, but sometimes these things don't necessarily succeed. I'm sure we'll see other efforts, at least in the Linux Foundation, around this.
Gordon: I think, as maybe you've alluded to, we do have this idea of standards coming out of code, rather than establishing standards these days.
Chris: To me, that's probably the biggest change. The archetype of the traditional standards organization, where you have a bunch of architects locked in a room, drawing pictures and diagrams. I think that's dead.
I think what we're going to transition to is, where we're going to go, to these organizations, where they're like OCI. They do have the traditional model that exists in a standards organization, but they are a code‑first organization.
There is no cabal meeting of architects drawing pictures and then sending this message from high‑up high, "Go implement this." That's just not how it works anymore. I think standards organizations are realizing this, and I think OCI is a trendsetter in setting how a modern standards organization should work.
Gordon: In one of the keynotes this morning, we talked about Kubernetes and the idea that the extensibility points really evolve out of the code.
Chris: Kubernetes has evolved significantly. They've evolved their governance. Their values have shifted a little bit. I give them a lot of credit, they have listened to their end‑users and community, more so than probably any other project that I've interact with. They've been very thoughtful, and they should be very proud of graduating today, which was another big announcement.
Gordon: I confess to, given how many customers [laughs] that are getting Kubernetes in production today, I'm like, "What? They hadn't graduated?"
Chris: I know. It's funny, but you have to remember, both OCI and CNCF, they're about two and a half years old. When we started CNCF, we didn't have a Technical Board. We didn't have the TOC, we had to bootstrap that. When the TOC was established six months later, "OK, we need a development process," and that takes a while.
We're constantly evolving these things. I would say about a year ago, we settled on a graduation and development process, and we're like, "OK, it's there. Let's see how projects will progress before we start asking projects to graduate."
We eventually reached out to Kubernetes, once they recently established their steering committee ‑‑ we were waiting for that ‑‑ and they decided that, "Yeah, things look great! We should formally apply to graduate." The TOC gladly accepted it, voted, and approved.
I think it's a great sign, reflects on the maturity of where CNCF as an organization. That we have a good graduation and development process, but it took a while to make that. We had to create this stuff on our own. We definitely learned from other foundations out there, but we had to create it on our own and put our own spin on it.
Gordon: I think a lot of people out there would like to hear, "Here's the playbook. Here's how you do open source," and it just doesn't work that way.
Chris: I wish there was a playbook. From my experience at the Linux Foundation, like I said, each open source project is unhappy in its own way. Creating custom governance, custom bylaws, and how these communities coordinate and interact? It's what the Linux Foundation does. You cannot just have one way to do things.
There are other successful efforts out there, like Apache and the Apache way. I've been involved in the Eclipse Foundation, there was the Eclipse way and development process. To me it's just hard to prescribe one specific solution for all projects to adopt, because every project has its own unique needs, depending on the business and users and so on.
Our work at the Linux Foundation is all catering to those needs and providing the best possible solution for them.
Gordon: You're saying your work is never done? [laughs] That's probably a good end.
Chris: We're busy. We're extremely busy. For me, it's interesting, because I wear multiple hats at the LF. Working on the OCI, that's a very constrained focus base. CNCF, obviously, we have grown and expanded from just one project, Kubernetes, to now 16, and ever‑growing.
It reflects how Cloud Native has taken the industry by storm. People really want to take advantage of some of the lessons learned from Google and other Internet‑scale giants, because they themselves are trying to take advantage of the needs or they're becoming software companies themselves.
We had discussions with the Automotive Grade Linux folks like, "Great! They're working together on packaging software in cars and the integrated console and work together." They're like, "Holy crap, we're going to need a cloud to back this. Where are we going to go for this?"
I'm like, "The CNCF, the Cloud Native folks, they've figured this out, so why don't we leverage that?" To me, it's just great to see that level of collaboration and interest.
Gordon: The CNCF, over the last year, is pretty amazing. I did a podcast with Dan Kohn, the Executive Director, at Open Source Leadership Summit last year. At the time, Kubernetes was obviously in there, and I think Prometheus had just been established. That was it.
Chris: I know. We had just two projects, a barely‑formed Technical Board and process, and it's amazing to see. Today's, like I said, a very special day for a lot of us who have been involved with the foundation in the beginning, including those folks on the TOC.
It's great to see Kubernetes graduate. I'm excited to kick off a vote soon for Prometheus, which was our second project. They're a very important project within the ecosystem. It integrates not only with Kubernetes, but to be honest, many people use Prometheus, even without Kubernetes, for all sorts of things.
It's a very useful tool in the Cloud Native space, but it is also a very mature project. [laughs]
Gordon: Probably should wrap up, but projects within CNCF, among other places, are such a great example of how open source creates this environment where someone can come up with a new, distributive tracing tool ‑‑ logging, monitoring, whatever ‑‑ and that stuff can all work together very modularly.
Chris: Absolutely. One of the key lessons we learned when we were starting CNCF was we didn't want to force the integration. If you look at the new interactive landscape and the cute little trail map we launched today, the whole point of that is to state that each project independently works on its own.
Some companies, like Red Hat, are free to integrate them and build a cool product like OpenShift with, but in general, there is no forced integration. The integration happens by our members building products and serving end‑users. There is no forced train or thing to say, "All projects must work together."
The key hack for us was, let the end‑users and members build useful things for end‑use and have that dictate how things are integrated and work together. I think it's working out.
No comments:
Post a Comment