Diane Mueller is the community manager for OpenShift Origin, a Caas and PaaS platform for cloud-native application development, deployment, and operations. In this podcast, she discusses how communities like the OpenShift Commons are evolving from groups that were singularly focused on code contributions to ones that focus increasingly on users and contributors in other areas.
Listen to MP3 [20:52]
Listen to OGG [20:52]
[TRANSCRIPT]
Gordon Haff: For the first time in way too long, I am here with Diane Mueller, who runs community development for Red Hat OpenShift. Diane's been spending a lot of time over the last year thinking about how communities should be built and how they should be allowed to evolve.
As a result, I think she has some interesting things to say about how open-source communities in general are evolving. Maybe we can start with a little bit of context of where you're coming from. We just had another very successful OpenShift Commons Gathering. What is OpenShift Commons and where we are right now?
Diane Mueller: I'm the director of community development -- which means nothing to anybody -- for OpenShift.
Basically, I've been in the open source world for almost 20 years now and worked on lots of different open standards, open source projects, and done a lot of thinking about what it is to develop a community that will sustain an open source project or move a standard forward in adoption.
Thinking about what it really takes to create -- as someone famous once said, the village that it takes to raise a child -- the village that it takes to create a global ecosystem that supports and sustains people using your project.
We hear a lot about trying to grab code contributions for an individual project and grow the maintainers of a project.
I've learned over the past four or five years working at Red Hat about a lot of different open-source community models. With OpenShift, we had some really interesting things happen that forced us to really open up our ideas about what it is to make a community that will sustain a project for the long haul. A lot of it was about collaboration with upstream projects.
What we did about two years ago, we pivoted the whole underpinnings of OpenShift to work with the Kubernetes community. If you don't know Kubernetes, Google it, find out about it -- cluster management and a whole lot more at scale for clouds. It is the underpinnings now, along with a lot of other open projects for OpenShift Origin, which is the project that I manage for Red Hat.
What happened when we did that pivot was two things. One, we pivoted and we had an existing user base, so we had lots of people we had to educate about the redirection of our architecture and our project, and how to use it with new tools, new pods and a different approach to containers. All kinds of stuff.
We had this fire-hose of information that we had to get out there to people who were already using it. Then we had a whole new community of people -- the Kubernetes community and others -- that we were trying to figure out how to collaborate with.
Now, rather than just trying to get people to contribute to Origin, we were contributing back to upstream projects that were integral to our project's lifecycle, and had to keep in-sync with other projects, how to collaborate with Docker, then the OCI and all the other container standards.
Tons of other projects for monitoring within the CNCF: Prometheus, Grafeas, and other projects that are out there. We had to create a new model. That model we named -- we had to give it some sort of name -- we called it the Commons because Red Hat's near Boston, and I'm from that area.
Boston Common is a shared resource, the grass where you bring your cows to graze and you have your farmer's hipster market or whatever it is today that they do on Boston Commons besides protests and wonderful things, but it's also right next to City Hall and all the state government stuff.
The governance and all of the other pieces of things that threaded together with the concept of common, so we created something called the OpenShift Commons. What we tried to do was open up our minds about what the community constituted.
There's been lots of other examples of people doing similar things where we reached out to the upstream communities, to -- we didn't ignore the contributors to our code base, because we love them -- to the service providers who were building infrastructure that hosted OpenShift.
We have AWS, Google, VMware, and a bazillion other cloud-hosting providers that are trying to deploy OpenShift and make managed service offerings of them. They constituted a whole lot of really good feedback besides the stuff that we're using ourselves, hosting OpenShift online originally, and then OpenShift dedicated in addition, and openshift.io, lots of things ourselves.
We learned a lot, and got a lot of feedback from there. Also all of the ISVs, all the consultants, all the database folks from Crunchy Data to Tigera. All kinds of other people who were trying to work with us, but didn't have a way in because, in the old model of open-source community management, you were only looking for those code contributors.
You only really talked to people when they were those people that were giving you code. We tried to flip this all on its head.
In addition to all these people who were adding services, or providing infrastructure, or working with us on this, there was that whole other community out there, the customers, the people who were actually deploying OpenShift Origin or deploying OpenShift Container Platform. How do we get their feedback back to the contributors, the engineers, the service providers on this topic?
What we did was try and create a new model, a new ecosystem that incorporated all of those different parties, and different perspectives. We used a lot of virtual tools, a lot of new tools like Slack. We stepped up beyond the mailing list. We do weekly briefings. We went very virtual because, one, I don't scale. The Evangelist and Dev Advocate team didn't scale. The PMs don't scale that are working at Red Hat.
We need to be able to get all that word out there, all this new information out there, so we went very virtual. We worked with a lot of people to create online learning stuff, a lot of really good tooling, and we had a lot of community help and support in doing that.
If you go on our Slack channel for Commons at OpenShift, you'll see a lot of people talking to each other that are not Red Haters, giving support to each other and peers. A lot of it was about creating this peer-to-peer network model, wherein Red Hat got out of the way so the conversations could be common between Amadeus and a Clydesdale Bank or someone else.
It had different interesting aspects. We were trying to create and use all those tools to do that, as well as we realized we couldn't just be virtual. We're here in London and we just came through a day of what we called OpenShift gathering -- which is not like a Red Hat Summit, which is huge -- or a meet up, which is just a two-hour thing.
A gathering where we all come together, like on the Commons. We have conversations. We have panels of like people talking about stuff, panels of disparate people from different open source projects. We get updates from different upstream projects.
There's lots of stuff that we do try to make that virtual world work, because I think you do need the people connections.
As soon as I stopped trying to attract contributors to my project, we went from...I think we had five external organizations contributing when I started on this project to OpenShift Origin.
We've gone from 5 organizations to 70. That's huge in two years' time. That's a huge growth spurt. It just shows that by giving people a voice, and making a space for people from different parts of our community, and different parts of our ecosystem, that actually drove code contribution.
I think we have to break the model of what we say is open-source community. We need new rules for revolutionaries. We need new open-source revolutionaries, and we need an evolution in how we think about who is part of the community. That's really what we've tried to do. What I've tried to do over the past couple of years is give the podium away.
Gordon: I'd like to take things up a level or abstract things away a level. We love abstracting things in computer science.
You've been talking about things that have been done specifically in the context of OpenShift. I'd like to probe about generalizing this. Why do you think things are different? Why has this been a good model for OpenShift, whereas it's not something that we've necessarily really seen in most other open source projects? Has the world changed? Is OpenShift different in some ways? Why?
Diane: We don't have enough time for me to rant completely, but I think, in some ways, in the old world, we would've thrown our code into a foundation. There's a lot of room for people and foundations for helping grow and incubate projects. Because of the pivot that we did to Kubernetes, we were forced to do something different.
In doing that and in breaking the model, or the rules, for what an open-source community is, we started finding a new framework. I think the framework is a more inclusive, diverse community and it allows us to really drive innovation.
If you abstract what we've done for OpenShift and apply it to any other open-source project -- and maybe not one that's in incubation -- maybe some of things that have come out of OpenShift that we're slowly incubating into other projects or moving into Kubernetes functions and features from OpenShift.
I think if you abstract what we've done, you can apply it to any existing open-source community. The foundations still, in some ways, play a nice role for giving you some structure around governance, and helping incubate stuff, and helping create standards. I really love what OCI is doing to create standards around containers. There's still a role for that in some ways.
I think the lesson that we can learn from the experience and we can apply to other projects is to open up the community so that it includes feedback mechanisms and gives the podium away from, say, an enterprise like Red Hat that's pushing something so that we don't have a one-way street, or that we don't always have to play the mediator in any conversation.
What I'm trying to do is break down the barriers between the different people in the network and really try and help people make the connections across the community. To do that, the other secret ingredient in this model is there isn't any anonymity. There's a couple of rants I've done somewhere online about it.
I love GitHub, but everybody who signs up for GitHub pretty much uses a Gmail account or some super-secret email that I can't figure out. A lot of them flag their GitHub with their affiliations, which is great. Then companies like Bitergia or Stackanalytics scrape that, and we can figure out what organization they're from.
I think, in the terms of community, in order to have a real trusted peer-to-peer network, you've got to know who you're talking to. The other aspect of these community models is that we ask people to really be clear about who their corporate masters are, who they're working for.
That doesn't mean that's your agenda, but it does mean that, if I'm working at some big financial institution, I know that I'm talking to another big financial institution and there may be rules that apply then I need to worry about -- privacy and things like that. Also, I can learn lots of things from people outside of my spectrum, my normal peer-to-peer network. That's really been very helpful.
If you took this, it's not OpenShift specific. I think what it is, is more these are the lessons. This is the framework we've had with the Commons model, is what I call it. You can brand it any way you want. I think the idea of having these shared resources, whether they are virtual Slack mailing lists, and having the lack of anonymity, and the ability to...
Here in London, one of the Commons' members, Secnix, was really the major reason we actually hosted the gathering here. Justin Cook did an amazing job organizing the venue and helping us pull this whole thing together in less than 50 days. A lot of the community gatherings and things are driven by the Commons' members.
When you let go being the absolute owner of a project...Not that Red Hat has let go of OpenShift or anything. I'm not saying that, but if you let go and let in other people into the community and have them have a say, and have a voice, and an ability to be recognized in lots of different ways.
We always talk in open-source about one of the best ways to get in is documentation, or log an issue, or do a pull request, or something that... but there's a lot more than GitHub-centric little pull requests and issues. Those are good. Don't get me wrong.
I think maybe when I talk about SIGs, Special Interest Groups, the distinction we make with OpenShift SIGs is that they really are about sharing best practices, and lessons learned, and what's in your stack that you're running. Maybe your machine learning on OpenShift is, "Tell us what all the tools that you're doing. Share that with your peers," versus, say, Kubernetes' SIG, which is, "Tell me how I'm going to get Cluster Federation working," or, "How am I going to do service catalog work and contribute to that?" There's this conversational level of community that has to be somewhere it has to grow from. It has to be nurtured.
I think that's the role today in community development that I'm espousing, is nurturing those conversations.
Gordon: You mentioned Kubernetes a few times. You mentioned some things like OCI (Open Container Initiative), CNCF (Cloud Native Computing Foundation)n. I've done a number of podcasts with various executive directors and other project heads within those foundations.
Obviously, OpenShift touches many of these things. Kubernetes, of course, but you've also mentioned Prometheus, and then there is Istio in the service mesh area, and a lot of other things. How do you think about and how do you interact and work with those foundations, which are often structured in a somewhat different way from OpenShift Commons?
Diane: I think the role of community management, or community development is to create those connections and to make sure that the updates from those different foundations make it, and unfiltered through, and get connected to all of the different pieces and parts. That's, in some ways, what the briefings are we do.
We get people to talk from different projects, different foundations, different aspects of the community and make that information available in some ways. The foundations, like I said before, are really great around governance and incubation. What we're trying to do is create the conversations for cross-community collaboration. That's really the connective tissue of communities.
That's where communities really help drive, and the collaboration that we do with these, drive the innovation back into OpenShift and into the people who use OpenShift into their practices as well, into their enterprises, and their uses of OpenShift, and the tooling that they're building on top of it.
Gordon: I promise I won't share with your manager, but what are your goals and plans for next year?
Diane: [laughs] Oh, geez. I think, we just did the metrics thing. I think I hate metrics, but yeah, shh, don't tell my boss. More face-to-face time. More gatherings, more regional gatherings. We did one in London. We'll be doing something in Copenhagen before KubeCon and something at Red Hat Summit. More customer stories.
When I say customer stories, it's not the Red Hat customers. It's people who are using the different pieces and parts of our ecosystem to get them to tell us what their full stack is. What are they using?
When I ask someone to tell me to share their story, their lessons learned, OpenShift may be just a component of say -- I'm really hooked on ML and AI right now -- might be just part of they're doing TensorFlow with JupyterHub and maybe they're off on the Kubeflow tangent or maybe they're using Spark or something from the radanalytics team, trying to tease out the entire stack conversation.
I see a lot more of that happening this year. I think we've hit the tipping point of where we're trying to teach people what Kubernetes is. We've done that, last year. We still got some more of that to do because it keeps evolving every three months. This year I see it as the year of workloads on OpenShift. What are we doing? Getting more of those stories out there.
The OpenShift Commons gathering at Summit will be almost entirely case studies. Users talking about what's in their stack. What lessons did they learn? What the best practices are? Sharing those ideas that they've done just like we did here in London. There were some great stories here. Wait for the videos for that.
Metrics, I probably will double the size of the number of organizations in the OpenShift Commons. That's really what's we're seeing now, is just really rapid. I think I said it at the London event, but in the past hundred days we've had over 40 organizations join the OpenShift Commons, which is phenomenal.
It's not like I'm going out and recruiting these people. They just are naturally finally finding the commons.openshift.org website buried under all the other Red Hat OpenShift properties there. I really encourage you, if you want to share your stories and meet your peers to come to commons.openshift.org, fill out the join form.
You'll get an email from me and all my contact information. Maybe not my home phone number, but everything else. I think growing the community of people who have production deployments and adding more of those is really the big deal this year. Track of everything that's going on in the upstream, too. Lots of that stuff going on.
Gordon: Thank you, Diane. That's a good note to close on I think.
Diane: Thank you very much. It's time for more coffee.
