 Who's just here because they saw my name on the schedule? All right. So for those who are not core developers, I will give you fair warning in the tradition of open source, you're going to get to see the sausages made. So I don't look to scare you too much, particularly the clients of mine who are in the room. All right. Anyone not know who I am? Okay. Larry Garfield, Krell, and so forth, enough about me. First disclaimer, I've got a lot of external references in this talk. I'm going to explain them and what their relevance is, but I've also put links to all of them on the project page, on the conference website, on the session page on the conference website, and the slides will be posted afterwards, so all the links will be in there too. So you don't need to rush to find links I'm describing. That list is there now if you want it. So we're talking about managing complexity, specifically managing complexity in Drupal core. So let's start off with what do we mean by complexity? What does complexity mean? The definitions we're going to use come from a man named Rich Hickley, who's the author of the closure language, and a presentation he gave called Simple Made Easy. It's an hour-long presentation. I strongly recommend you all watch it and watch the sequel, which is from our own Sam Boyer at DrupalCon Austin, called Stomp Complexity. Hickley's version of this talks mostly about language design. Sam takes the same concepts and applies it to Drupal architecture. I'm going to be applying it to Drupal the project. So basic concept, simple. What does it mean to say that something is simple? Something is simple. The word itself comes from simplex, which is I think Latin, meaning one braid, one concept, one thing. It's not intertwined with something. It's just one braid. The opposite is complex. Easy, on the other hand, comes from the Latin ice, which means to lie near, and its opposite is hard. Important thing to note. These are not even remotely related to each other. If you try and use simple and easy as synonyms, that's not actually what we're talking about. Simple means few concepts. It means one concept. Easy means lying near. Lying near as in near at hand. I can easily reach for it. Sam's giggling at me over here. So these are very different things that we often colloquially confuse, and we need to un-confuse that. We need to separate these definitions. Another important difference between these two is that simple is objective. I can look at something, and you can look at something. You can both say there's one thing here. There's one thing going on. There's one concept. Or there are three concepts tied into each other here, which is different than something is easy, something is familiar. What's familiar to me and what's familiar to you may be completely different things. I find presenting easy. Lots of people find it incredibly hard. I find CSS ridiculously hard. John Albin breathes that stuff, and God bless him. But that's a very subjective measure. Easy and hard are very subjective, whereas simple and complex is an objective measure with a clear definition. Simple is effectively a synonym of decoupled. Simple means there's one thing and it is not tied up with something else. That's the same concept as decoupled. Easy is familiar. Is it familiar to me? Is it familiar to a given person? Is it recognizable? But is it recognizable to whom? Simple implies learnable. Simple things can be learned because the concepts you can take one at a time. Easy simply means I can recognize it. It's familiar. I've seen this before. It does not mean that the thing I'm talking about is simple. If you already know how to play the violin, learning to play the cello is easy. It's the same basic mechanics, just a bigger size. If you're coming from writing code to playing the cello, I've done both. It's very hard to jump from writing code to playing the cello. A couple more definitions. Complex. This is a fun word. It means to make complex as in braid together. To take two things that are separate and wire them into each other. And connect them and tie them in against each other. To decomplect, I don't know if this is actually a word, but Hickey uses it, so I'm going to, is to unbraid it. It's the opposite. Pull things apart. Take the various concerns, various concepts, and pull them apart. De-couple them. That's de-complex. To compose is simply to put them together. Hence, composer the PHP system. Not to mix them together, but to place them together. You put a variety of songs on a CD together. You're not overlapping them. You're not mixing them. You're just putting them together in a collection. They're not affecting each other. That's composing. And this concept of simple meaning one thing, or one thing at a time, is not new. Simplicity is a prerequisite for reliability from Edgar Dykstra, who is one of the founders of computer science as a discipline, who died a long time ago, which means this quote is, I don't actually have a date for it, but it's a very old one. Even older, simplicity is the ultimate sophistication from Leonardo da Vinci. Something that's sophisticated if it is simple. Not if it does a lot. Not if it has a lot going on. But if all of the pieces of it are nice and organized and separate from each other, if they are simple, if they are simplex. Programming, what we do, when stripped of the irrelevant mumbo jumbo, boils down to avoiding complexity, to making things simple, to a vigorous separation of concerns. That is programming. That is breaking things down to individual pieces that you can solve separately and avoiding complexity, avoiding complexity. That is programming. That is software design. One problem. We as humans are very good at making complexity and very bad at understanding it. We cannot understand things that are complex, but it's really easy for us to make it. And when you build something on something else, you inherit its complexity. You can't undo something's complexity by putting stuff on top of it. Complexity is only additive. You can abstract away, you know, paper over complexity. You can make that complexity look easy. But making complexity look easy does not mean the complexity is not there. It just means you've papered over the complexity. It's a different thing. When you break it down to it, the only way to manage complexity is eliminated. So for those asking, you know, who came here looking for a way to deal with their complexity, my answer is, get rid of it because you can't. You can only eliminate it. So how about scale? What is scale in computer science? Norse numbers. That's a fairly new concept that's starting to come around informally. And this link is to an article by Lawrence Kesseltut. Who is referencing John Cook, who was talking about a conversation he had with someone named Cliff Norse. These are all big computer science named people. And the basic idea is this. Under around 2,000 lines of code, any idiot can write it. You don't need to bother with architecture. You can solve the problem by just throwing code at it until it works. And it's small enough that you can fit the whole thing in your brain at once. If you're a typical sized human brain. And you can get it done. Unit testing is probably not worth the effort. And, you know, separating things out, you can, you can, but you can get by without doing so. Once you get above 2,000 lines of code, you start needing classes, packages. You need to have some kind of separation of concerns. You need structure imposed on your thinking so that you can keep up with it. You need that divide and conquer concept to be able to deal with it, to be able to reason about it. Above 2,000 lines, you know, around there or so, you start needing to look at a much more vigorous approach. You need to take a much draconian approach to simplicity. Your approach to the problem changes when the scale changes. Down here, throw any bunch of functions at it and you're done. In here, you start needing to organize your code to be able to keep up with it. You know, coming up here, you need to be vigorous and strict on how you're separating things. You need to discrete packages. You have to have unit testing. You have to do things like dependency injection. Otherwise, your code becomes unmanageable and impossible to reason about. And, you know, this article said, I'm really looking forward to seeing what the next order of magnitude difference is. You know, I'm going to speculate that's when, you know, if you're not using functional principles of purity that it's all going to fall apart, but I haven't written anything that's 2 million lines long, so I couldn't say. But the important thing here is that the approach you take at different scales to a problem is different. And this is true in programming, it's true in a lot of other subjects. And, you know, that complexity per size, it does actually vary a little bit. Simple code. Simple as we defined it a moment ago, of one concept, one thread, has linear complexity. So, the more code you add, the more, you know, the more difficult it becomes about a linear rate. Heavily-complexed code has geometric complexity. That means you had, in the first case, you had one line of code, you go from 1,000 to 1,001 lines of code, you've added with that 0.01, to your difficulty of dealing with it. If you have 1,000 lines of highly-complexed code, and you add one more line, that line could affect 12 different subsystems, and so you're adding 1 or 2% to your difficulty of maintenance. For the same line of code, because the code is more complexed. This is not limited to computer science. Think of democracy. Around a dozen people, maybe two dozen, consensus works. You get a bunch of people around a table and talk about it and you come to a conclusion. That can work fine. It scales to that level. You get above, you know, that scale, and consensus just becomes far too problematic. It's far too unstructured, and you can scale it to direct democracy, where you actually have a vote to decide things, rather than consensus. But everyone gets a vote. And that can scale to a few hundred people, maybe a thousand. Do you remember the original democracies, you know, Athens and so on? Every citizen had a vote. Citizens were maybe 5% of the actual population, which made that work. But the actual voting population was a few hundred. Maybe a thousand. It was basically military officers, as all they had. Above that, and you start seeing republics. You start seeing elected officials who take over the governance responsibility and get replaced periodically and so on. You can see this all around the world. Even if you're dealing with a dictatorship, you have a small chieftain. He controls everything. He's the boss, whatever. Get up to a kingdom-sized system. Then most large-scale kingdoms, or dictatorships, have some kind of nobility. The structure may differ, but they've got some kind of internal organization to delegate authority. You get up to worldwide empires. You've got some kind of local governor, maybe locally appointed, maybe appointed by the emperor, but you have some kind of internal structure that dictatorial emperor is not responsible for everything that's going on. They delegate authority. Different scale, different governmental styles, just like in code. The approach you take at one scale, in anything, is different than the approach you take at a different scale, because the approaches don't scale up or down. Having an elected republic for 12 people is just way too over-engineered. For 12 million people is a necessity. It works if no one does anything stupid as a terrible way of running anything. Thank you, Sam. So let's talk about structure. And let's go to Jo Freeman, a speech she was a prominent feminist, writer and activist. This is a speech she gave at the Southern Female Rights Union in May of 1970, called The Tyranny of Structuralistness, talking about radical feminist movements in the United States at that time, and in the past 10 or 15 years at that point, many of which prided themselves on being unstructured organizations, on not having leaders, on not having hierarchies. And the point that she was making, which my experience is completely true, is that you can't actually decide to have a structuralist group, only whether or not to have a formally structured group. Human interaction creates structure. The fact that you have more than two people working together or doing something together, interacting together, means structure will happen. Informal structure will emerge on its own. You will not have an unstructured group. That structure is inevitable. Now, that doesn't mean that informal structure is inherently bad. If the group is a local user group and your goal is to get together and share knowledge, then, cool, informal structure is going to work great. If it's an awareness-raising group and your goal is to get together and share experiences, either as women or as alcoholics or as whatever, if your goal is just pure communication, then an unstructured group works fine. But it doesn't necessarily scale. Formal structure is documented. You can look up what the structure is. You can ask someone and there's a definitive answer. It has clear change points. Who is responsible for X? It's written down, and there's a clear mechanism to know when the person responsible for X has changed. It could be as simple, as we defined it before, structure or complex. Formal structure does not inherently mean fill things out and triplicate with five different offices. That's a complex structure, but formal structure doesn't have to be that. Formal structure could be as simple as that's the person who's responsible for, you know, cleaning up the chairs at the end of the day. That's their job and they've got a name tag and everything. It can be very simple. And it leads to process. It leads to writing down rules. It leads to guidance and structure that you can reference, that you can look at, and put different people into. Informal structure, on the other hand, is very implicit. You learn it by becoming part of it, sort of. But everyone may have their own take on it and may have a different opinion about what it actually is. And when it changes, you don't necessarily know, or different people find out different times in different ways. And again, it could be a very simple informal structure or a very complicated and complex formal structure. But what this leads to is elitism, at least it clicks. And when I say elitism here, I'm saying elitism the same way that Joe Freeman did. It's not a conspiracy. It's not people, you know, not a cabal getting together and deciding to take over the government or anything like that. It's people who have some common attributes, some common interests, who are participating in your group, work together better so they form a click. They form a party. They form a faction. And when that happens, that group tends to take over because their communication channels are simpler. And that could be formed by, you know, people who have been friends and are friends outside of whatever this group is. It could be they went to the same school, so they know the same teachers, they were in the same fraternity. It could be they all work for the same company. It could be they're all men, they're all women. It's a common element that is not relevant to the organization, to the group, but that becomes a structure around, an attribute around which informal structures will form and elites will form. Again, this is not necessarily a bad thing. People being friends is not a bad thing. It's bad if you are governed by this kind of elitism because elites are informal structure. Informal structure is filling a vacuum in formal structure. If you do not have formal structure, informal structure will emerge to fill it. It will happen based on whatever. And informal structures may create informal qualifications. To be part of the leadership, you must be of the right age range. You must dress properly. You must dress improperly in the proper way. You must come from the right socioeconomic background. You must be of the right gender. You must be of the right race. You must know what the Drupal Way is. These are all things that are inherently irrelevant to the group, but around which these informal structures will form if there's a vacuum to fill. Informal structure complex structure of an organization with things that should be irrelevant. You can have successful informal structures. And this is again from Joe Freeman's article. To have a successful informal structure, informally structured group, the group must be task oriented. There's a thing that they need to accomplish that is very clear and obvious. That task is just readily apparent to everyone. The group needs to be small and relatively homogenous, which means that communication channels become really, really easy. It's really easy for the people to coordinate. There's very few communication channels, so information and knowledge can disseminate very, very fast. And low specialization. Good example here, organizing a Drupal camp. Not a Drupal Khan, a Drupal camp. You need five to ten people to organize it, and the person responsible for calling the venue to make sure that they have enough chairs, that's an unskilled job. That doesn't require special training to do. Anyone can do that. So anyone can do that. And so you have an informal structure that says, you know, Bob is responsible for calling the venue and making sure there's enough chairs, you know, Jane is responsible for sorting out speakers. And, all right, that works, whatever, we'll roll with it. And that can work out very well. Most Drupal camps work on that kind of informal structure, and that's okay. The problem, though, is when you get to questions like, who's actually in charge? If there is, in fact, a dispute that needs to get resolved, who's in charge? Who actually gets to make a decision if there is a problem? Who is responsible for something? Is Bob actually responsible for chairs? Who's doing chairs? Do we have that written down somewhere? Who's actually calling the speakers? Do we know? Who can veto? Who actually has the job of deciding, yes, the speaker is coming, yes, the speaker is not? Yes, we want this keynote. No, we're not going to go to this venue because, you know, that venue hates us or whatever. Who has the authority to say yes or no in cases where you need to say yes or no? What back channels are there? There's always back channels. There is always back channels when you have more than two people communicating. What are they? Are they public? Should they be public? Do we know that they're there and they're not public but we're okay with that? It's okay to have back channels that are not public as long as you know that they exist. But if you don't even know they exist, then you are inherently on the outside of that elite group. How do you get into the elite group by whatever definition that is? The people in charge informally, how does one become one of the people who are in charge informally? When does one stop being one of the people who are in charge informally? Retire versus fired. People are starting to catch on here. You know, how do you step down from a position of leadership you never stepped up into? How are you fired from a position you were never hired for? How do you know when the person in charge of a new person is running things now for some definition of things, how does everyone else know who is not the five people at lunch who decided that this person is in charge now? How does anyone else know that? These are the problems with informal organizations and informal structure. I love this quote. For movement continues to deliberately not select who exercises power, it does not mean that you eliminate power. All it does is abdicate the right to demand that those who exercise power be responsible with it. I'll say that again. All it does is abdicate the right to demand that those who exercise power are responsible with it. And if you keep power as diffuse as possible because you can't demand responsibility because you don't want to demand responsibility, it ensures that the movement is as ineffective as possible. Diffuse power is a very, very inefficient way of organizing power. Maybe you want that. The U.S. government was set up to be very diffuse and slow as a defense mechanism to try and keep it from going off the rails. It happened anyway, but that's another story. But you can deliberately design inefficiency into a system by diffusing power. But that's only if that's what you want. This applies to any group. There is no such thing as structuralistness. Informal structure will happen. And if left to its own accord it collects and inefficient. It's simply the nature of human beings. It's another prominent feminist, Ash Dryden. A lot of people here probably met her at some point. This is an article she posted last year called The Ethics of Unpaid Labor in Open Source Development talking about the problem with this idea of meritocracy. Meritocracy, as she defined it and pulled from Wikipedia for it, is the belief that those with merit for some definition of merit float to the top and are given more opportunities. Paid higher, more access, whatever the opportunities are. Problem with that, merit doesn't exist on its own. It would be lovely in a wonderful world if those most able to handle a problem are the ones who get to handle it and get benefits commensurate with that. I would love to live in that world. Unfortunately, merit doesn't exist on its own. You may have qualifications for something to volunteer for something, but if you have kids or a family that you're taking care of, you have a sick relative at home you're caring for, you have a child who has higher medical needs than someone else's child, that inhibits your ability to do something for reasons that have nothing to do with your skill at the thing in question. Maybe you're driving. I have to spend more time at home taking care of a sick kid who has cancer. I don't have much time to drive so I can't be rewarded more for driving so I don't get the rewards despite the fact I'm the best driver around. You could have your own medical conditions that limit your ability to do whatever. You may have a long commute. You don't have as much volunteer time. My commute to work in the morning is a half hour or so each way. That's an hour out of my day that I can't volunteer for anything. Someone else works from home. I don't have to volunteer on something that I don't. Someone else has a two hour commute that means they've got four hours out of their day that they cannot donate to anything. You could have an employment contract that says you're not allowed to contribute to open source. You may have an employment contract that says we own copyright on anything you do even outside of work hours. Lots of people do, especially in the U.S. It's disgusting but they do. The problem here unequal opportunity the problem with meritocracy is that it complex merits and opportunity. These could be unequal. Asher's article talks mainly about racial and gender differences in opportunity but it applies to those. It applies to anything else as well. Any time there's an unequal opportunity it means meritocracy doesn't work right and we all have unequal opportunity on everything for a variety of reasons. Now in Drupal we don't call things meritocracy we use a different word, duocracy which roughly translates as one hour, one vote. You want something? You do it. You don't have time to do it? Sorry. What does this actually mean? What does duocracy actually imply? Ruled by those with nothing better to do at their time. I'm not actually the first one to say this there are people saying this after the Drupal 7 cycle too. This is what duocracy means in practice. It means ruled by those who have lots of spare time to do. People who don't have as much spare time for whatever reason are inherently at a disadvantage regardless of their actual ability to do whatever it is they're doing. So how does this apply to Drupal? Someone's giggling. Okay. Let me ask you this simple question. Who is Drupal's technical lead? Who is Drupal's lead architect? My life would be so much simpler. We'll get to that later. I'm an initiative lead. What does an initiative lead do? What does being an initiative lead actually mean? I've got another initiative lead. People can blame you. It means people can blame you. For decisions you did not make. This is what is actually listed on our website for what initiative lead means. It means we coordinate and communicate. Initiative leads are glorified secretaries. The only job description I have as web services initiative lead is glorified secretary. Note what's missing from here. Any sense of authority or power. As initiative lead, I do not have any actual formal power at all. That's true of every initiative lead. How about component maintainers? We've got 20 or so listed in maintainers.text. 70. We've got a lot of them. Listed in maintainers.txt. What do they do? According to the website, they do issue queue farming, mentoring. They review patches, answer questions, and write issues for other people to do. They're glorified secretaries. Note, nothing here about authority or deciding future of a module or a subsystem. This is what's actually on the website. This is the closest we have to a formal structure is this. Who here is a mentioned maintainers.txt somewhere? In writing, the only formal structure we have is you are secretary. How about branch maintainers? Do we have branch maintainers in here? I thought we had one. This is what it says on the website. Oversee the developments of a major version by making ultimate decisions in software and working with the community to set goals, priorities, and guidelines. We actually have someone here who has the word decision. We've got four people who have the word decision on their job description. For Drupal 8. Yeah. So branch maintainers for Drupal 8 is catch. I don't know if Alex is technically a branch maintainer or just a committer. What's that? Okay. Okay. So catch actually has ultimate decision making power on a patch by patch basis except when Dries is the one who has that authority. And as someone who's in the issue on a regular basis I only know one guideline by which to say Dries gets responsibility for something and that's when we're adding a new third party library. Other than that, I don't actually know what the policy is on when you assign something to another. I don't know that anyone does except them in formal structure. How big is Cornell? And we've got four people who are responsible for knowing enough of it to set direction for the entire thing as one big gigantic project down to the level of individual lines of code. So who is Drupal's technical lead? Remember we're a duocracy. This question was asked on Twitter and this was the answer. Harsh but true. It's either Daniel or Tim depending on the week. So that's our tech lead. Who used to be the tech lead? We don't know when a tech lead changes not even the person who is an informal de facto tech lead. What does it feel like to get edged out of that kind of position of authority informally without ever being told? I haven't experienced it yet but I'm pretty sure it sucks for everybody. Ask this question. Who do I need to run this issue by? Who do I need to get sign off from for this patch or that patch or this recommendation or whatever? I couldn't actually tell you. The reviewer. So random other newbie who comes by the issue. Maybe? Depends on the issue. Some issues yes. Some issues you need to run it by someone else. Is this an issue that you need to run by Tim Plunkett? I don't know. Is this an issue you need to run by Daniel? Because I happen to know these things because I've been working with Daniel for the last year and a half but that's only because I've been working with Daniel for the last year and a half. You probably want to talk to Wim on that one or no, this one. You should probably go ask Cat Bailey because she hasn't been around for a year but she's still worked on that part so she knows what's going on. If you haven't had your hands deep inside the system for the past three years how do you know any of this? You don't. Selecting who exercises power does not abolish power. It's the right to demand that those who exercise power are responsible with it. We ignore component containers on a daily basis. Fact. Couple of examples. Just this week, I noticed actually how Daniel pointed out to me, a patch went into the database layer that's had a static call against the Unicode utility library. Which means we have now completed our database layer to our Unicode library with a static method call. As database maintainer I would never have approved that but no one asked. I'm the maintainer for the routing system. Six months ago another core contributor changed part of the API around route handling that I've written as part of a series of patches to go in a certain direction. And he changed it and I didn't find out about it until two days after it was committed. Six months later we haven't undone that damage yet because I spent the first five months of it trying to argue that point that this piece of this subsystem that I am the maintainer for and the primary author yes should be this way, stop arguing with me. And it's not just me. I'm not just complaining that I don't get my way. I've done this to other people too. And who here knows Khaled Bahilin? He was in one of the videos at the pre-note. He's the subsystem maintainer for the DB log module and the syslog module. Except we have gutted and rewritten both of those. Paris Diakos and I gutted and rewrote the entire logging system and used PSR3. I don't think Khaled even knows it yet. We didn't actually ask him. We just did it. And it got committed. I'm not sure if he even knows that it's happened yet. This is a regular daily occurrence. One hour, one vote. Being a branch maintainer or being a subsystem maintainer doesn't actually count. So why is Drupal 8 not done? Why was a certain part deleted? Well, Angie asked this question on Twitter a couple of days ago. Is it two weeks ago now? Three weeks? And I highly recommend reading the full thread. There's a link here and a link from the session page. But I want to call out a few of the responses. I have no desire to spend time attempting to disagree with someone who likes sleep less than me. Because the person who likes sleep less is going to win the battle. My mental health is worth more to me than Tor's release date. This is Greg Dunlap who was our first initiative lead and stepped down from the position after two years. Anyone remember J.C. and Louise? She was the initiative lead for the HTML5 initiative. She burned out badly within the first year because that was the most bike shuttable discussion we could possibly have is what markup do we use when moving to the HTML5. And she got slammed by everyone who had more time than skill arguing about every little detail. She never had the authority as initiative lead to say, no, we're doing X. We're going this way with it. Stop talking. And so it destroyed her. She quit the project. How many core developers have been a major significant mover and shaker for three or more years? Can anyone name them? I can name two. Chex and Stephen Wittens. In Drupal's what is it? 14-year history? Two. That should tell us something. Remember, we're a duocracy. Ruled by those with nothing better to do with their time. That's a constantly shifting population that we're making by attrition. Easy also means easily replaceable. If something is easily recognizable to a large population, it's really easy to find a replacement. If you burn out a volunteer, there's another volunteer just waiting who would love to help out and take the place of the person you just burned out. We have a huge burnout problem in core development. This is not a new statement. It's been said for easily six years. But we keep turning along because there's always another volunteer to take their place. Is that actually how we should be running core? Our result? No one actually has authority in Drupal. Everything, this structure begs for bike jets. We have bike jet discussions in issue Q daily because our structure demands it. Which means that the steamroller developers and I say this as someone who is one they win by doing things the easy way. And in this case I mean this gets a patch in that everyone can understand the feature at the end of it. The code inside it may be horribly complexed but it looks easy. It looks obvious. I understand this one patch and so good enough. Except easy is not simple. Easy papers over complexity but it is not simple. So we get lots and lots of code that is not simple. It may be easy but that's just building up complexity. It's building up complex thing. Informality at the scale that Drupal is is a horribly complex. We have nearly twice as many contributors to Drupal 8 as the Linux kernel had to version 3.10. We are huge. Informality does not scale to this level. So who has authority? It's not the initiative it's not maintainers it's not component maintainers. There isn't any. Drupal the code base remember we said before you can't inherit the complexity of everything below you. You cannot avoid inheriting the complexity of everything below you. Drupal the code base inherits all of the complexity of the Drupal community. All of the inherent complexity in the Drupal community and development process impacts our code. Drupal core is complex because Drupal the community is complex. And this is not something new that I'm saying this is Conway's law from 1968 which Harvard researchers have verified before. Organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations. Who's had the problem where you've had to explain to a client no your organizational chart is not the right way to design the IAA on your website. We've all had that experience. This is the exact same problem at work. The only way to manage complexity is to eliminate it. And I mean eliminate it in the code and in the community at the same time. We complex too much. The way to do that is clear decoupled structure. We need clear decoupled structure in the code and in the community. We are too complexed with each other and so our code is too complexed with itself. Now let's be fair. Drupal 8 has improved the situation. A ton of work has gone into improving that tight coupling. Drupal 8 is more decoupled than any version of Drupal before it by a wide margin. And yet we still are throwing static calls to random other classes in the middle of codes somewhere without talking to anyone because it's easy to do. Two steps forward, one step back. We still have a long way to go. How do we do that? This is not a framework versus application discussion. I'm not talking about splitting framework between each other or anything like that. Joomla actually tried that at one point. They split the Joomla project into Joomla framework and Joomla the CMS and they don't actually talk to each other anymore. So let's not do that. Learn from that. Let's learn instead from some of the other large open source projects. These projects, these nine projects are as of 2010 10 times larger in terms of the number of participants than any other open source project. We're in a pretty high level here. Drupal is among the elite of open source projects. To be fair, this is a really nice group of friends to keep. So let's look at some of them. I actually tried to reach out to some of these projects and their initiative leads or their representatives and they were all too busy to talk. But there are some commonalities that we do know about these projects. One is that they're all community projects. There are lots of successful open source projects that are backed by one company. MySQL, MongoDB, various others. But these big projects are not. They all have some kind of non-profit foundation at their core. This includes us, in our case it would be the Drupal Association. And they are all architecturally highly modular or their collections of software that come from different places. The emphasis is on this modularity. That is how you are able to scale is divide and conquer. It's break things up into distinct components. So I said I tried to reach out to some of these and didn't get much response. So we'll go with what we do know which is public knowledge. From Linux. Again, a project half our size. Linus Torvalds does not merge patches. He just doesn't do it. He doesn't deal with individual commits. There are component maintainers for different parts of the kernel or different drivers. They merge stuff. If you have a patch or a bug fix to the SCSI subsystem you don't talk to Linus. You talk to the maintainer of that subsystem. He doesn't enter the picture until a month later that subsystem maintainer sends a large change set all up to Linus. Once he merges that whole branch with contributions from 20 different people doing all kinds of different things. But he'll trust that subsystem maintainer knows what he's doing. And this works because most components in Linux are in fact fairly well decomplected. Two thirds of it is drivers. They are fairly standalone. As long as the API to the kernel itself doesn't change do what you want. You're not going to break anyone else. You may break the driver for this one little piece of hardware but you're not going to break the system. The core system, Linus will watch it more but there's still a lot of work to try and keep things separate from each other. Drupal needs to be a composition of different components. Right now we are a complexion of components. Our different subsystems are still too tightly coupled because we are too tightly coupled. Both our code and community need to be a composition not a complexion. Contribs sort of has this because you can mix and match those and those are independent of each other unless you have an explicit dependency you're not going to break someone else. But core getting bigger and bigger and bigger is less and less like this. Core needs that kind of benefit that Contrib actually has. My recommendation for this is that containers need to have actual authority over their subsystems. They need to be able to say no. They need to be able to say yes and have it stick. Give them responsibility and authority. And someone's going to ask, well how do we make changes that cross everything? Are we going to have to get signed off from 20 different subsystems maintainers? The fact that you're making a change that seems simple but needs to sign off is the bug. Make conflicting painful. That forces us to decouple. That forces the complexion. That forces us to break things apart because we have to. Right now everything is in one big pool because that's how we're structured. If we instead have a series of connected pools we'll have a series of connected components. This is forcing the issue. The fact that we need to talk to a dozen different systems to make a change is the problem. Yes, there is some pain in this. There's going to be pain in the new release cycle too. Where we look at it and go, hey, I want to make this change for 8.1 or 8.2 but I can't because that's an API change. But I can make this change over here because that was more loosely coupled. That development process in Drupal 8 is going to mean pain for the core developers as they realize, oh, this decoupling and simple thing actually matters. I'm going to experience it myself and actually get a respect for it. It's going to be an educational process for us. Exact same thing here. We need to force ourselves to see the problem and force ourselves to solve the problem. Another recent post from Sam called Keeping It Simple where he talks about many of these same concepts. He has some recommendations as well. I'll open for discussion. He sees a simplifier role. It's like the words he used. This is a person who is a keeper of simplicity and quality in a focused area. Possibly same as subsystem maintainer, possibly not. But they are not interested in release states or global strategy. They're interested in the forum module. They're interested in this module being good. This module being simple. This module not being 12 other things unless there's a very good reason for it to be. They're not interested in functionality. They're not interested in things that will sell to VPs. They're interested in code quality. They're interested in being responsible for the upkeep of this system. Responsible and authority. Responsibility and authority must always come together as a pair. They can partner with the easy people. By easy people I mean people who are interested in making things easy. If we've got we were talking, I think it was earlier today or yesterday, about they need to get designers more involved in the process. If every module, every subsystem had a person who was responsible for the code, authority and responsibility and they're not just, they don't deal with UI. They deal with code being good and they partner with someone who can talk about UI and make it easy. So you have someone guarding easy and someone guarding simple and they work together. Then you've got a path to a clean, good, powerful system. We need to have a brutal and I mean brutal focus on simplicity. I say starting as soon as we get 8.0.0 at all levels. Code UI and community. We need to have a heavy focus on simplifying on not on making things easier to do but on making things easier to understand making things less tied together in weird and undocumented ways. And if that means along the way we lose some easy or lose some features, that's necessary. You can build easy on top of simple you cannot build simple on top of easy. We need to focus on simple so that we can build the next generation of easy. Thank you. I now don my flame retardant suit. There's a microphone in the middle of the room. I think this distributed power of different subsystems it works if there's competition and the possibility to drop one solution and use another one instead. So at the top there's someone who just puts different stuff together and composes it and and then one person may have the power over one subsystem but if the power of other ways means that you also have the power to do the wrong thing or something that others don't like and then the others have the option to opt out of this thing and use a different solution or a fork or something. And in Drupal we have everything in the same repository so if one subsystem entertainer sucks or doesn't care about the project it goes in a different direction Okay. Okay. But then we have an explicit statement of this person has been replaced with this person. Uh-oh. So for the recording this is Jess XJM. My name is Jess and I'm XJM on Drupal.org For context my full-time job is doing release management for Drupal 8. So first of all I need to call you out on something. I'm going to read to you the actual language from the component maintainers page on Drupal.org. It says thank you also known as issue farming when a new issue is submitted that involves verifying that it's a valid issue taking appropriate action, tag as novice, change the status if more information is needed if it's not really a bug, change issue parameters, etc. That sounds like secretary work, sure. Mentoring new contributors who are working on issues related to that subsystem being the point of contact for that subsystem's contributors reviewing proposed patches on that subsystem acting as an expert on the workings of that system answering questions that come up and being involved in discussions of major overhauls and re-architecting and translating strategic thinking about their subsystem into actual issues. So I think what you put on the slide was misleading first of all and I also think it's extremely I will say not strategic to call that a glorified secretary because there's extremely valuable skills in there. Am I a secretary Larry? Is Kathy Faye the secretary? I think most of those roles and the contribution and the technical expertise that is required to perform those roles I think is a bad idea. So that's all. I just wanted to point that out. My point is it's responsibility without authority. What's in writing is responsibility without authority. Glorified secretary is not what it is. But then I did have two actual comments on the content of your presentation that I wanted to ask about. So the one thing that you said and I've come up a lot of times before is well I will just say that having every subsystem maintainer be responsible for their subsystem be the final authority and control that part of it sounds on paper like that seems like a fabulous idea you know every time people bring it up when I went to Drupal Kondenver and I heard a Cork Conversation presentation that day it sounds fabulous until you actually have to work with all the component maintainers all of the time and you see the varying levels and another thing that plays into that is I believe Sam's blog post he said something in there about not having a concern about the overall release date of the project as part of the thing that and well people ask why Drupal 8 is not out yet that's a big part is that there are a lot of people who have technical roles in the project who don't care when Drupal 8 comes out and that's part of why it's taking so long if there is and I think I've heard a lot of people say that that's a serious risk that they have clients or their own shop are considering moving to a different solution because of how long Drupal 8 has taken to get to even a beta I mean it's okay for an individual person to say you know I don't care about the release cycle that's not relevant to me but I don't think that we can put them in charge of Drupal's code base I think it's a different role it's not that there should be no one who's concerned about release date and I don't think what Sam was describing necessarily maps to a subsystem maintainer in all cases but someone there needs to be someone whose primary focus is keeping the code base simple keeping the quality up separate from what features can we check can we check off those are different roles and we need we don't have anyone who is empowered to focus on keep things simple we just keep making things more complex I would say that it's an overgeneralization and you're assigning motivations to other contributors that are necessarily there I don't think you're assigning motivations to contributors at all at least the microphone microphone microphone but the thing is that it doesn't get crap done that's the thing if someone if you're concerned about the fact that as opposed to simple I can agree with that and I don't exclude myself from that in the slightest so then the one question I do have is if we want you described a situation where a commit was made to the database component that added an unnecessary coupling an undesirable coupling and no one asked you about it and so the question that flowed across my mind then was well your answer will be I should just be able to commit to the database component optimally but the question is not necessarily and you don't have the availability though to every single time that there's a how much longer will it take to get a patch and if every single time there's a patch that needs to be in the data system it has to go through you instead of the core maintainers who have this between the four of them this extreme concentration of time available which ties into the resourcing questions and funding questions that have been happening all week these subsystem maintainers if we're going to make them local authorities we need the resourcing to be local authorities we also need to then defer to them when appropriate and right now we don't do either one of those and that's a problem part of your point was the complexity of Drupal maps to the complexity of the community your proposals address how we handle really leadership in the community and I'm wondering what the impact of those kinds of changes would have on the overall community because the communities the whole point of this was the complexity of the community and the leadership is just one small piece of that and I see it as building a clear and documented skeleton around which the organic community can still work I'm not saying we should get rid of organic contributors and drive by contributors those are great we have twice the size of Linux that's awesome but there needs to be a skeleton that they can latch on to who is in charge of X I want to work on this kind of thing where is the page that tells me who I should talk to to see what the current roadmap for that section is I don't have an answer for that question if someone says if someone comes into the IRC channel and says I want to help with Drupal I'm interested in this kind of thing I know personally who to send them to most of the time but that's because I'm in IRC far more than it's healthy for someone who is not or doesn't know what to hop into IRC how do you find out maintainers.txt is not actually accurate in terms of that answer I was just going to point out that the other thing with being a maintainer and actually maintaining that codebase is that we're kind of disincentivized around it right now so as someone who is a maintainer it's my job to actually know and facilitate the commits or whatever of new patches to the plugin system it's great I don't check that list though because a lot of times it doesn't really matter what I say there so despite the fact that I actually do understand how that's going to have an effect on the component in question it's largely just me saying hey you shouldn't do this because and then getting to undo it at some later date when people run into bugs because they did what I told them not to do and I mean this has happened time and again not just with that but there is a system in place that actively disincentivizes people who are in charge in many situations responsibility without authority I think we have time for one more comment if anyone else wants to disagree with me I've encountered the power vacuum that you're talking about in all kinds of different contexts outside of web development so you might have heard of Byron Bay in Australia famous alternative kind of area probably a bit like San Francisco in the States although I've never been there but the thing is when you get a large group of people who all kind of you know are simpatico in some way but and they have some kind of alignment but they don't have a power structure to sort of keep that in place then yeah things fall apart over time and it's really sad you see so many different contexts in companies and organizations and whole geographic communities so I really get what you're saying with this talk yeah and there I cited a whole bunch of sources here if I looked another two hours I could find a dozen more that observe this process elsewhere of trying to be informal and structuralist and it coming back to bite you so this is not by in any way shape or form a Drupal unique problem and just like the funding problem we need to be looking elsewhere and see how has this been solved, how does this work what has not worked and the model I'm looking at is Linux I opened other models but the current model is not scaling I just want to say from what I've heard it sounds I'm not a cool maintainer so sorry I'm here but from what I've heard you say it sounds eminently sensible so my question is what's the next step what do you ask people to do we have to convince the structuralist structure that Larry's right for the recording Chris just commented we have to convince the structuralist structure that Larry's right or has a point yeah I think keep this conversation going think about what kinds of structure do we want we have a structure now I would submit it's not a good structure what structure do we want instead let's look at other organizations if anyone knows someone who works on Mozilla, on Firefox or knows someone who works on KDE or knows someone who works on Nome talk to them, get information from them see what they've done with this kind of problem and blog about it let us know, I would love to know potentially I do think I know which project you're talking about oh no absolutely I agree okay I think next step is sorry David Wang was saying there are a project that we know but will not name that has adopted an Apache style governance model that we could look at and see how it works there and potentially learn from that too is that accurate summary sure and it's also possible that some of these other organizations haven't quite figured it out and have just the same problem or some related problem let's find out let's get off our governance island too as long as we're at it and figure out where we want to move to and do so deliberately and with that I think we're done and despite anything I said here I expect to see all of you at the sprint on Friday because we do still have a release to get out