 All right, let's get started. Good to see that you made it to the last slot of Drupalcon. Has it been good so far? Yes! Awesome. Let's see if we can make this work. Can you all hear me all right? Is that good? All right, so we'll talk about core initiatives and corporate roadmaps. I'll share some lessons or perhaps like a point of view from how it's been to run an initiative for the past five years or so, depending on how you count. But it's also kind of maybe a proposal for how to sustain core initiatives so the talk will turn into that at the end. It's an uncomfortable topic, right? We're going to talk about money, kind of intentions. These are not great things to talk about, but it's, I think, very necessary. There has been a lot of conversations about this already in the community, not only in Drupal, but in the wider community. So, Dries wrote a very popular blog post. Webpack is kind of leading the pack. So, figuring out ways also to sustain open source. MongoDB Elastic has recently had to change their licenses because they couldn't sustain their open source model. And there are lots of other interesting initiatives out there as well. So, the outline of this talk. I'm going to share a couple of lessons. And then we'll kind of look at maybe what the perfect kind of initiative might look like. Like, what's the ideal setup? And then a proposal towards the end. But before I go into that, who am I? I'm a work professor, a long-time core contributor, and coordinator of the workflow initiative. I am Attic, also on Twitter. My DMs are open, so harass me on Twitter if you don't like what I'm saying. Or here in the room for that matter. So, just to be clear, this is my personal point of view. This is not the opinion of my employer. However, of course, it being my personal point of view, it's still a perspective from within a, what we sometimes refer to as a user organization. An organization that is using Drupal. Pfizer's purpose is not to deliver or build Drupal sites for any clients. We use Drupal to provide value to our users, to our marketers, and at the end of the day to our patients. So that's a unique point of view from core initiatives or core development perspective. Not unique. I shouldn't say unique, but it's definitely more common to see Drupal agencies or so contribute to core. At Pfizer, it's my job to effectively buy and provide technology for my users. So that is an interesting point of view as well. And again, I tell the story as myself, as a community member or community leader. And also, an interesting twist here in terms of how I choose to lay out this session is I'm going to look at what the initiative did for Pfizer. Not so much as what Pfizer, because Pfizer drove the initiative, right? But I want to kind of de-couple Pfizer a little bit and see what the initiative, as a group of people, did for Pfizer. And perhaps that will become evident and more clear as I continue here. So I'm going to stop by sharing a couple of lessons. First of all, I think core governance, generally speaking, works quite well. The initiative roadmaps have provided a lot of clarity, I think, for organizations who want to participate. There's a direction. We know roughly where Drupal is heading. A set release schedule has also provided certainty along with that clarity, so that's great. We've got a great product team. Now, Boyan and Roy hasn't been involved just recently, but they help the workflow initiative a lot, which is why I'm bringing them up here. They've been very important for the initiative. And this, in and of itself, has been a great enabler for any company who wants to participate and develop Drupal. You need clarity, you need direction, and you need some certainty if you're going to make an investment and contribute back to Drupal. So we need to do more of this. Also, for the workflow initiative, if you're contributing the right thing, it'll probably get in. If you have the backing of the community, of the product team, then that makes it a lot easier. So picking where you contribute is also important. All right. And then, you know, in pitching this idea to the company that I work for, it's important how you can lay out the reasons for why you want to contribute something. It's all about optics, in a sense. You know, don't sponsor open source. Sponsor kind of implies that it's some sort of charity, right? Companies don't do charity for software tools. Pfizer's an organization that do charity for human causes, right? Not for a software tool, you know? So, you know, in pitching the idea to the company, you know, I want to ship products with the best developers. I want to deliver something valuable to the organization. That's how you get, you know, a director to sign that bill, you know? I like products. That's nice. I'll sign that bill. That's a good product. This is not charity. I mean, of course, the causality is in a way, you know, a contribution. But so it's important how you kind of angle it. And you need to ship a great product, right? You need to, first of all, know what you want to build and want to contribute. And if you don't, do research and use data to back up your idea. Not only do you need to convince the community that it's a good idea, but of course, you also need to convince the company that you want to then also contribute to the development of this idea. You need good product management. And you need to be able to very clearly explain what is the value of this. Who's going to use this feature? You know, that's critical. In the core initiative, in the workflow initiative, we started back in 2015, between 2015 and 2017. We worked a lot with Roy Boyan and Joseph Toff to kind of flesh out what is this thing going to look like? What is the value? Who is it for? And how is it going to work? You need to have that before you put yourself in front of a company and say, this is what I want to build. It needs to look great, right? This is where a good product team, good designers are incredibly important. Again, underscore the value of why you need to do something rather than I want to sponsor something. I want to help the community. That's awesome. But at the end of the day, it's sad to say the companies are there for their own bottom line rather than contributing to the software too. So thank you, Boyan Roy and Joseph, who did a lot of work up front in kind of defining this. And it was already back in 2015 that these ideas came together. And this is pretty much what we have in Kornau, right? We had the idea of hierarchies of workspaces. That patches is pending to be committed now. The user interface, although it's not exactly like this, we're pretty close. And it's been steering the development. And this is the product that we put in front of my directors and my managers where I said, this is what we want to build. And this is why it's valuable. You can, on the YouTube link there, I'll share the slides later, but you can see the presentation from, I think it was 2016 or 2017 when we kind of walked through the whole product, effectively, that we wanted to contribute. Another interesting thing when you pitch in your idea and when you want to build something sustainable, especially for a big corporation whose job it isn't to really develop a group, I was trying to find the best words here, but reducing reputational risk. I'll talk to what that means. You won't get fired for not contributing. As a manager, I'm a technology manager at Pfizer. I could have picked a simple route. I could have gone and hired another company to develop CMS or build some feature. And maybe a big consultancy firm, a big contract, that's comfortable for me as a manager. I will never get fired for choosing Adobe or for choosing Microsoft. That's a safe route. So when we pitch to companies to do things the core initiative way or contribute to that, we need to be kind of conscious of that. We need to help companies feel kind of, you know, we need to reduce that risk. Timeline and budget targets are always in the way of uncertain contributions. Contributions is, I don't know if it will get in. I don't know, we're putting ourselves out in the open. It's risky. We were put in front of the community working group at Pfizer for misconduct. That could have been disastrous for Pfizer, right? We had timeline targets. So, you know, admittedly, we stepped on some people's toes. Because we needed to ship something. We needed to get something done. And, you know, it's good that we have this process so we can sort out these disagreements. So it's great. I'm very appreciative of the process. But that's a huge risk for a company. So we need to kind of be conscious of that. And also the structure of the contribution is important. Very important. Is the company paying someone to deliver a feature? Or is the company implying responsibility of a piece of software that is being built? There's a very important fine line between the two from a legal point of view. So if you can kind of, if we can think about how we get organized and how we structure our core initiatives, that might have a big impact to how we do things. And I'll get into kind of some concrete examples and a proposal for how we perhaps fix this. And then, of course, we need to get organized. Presenting a sloppy solution or a sloppy idea to a company, you'll never get buying on that. You need a great product manager to think about these ideas. That's where Boyan and Roy and Joseph helped out a lot. I'm not a product manager. So that was very important. To conceptualize that product and have a story to share in a way. And as a team, you also need to be ready to take accountability and actually deliver that product. If the company is going to put some money on the table, there needs to be something coming back. And it needs to be, we can't guarantee, of course, but maybe we can do things to kind of try to do our best to do our best to meet timelines and goals and so on. We need to be conscious of that. Otherwise, companies won't show up, I think. And of course, you need awesome designers and developers. So someone at the end of the day needs to deliver this. It doesn't matter if you have a great idea if you can't deliver it. So, you know, Andre and Andre and everyone else in the room here who helped build this. Thanks to you. So get organized, right? We need to kind of structure the team in a way that makes it possible to execute and deliver. And make paying for it easy. How are we going to receive, like, how are we going to pay people? Right? We've had to figure out quite some interesting things in how we actually, you know, pay for contributions within my company. It's not as straightforward as, you know, as if it's a big corporation might not be able to set up contracts directly with freelancers. It needs to kind of, you need to organize it. So make paying for it easy. Budget and finance is hard enough in a large corporation and paying a group of contributors isn't making it any easier for, you know, a manager directed to sign a bill. So we don't have a solution to that today. If the company rocks up today and say, hey, I want to contribute to the media library initiative. How? You know, I have a bill. I'm ready to sign. How do we do it? I don't know, you know. Send the Acquia some money? That will work. But should everything go through Acquia? Probably not. Right? I like that, guys. And don't put the burden on the corporation who wants to show up and do the right thing. Don't put the burden on them to figure it out. Right? We had to figure it out at Pfizer, how to structure this and how to organize this. That was additional overhead, additional complexity that we could also have, you know, not needed to deal with. Would have been great, you know. All right. I realize it's actually, there were six lessons. I said it was seven at the beginning. My company was probably not that great in the middle of the night yesterday. So what does the perfect initiative look like? So these are lessons that I just went through. By no means am I saying that, you know, the workflow initiative was perfect. We didn't do all of this, right? But this, what I've gone through here would have been, you know, that's the lessons we took out of it. It would have been great to do this, right? I think our initiative has been very, very successful. But I think we also fell short in a couple of ways. Especially when it came to kind of getting ourselves organized and sustaining funding has been hard. Andrew has done a great job building all the awesome features, but he's been left alone many, many times as well. So what could the perfect initiative look like? This is not going to work for everyone. What I would propose here is not like a silver bullet. It's not a solution for every initiative. There's different kinds of initiatives. But this might be part of a bigger picture perhaps. But generally speaking, we went through it a little bit earlier on. It must be a good idea, right? First of all. Back by data maybe, back by user research, back by community feedback. And the more certain we are that it's a good idea, the better, of course, right? And it needs to be a team who corporations wants to fund, right? The idea should be so great. The team should be so great that it shouldn't be a question, you know? Funding the initiative should be the best option to solve that common problem. There shouldn't be another option to go about it. It should be the best presented option on the table. And of course the team needs to be capable of delivering the best solution, which means the teams need to be reliable, well-funded, be able to work regularly, prefer to be full-time, or at least kind of consistently part-time, so that we can set some expectations around how much we can develop when we can finish working on things and things like that. And, you know, as an industry we've already figured out that taking an iterative and data-driven approach to product development is usually the best way to go about something. Not always, but it's something that most companies do when they do product development. When they build, whether it's Adobe building their CMS, they're not guessing, you know? They do market research. They use data to support their decisions. They ask users, right? And the perfect initiative also makes it easy for corporations who want to do the right thing to, you know, chip in or partake. So the question then becomes how do we position initiatives with a competitive edge? There needs to be something that puts initiatives apart from other ways of doing something. So if there is a common problem, let's say we need, you know, better ways to find and choose media in Drupal Core with, you know, prior to media library, perhaps. How do we make sure that the team who wants to contribute this to Core is the best option to go about it? Right? So here's a proposal. So we have the telemetry initiative. This initiative, we could kind of twist this a little bit from the initial proposal. This could be an initiative to coordinate data-driven product development for Core initiative's purpose. For those that are not familiar with what the telemetry initiative is, it's an initiative that wants to build solutions and functions in Drupal to collect data from opt-in Drupal sites, things like usage, statistics, user behavior, et cetera. What modules you use, what features perhaps you use within a Drupal site, what fields are people using, what field widgets are people using, where do people click all the time? Like all these things. You have the issue number on the screen there if you want to go check it out. The initiative would then also maintain data and privacy policies for this data that's being collected. The data would be sent back to Drupal.org. As we have modules doing that in Core already. So we'd have to build out infrastructure on Drupal.org. The telemetry initiative could also take it upon itself to go gather large-scale and do perform large-scale market and user research. So not only is it sometimes enough to collect data about the product itself, we also need to go and ask users. So it's kind of this initiative to like gather data, gather feedback from the community or from users. And here's the clicker. The telemetry data I propose should only be provided to core initiatives. And core initiatives only. It creates a very competitive edge for core initiatives and creates this massive incentive to go through core initiative to get work done. These are people who wants to develop something in core. We provide them with the telemetry data. Maybe they need to sign an NDA with the Drupal association. They can't share this data outward externally. We would then ensure that core initiatives are equipped with the best data to build the best features in the best possible way. It'll be by far the best option to go about something, to build a media library, to build a layout builder, or to build a workspace, for example. No other team will have access to the same data to build a proprietary solution. And we can then couple this with helping to coordinate the funding for this as well. So I will volunteer as a community member, not as a Pfizer employee, to possibly drive this forward as an option and see how we can organize this. This is not a complete solution by any means, but it's an idea. So the question then becomes, how do we really organize this? Because that's just an idea, collecting data and so on. We need to organize it somehow. And there's something called open collective. That's what webpack is currently using. So open collective is this, I think it's a not-for-profit organization. Not sure about that, but they provide infrastructure for open source projects or other similar types of organizations. They provide a legal entity. They provide some legal support. And they provide means of collecting funding. So it's a legal entity that a corporation who wants to contribute can pay. Open collective will then be responsible for then distributing these two members of this open collective. You can put together whatever collectives you want. In the case of webpack, they kind of have their own offerings. Open collective makes it possible to have transparent budgeting. Open collective, in this case, they've managed to pull together annual budget of nearly half a million dollars, which is pretty impressive. So core initiatives through open collective then. It creates a legal and professional-looking front. Remember, at the beginning, we talked about it's all about optics. It needs to be presented the right way. We need to have a reliable team. Remember, we want to ship products and features with the best developers. We can get organized in open collectives. With telemetry, these open collectives can effectively become product teams in a sense and do iterative development and use the tools by open collective. And also, it's more like one of the challenges we had at Pfizer is it's been Pfizer, in a sense, building the software. We're taking on a very reputational risk. It would almost have been better if we could pay an entity to deliver features for it. This is what companies do all the time with IT projects. Pfizer doesn't build any software. We pay companies or entities to go and do that for us because we're in the business of improving patient's lives, not building software. So while we need to make, you know, contributing the best possible way of solving a problem and not go and build things ourselves, that's not what we're here for. And most user organizations will have exactly the same take on, you know, as Pfizer in this case. And then we talked about getting organized. This is what open collective provides, you know, simple finances, budgeting, et cetera. Some additional ideas. These are already partially at least ideas from the telemetry initiative. Of course, the telemetry data that we collect should be, you know, anonymous. And it should, of course, be possible to opt out your site from sending back data to Drupal.org. And I already mentioned it. We probably should have some sort of non-disclosure agreement with people who actually get access to this data so that it's not shared, open and public. That's my proposal at least. So that we create this competitive advantage for core initiatives to use this data in developing solutions for this. Imagine the admin theme initiative. Imagine if they had access to a million Drupal sites, clicks, heat maps, usages. You can see where people are struggling. If you want to build a better admin theme, any sensible organization would go to this team, because they will have all the data. It creates this good, very massive incentive to go and do the right thing. Briefly spoke about the fourth point as well. We should probably include module usage statistics, but I think we should be more granular than that as well. We should measure features, what widgets, you know, what fields are people querying in the JSON API? What types of fields? What are the error codes that JSON API sends back all the time? Where are people struggling? Where are people clicking and missing buttons in the media library, et cetera? So we should be granular. We could embed Matomo or previously Piwik in the admin theme to track user behavior. It's a controversial topic. As open source enthusiasts, we're not very keen on kind of privacy invading things. But this is how products are developed. This is how Adobe is competing with Drupal by doing data-driven product development. Arguably, we need to do the same to stay competitive. And here we can even create this competitive advantage for people who want to build features in Quora. And I think that we should combine telemetry data with user market research data. That should also be in the package of data that we give to Quora initiatives exclusively to use. Of course, if anyone else wants to go and do user research about Drupal, they're free to. This initiative would try to go out and do it large scale. We'd figure out good ways of doing that. And this would be, in addition to telemetry data, data that the initiatives would get. Imagine also coupling this with the automatic upgrades initiative. We ship the feature. We change something. We measure it. And then we were allowed an auto-upgrade and see what happens to user statistics. Did people use it? Did they not use it for experimental modules? We'd roll it back. We don't include the complexity if they're not using it. A-B testing, effectively. Be awesome. And that is pretty much it. There is 15 minutes left. So thank you. I'd love to continue the conversation if people have questions or feedback. I'm Dick Olson on Twitter. So yeah, thank you. What thoughts have been put into the privacy piece of this? I'm thinking in the context of GDPR and the new privacy laws that are about to go in place in California, for example. It's a very good question. It's something we'd have to be very, very deliberate about, of course, and figure out the best ways to do it. Completely anonymizing the data, I think, is absolutely needed. And should we use existing tools like Pwik? They are already providing GDPR-compliant features. We can ship that software, that library in a way that is GDPR-compliant. So that has to be first priority, of course. So we need to do a lot of thinking about this. By no means do we have a complete solution yet. It totally makes me nervous. Yeah, it does. But I think it's necessary. Thanks. That's really interesting. It's interesting to hear from a very different perspective on initiatives. I have one question and one remark. The remark is what the things you're trying to propose or trying to get off the ground are very similar to what Mike Meijers tried to do a couple of years ago. So I think the two of you should definitely talk. For sure. He used to be at Arcadia and now he's at Tech One. So definitely go and find him. And just to be clear, the telemetry initiative isn't my idea. I don't know if that is what. Sorry, I was referring to actually existing tools. Yeah, this one. I can't hear my own voice. It's kind of strange. No, he wasn't actually talking about the telemetry aspects. That is completely new and separate. But what he was trying to do is to get big corporations to fund certain pictures. And it was really hard to get it off the ground to get convinced. But it was different in that you're proposing to do it through Open Collective, which is something that didn't exist at the time. He was trying to do it through Acquias LSD, a large-scale approval program at the time. So I'm sure that the Acquia component makes it very different. But it was like a way to get it off the ground. I think this has a better chance for sure. But he probably has some insight into concerns that other corporations and Pfizer might find. So you should find him. The question I had is, so if you're collecting lots of data and I agree that we should be doing data-driven development and making future decisions like is this worth including or not as well, the interesting challenge there aside of privacy is that if only a certain team has access to the data and the team that makes data-driven decisions, how do they communicate to the community? We are making this decision because the data says so, but the community can't see the data. So how do you propose it? Do you have thoughts about that? I mean, just clearly explaining to the community that this team is doing data-driven development, that this team has access to high quality data would probably build a level of trust. I think that this team is just not guessing when we're shipping features, right? But at the same time, something doesn't get into triple core, generally speaking, unless it has test coverage and we don't trust, like, hey, does the patch is green? Trust me, I've written great tests. No, we actually require a patch to be posted without the actual fix and we actually post a test-only patch that should feel like weakly verified, basically. It's kind of hard to see for me at this right now. Just trust me, this button shouldn't exist. This feature shouldn't exist. That's a tricky thing. Yeah, I think in terms of test coverage, I think everything should always be built with full test coverage. But if the team is arguing, we need to move the button in this dialogue from here to here. Yeah, I think that a button location is maybe too trivial. An example of this is more critical aspects of a feature or of a product or of a module. Yeah. Like, that could be hard, too. Yeah. I mean, I think probably what does make sense is to always have kind of an outcome-driven, the team needs to explain, here are the outcomes that the data is telling us about or the outcomes that the users seem to be expecting. You can talk about the outcomes without talking about the inputs. So, I don't know. It's difficult, right? Yeah, absolutely. Thanks. Any other thoughts? All right. Thanks, everyone. Hope you had a good group who come.