 Thank you, Holly. So here I am again. Welcome to Drupalcon Amsterdam. We're just the biggest European Drupalcon ever. We are more than 2,000 people here. Wow. I seem to suffer from a slight Drupal flu. So please bear with me if my voice fills me at some point. This year, I prepared my keynote a little differently. I ask you, the community to give me the topics by crowdsourcing the keynote, not because I'm lazy, but because what the community thinks is so important to Drupal and to myself. I received hundreds of truly great ideas. And hopefully you will see that I included a lot of them this morning. I know that the people in the community don't like a lot of corporate bullshit about the speaker's own companies. So I'm not going to mention Acquia more than once. And I just did. Instead, I would like to talk about Drupal's greatest resource, you guys. Yeah, there is a special part of our community and a personal favorite of mine, the people of Wunderkraut. They keep on growing. They are a platinum sponsor of this Drupalcon and they contribute so much to Drupal. No, no, no, no, no, no, please. I want to know. No, no, no, no, no, no. Sorry. Oh, boy. They are constantly on my mind. I love them like my own kids and dark. And even that little crazy carrot there in the back. So Wunderkraut, the best part of our community Wunderkraut, the spine and veins of us all. So Wunderkraut, don't we just love the word Wunderkraut? Even listen to the sound of it. Wunderkraut. So please stand up, everybody, please stand up, stand up. Yeah, yeah, OK. And spread the word with me. Please say Wunderkraut, Wunderkraut, Wunderkraut, Wunderkraut, Wunderkraut. And please, when I say Wunder, you will say crowd, a Wunder, crowd, a Wunder, crowd, a Wunder. Hello. Why are you? Well, I'm not. Well, I'm your most favorite impersonator, right? So, well, OK, OK, OK, you're going to go starting with chicken or grime. Yeah, but please, can I sing one more song for them? I don't know. Do we have security or something? No, no, wait, wait, wait, wait again. Just one more song about Wunderkraut, right? OK, OK. Wunderkraut, Wunderkraut, Don't we just love to spread it? Wunderkraut, Wunderkraut, I am eating a carrot. I love you, Dresch, I love you, see you in Japan. I must say, that was a little weird for me. But thank you, Wunderkraut, for the very original, you know, opening, I guess, or announcement. So, yes, I am going to talk about the state of Drupal. And I did a bit of travel lately. I've been traveling a lot, actually. And two weeks ago, for example, I was in China and Japan. And I had an opportunity to meet with many people who were interested in the Wunderkraut. I had an opportunity to meet with many people in the Drupal community. We organized meetups in both countries, as well as, you know, met with Drupal agencies and system integrators. And, you know, I've learned a couple of things which I just wanted to highlight here. You know, China was actually quite eye-opening for me because there is like 1.4 billion people in China. I mean, it's huge, right? And Drupal is relatively small. And I've talked to so many people about it. And the only reason it's so small is because they don't have proper documentation in, you know, Mandarin. And there's very few people that can translate the Drupal documentation, both marketing information, like what is Drupal, who uses Drupal, as well as developer documentation. And because of that, Drupal hasn't really done all that great in China. And so, to me, it felt like with some very small changes, somebody translating a book from English to Mandarin or somebody translating some documentation, you know, relatively small steps, we could have a huge impact on everybody in China. From China, I went to Japan. And, you know, Japan was the exact same situation, by the way, people were missing Japanese documentation because they're not very comfortable with their English. And as a result, they do not participate in our community and they just can't get started very well. But the one other thing that stood out for me in Japan is that they're a very strong local leadership. And, you know, despite the fact that they have some issues, some challenges with the Drupal.GP domain name, they have been able to build a great community. And so, for me, this is something that I've learned already, but I just wanted to iterate it here, but wherever I go in the world, the local leadership is what makes all the difference for Drupal. You know, those areas or regions where we have great leaders that organize events and meetups and all of these things, Drupal does really well, really. And the areas where we don't have those people, Drupal does so, so. So, hopefully, that is a little bit of an inspiration for all of you to go home and to sort of, you know, up the game, if possible, in what Drupal means and does in your local community. And while I was in China, I actually had an opportunity to meet with a few ministers from developing countries. I met, for example, with the minister of youth from Rwanda and others. And it's kind of mind-blowing because he was telling me that 70% of the population in Rwanda is less than 30 years old. And it's like more than 50% is less than 18% old. And so, they have all of these young people, right? But they don't have jobs. And so, when I started talking to him, he asked me, so what do you do? And I said, well, I do Drupal and he got really excited. He actually knew Drupal and he was very passionate about open source and the impact that open source could have on the youth in his country and how it could help people build local businesses or connect to each other or help each other make a difference. And so, that got me thinking that actually only 40% of the world's population is actually online today. You know, and many people are rapidly coming online, often on mobile devices, but also on desktops. And I really truly believe that we have a huge opportunity with Drupal to make a difference in the world and to enable other people to help each other. And I really think, because in the next 10 years, 15 years, billions of people will come online that need jobs, that need to do things for their families and their communities. And I truly believe that we can help them by providing them great technology. And so, think about that, you know, because in doing what we do, we actually do this. Like, there's not that much extra we need to do other than to keep growing Drupal and keep thinking about these people as well. And I'm actually excited about that because I think Drupal 8 will actually make this easier. The things we've done around multilingual in Drupal 8, the things we've done around mobile improvements actually, which is very important in these countries and also the usability improvements we've made, will actually make that even better. All right, and so that's what really excites me, personally, after this trip. But as mentioned by my double-ganger, I guess, I did things a little bit differently this time and I did a blog post and I invited everybody to basically suggest topics about what to talk about in this keynote. And I got a lot of responses on Twitter, I got emails, actually quite a few emails and people coming up to me in person and they say, oh, you should talk about this and you should talk about this. And I looked at all of these suggestions or a bunch of funny ones and somebody wanted me to talk about robots and robots that are hugging each other. Of course, somebody else wanted me to promote Belgian beers. But consider that done. And this is my favorite beer because a lot of people also ask me. But on a more serious note, there was a lot of suggested topics and I made a little tag cloud here and some of the topics were about innovation, people suggesting headless Drupal, people that wanted to know if there was any follow-up from my experience web talk in Austin and some of the talks I've done before. And I'm gonna touch upon that very lightly, but really, when I looked at the schedule, there's actually a good number of topics on headless Drupal and so I felt that was covered. I think the other topics around, say, getting Drupal 8 released about the issue with potentially burning out people, the issue about the complexity of the code base and how we're gonna deal with that. And if there's a risk in losing hobbyists and maybe we should hire more full-time developers, these were, in my mind, definitely a big theme in all of the suggestions. And so I wanted to talk about that in this keynote because I really believe it's a really important topic for us to discuss and to figure out. It's also a really hard problem because in many ways I feel this is new territory. There is not that many open source projects that we can look at and say, here's how they solved it. The few projects that are bigger are actually also a little different from us. And so it's an important problem. It's a hard problem. And so I feel like we really needed to discuss it. And that's what I wanna do. And that's exciting to me because I also feel like we're paving the path for others to model some of the things we've done. And I think if we do that, we'll actually be able to fulfill this dream of being able to have a bigger impact in the world. And so over the last month, I actually did a lot of reading about economic papers and lots of different things. And I wanted to talk about that today. It's gonna be a little bit more academic. There's an academic hidden inside me. Then what you may be used to. So please don't fall asleep. Please pay attention, keep an open mind and don't immediately jump to conclusions, I would say. But because I do think it is a very important topic for us. And so as I was reading all these things, one thing that kept coming up which was the notion of public goods. And I thought that was interesting. And basically I read this book or paper from Samuel's song which basically sort of prototyped the idea of public goods and he defines what basically is accepted the definition of a public good. And there's really two properties. One, it's non-excludable. What that means is that everybody can use it. Like you can exclude people from using the public good. And secondly, it's non-rivalrous. Meaning if you use it, it doesn't exclude somebody else from using it as well. All right, so it doesn't reduce the availability of the resource. And so there's lots of public goods available. The roads, the school system or the basic education system, parks, street lights, national defense system is a great example because you know you can't really exclude anyone from being defended. But I think Drupal is also a public good. A really thing that's true. An open source in general. And so if you think about Drupal, it actually matches this definition. Nobody can stop you from using Drupal. And if you use Drupal, that doesn't mean that she can't use Drupal. And so it definitely matches all of the characteristics of a public good. And so let's talk about one example because this idea that Drupal is a public good is actually a very helpful one because it allows us to expand our thinking. We can learn from other public goods, how they're maintained, how they're scaled and apply these thinking to Drupal, right? And so if you think about the road system, roads were initially invented by volunteers, if you will. Like people literally made roads between their villages or between their houses, right? And it wasn't until later, sorry, I think I skipped the slide, let's see. And so here's actually an example of one of those roads. It's a 5,000 year old road. It follows the top of a ridge and it still exists today. And it was created by volunteers to basically go from A to B and they build it on top of a ridge so to essentially keep themselves dry, keep the road dry. And it's still in use today, you can go there and walk on this road. So it's a great example of how roads were created by volunteers. And over time, businesses came along and they actually helped improve the roads. First of all, they felt like we can do more business if we can transport goods faster but also they charged for the roads. We have things like toll roads that people would pay for. And you can see a little image here of how you had to pay if you wanted to bring a horse or a cow, any of these things. And the same was true for the railway systems in the world. And this is a photo of Penn Station but what very few people know is that Penn Station was actually a private building and the railroads were run as a private business before it became a public good, if you will. And so as the road system was improved by businesses, the community, everybody basically benefited from that. Everybody can use these roads, not just the businesses. And as these things evolve, they get more and more complex and roads become highways and stuff like that. And at some point, the road system starts to crack down and they need a different level of maintenance. And this is usually where the government steps in. And for example, in the U.S., I think that was in the around the 50s that they basically said, as of today roads are government property, if you will. And so it's interesting if you look at the evolution of many of these public goods today, they basically started with volunteers. And as it grew, businesses got involved and it accelerated the development of these things and eventually government got involved. And so the same kind of pattern applies with all of these, to be honest. Education system, people would just teach each other in their villages, if you will. And then private schools came about and eventually there was a public school system. Or the same is true for national defense. At first, people just defend it. Again, farmers defending their own lands or teaming together as volunteers to protect their fields from, I guess from enemies, that evolved into more organized militia and eventually became a national defense system. And so as we look at all of these things today, like parks, they all eventually evolved from volunteers to business to government. Another way to look at this is that they went from an invention to a product to a utility that is available to everyone. And as that happened, basically, the reach of these public goods become wider and wider, but also the complexity to maintain them and to expand them as well as the cost to do so. And so it is not unlike in Drupal, really, because when I started the Drupal project, it was very much a hobby project. And I started on my own, other people joined and today, for example, there's a lot of companies. We have a very healthy ecosystem of commercial companies that are all building businesses on Drupal. And in doing so, we're actually improving the software. Many contributors are also being employed, right? And so this idea of commercialization of a volunteer open source project is not a bad thing. It's part of the natural lifecycle of open source projects. And so in many ways, we have to accept that because it brings an opportunity to get things to the next level. That doesn't mean that there is no room for volunteers. If you think about how innovation happens, volunteers are critically important for any kind of innovation, but as things get bigger, the complexity of maintenance, as I mentioned, increases. And you may need full-time people to do these things, right? But as I said, it doesn't mean that volunteers don't matter anymore. If you think about innovation, this is kind of how I mentally think about it. And there's a lot of opportunity on the edges for volunteers to try new things and to prototype them. And that's frankly what they're passionate about. That's what they want to do. They don't actually want to maintain the infrastructure most of the time. And so if you think about some of these innovations, could be headless Drupal. I mean, a lot of that comes from the edges and then becomes popular and then is being moved into core, for example. And so so far, we've learned that Drupal is a public good. At least I believe it is based on all my research. And that as volunteer-driven projects evolve and grow, businesses get involved and it's not a bad thing. This notion that Drupal is a public good is a good one because we can actually start looking at other public goods. And one of the biggest challenges that they have is provisioning of the public good. And I'll talk about that next. So there is this person, Garrett Hardin, and he wrote a book called The Tragedy of the Commons. How many people have heard about this? All right, a good number of people. But so essentially, there's a lot of challenges in public goods and again, this is where I think open source can learn from it. And the Commons really is a shared grazing area where people could bring their cows or other animals. And actually I live in Boston and there is still a Commons in Boston. It's called the Boston Commons. Today it's a big park, but in the law, it still is written that you can technically bring your cows. Of course, nobody does, but you could. And so that's a bit of an exception, but the reality is that a lot of these Commons just stop to exist. And so this paper studied that phenomena and it's called The Tragedy of the Commons. And so the idea is that these shared grazing areas, people can bring their cows and people also have to help maintain it. And so these are what we call the caretakers. And then there's also people that bring their cows, obviously, but don't help take care of the Commons. And these are typically referred to as free riders or sometimes the economists will describe it as the George will do it problem, because people just bring their cows and then assume that George will help take care of the Commons and that they don't have to do it. And so these are typically referred to as a free riders. And so the problem is that as the Commons becomes more popular, more and more people get involved, more and more cows, and effectively there's overuse of the grass, which leads to depletion and ultimately the collapse of the Commons. And that's how a lot of the Commons basically stop to exist. And so this is interesting because if everybody that used the Commons contributed a little bit, things would be perfectly fine. And so a lot of people studied this phenomena. One of them is also, he wrote one of the most fundamental books on this and I encourage you to read it if you want to, but it's called The Logic of Collective Action. And so he studies this problem that it's actually a no-brainer for everybody to help a little bit, yet they don't, right? And so he basically, and I'm summarizing things very dramatically here, but his basic premise is that people contribute out of some level of self-interest, bounded by social norms and things like that. And he said, as your project, as your group, community grows, the cost of contributing increases. And I think we can all recognize that in the Drupal world. Getting a patch committed to the core was very easy. Today, it takes a lot of effort. And this is something that we talk about a lot. The other thing he said is that as you grow, the benefit of contributing decreases. So there's actually two forces, not just a cost increase, but also a benefit decrease. And I think we can also see that. Like maybe in Drupal, you know, whatever, 4.6, I could create a slide and put photos of all of the contributors on one slide. And people would have, like, their photo there. And that would be a benefit for them. Like, they would be recognized for all their hard work. Today, the best we can do is create a tag cloud. No photos, and the tag cloud will show, you know, for Drupal 8, for example, that there's more than 2,000 people, actually over 2,300 people. And so we can actually recognize them that easily and give them the same level of visibility. The other thing he said is that the cost or the benefit decreases because people also start to assume, like, somebody else will fix this. I don't actually have to fix this. There's enough people, it will be fixed. And so the problem becomes worse. Because when you're small, there's social norms. If you're only three people, it's like, you know, it's hard not to do anything. And as you get bigger, that kind of becomes easier, and more people will freeride. And so basically another way to look at this is when your project is small, you have some sort of ratio between freeriders and caretakers. I picked three to one, but it could be whatever, right? And so what happens as you grow is that the ratio gets smaller. You get more freeriders and fewer caretakers. But actually, what he says, what you need is, you need this ratio to change. You need to ratio to become bigger because the benefits decrease and the costs increase. And so to maintain it, the level of effort into the caretaking increases, and so the ratio actually has to change. And so before I go on, I wanted to say freeriders aren't bad. So I don't wanna suggest that freeriders aren't, you know, aren't good. They're actually very much needed in any community because they help you spread the word. And they also have the opportunity to become caretakers as well. So it's not like we need to block out the caretakers, we need to get more, sorry, it's not like we need to block out the freeriders, we need to get more caretakers involved. So it's all about this ratio, not about the fact that there is freeriders. And so the big question here is how can we actually achieve that? How can we change the ratio? And I think the answer to that question will fundamentally change the dynamics of the community but also allow us to overcome a lot of these pain points that I mentioned on that slide. All right, and so this is again where we can learn from economists what they did with other public goods. And so there's lots of solutions being used. In the world today, and I listed some here, but privatization is commonly used where they just take a public good and they say, oh, it's no longer public, we're gonna privatize it. And so that kind of happened with Mambo which tried to take back the open source project which led to Jumla being created. Or when it comes to fishing, people use legislation. And they say, well, you can only fish in this area or you can only fish in these times. And so they basically impose rules about when you can use a public good and in doing so they avoid overuse or depletion. Taxation is probably the most common one and that's typically what's being used with parks. Like nobody wants to maintain the park, the government will just tax everybody, all the citizens and use a little bit of money to maintain the park. And that's how they fix the problem. Altruism, basically asking for donations is a strategy that others have used, like give us money and we'll help maintain the park. And I think Wikipedia is a great example of an organization that does that very effectively. They're raising millions of dollars each year through big fundraisers. Social capital, I think this is actually where we are good. You know, we contribute because it makes us feel like we're part of a community. You know, it makes us feel like we get recognition from others. It actually helps us build friendships and a network of people that we know and like, people that are like-minded. And that is social capital. And it's also real value because you can actually translate that capital into finding a job or there is real value in doing these things. And that's often, in my opinion, why people contribute to Drupal. That are a sense of altruism. And then there is privileged groups. And this one is interesting and needs a little bit more explanation, but the idea of a privileged group is that you give special benefits to caretakers in exchange for contributing. And so those who contribute get benefits and those that don't contribute don't get benefits. And the idea is that a subset of the group, of the community can actually maintain the public good and make it better. And the free riders benefit from that, but they don't have to contribute. But the public good can be provided for everybody just by a subset actually doing the work. And so there's actually great examples of that in open source, I believe. And so I think automatic is a great example with WordPress.com. So obviously, automatic gets to use WordPress.com which is a very exclusive selective benefit which makes automatic a privileged group. They're making, they've built like a hundred million dollar business of WordPress.com and so that was huge incentive to help provide, you know, WordPress. And so they're one of the largest contributors. Well, they are the largest contributor to WordPress. Another example is Firefox and Mozilla. I don't know how many people know, but Mozilla is like a 300 million dollar company or something in that range simply because every time you do a search, they get paid a little bit of money by Google. And so they're making all this money from open source because lots of people use it. And as a result of the fact that they've built this very large business using Firefox, they're also doing like 80% of the work on Firefox. They have a huge incentive to provide the public good for everybody and we all benefit from that. They make money from it, but we benefit in a sense that we get to use the browser. And so what about Drupal? Like what could we do, right? And, you know, first of all, I think a number of these things are not really open source friendly, you know, privatizing basically change means changing the license of Drupal, no longer open source, taxation is kind of hard. Legislation doesn't really apply either in my mind. So I've eliminated those. Altruism and social capital, as I mentioned, I think this is what we already do. I don't think it's very scalable. It works to some extent, but we're not Wikipedia. You know, we don't get hundreds of millions of people visiting Drupal.org. So it's hard for us to do that in a really scalable way. That doesn't mean we have to stop doing it. I think it's good that we do, but I don't think it's a solution for Drupal. And so that leads us to a couple of other options. One is reducing our costs, which is obviously something we can do to, you know, get the balance, you know, to balance out, I guess. And so this I think is well worth talking more about. And so we should start to study what are these costs? And again, I simplified it dramatically here. But if you think about it as there's core, and there's, you know, libraries that we built, and actually the core maintainers back in the day were also responsible for building Drupal.org and maintaining Drupal.org. They were very much the same people. And so we've actually helped reduce the cost. Like one of the things we did is we sort of spun out the maintenance of Drupal.org to the Drupal Association. Right, and so now we have staff at the Drupal Association combined with volunteers that maintain the website. And it's actually been working better. Like we've actually seen a lot of acceleration in terms of new features being deployed on Drupal.org. Libraries, I think we've done a good job in Drupal 8. We've actually sort of took out, we took out a bunch of custom-built libraries and we've replaced them with symphony components or other JavaScript libraries, these kinds of things. And I think it's worthwhile to think about that as a way to reduce costs. Like we don't have to maintain those libraries. We don't have to build them. At the same time, Core obviously got bigger too. And we've added all of these things and these are all great things, honestly, that are needed or that make the platform better or that allow us to expand Drupal's audience to more people. So we've done things to help reduce costs and then naturally we've added things which make things more complex. But I personally feel that a lot of the things we've added, they really matter. So the challenge here going forward is we need to think really hard about the things we add because we don't wanna make things more complex, unnecessarily complex. At the same time, we do wanna add complexity if we have to. And so I personally feel like we've done a good job at that. So now the question is what can we do on the other side of the scale, right? And this brings us to social capital and privileged groups. What can we do to provide organizations, individuals, a real incentive to hire a full-time Core developer, for example? Because right now it's very difficult to make the case to hire a Core developer because, again, the benefit does not outweigh the cost. And this is something we can do to change that. So I'm gonna propose a number of solutions. And these are not final solutions, these are just ideas. And I hope there'll be starting points for discussion about what we can do. So the first thing I think we need to do is we need to recognize that there's different kinds of contributors to the project. And they all work together. There's individual contributors, people like Chicks or Alex, Alex Spots, or WebChick and many others. But there's also Drupal agencies. These are the face-to's, the Wunderkrauts, the Lullabots. When I call them agencies for this presentation. And then there's the end-users. These could be small organizations or large organizations. Organizations like BBC or NBC, large companies or nonprofits, all of these. And what I think we should do first is we need to track what each of these personas actually contribute to Drupal because today we only track what the individuals contribute. And that's a challenge because if we don't know what the agencies contribute, we cannot actually reward them for their contribution. So understanding how our ecosystem actually works is a very important first step. And so a while ago, actually coming out of DrupalCon, Austin I proposed on my blog to change the way we give credits in our commit messages as a first step. And this is roughly how we do it today. I mean, obviously not exactly like this, but in idea. So we basically, when we fix say a performance bugs, we say, Sam, Megan, Tim and Josh helped fix it. Thank you very much. And we give credit to the individuals that helped. What I'm proposing is that we change it to something a little bit more complex. To say Sam at Acquia, Megan, Tim Star, Pfizer or Josh at Tag1, Star, Nestle. And I just made these things up, by the way. They don't actually mean anything. And so what that really means is, this is the format. So individual agency and user organization. And real quick, just to get you a sense, this means that Sam helped fix this bug on his Acquia time. Megan fixed this as a volunteer. And she may work at a company. She may work at chapter three, but she didn't do this work at work. She went home and she fixed these things in her spare time. And so she can say, I wanna get, and she can specify, I want the credit to look like just Megan. Or Tim can say, I work at Pfizer. Pfizer is not an agency, they're a user, but they also, a lot of these organizations have their own Drupal people on staff. And so he can say, I'm Tim and I work at Pfizer. And so please give Pfizer credit because I did that work while at work. Or it could be more complex. Like I'm Josh, I did this work because I'm employed by Tag1 and Nestle actually hired Tag1 to do this work. And so now we actually understand the chain of the relationships. And I think this is very good for a number of reasons. And I'll talk about that. Actually, let me talk about that now. So first of all, I think it increases the transparency in what we do. Like if there's potential conflict of interest, they're actually exposed here, versus not exposed at all. Another big challenge is, say, Sam leaves Acquia and goes to another company. Today, all we have is Sam. And so all of this history, the credits history, sometimes you call it, moves from the old organization to the new organization. So we're not actually able to track accurately how these things change as people move from one employer to another employer. And so there's other reasons why I think this is a good idea. The other thing I think we should do is we shouldn't just track the different personas contributing, but also recognize all of the different kinds of contributions. And we've gotten better at that, but I think we can do more. How exactly we want to do that is still a bit of a question. But one idea is we have this drop-down menu and as you upload something, or you can actually select what kind of contribution it is. I think this is important because some people spend, let's say, hours reviewing a patch. They don't actually contribute code, but they don't always get credit for reviewing the patch, even though it's a substantial effort in terms of work. And it's not just reviewing patches. There's a lot of things which we don't always properly award, in my opinion. And so if we do these two things, what's exciting is we can actually understand how our community works. To me, that looks fascinating. And as I mentioned, we can deal with how credit moves, when people move, or we can actually, we can understand where we are in this life cycle diagram. Like how much of Drupal is actually funded by commercial companies. Right now, we don't know. We assume a lot of people do things in their spare time, but we really don't know. Right, so if we have built this, now we have a system in place that we can use to award people when they do things. And so if you think about the agencies, you know, all of the Drupal shops, they probably want primarily three things. One, they wanna get customers. Right, at the end of the day, they're a business. They also want to attract the best employees that they can attract. And often they want to see recognition. And so as we track all of their contributions, we can start doing things like organizational profiles. Because today we sort of, we have a marketplace, but really we only have individual profiles. And on these profiles, we can show a lot of information about this company. Like they're a top 10 contributor when it comes to documentation, or they're in the top 50 when it comes to testing. Or we can say based on this, all these commit credits, we can see they have 56 Drupal developers and in total they've contributed 110 patches. Like all of this interesting information. And that's useful because they can actually show that to their customers and say, hey, I know what I'm doing. I'm contributing to Drupal. And customers actually love that, right? The end users really wanna work with the experts. Plus, if people are looking for jobs, they also wanna know if this company is gonna let him or her contribute back to the project. So it's very useful information for different audiences. And so this notion of agency profiles, I called it here, I think is a very valuable one. But what else can we do? We can also visualize companies or almost penalize the companies that don't contribute. I'm not suggesting we should that in a harsh way, but we can do it in subtle ways. That may provide them an incentive to contribute. And this is also something that is often discussed in the academic research. Like you can either incentivize people to do something or you can somehow penalize them or disadvantage them. And maybe subtle design things on these profile pages could encourage contribution from them. Something to think about. Another idea, and this one is maybe a little more debatable, but what about we allowed contributors to advertise on the d.o. main page, right? And this is only available to contributors, say. And we built this kind of system where say if you fix a bug, or you know, and it doesn't have to be all the large systems. Like one of the question is how can we make this fair? So that when a small organization contributes, they would get visibility and when a large organization contributes, they would get visibility based on their contributions. So we don't want one company to get more benefit than another as long as they contribute equally. And so imagine this, and again, this is just me brainstorming, but if you fix a normal bug, let's say you get, I don't know, 10,000 ad views on the main page. Some amounts, whatever it is. But we could say, well, if you fix a major bug, we value that more, right? And so we'll give you 20,000 or whatever number. And if you fix a critical bug, well, we'll give you 40,000 ad views. And we can actually change these incentives based on where we are in the release cycle. Maybe early in the release cycle, we say we wanna encourage UX improvements. And we say that's gonna get you the most ad views. But maybe late in the code freeze, like we are today, we could say beta blockers, if you fix those, you get the most. But if you try to introduce new features, maybe you shouldn't get too much award for that. And so you can, again, this is just a rough idea, but you can see how a system like this we could actually use to try and direct resources in the community to help us accelerate things like the Drupal 8 release cycle. I think the marketplace, I don't know how many of you have watched the marketplace, but it has a notion of agency profiles, but all it does right now is it lists things alphabetically. So organizations like 2Bits are always on the first page because their name starts with a two. And I mean, and I love 2Bits, I have nothing against them. But organizations like, let's say phase two will contribute a lot. They're like on page 70. And people never get to page 70. And so what about in addition to listing organizations alphabetically, we did small little things as list them based on the amount of contributions and maybe we slice and dice it based on their size of organization. I mean, there's lots of different ways we can use that information. And in this case, I just showed some ads up there. In general, of course, this is a very complex problem because it's not just about commits. And there's all sorts of things which you should get credits for. Whether it's mentoring or support or you contributed a new module or you work on Drupal 7, it's also not just about Drupal 8, whether it's you helped organize a sprint or whatever it is. And so in my mind, we could develop this rank-commatic machine which basically takes in all of your contributions. Apply some sort of algorithm. Calculates a rank or whatever it is and out of that machine come, you get so many ads and you get this batch and there's all of these little things we can do. Of course, this is not easy to build. I don't think we can build this overnight. I think this is almost patron-like. And it's like a living algorithm. It needs to be tweaked and tuned and extended. But I do believe that having something like this is better than not having anything at all because what we have today, in my mind, is not gonna scale, right? And I think there's lots of early signs of that. And so an imperfect solution still beats no solution because I know all of you have 100 ideas of what could be done differently, what could be broken with this. And I probably agree with all of those. But I do think we need to do something and even if it takes us years to get it right. All right. So we can also look at the end users. As I mentioned, the non-profits or the commercial organizations using Drupal, they also have needs. They also want things like benefits and they really wanna attract employees as well because they often have in-house Drupal staff or they use a hybrid model where they work with some Drupal agencies but they also have some in-house staff and they also wanna get recognition. You know, when I talk to Pfizer or NBC, they're all contributing millions of dollars back into Drupal but nobody knows. And it's very frustrating for them because they're also trying to hire Drupal people, right? And so imagine we help those organizations find more talent and this is a real problem. Like the Drupal Association did a survey just a month ago or something and some of the things that came out of the survey is that 92% of the hiring managers across agencies and end users think it's really hard to find Drupal talent and yet 82% of them, they're really trying to find those people. So it's a big challenge sometimes to find Drupal talent. At the same time, about a third of the contributors prefer to work at employers that let them contribute. And so with this magical problem and solution almost, we just have to connect a few dots and we're there. And so we could do things like on the Drupal jobs page and again, this is a mock-up but it could look like this where Nvidia is a gold contributor so they're at the top and they have this little batch and in a very small but subtle way it flags to job seekers that this is a great company to work because they contribute to Drupal. And this case are featured because they also paid the Drupal Association to get their job listing but maybe Pfizer didn't pay but they still rank maybe hiring the listing or they have a little icon somewhere to signal that they are a good company and then company B, which is all the way at the bottom who isn't contributing just doesn't get these little visual elements, if you will. And it's a small little thing but in talking to some of these organizations they actually believe it's a big thing. Again, it's a small little steps that could have meaningful impact on the community. And users would also get profiles, not just the agencies and this we don't have today. And so again, just like the others they would be recognized for their contributions in their profiles, which is what they want. They want that recognition, they wanna be able to attract talent that way. And of course the contributors are also really important they always have been and if you were in the pre-notes people actually were, I mean it was pretty amazing to watch all the stories and how people felt empowered and how they loved contributing and how it gives them that sense of recognition and belonging and there's things we can do to amplify that and to make more people feel like their contributions matter and that they're part of something bigger. And so again, there's lots of things we can do also to the individual user profiles. And I wanted to thank Danny real quick for helping to design a lot of these. He did a lot of the research and the design behind these ideas and then I took them and together with Kevin or Liri we kind of expanded upon these ideas. So thank you Danny for taking charge here. All right. And so all of these things that I talked about are benefits and we can essentially add them to the scale and hopefully it will tip over the scale. And I think it could, we just have to dial the algorithm to the point where a company says, well it makes a lot of sense for me to hire a full-time core developer for example because if that person is a productive core developer, contributor, I get so many ads and these ads will give me customers. And so it almost becomes like a marketing expense for these organizations. And it doesn't have to be a core developer it could be contributed modules or whatever you think it is. And I really think it could work personally. And so far we've learned that Drupal is a public good which I think is an important realization because as I mentioned we can learn from other public goods which I tried to show you in this presentation. We also learned about how volunteer different projects evolve into public goods and how business gets involved and these kinds of things. We also learned about the challenges of collective action. As things get bigger it becomes more difficult to contribute but it also becomes less interesting to contribute. So what that means is as we grow we need to change the incentives. We need to change the cost-benefit balance if you will which we also talked about. And the way to do that is to evolve the way we think about incentives. When you're small it's good enough to get recognition from 12 peers. When you're the size we are that becomes increasingly less interesting frankly. And so as we get bigger we need to involve the incentives and I proposed a few incentives which we could do. And again it's only the start of a discussion about maybe other things we could do. But I do believe that this is very important for us to do as a community. I think a lot of the pain, a lot of the questions that I got when I asked people to submit those questions were related to this problem. Like you know people are afraid of losing hobbyists but we're not losing hobbyists. We're asking hobbyists to do very difficult things and as a result they're being turned off. They don't want to do these things. So and we need more full-time people to do the really hard things so that the hobbyists can keep doing what they're most passionate about which is innovating at the edges. Doing things like headless Drupal and prototyping these ideas. People asked about funding core development. Well we don't want one company to fund all the core developers but we want to build a system that creates an incentive to every Drupal company to hire core developers. A fair system not a system like you get WordPress.com. Not a system which gives an exclusive advantage to one organization but a system that gives advantages to every organization that promotes equality within the ecosystem. And I think some of these things that I proposed well all of these things that I proposed match that these requirements. People also are really worried about why does it take so long to release Drupal 8. And that's a very complex question but there's definitely a case to be made to get more people involved to help us fix critical bugs. Other people were nervous about innovation and I think this would actually increase innovation and would increase the impact we could have on the world as I mentioned. So I hope you guys are excited about that. I can imagine it raises a million questions and a lot of concerns. But I do think it's an important topic and it wouldn't be smart to not really talk about it or to not go and tackle the problem. So that was my response to all of your questions. There's one more thing. And obviously that one more thing is Drupal 8. And so we've had a lot of people contribute to Drupal 8 over 2,300 people that contributed, unique people that contributed. And over 11,000 patches have been accepted. We fixed almost 200 beta blockers since we started the beta process. So we've done a crazy amount of work. And like literally people have been pulling all nighters at this conference to try and get all of the beta blockers fixed. We've also done 15 alpha releases. And so a little while ago, we had zero critical bucks, beta blockers. But we asked you to come to Amsterdam and to test. And so yesterday, I think about 100 people got into a room and were like, we're hammering on Drupal 8 beta and they found a problem. And we fixed it. And we fixed it. Woo! So the core maintainers, along with some of our right hand people, so to speak, we met last night and we talked for probably almost two hours about like, what are we gonna do? We have this beta blocker and apparently it was fixed during the keynote. And so first of all, I wanna thank those people that literally contributed and tried really, really hard to get to zero by the keynote. I know people were up till five o'clock in the morning and probably beyond that and really gave it everything they've got to try and make this happen. But we met last night and we said, we will release beta one this week. We weren't ready to release it this morning, but we all felt comfortable to release it this week at the Drupal conference. And so we just need a little bit more time to cross the little dots. But before you all go home, Drupal 8 beta one should be released. So all the credit goes to the people that worked hard on it and helped fix all the beta blockers. So we don't know yet when we will announce it, whenever we tag it, but come to the keynotes, maybe we'll give you a quick update before the keynote tomorrow or maybe we'll give you an update in the closing session. So I encourage you to keep coming to these events. And then we also would encourage you once it's released to take it for a spin. So there will be a download on the project page on drupal.org and at the sprints, we can teach about easy ways to test it using things like simple test.me. So it's not hard to get it going. And we want you to beta test it. We want you to report anything you find, bugs in the issue queues. If you are a module developer and if you maintain contributed modules, this is, once we have released a beta, this is kind of the green light for you to start upgrading your modules. But there is a but. There's some things which are critical bugs which we're aware of. And so while we feel that beta will be stable, there's also some things that we know of that we still have to change. So it's kind of mostly stable, if you will. And we will, when we announce the beta in a blog post or on d.o, we will give you direction or guidance about which sections of Drupal 8 we know we still need to change. And so at the same time, this is a good time for you to start upgrading your modules and to report bugs as you do that as well. If you are a themeer or a documentation writer, we want you to hold off a little bit longer because we're still gonna change strings and we're still gonna do small tweaks like that which will cause some problems. So hold off a little bit longer if you wanna start upgrading your themes or if you wanna translate things or document things. And then if you are a core contributor, this also means that we're gonna become more strict. What that means exactly, we need to provide some guidance around and so we're actually meeting again today to discuss what it means in terms of getting features in or some non-critical API changes and we'll communicate our thoughts on that in the next week or so, I would say. With that, I'd like to thank the audience and I'd like to ask every individual contributor that contributed to Drupal 8 to please stand up. I wanna everybody to thank you. You guys are awesome. Please, please, don't sit down, don't sit down. In the interest of eating our own dog food, I wanna ask all of the Drupal agencies that employ one of these people to also stand up. So if you work for any of these companies, please stand up or if you work for any of the end users that employ core contributors also please stand up because we should also be thanking all of you. So thank you for contributing to Drupal. You can sit down now. And so remember that George will fix it. Well, you guys are George. Don't forget that. So thank you again. That was my keynote. And I believe Paul Johnson is gonna, I think he looked at all the Twitter questions and stuff. Yep. So great keynote, Drees. There's certainly been a lot of action on there. Social media, you've caused a bit of a storm out there. So we've not much time so I think we need to just drive straight in. So Drupal indeed open source is fueled by passion. And do you think that this reward mechanism that you're proposing could skew this or even suppress it? No, I think it could actually help with that because as I mentioned, I think we, you know, there's a lot of passion today. I think that won't go away and we should find ways for people to, you know, contribute and innovate and sort of unleash those passion. Do you think perhaps this is an opportunity for a lot of the unsung heroes that are in Drupal, not just the shops, but the individuals to emerge and we can kind of celebrate them and they're leading by example? Yes, absolutely. I think it makes it easier for people to get involved and to get recognized because we're beyond the point where, you know, at some point, everybody knew everybody, right? And we're not no longer at that point. Like there's a lot of you that I don't know, although you are contributing and there's no way for me to really know that. Right, so I kind of would like in Drupal to be in a bit like a village at first where everybody knew everybody and we've got to a scale now where that's just impossible. I mean, look at the number of people here today. Do you think that there's a need for sort of devolving the responsibility of tracking these things perhaps down to more of a regional or it's kind of areas of Drupal? Yeah, I think that could be actually very interesting. And so, you know, what I'd like to see happen is, and you know, the Drupal Association is actually working on these commit credits for organizations and to make all of the data available, you know, to an API or, I don't know, just, you know, expose the data and, you know, encourage people in the community to take that data in and to build their own modeling tools. So that touches upon something interesting that Dave Hall has asked. You're going to have this kind of agencymatic system which tracks their contributions. Will that be open and available for us to see so that we don't get situations like in SEO where people are gaming the system? Yeah, I think that's a great question. I don't have the answer. I think I can see the benefits of opening that. I can also see the downside of opening it up. Like, obviously, if you expose the algorithm, it allows for gaming more easily. So I don't know what the right answer is, but I think we should explore different options. And we should have a culture of experimenting with these things versus, you know, just to see what works and what doesn't work and evolve it. Yeah. So Larry Garfield said that this incentivization is a great idea. But how do we make our structure more comprehensible to new contributors? Yeah, it's like our organizational structure. Yeah, yeah. Yeah, I mean, I think that's where the data comes in. And again, we can build, you know, like overview pages or leaderboards or whatever it is to show the world. And the Linux Foundation, for example, although they work differently, they, you know, the foundation, every year, they do this big research and they summarize how the community works and they publish that. So there is ways to, once we have the data, we can think about ways to visualize it, whether it's PDF documents, you know, once a year, or it's something that's more real-time or you know, both of these things. Seb Corbin has been expressing concern around, you know, the smaller shops, the other two-month bands or the individuals. And perhaps how there may be too much of an emphasis towards these larger organizations and... I don't think so because, I mean, we should talk about it more. But if a one or two-person company, when they contribute and say, we do the app thing, like they would get, I don't know, 20,000 ads. And for a small organization, I mean, it's balanced in the sense that they get equal reward. And they may not need that much leads compared to a larger organization. So, you know, I think the system actually, at least in my mind, it's fair. Yes. TACOPTZ, as mentioned about, how do we gain more social capital from organizations that are enterprises and charities and governments that are using Druful, but perhaps aren't necessarily contributing, you know, these valuable investments back? Well, we need to capture... I mean, well, we need to, again, we need to track what they're contributing. And it doesn't have to be code sometimes. So, some of the times these are behind closed doors. How do we stop that from happening? Well, that's a hard one, because if nobody knows about them, it's hard to, you know, give them... And do you think that perhaps this idea of having these beacons more visible on Druple.org is a way that they maybe will start to encourage that? I think it would, yeah. I think it would make a huge difference to some. Rude Evans has been in a discussion yesterday about crowdfunding. What's your opinion, as far as there being a central entity that could raise and distribute funds to maintain Druple's velocity? I think that's another option. I think it's... You know, I'm skeptical about that right now at the scale that we're at. I mean, we've tried to raise money, but we need something that is very scalable. And we've tried with things like GitTip, which worked a little bit, but it didn't really work. Like, we couldn't even pay one full-time person from the GitTip, or maybe just one. But really what we need is we need to figure out a way to get hundreds of people involved, just in core, and thousands of people in Druple. So, one organization hiring people, I think is a great idea, but we can't assume it's gonna be the solution, because they're only gonna have some amount of impact. Like, we need systems that are scalable way beyond that. Okay. Changing the subject subtly. Robert Douglas said that you talked about social responsibility within Druple. Do you think that we as a community should have shared social responsibilities beyond code? For example, carbon footprint, protecting freedom of speech, and privacy. I think it would be great if we could. I don't, I need to think about more about how we would be able to do that, but. Actually, what I like best right now is that we do well by just doing what we do. It's like the side effects of our daily work is that all of these other organizations can use Druple to better the world. Is there more we can do beyond that? Yeah. And we should think about ways of doing that. So definitely in favor of that. So we're running short of time, but there's one more question. So Kathy's asking, what's your secret to keeping abreast of Druple call status? Well, you know, so I've been able to build a small team around me of people and, you know, and so I do some of my own reading and keeping up to date, but then also it's very helpful to have team members that live in the issue queue and that can like summarize an issue with 300 comments in like 15 minutes because reading it with the three hours. Yeah. And so there is, you know, these kinds of things and there's also technology changes we've made around issues, summaries and stuff like that, which, you know, is very valuable for everyone. So. Thank you. So we need to move on. So it's the all important group photo. So I'd like to thank Dries for your presentation. Congratulations on reaching beta. And we'd like to hand over to Robert or is it Jam? OK, can you hear me? This is oh, hey, this is on. So before any of us are allowed to caffeinate or nicotinate, we have to go if you're in the main hall straight up and out the G doors into the courtyard here between the two buildings. There is a very familiar graphical representation on the ground that we're supposed to fit ourselves into. Go find it and we'll see you out there.