 So, welcome everyone to the last session of DrupalCon, or almost the last one, there's still the closing session. Thank you for choosing this one. I'll try to make it worth your while. So for this session, I would like to talk to you about Drupal Contrib's commercial horizon, and about API integrations, and about GUIs, and about clickers, and about business models, and about conference budgets, like a whole lot of different things. And if I count all of the possible constituencies, I think there's four. So there's a lot of different audiences to cater to. So I wanted to just do a raise of hands, like who here is here because of community? Like who here is organizing community events, and is looking for more sponsorships? Okay, a few. Who here is from a Drupal agency looking for more work? Who here is looking for, who here has an API, and is like a SaaS owner? Okay. A few. So some overlap, which is fun. And then who here is a side builder, looking to learn more about third-party integrations and stuff? Okay. So that's a lot of different hats, daunting task. I've done my best to compile something that caters a bit to everybody. If there are specific questions, just ask me at the end. So I'd like to start with the problem. You see, because I think we have kind of a problem in the Drupal community, and it's this problem. We, when there's fundraising efforts happening, it's always the same people giving money. And it's never really end users, or very few end users that are contributing to our community initiatives. It's like for a few notable exceptions, the D8 rules fundraising effort, which was one of the biggest fundraising efforts for a code writing initiative, was mostly funded by developers. Basically one developer giving money to another developer, which is kind of weird. And then there were like, there were a few LSD members, large-scale Drupal members that gave the big bucks, but most of the money, I think, still came from the community. It's kind of, yeah, I don't know, it feels wrong, right? Because I think Drupal is a lot like air, water, and the climate. It's a public good. And as a public good, it has a free-loader problem, that a lot of people are benefiting from it, but not necessarily contributing to it. And it's a little bit risky, because as a result, it's possible that you get a lack of funding and a sea of value. Like a lot of people are getting an enormous amount of value out of a good, and there's not enough to keep maintaining it, and that's very risky. Now, I don't really like gloom-talking. I don't like punishing people. I don't like zero-sum thinking. So I think that ultimately, even if people are not contributing back, that probably should be okay. I think we just need to find better incentives, and we need to find other people that have an incentive for contributing so that we can keep everything running without having to do draconian things like, I don't know, dual licensing Drupal or something like that. So because, but it still, it opens up a really interesting question, because no matter how big the value that you're providing, if you can't create a differential, and I'll explain that in a moment, it's going to be financially irrelevant. This part is still the community part, the part for API integrations. Sorry, I don't want to make you feel uncomfortable. That's coming later. It's getting better. So we need to find out ways that we can create a difference between what you just get, and then a way to make people pay for the services that they're getting. In Drupal itself, that won't really work. There's been some efforts, there was even a talk at this conference about products and features, and about how we could build paying products just like the WordPress community has done, to API stores and all that kind of stuff. And there's been a lot of discussion about that, a lot of heated discussion, because a lot of people don't really like the idea. But I don't think we even need to go there. I think there's better ways. Because WordPress has already put a bottom price to that market. Like WordPress is the biggest, right? WordPress has what now, 50% of the CMS web, or no, it's an insane amount of installs. And they've built this whole app's ecosystem, like with vertically integrated apps, and I don't think that Drupal should try to compete against that. I think that there's better ways for us. We were in a different niche. So I don't believe that that is Drupal's true potential. Because Drupal is like LEGO. Drupal is a bunch of APIs that you puzzle together to build whatever you want and exactly what you want. And Drupal is kind of like a graphical interface in front of a bunch of APIs. That opens up a whole bunch of different perspectives and ideas and possibilities. So I don't think that we should try to be the app store. I think that there's other ways to generate value for our community. But then the solution. So how can we capture more value? How can we grow our community and make our community more valuable to more people? I think one really interesting place where we could do that is API integrations. Now for almost forever, well, not forever, like 10 years, that I've been running my consultancy, I was thinking about ways that I could build a product, like passive income, that whole story. I'm sure a lot of others here in the audience are thinking in similar directions. So I was always kind of trying to figure it out. And then you go through the list of all the open source business models that are there. And there's this one at the bottom there, like API integrations that always struck a chord to me because it felt really elegant, where you give away something valuable to the community that becomes a sort of carrier, a window through which it becomes easier to offer your services to that community and a sort of plug-in service into the community. I always stop. I had to build that myself. But maybe we don't have to. Maybe we can help others that already have built a successful API and successful SaaS application to extend their products to find their way into a bigger market, help them become more successful, and give them an avenue to give back to a community that gives back to them. So I don't think that we need to. I don't believe in just telling people, you have to. And why don't you do your part like this? Don't ask what your country can do for you. Ask what you can do for your country stuff. To some extent, that's true. But I don't think I don't really believe in that. I don't think that's the best way of playing things. I try to be an altruist. I enjoy being with altruists. But you can't force-feed altruism. That's something that has to come from inside. So how can we make Drupal more valuable? So like the multi-layered, I hope you appreciate. There went a lot of thought into the multi-layered Drupal cake. So how can we, if you don't look at products and features, but you look just at Contrib, I think we've been overlooking this forever, actually. Because the traditional value chain in Drupal is a customer pays money to a company or a consultant. A consultant gives money to the community to keep things going. And there's this linear flow where some of the value is creamed off, and then hopefully some ends up back in the community. But if you do it this way, there could be an alternative flow where there's mutual beneficialness where API companies and SaaS companies could benefit from our community. Because they already know how to make money. They already have a product. They already own. In most cases, some cases they don't. But in most cases, they've already figured out how to make people pay for their services. And just they haven't fully reached their potential yet, because they haven't found the Drupal market, which is, by the way, like now a million sites or something. That's huge. It's a really big potential. And there's actually already 3,000 third party integrations. I was really surprised when I first went looking for that. Not all of them are for API companies or SaaS providers. But there's a really big amount. There's one for what is it? Watson's, IBM's artificial intelligence service. They have a lot of downloads, like 70,000 or I don't know. There's quite some successful third party integrations already in the community. But why aren't they contributing more? And I think here we come back to the picture that I showed in the beginning of the waterfall, the dam. The value is already flowing. There's no extra benefit that they're getting from interacting with the community. Because people just use the module. They built the module themselves. Like some consultant does it for a customer. And then a bunch of people just use it. And in a lot of cases, SaaS companies don't even know that they're being used inside of Drupal. And I think that's something that we need to change. Because code is just part of the equation. Code is actually a tiny fraction of the equation. Because for the most part, if we want to make API companies and SaaS companies successful in our community, we have to help them with adoption. Now, I'm not advocating for hardcore marketing and sales. Because I don't think that works, not in a community. But there's other ways to do community-friendly promotion. And to show people that these are the organizations that are contributing to our community. So maybe we should give our business to them, rather to somebody else who is not maintaining their modules, who is not paying for their integration, who doesn't care about the Drupal community. And I think that we need to put those companies that are contributing to our community better in the spotlight. And we need to help them. We need to guide them towards more business. Because they need guidance. Because in a lot of cases, they don't really understand the Drupal community. Like, try to explain pre-note to anybody from outside of the community. A bunch of crazy people in Spandex is doing songs. And that's just one of the quirky things that we have. There's a lot more crazy things that we do. So one of the surest ways to waste your money is to send a bunch of salespeople to an expensive booth at Drupal God. That's like, unless your product is really, really fine-tuned and you've got great marketing, that's just going to be a waste. And that's really expensive. You have the wages, a whole week long, the flight tickets, the hotel, the food, et cetera, et cetera. Then the booth. That's 10,000, 15,000 for the smallest package. And then you're like one or two people. So we need to help them. And there's a term for that. It's called developer evangelism. I don't know who had heard about developer evangelism before. I know you did. OK, so every one third, one fourth, it's kind of like marketing. Don't tell them. It's kind of like sales. Definitely don't tell them. It's also a bit like engineering. It's kind of somewhere in between those three things. It's all of them and none of them. And depending on what business they're inside, developer evangelists will be doing their job in a slightly different way. But it always comes back to the same principles. And I've tried to reduce the amounts. Like these come from this book. So if you want to learn more about developer evangelism, this is a book that you can just order. And it's quite comprehensive. If you don't have the money, you can even just read it online, which is nice. Or if you don't want to wait for the delivery from Lulu. But it's very interesting how much this resonates with the way I know that or I've seen that things work in the Drupal community. So first of all, you remove brands. So this is not about selling your product. It is, but it isn't. So if you're just openly going to be promoting and just like buy my product, like nobody's going to buy. Well, no, some people will. But you're going to alienate the community. And nobody will want to play with you and work with you. So you need to find this very interesting balance where you're not playing a zero sum game. You're trying to build a bigger cake together with the other players in the community. And that's very different. That's most marketing and sales doesn't work like that. Most of the time, marketing and sales is a zero sum game. It's like us or the competition. And there's a limited amount of customers. And we need to get them all. So with developer evangelism is different in that it's softer. And it resonates better with community and community principles. And what does a developer evangelist normally do? They'll do blog posts. They'll do sessions. They'll do talks. They'll do cool stuff together with other people in the community. They'll do tweets, be part of bus campaigns. That's the book again. There's a whole community for these people. There's even events for them. Defralcon is a really nice one. I was in London at Defralcon. I couldn't make it to San Francisco. But there's going to be another one coming up in London again. There's a Slack channel. If you want to join that, just send me a message. And I can send you an invite. There's Facebook groups. So there's a whole, it's a different type of job with its own community. Now, so far, the problem, one solution. I want to talk a little bit more about the opportunity. Because I think, and this ties in really nicely with what Dries was talking about in his keynote, I think that I'm a side builder. I'm not a developer. I got into Drupal because I was able to leverage the configurations and the interfaces to do really complicated things without having to write code. And that was amazing. And I think that this is one of the key characteristics of Drupal. And Dries actually confirmed that. That side builders and people that do stuff in the UI are our biggest constituency. They're the ones that we should be building Drupal for. And currently, Drupal is kind of like a gooey in front of a bunch of internal APIs and then some external APIs through third party integrations. I believe that we could make Drupal even more of a gooey for even more APIs. And that we could actively pursue web APIs and artificial intelligence services and a bunch of other stuff to give them an opportunity to interact with a market and with their audience through the Drupal interface. And I think that if we do this right, there's a really, really big opportunity because APIs are growing like crazy right now. There's lots of reasons. Some of the biggest ones are that there's a deconstruction of the value chain. So like Amazon, where each department has its own APIs to interact with the other departments, this is happening everywhere. Every single Fortune 500 company is working on an API program today. And I think Drupal could get a part of that buy. And that's a big buy. And we could actually provide a lot of value for them. Another really important reason is that artificial intelligence is rising. And you can't run your own artificial intelligence service for your tiny little audience that just doesn't work. You can't train a photo recognition AI on your own data if you only have 100 pictures. You need global pictures, like pictures from everybody to be able to do that. So being able to plug in into a specialized artificial intelligence is another area where I think there's a lot of growth potential, where we could do some really amazing things as a community. So I think Drupal really is well positioned for that. I think Drupal could become a GUI for the API web. But even if you don't look that far, even today, there's some really interesting things that we can do for APIs. Now, people who have APIs from SaaS companies, this is your queue. So we've been doing a few integration modules for different companies. And what I want to do is to show some examples of what we've done and how we've done it and what the benefits were of that. So one is a Context.io. Context.io is an API. It's a RESTful API that sits in front of email inboxes. So what it does, it makes it simple to query an email inbox. So if you're a developer, that's really awesome, because you can just write a query. And no matter what inbox is on the other end, it just gets the data out. But it's like if you're not a developer, you're out of luck. So what we've done is we've built a module for them. It's called Context.io, obviously. And what it does, it uses Feeds UI to query mailboxes. And it's kind of handy. Cool thing was that we won the app challenge from Context.io with this module. They even gave us a lot of money for that. Because they believed in the value of a prototyping tool, like a tool that clickers, people that don't write code, would be able to use to experience their API and to do stuff with it. And it's really powerful for prototyping. We've actually been approached by companies that wanted to use it to test out how they could use, how they could build an extension of their product that got data out of the email inboxes of their customers. There's, I think, this really cool module. There's not too much downloads yet. So we have some more work to do on the developer evangelism side. It might also be that this is more for consumer apps. And then maybe that space is a little bit harder. But this is one example where you basically can build a GUI that makes it easier to prototype against an API. Another example is Brightcove. Brightcove is a video hosting company. To my knowledge, they are the only company, the only video hosting company, that actually sponsors their module. That actually, I was going to say cares about their module, but probably others also care. But they're the only company that actively supports the community. Like here, the keynote that was recorded and streamed, live by Brightcove as a sponsor. And they've been doing this for years. So they really get this interacting with the community. But they get more out of it than just exposure to a really important audience for them. Because the websites we built, a lot of them use video and could use Brightcove. They've also been working on making their APIs so that you could use Drupal as a front-end for their APIs. And the cool thing is that then you can really, first thing is that you can then just upload your video right in the interface. So if you want to upload a video for a blog post, you just do it inside of Drupal, which is kind of cool. But it also allows you to heavily customize the UI, so that you can build custom workflows or add your own metadata. And it all gets synced back to Brightcove. But Drupal is the front-end for that. So we've done that in Drupal. They're also the first video module to have a Drupal 8 module. So yeah, I think that's pretty cool. But just to kind of blow up, this idea blew my mind when we first started talking about it. You could imagine using Brightcove plus Clarify, which is a captioning tool, plus Lingotech, which is not a bright spot in our community. Like, Lingotech, they've been doing developer evangelism really well. They're on pretty much every Drupal camp. They're almost always a sponsor. And I think they've been benefiting from that very well in the community. But if you would combine these three services and, well, the connection with Lingotech isn't done yet. But then you could just upload a video, get it captioned automatically, get the captions translated automatically, and just have multilingual video out of the box. And that's awesome, right? And the cool thing is that you do that through Drupal, which becomes a sort of system integration interface between these different services. So yeah. Also, this has been very good for Brightcove. They've tripled. Since 2013, they tripled their installs. So people, like, this is an enterprise video hosting. So it's not for a small blog where there's no business. Like, you wouldn't use Brightcove. You'd probably use YouTube or something. So they normally have the higher end customers that require high availability and the ability to put ads in and all of that stuff. But they've tripled their install base in the last few years. So this is actually working for them. Another example in here, and I think it's interesting, because I don't know if you do know the term whole product. Have you heard of that? It's something that comes from, I think it's from Lean. Wait, what is it? From Crossing the Chasm, that book. Maybe it's a few if you have read it. It's this concept that when you build a new product, you might put a product on the market. But in most cases, that's not the whole product. It's kind of like Acquia. Acquia needs Drupal shops to customize the sites so that they can be hosted. And they don't provide the whole product. They don't provide all the services for you to be successful. You need all these different players to be successful. So in Apigee's case, Apigee is an API management company. And for a few years now, they've been using Drupal as the basis for their developer portal. Funny enough, they have, I think, a few hundred developer portals in some of the largest companies worldwide that are built in Drupal. And they use that so that their customers could customize the experience, the developer experience, that developers have when they go and get their API keys and they learn about how an API works, et cetera, et cetera. Now, their developer portal used to be something that you couldn't just get unless you were a customer or you were starting to explore working with them. But yesterday, I got an email that they'll be working with us to open source their developer portal and to bring their modules to Drupal 8 and to, well, normally, and then to basically do that in the open so that this becomes part of Drupal ecosystem. Because they're already using Drupal. They're already part of the community, some extent, but not really integrated in it. And I think I've been convincing them, so my pitch has been that it's not enough, well, OK, having a module in Drupal and using Drupal is great, but they're not getting the full value of Drupal because they're not getting the market value. There's lots and lots of people that are building APIs, that are looking for API solutions, key management, et cetera, et cetera, inside of Drupal that they could be reaching with their product. And they already have one leg up because they're already in Drupal. So yeah, so that's something that's coming. Last category, you don't necessarily have to start with building an integration. This is something that we've done for a few API companies. Where basically, we start with a blog post to validate if there is a demand for an integration. And to start, maybe, find allies that might be interested in an integration. So iText is a PDF library in Java. And OK, I know PDF, Java, a lot of you are like, ooh. But PDF is still really big. And the founder of iText, I was talking with him, he had this really interesting way of pronouncing it, where he said, PDF is dead, long live PDF. And what he means with that is that PDF is kind of like a digital envelope to put content in. And to ship content, to even provide shippable forms, a lot of really interesting things that you can't really do in another way. Also for long-term storage, governments are using PDF to package all the tools and the letter types and whatever, so that in 20 years, 30 years, those digital objects will still be accessible. So yeah, just to say that PDF is still very important. Now, one thing that we've been looking at is could we find a market in the Drupal community for something like Apache Solar, but for PDFs, where there's a demon that generates PDFs that you interact with through an API from your Drupal site, and there's a Java demon that then generates the PDF files. You could make accessible PDF that way. So like for government and so on, I think it could be very interesting. But the verdict is still out. We're still running the experiment. So we've done a few blog posts about that. I did that one with my son. That's his work. And we've also done something similar for PySync. PySync is an identity synchronization company. So they're big in small and medium-sized companies, like mostly small companies that want to synchronize account data between different systems. So you have your site, and you want to get the contact details into Google contact or something, or into MailChimp or something like that. Also, that is still the verdict that's still out. Now, these were all examples from our company, but there's a few other brides. Well, OK, I don't want to trump my own horn too much. But there's other companies that are doing similar stuff. Think Shout. I would like to shout out to, because they've been doing the MailChimp integration, and they've actually done this long-standing partnership with them to get them more involved in the community. Gold Gorilla has done the same with Yoast. I really like the way that they've been engaging them and bringing them into the community, having them at events, helping them be a good sponsor at events. So there's a few other bright spots. But very few other companies have taken this approach. And that's why I wanted to do this talk about it, that when you build a module, OK, what happens most of the time is that a consultant has a customer. They request a module. They need some sort of integration. Most cases, that's where it ends. Some cases, they might send an email to the company for whom they did the integration, like, hey, we did your integration. Don't you want to pay for it? And that's about it. But the discussion is completely about code. There's no promotion. There's no adoption or sales or marketing or any efforts to actually help them be successful are never mentioned. And I understand because it's expensive and it's hard. Like writing blog posts, yeah, we have now a technical writer team in the company. But that takes a lot of effort. And it's expensive also. So if you're a smaller company, if this is not your core focus, you can't afford doing that. So we've been thinking about how could we make it easier for other consultancies to, when they make an integration module, to help bring those API companies more into the community. So how can we help SaaS companies to be more successful in the community? And this is why we're still working on it. But we're launching a new initiative that we call the API Alliance. And the idea is that we would basically become sponsors for events, but not with one company, not with our company, but with a group of companies. And we would go to, well, it's a short day. So if you're an API company and you have a Drupal integration and you would like to be at a Drupal developer days in Milan in two months, contact me. But to make it cheaper for API companies to be at developer events. So to cut those costs of sending your own people, cut those costs of being a sponsor, cut those costs of marketing materials and all of that stuff that normally, that can mount up to a lot of money, and to make it really inexpensive to go to events. And to also have people at events that are developers, in first place, that probably will be our developers. But in the long run, I imagine that we could maybe have people that have been volunteering time to write certain modules, maybe even students or whatever, that we sponsor her to come to DrupalCon on the budgets that we get from these API companies. Meanwhile, reducing the total cost of having someone at a booth who actually knows what they're talking about. And splitting the cost between a few different providers. And then also being able to buy a really expensive booth, or one of the bigger booths. We are now thinking about trying to get a platinum booth at the dev days. Still a bit shaky because it's short term, but we're working on that now. Other things that we're working on, together with the Drupal Association, I've been talking about doing a clickathon in Dublin, which is a hackathon for clickers, for people that do stuff in the GUI, where site builders would be able to build business applications just by combining a bunch of APIs and the modules and doing cool stuff. An API clinic could be something that we could do where you could go with problems about integrations that you have, or if you have specific questions. Kind of like all these things that make it, that provide value to sponsors, or to API companies, so that they can be more successful, have a bigger reach, be more visible, while spending not crazy amounts of money. And everybody benefits because the events get more money, developers have a reason to ask for a contribution, and the community can grow. And we can get more features into Drupal, and have a bigger, broader, expanded product. Another thing I'm thinking about is ClickerCon. ClickerCon is something that I've been brooding on for a while, and I haven't bitten the bullet yet, but someday I'll do that, which is basically an event for site builders, like a no-code event, Drupal Uncoded, is how we're thinking about calling it. And that's the API lines. If you're interested in this stuff, if you're a developer who would like to be part of this initiative, if you're an API company who would like to hear more about how this works and be getting emails when we're gonna do a booth at some place, or generally interested in this sign-up, this is a newsletter, we're also working on a white paper about the Drupal market. So what is the market opportunity of Drupal? How big is it? Who's already in there, and what can you get out of it, and how can you interact with the community? All of this stuff, all of this knowledge that is kind of obvious for us, but really, really alien for marketeers that are trying to get into the community. So making, and that's gonna be good for us, because they'll know how to interact with us in a way that is community-friendly, and they'll learn how to help contribute to the community so that it's not a zero-sum game. Because I've been, I get quite a lot of emails from companies about like, hey, don't you want to use our product? And normally that doesn't really work. I like same with, yeah. I like seeing community engagement and involvement. So key learning points from the stock. API integrations are, I think, a really big growth opportunity. I think we can grow our community and grow the value that we provide to the people in our community and to the API companies that are trying to interact with us. Drupal could be a great GUI for the API web. You need more than code to be successful. It's kind of obvious, but a lot of people don't think that far. Most of the time it's just like, throw your code over the hedge and that's it. But I think a really important one is that Drupal is a really valuable market. What I mean with that is, like currently, if you look at the CMS market, Drupal and WordPress are in the lead. And like normally any market, normally there's always Duopolis. There's like normally two market leaders, like one really big one. WordPress is becoming that. And then another one that's also really big. Now, both of them are catering to different cases. But I think that for the foreseeable future, I think that those two are gonna be the leads of the CMS market and that's a huge market. It's also, and I didn't talk about that here because time is kind of limited, but I think that it's also a really good way to get your product into the market or because we are a community of consultants that are all over the world. And we're everywhere. We are often in a lot of different companies. Someone in the Drupal community has contact with every single multinational, like several people have. So there's, Drupal could be a very good vehicle for introducing products into the market and for driving growth. Traditionally, developer evangelists look more at developer languages, like PHP and they'll build a PHPHCK or something like that. I think that for a certain class of APIs, Drupal could be a better vehicle for getting into the market. And that's my talk. Thank you very much. Who has questions? Yeah, probably we should. Yeah, I can repeat your question. I'll do it for you. We can do that next time. We'd gladly do that. We talked a bit about it. I think it would be great. Yeah, good. Other people? More questions? I know it's late. We're all kind of like hangover from too many hangovers. Yeah? Yeah. Yeah. building that site on Drupal, and there's an API service that does our voice, so we've got Jareng here. So Drupal, they're only going to do services at that point, there's deals and green markets in. Well, I think the key is there that we need to show how big the opportunity is. Because in a lot of cases, yeah, people don't really know how to express that. And I think that they're like a joint marketing resource could be very valuable. So that's something we're working on. And you're right, the eCommerce, I know that eCommerce guys did a lot of third party integrations. They also did an interesting thing where I think they have like an affiliate sales deal with those integrations, which is different. So there's possibilities to do that kind of stuff. You don't just have to ask money for the integration. Other questions? So the question was, how do you convince API providers to put money in an integration? It's hard. I think so far, it's like with all forms of sales. This is a sales question, right? Like how do you convince the other of the value of what you're trying to offer? So you need to make the case. You need to show what we're doing, like the I-text and PySync. We basically did a test, a tester, and we've done this also for Dita, for building a Dita CCMS, that we create a blog post, we have a questionnaire on it. And then we just measure how many people sign up. That's one thing you could do. But then, yeah, you need to get in front of enough people with that. So maybe you need to do something more involved. Maybe the API lines could do that. It's like, would you be interested in Service XYZ if it would have a provider? Maybe that could be, that's a good idea actually. But it's a sales question. And that's really weird. Salesforce is such a weird case. Like they have so much potential value in Drupal, and they don't have, yeah, I don't think that they're contributing to that, which is really weird. I might see some of them in two weeks. But yeah, some of these companies are just really hard to get into. And some of them are like, you know, like Google and YouTube. Why should we? Everybody's already making integrations. So why should we spend money on you? It's a little bit hard. Other questions? Okay. Then thank you very much. It was a pleasure.