 So I go up and get, you know, they're perfect. Oh, do I need the mic? Yes, you do. And then we're just like way too many snacks. So I just put them out in the hallway and told everybody to eat and hopefully they will. Everyone, welcome back to the community dev room. And for those of you who have just joined us, welcome. Thank you for coming. Our next speaker will be Amir Chaudhury, who will be talking to us about balancing community and corporate needs between the MOE project and Docker. So thank you for coming in here. Thanks, folks. So I'm talking about, essentially, the Docker project and the MOE project, which came up as part of that. I'm curious how many people in the room have heard of Docker? Can you just raise your hands? How many people have heard of MOE? Awesome, almost the same number. That's great. So what I'm going to be talking about is essentially what is Docker for those who may not know. And then give you an overview of what the project and community growth has been like, just very briefly. And then try and describe the kind of different constituencies that you end up with once you have a project that quickly and over the time scale that we've had. So Docker is coming up this year. It'll be five years old. So that's not a long time, but also a really long time, depending on your perspective. And then I'll talk through the creation of the MOE project and the reasons behind that and the things we learn from that. And then I'm curious to know what kind of questions you might have, what discussion points there might be. So I'm talking to audience already knows. So Docker is essentially container technology. And there's a commercial company behind the open source project. So it's open source software. It's built on underlying things that are in Linux. And it's actually an ecosystem of tools, components, and services. So the Docker name covers actually a lot of different things. And the idea is it makes it easy for developers to build, ship, and run their applications. And it has been hugely successful. So this has had tens and tens of thousands of stars and forks. And this is just the one main repository. There are actually 350 different repositories that people who work on Docker all contribute to. And each of those form different components, different services that all get pulled in to creating what the company produces as a final product. Now, stars and forks don't really indicate anything about deployment or how much usage there is of the software once it's out in the wild. But one of the other things that Docker the company provides is a registry, which is called Docker Hub. So many of you may know that. And Docker Hub gives us an idea of how quickly the use of this software spreads because when you do a Docker pull, you actually pull from the registry and we can tally up the number of pulls there are. And so over the last few years, we've crossed 11 billion pulls on Docker Hub. And this is an old slide. This is from 2017. So we're way beyond this now. And so it's much, much higher. And with any project that's growing, there are always natural tensions. So I'm assuming a lot of people in the room here contribute to open source projects and are involved with projects that grow. There are always tensions. It's not new. It's not unusual. And how you deal with those tensions is one of the defining ways of figuring out how healthy the project is going to be. But it's natural. And different groups and different types of needs form depending on how big your project gets. Now for a project that's like Docker, when essentially the aim is we want it to be large. We want it to be used every day. We want to solve a big problem for how software is deployed. You end up with a couple of different large groups of constituencies. So on the left-hand side there will be the programmers, the people who first got started, the ones who downloaded stuff from a Rebo, build stuff themselves, tried things out, saw the benefits. Not necessarily deployed many things to production, but ultimately understood the value. They saw what was good. And they enjoyed getting involved and they formed the early part of the community. But on the other hand, when something grows and there are people who actually want to use this and actually deploy it, large, large, large companies tend to get involved because they have problems that they want to solve. The developers that work at those companies are saying there are solutions that could help with this. And so you end up with constituencies that span all the way from individual developers who are contributing code because they enjoy it and it's fun and they like the community. And on the other hand, businesses that just want to solve their problem. They have issues with deployment, managing software workloads, dealing with their traditional applications and they see this as a potential way of fixing some of their issues. At this size, when you get to a size like this, when you have that many deployments, that many pulls on registry, both of these are part of your community. All the way from the individual developer that's contributing code and just trying out your project for the first time, all the way through to the large enterprises that are trying to figure out how to take your stuff and deploy it internally and make it useful and then manage everything that's going on. And this isn't necessarily a new problem either. Think of the spread of Linux. So Linux is pretty much everywhere. And so that's used by people who are hobbyists and people who are contributing right the way through to large enterprises because they'll deploy this on their data centers and internal clouds. But those constituencies have very different needs. So the needs of the community things around customizability, freedom. That's one of the reasons that people get involved in the project in the first place. They like the ability to see everything that's going on, take the pieces that they want, ignore the pieces that they don't want. But there's also the desire for transparency to see everything that's going on across the project to understand what's happening. And one of the things that the project has to deal with is provide that kind of transparency and manage a stakeholders from all the different groups, all the different individuals that are involved, especially trying to figure out who are the good contributors who you should make maintainers, what kind of rights do the maintainers have, how does that cycle work, all those become important things. And then that also leads on to how an open source project is actually governed in terms of how people are represented on there. And that works all the way through from small projects to also when the project gets much, much bigger and needs to be much more formalized. And there are also foundations that deal with these things. And of course, everyone wants there to be some level of support, whether that be maintains or responding to issues on the issue tracker, or people looking at your pull request and contributing code or people telling you how to actually get involved with the project, writing documentation, all of those things. The community project wants all of those things. And many other things besides, but I'm highlighting these for now. People who are interested in the commercial project, which is typically the larger enterprises, they have a different set of needs. So typically this is someone in an organization who may not be writing code themselves, but understands the technology behind it. They're looking for something that's much more fully featured. They want something where the opinions are already baked into the software, so they don't necessarily want to be faced with a multitude of different options and have to think about the trade-offs themselves. They want to get the benefit of all the work that's been done, but they want someone else to decide what the defaults should be, and there should be same defaults that they can then twiddle. They want things, they want there to be an efficient development process as well. So this is a need of the company that's behind the open-source project and the people who are essentially buying that product because the product needs to be able to respond to the market needs. So if enough customers say we need feature X, and feature X is really important to us, the company behind the project needs to be able to figure out a way how to get that into the product to satisfy that need. And then there's also the issue of product and brand control because those companies are interested in essentially making sure they're getting the thing that they pay for from the people that they've been talking to. And so that means that the people building a product need to have enough autonomy, enough control over that, to be able to make sure there's consistent messaging, that people understand what the story is about a particular product, and that that's consistent over time. And of course, larger enterprises, the commercial product also needs to be supported. But in this case, that support may take a different form. There may not necessarily be an issue tracker involved. There may be, depending on the size of an organization that's interested in that open-source project, there may need to be a technical account manager who actually gets hands on and understands what the problems are and then can feed that information back into the development efforts. So going back to the previous slide, just a reminder that the projects like this have interest because they solve a particular problem. And that's why people all the way from an individual developer right the way through to a commercial enterprise are actually interested in it because it solves some kind of problem. But once you get into the weeds and you're involved in a project yourself, it can start to feel like you're competing against each other. It can feel a little bit more like this. So there are people throwing in what their views and opinions into how things should be built and then people on the other side. And it can start to feel like you're facing off against each other. This is largely unhelpful because you're still trying to fix the overall problem out there. So you need to bring skills from both those groups to actually be able to take all the ideas and opinions form and actually build something that is going to be useful. But without stepping on each other's toes, without getting in the way of each other's contributions so that everyone can get what they need. So this was an issue, this was something that Docker, the company needed to think about in terms of how things were going with Docker the project. So there was just Docker the project and Docker the company. And so what a decision was essentially made that we should separate these two constituencies out so they both have the flexibility they need to solve essentially the problems. So this became, on the left-hand side was something called the MOBI project which is the upstream set of open source work and then the downstream platform and product which was called Docker. So upstream makes the container systems so it's where all the open source work lives, it's where all the open source contributions and discussions happen and then downstream is where all the opinions get baked in and then a product gets shipped out to users, typically enterprise users. And there's also downstream products that are shipped that are free to end users as well. So this frees up the upstream to concentrate on the things that it cares about which is having transparency over things that are going on, having the agency getting involved, understanding the governance, but it also allows the downstream to just move quickly and change things as they need to to solve whatever needs that they're facing. And so this was the decision that was made to make that split, make that separation between the two sides of these kinds of projects and this was, actually this was the day before that was announced. So this was the meeting room where the rehearsals were happening for announcing the MOBI project. So to draw an analogy what the MOBI project was like is we can draw an analogy with Linux. So it's a set of open source components. It's not a perfect analogy, a set of open source stuff which essentially feeds into the MOBI project and then that is upstream of Docker. So a rough way of thinking about it is something like Fedora and Red Hat. So Fedora is where all the open source and innovative stuff can happen and then Red Hat Enterprise Linux is the thing that Red Hat will sell to enterprises. So a slightly more detailed view of this is there's a whole bunch of open source components. So I mentioned that we have over 350 repos. And so way on the left there you can see a number of those components. Those all form part of the MOBI project which is an umbrella. And then there's tooling and there's information and documentation about how to compose those things into producing essentially your own container platform, your own container system. And from this upstream Docker produces its downstream products. So Docker CE, which is the Community Edition and Docker Enterprise Edition are the downstream products built from the upstream open source components. So what happened when we did this? So at this point we decided we were gonna do this, this is how it's gonna look and then the company thought about it, all the open source maintainers were consulted and then we went ahead with it. So this was just a change to the read me. So there were 122 comments made on this. This was just the PR to change the read me to describe what was happening. And this is just one place where the discussion was taking place. There was discussion everywhere on Twitter, on various other GitHub issues, in people's emails, on forums because a lot of people were touched by this change. Yes, you know what I'm talking about. Some people didn't quite understand what was going on. And luckily we did spend a lot of time briefing people, talking to maintainers, talking to influential people in the community to help them understand what was going on. So the majority of people did get what we were trying to do. And one of the benefits of having a company behind an open source project is we can take that time to go out with the cloud, to go and brief people from the press, people from industry, people who are writing about these things in journal articles. So Docker also runs a captains program. So there's lots of people involved in the captains program who we were able to brief and make sure that they understood. So when they go out and give talks and explain things to people, that they also understand what we were trying to do. So the fundamental question here is, did this actually work? So if we go back to this, the idea was essentially anyone could be able to take those open source components and be able to build their own container system. And it did work. So another project came along, looked at the open source work and was able to put together their own platform for their own needs, for their own customers, based on Moby. So this was Bellina, which is from Resin, and it's essentially taking those components and applying it to their Internet of Things platform. So in a way, we can say that some of this was successful. But of course, a project this scale, these things take time to percolate through. There's lots more changes that still need to be made. But in principle, what we were aiming to achieve, we did actually get to. And there's also a forum now where people can collaborate and communicate about things that are going on, and this is active and growing. And all of the original open source components still have all of their activity and are still growing. And something I didn't mention earlier is that those open source components, we also donate to other foundations. So there's not just one company involved anymore, there's multiple different organizations involved in trying to foster that open source community and ensure that it stays healthy. So overall, the kind of things that we learned from this is that you do need to overcommunicate and you can't do enough of this. Things will happen on GitHub issues. You need to have blog posts, people will give presentations, update readme's everywhere. It would also be a good idea to have things like FAQs for the commonly asked questions and build that up over time. And also try and provide a canonical place to point people at, which actually has all the relevant information about what you're doing and also why you're doing it. Because the why is helping people understand why you're doing it is just as important as the thing you're actually trying to get across. And so allow time for those discussions to take place, that time for that Q&A, especially with all of the major stakeholders in the projects. And if you have a number of different repositories and a number of different projects, especially with the maintainers of all of those projects, because they all need to be on board with any wide reaching changes. And no matter what you do, it's not going to be enough. You will either miss something or there will be a place that someone first lands where you didn't actually put the information and then they don't necessarily find their way easily to the canonical information. It won't be enough. And change is always difficult. And especially changes that are really, really large that take quite a while to work through are going to be more complicated than most. Do try, but understand that you won't necessarily get everything. But this is a process where you can learn. So you can always be learning when you're going through this process of communicating with all your users, especially when you've got a community that ranges right the way from individual users through to companies. Because once you've learned what that process looks like, you can then start encoding it so that then the next time you need to have a large scale change, you understand what that procedure should look like. So a summary of this is the open source and commercial needs both matter. If you want there to be widespread usage of the software, if you want lots of users contributing, lots of people involved in the actual repository, as well as lots of people using the software. So both the pure open source work and the commercial products that come out of that matter. And those different constituencies will have different needs. And sometimes trying to satisfy all those needs will involve some kind of structural changes of the way you actually work on the project. So allowing people the space to get what they need without having to step on each other's toes, without then necessarily having to be that kind of conflict. And finally, communication is difficult, but it is really, really important. And you need to allow for that kind of communication in lots and lots of different places. And if you're interested in finding out more about the Moby Project, you can go to MobyProject.org. Does anyone here have Moby Project t-shirts? Okay, I can get you Moby Project t-shirts if you'd like, come and talk to me if you do. And I've gone through this fairly quickly. So thanks for your time. I'm also interested in what kind of questions or points you guys might have. Some components. Yes. So the question, to repeat the question, just in case for anyone who's watching the stream is, did we use the Moby name anywhere else internally? It was up, did I paraphrase that right? Yeah. Do you mean internally or outside? Okay, so the question was, did we use the Moby name internally anywhere else before? Yes, we did. So has anyone used Docker for Mac? Okay, so Docker for Mac had a minimal OS in there. And we named that OS, Moby. And that was not meant to be released to the world at all. That was just internally, just for us, and we just happened to call it Moby. And then when we were casting around for a name for this project, for the open source project, the name Moby bubbled to the surface. Now, Moby is actually the name of the mascot for the company. Moby Dock is the name of the mascot. So that's why it was just the internal, OS was just happened to be called Moby. So there was some, a little bit of internal confusion, but I wouldn't say it was particularly that great because that internal project was not really exposed to the outside world. So the confusion that the outside world may have seen was not because it already had a previous name internally, if that makes sense. Yeah, I think I saw it. You probably had a look in the, when you were running Docker for Mac, you probably had a look in at what was going on. It had a shell which said maybe something. Yes, yeah, that's why you would have seen it. Question here? Five of the top is balancing community and corporate needs, which is quite the most challenging in your experience to balance here. Okay, so to repeat the question, the title of the talk is balancing community and corporate needs, and what is the most difficult thing to balance? What has been the most challenging? What's been the most challenging thing to balance? Top of my mind is the vast difference. Firstly, corporates want opinionated software. Open source contributors want flexibility and freedom. Those two things don't necessarily go together. That's one of the difficult things because essentially the companies want something that's fully baked. They want a platform, they want something that is essentially called turnkey. It works first time, it integrates with all the rest of their systems, it deals with all the horrible glue code, things work. Open source software is not necessarily built that way and you don't necessarily want to bake in all the opinions of the open source software because that's not what the open source community necessarily wants. That's one of the hardest things to deal with. So personally, what do I think? So not speaking for Docker, personally what do I think is one of the ways that we could show that we've met that challenge is that given the way this separation happens is that someone uses Moby project stuff to build their own container platform and customers of the Docker product are happy with the product. That would be my personal criteria for did this work, which is what I essentially tried to get to it because if someone uses the stuff that's from Moby, then that means that there was some value there that they could use. They didn't have to use all of the Docker stuff, they could take the Moby stuff and build what they needed from that at the back. Can you say that again, please? Have we seen growth to the Moby project since it's been split out? I don't have those stats to hand and I wanted to run those stats before but I didn't get round to it. So if I get you details, then I'll try and do that and then get an answer to you later. Any other questions? Can you alternate the feedback on all the groups of us with the dev group organizing some feedback? Ignorant and don't know how we leave feedback. How do we leave feedback? I did not know that. I'm not joking. I really didn't know that. Thank you more. Okay, everybody, that was maybe to take a moment to stretch and move your body. If everybody's in a very small load of flow and if you'd like, we can once again do the Macarena because it's not going that far. Oh, I do have my work by hand. I'm going to show it to you. Well, do you have your hands on the back side? I don't know. That's the thing. What? I don't know what kind of work I was telling you to do, but I'm sure it's important. Okay. Be careful with this. Yeah? Yeah. Crawl backwards down the wall. Yeah. Yeah, slowly. Slowly stretch down the wall. Okay. I want to try doing that for the body. Okay. Do we have water in this thing? I'm sorry. Do we have water? Water, yes.