 Are you ready to start? OK. We're going for it. We'll just let the stragglers come in right. When the door is right by the stage, it's always a little embarrassing for them. That's good. See? Yeah, plenty of room. OK, quick show of hands real quick. Just trying to understand who's in the room a little bit. Are people here because they have built a product and they want to know how to sell it? Raise your hand. People are here because they haven't built a product, but they kind of want to. People are here because they don't think that Drupal products are a thing. That's right. Any other things that people are dying to learn, hope to gain, things that I can tell you, whether you're going to learn that or not, you can decide whether you want to stay. Any ideas, thoughts? OK, we're getting it started then. Hey, guys. Those are my colleagues. So I'm Karen Bortchard, and I'm with Phase 2. And this is Robert Declis. He's with Commerce Guys. And this is our third product talk at AdrupalCon. We really enjoy talking about products together and about the possibilities. And today I am going to work hard to shatter all of your dreams about products in Drupal. And then Robert is going to do his best to build them back up. And that's why we work well together. So we're just going to go ahead and jump right in because we think we have a lot of slides here. So we're going to talk a little bit today. Hold on. Let's see if I did it right. Nope. All right, good. Oh, I better turn it on, right? Just turn it on. All right, I can click. Just click. Just click. Here we go. So here's our little agenda. We're going to talk about the open source product conundrum. And then we're going to talk a little bit about how to really make it work. Thanks. We're going to talk about choosing a business model, deployment, and maintenance, taking money from customers for a Drupal product, and the concepts of marketing and support. So I'm going to start, and then Robert's going to get to all the really fun stuff. So why are we here? This is a session about taking a product to market. We promise to leave you thinking about your Drupal business adventure. And that is a lot more than if you build it, they will come. Building and bringing a Drupal product to market is not just about building a great module or a great distribution, and then hoping that it's going to make you a billion dollars if it was. That would be a lot easier. So we like to start with the basics here. What's a product? You can't have a discussion about products in Drupal without really understanding what we're talking about and what we're not talking about. So we're going to start with a talk about just what a product is and what a Drupal product is. So a product, as it's basics, like to get everybody right on the same page, right at the ground level here, a good idea, method, information, object, or service created as a result of a process and serves a need or satisfies a want. It is a product is going to be something that allows you to do something and solve a specific problem. Not that specific problem. He didn't like this session. So what's a Drupal product? In open source, things work a little bit differently, right? So in open source, we generally build tools and tool kits and not traditional products. And that causes, come on in guys, plenty of room. Down in front. And why is that? Because in open source, tools and tool kits are more conducive to contribution and extension and open source goodness. And that's why we build them as tool kits. In Drupal, products work a little bit more like IKEA. And so rather than buying a table, an IKEA, you build a toolkit to build one. That's what you're buying, and that's the product that you often see. So you have all the right pieces, you have all the right instructions, and a lot of the hard thinking about how to put those things together is all done. But you can definitely make a table out of it, but out of the box, you're not buying a table. You're buying a kit to build one, right? And that's very often how products in Drupal really work. So when we're talking about software, most buyers are thinking about what they get out of the box. They're buying an intranet, they're buying a website, they're buying a specific piece of functionality. And in their minds, tool kits are not products. And that causes a real challenge in our world because what we've built and what we think of is something that we feel like this is a product, this is an intranet and a box. This is a website ready to go, but it's not really right out of the box that way most of the time because it's open sourcing, because it's a toolkit. I like to give the example of one of the ones that we actually use in phase two. So Open Atrium is a distribution of Drupal. You might know it. Question is, is it a product? You know, people will tell you this. This is the way we talk about it. You hear this a lot. It's an intranet and a box. It's a community portal, but it's all open source. You can use it instead of SharePoint. And these are all of the things that make it feel like it's a product, right? So, you know, and you start to see the use cases for it. You start to, you know, you can, you see these cool things built on it that are these intranets and portals and, you know, learning systems and citizen connectors and all of these great things. And you think, yeah, it's a product. This is a great product. So you download it and you're like, yay. And then you get it open and you're like, what? And that's a challenge, right? And the reason, but it's by design. OpenHRM is built as a toolkit. It's built as a platform that we're building on top of and that you can use to build all of those things. It's a toolkit. It is here to build a collaboration tool not to be the thing out of the box. And people use it in a lot of different ways, which is awesome. Sometimes people build, you know, the basic use with something like OpenHRM and sometimes people configure it a little differently so it serves a slightly different use case and sometimes people put a really beautiful theme on it and make it into a really beautiful intranet. And sometimes people do stuff with it that we had never imagined. And sometimes that functionality serves different purposes than we imagined. And sometimes they go nuts. In case anybody has not seen this hack, it's a great one of that same coffee table in Ikea. Taking all of the toolkits and all of the parts and envisioning something completely different out of that toolkit than one can imagine. And that can be a really powerful thing, right? Like that's what's awesome about open source. This is a great thing, but one thing is really challenging with that. A table is not a bicycle. And so when you get to the point where you're selling this thing that you've built, you have to ask yourself, are you selling a table or are you selling a bike? And the question of which use case you're solving and the buyer experience of knowing what they're buying out of the box becomes something that's really important to the buyer. And when you're talking about building a product or taking a product to market, what your customer thinks they're buying is extremely important. So even though you can use this toolkit to buy either one, the person that you're selling a table and the person that you're selling the children's bicycle to, it's likely not the same exact person or the same exact customer. And it's really important to understand really what people are going to use the toolkit for and how they're going to use it and who you're selling it to and in what way. And that's the conundrum part. The very thing that makes open source awesome is what makes our products really difficult to define and deliver and sell. And that has been a problem that has plagued the idea of products in open source and in some ways products in Drupal for a really long time. It's why this is the third talk we've given about products in Drupal. So we try a lot of stuff, right? We will say, okay, all right, toolkits, not products, I get it. Okay, cool. What if I do my toolkit, my module, my distro and host it? Then it's a product, right? Not really. It's really just a hosted toolkit at that point. And they say, well, what if I put a really cool theme on it and maybe add a little demo content? Then it's a product, right? So it's a toolkit, hosting and theme and it still doesn't quite feel like a product, right? And really when you're getting close to it, it's really when you're adding in a lot of things. Toolkits and hosting, services, and automation and content, and then you're getting closer to a product. But what you're really looking for is how you're gonna solve the problem for the customer and which problem you're going to solve for the customer. So making an open source product is about doing what's needed to start solving a customer problem on day one. And that's really what it comes down to. It's not really about hosting or services or configuration or themes or any of those specific things. It's about what do you need to do to this toolkit? What do you need to do with this toolkit in order to make something that starts solving a customer problem on day one? So why is this a good thing? Why even bother with this? Cause this seems like a lot of work and it is. Making your toolkit into something more usable out of the box gives you the potential to bring it to a lot more people. And that's great for you. It's great for Drupal. And it can be great for your business too. The market is demanding open source alternatives to proprietary solutions. That's why Drupal is growing. That's why a lot of us are here. That's why this conference is bigger every year. The market is asking for open alternatives and the ability for us to build them and deliver them in a way that is still open is really, really powerful. That's a defining function for us in the market that's really amazing. Come on in if you want. And then products provide a different opportunity for revenue and profit. It's a different way potentially of selling your goods and services and in making that part of your business model and part of a more diverse business model. So products can be a really great thing but it's really about four things. It's about understanding the value that you add. It's about understanding your market. It's about understanding what you're really selling in your business model and it's about understanding then how to put that all together. How to take that value to that market using that business model and putting those things together. So now that I have told you about how difficult products are or how you can think about them in a little bit different way and that there is a bit of a conendrum here. We talk a lot in Drupal and around products. A lot of the questions that come up is how would you actually do this? And when we were in Austin at DrupalCon, Robert and I were talking about this and we said, why don't we talk about a session that really just shows how you might do this? How you might actually go about doing this? So like I said, my job was to kind of explain the basics around the product. Robert has a great one option for how you could actually do this. So let me turn it over. Thanks, Kara. So the takeaway for me from what Karen just wonderfully presented is that the work that you have to do as a product owner before you can even think about having a SaaS offering whether you start with open source or not is massive. And we're not talking about that. You've got to find your own market and you've got to find your own SaaS offering that makes sense, fills in need and will make your customers productive from day one. And once you've done that you might choose to use Drupal to build it because of some of the unique properties that Drupal has. So let's get on right with that. Why would you choose Drupal of all things to build a SaaS product? Because it probably is not the most likely choice. In a SaaS product, you don't distribute the code base necessarily. So you might just choose to build something from the ground up with a really slick framework like Laravel or maybe a Ruby people or Node.js people, or you wouldn't be at DrupalCon if you were. But you've got all these different options for making really custom code that does one thing really well and why would you not do that? For me, the reason you wouldn't do that is because Drupal presents an opportunity to make a SaaS offering that has a level of flexibility in it that can't be achieved if you do something specifically custom-made just for the one purpose, okay? And to understand what that flexibility is and why it's important, we have to talk about the difference between a multi-tenant SaaS offering and a single-tenant SaaS offering, which is a bit of a new model. So when we think about the granddaddy of all SaaS offerings, Salesforce, what we really have there is a multi-tenant offering. Somebody told me that Salesforce database has two tables and all of the customers and all of the applications and all of the software that runs on Salesforce, including force.com, somehow put all of their data in those two tables. That's what I heard. But the point is all of the customers who use Salesforce are basically running the same application, the same code, and they're putting their data into the same database. Same with Facebook, same with Google Apps. Those are all what we call multi-tenant systems. Now the problem of a multi-tenant system in Drupal is that if, unless you're building a social network where your users and your customers have to interact with each other, and that wouldn't be for a project management tool, so let's bring some examples into it. Basecamp, you sign up for Basecamp, you want your organization, your people to be on Basecamp, but my organization wouldn't necessarily need to collaborate with Karen's organization. So when she logs into Basecamp and when I log into Basecamp, we see totally different things. Those are still usually done when Basecamp does it in what we call a multi-tenant situation where all of the organizations, all of the users, all basically hit the same application and the same code base, it just divides everything up. So we see the right thing. That's not where I see the opportunity for Drupal. I see the opportunity for Drupal in something that is what I call a single-tenant SaaS offering. And the quintessential example on the market right now today is Drupal Gardens. When you sign up for a Drupal Gardens site, it hits the same code base, but that's inconsequential, but you get your own database. Your database is actually segregated from everybody else's data and you can export your entire site and take it away. So that's the open-source SaaS model that Drupal Gardens actually pioneered, and it's a very interesting model. And I think that the thing that Drupal Gardens got right in that is the single-tenant aspect because it's therein that the potential for customization and flexibility lies that would differentiate a Drupal-based SaaS from just a normal SaaS that you built in Ruby or PHP or whatever, where you never distribute the code and you just build the code to do exactly one thing and that's what your product is. Okay. I think I'm confused about what people are seeing versus what I'm talking to. Your people can see that one. Okay. What did I just talk to you? Okay. So I showed you the single-tenant site. Good. Fine. So, you would build a SaaS on Drupal for two reasons. First, you build a SaaS to control the product. Okay. Software as a service means you don't give your customer the code. It means you control it for them and the reason you would do that for them aside from commercial reasons of being able to charge them to have access for it, which is the commercial model somehow, the reason you do that is because you control the experience so thoroughly. You provide the features for them and you can provide it to a lot of customers at once and you basically assume that at some level your customers are going to use the features you give them and build for them and that's what Karen talked about. You've got to think really hard about what those are and get that right. But you would build that SaaS on Drupal because of this flexibility and that comes in the ability to have the SaaS but maybe possibly offer the ability for your customer to have custom themes or even custom modules which open the door for custom integrations. So there are lots of ways you could do that. A Salesforce Shopify, for example, will provide integrations for you that you can use but they don't really let you say build your own integration to your own ERP that they've never heard of that they're not interested in. So they don't open up the world of code to you to go in and hack around in any way because that's too dangerous to them because they're essentially a multi-tenant SaaS and you could break the experience for everybody on it. So this recipe that I'm going to go through now really quickly about SaaS in a box focuses on several things. So first of all, we said in the session description that we've got a prototype for this and I'm going to let you on that the prototype in my mind is exactly what Commerce Guys has actually built in the marketplace site that is like the checkout experience and the CRM and then the platform hosting site that you get when you sign up for platform.sh. So you go to Marketplace and you sign up for your site and then you get pushed back to your platform.sh and the whole workflow about customizing the product going through a checkout and at the end of the day getting redirected to what you've just bought is what I'm talking about. So in Drupal world you'd run a site that says hey, this is my product, come and buy it, you'd have a checkout, you'd give your credit card and at the end of the day you get bounced off to what you just bought which is your Drupal website. Let's say Open Atrium but made more into a product than a toolkit. So that starts with a customizable checkout. So the first part in the recipe is that I'm very squarely talking about Drupal Commerce because in Drupal it's the very best option for being able to define all the features that you want. Okay, do you want a CRM feature? Do you want a blog feature? Do you want to be able to send emails? Do you want to be able to upload large files? Whatever the features of your product are and that varies very widely from product to product so I can only generalize but you're definitely going to want to start with Drupal Commerce. Okay, stick in the mud, that's the starting point. Now after you've gone through the Drupal Commerce checkout my next major point in the recipe is that you want to be able to build a single tenant SaaS product for that person that's customized based on the choices they just made and I would recommend that the solution that you choose can do something similar or equivalent to what Drushmake gives you in building sites. So what I've got here is the ability to specify your upstream distribution. I used Commerce Kickstart as an example with a module here and a module there. Those could be the checkout features that they added in the cart as they were checking out and when you specify this that should be enough to provision the entire software as a service experience for that customer. So the idea is that they check out, they've got a list of features, it builds Drushmake file or something similar and it goes and builds a site according to their customizations. And mind you, this is exactly what we've already built at Commerce Guy, so I'm giving you what we've done as a prototype. So the power of that is that when you've got that Drushmake file and several different up source streams of code you can do the distribution yourself but you can get a theme from GitHub and think about what that gives the customer the ability to do. They can either maintain their own theme or they can hire an agency to do the theme for them. All they need to provide you is the GitHub repository, push commits to GitHub and it appears in their SaaS. You can put bespoke code in that repository so maybe one of the upsells for your SaaS customer is that you actually customize their SaaS experience that combines the benefits of a SaaS where you deploy features to your entire user base at once and you lock down a portion of the experience but you still retain the extensibility and the customizability of your agency business because you've got an organized way to mix the upstream product code with the bespoke code and maintain that going forward. And it also allows you to do what a lot of Shopify's and Heroku's have done and that is to build a thriving partner marketplace where partners can provide stock components known to work with your product and they can easily be integrated into the build process of this single tenant SaaS just by putting a single line in the Drushmake file. So Drushmake is definitely your friend. Here's, it's a little bit hard to read this black and white but down here what I've done is I've taken a potentially private GitHub repository and I've included into the Drushmake file and only single tenant SaaS would allow you to do this to take a line like that in a Drushmake file, build an application that's pulling code from GitHub into your SaaS application and you have a reasonable guarantee that it's going to work. It's more reasonable in Drupal 8 with Twig than it is in Drupal 7 because Twig runs in a user space sandbox so you can't make horrendous PHP mistakes and take the site offline because you missed a semi-colon. So I see even more potential for this model with Drupal 8 than I do for Drupal 7 but even with Drupal 7 as long as you can trust the person committing to the GitHub repository that's providing that theme then this would work. So how do you maintain a system like that? Let's say you have hundreds or even thousands of customers on that. What happens when it comes time to update that? Well, this is really nice. You could actually make it so that you only have to change one line in your Drushmake file and that would trigger the rebuild of hundreds or thousands of sites with that new code. So as long as you've got, say, for example, Commerce Kickstart is core and no version specified then all you'd have to do to update your entire SaaS infrastructure is release a new version of Commerce Kickstart on Drupal.org. Poof, done. And if you want to be a little bit more precise about it then all you'd have to do is specify the version number and then you'd only have to edit the version number in the Drushmake file and then you'd upgrade all your SaaS customers to that new version, say, of what you see as what you get module. Oops, too fast. So there are some examples. Call out to Ronald in the house. So he's got a product over there. You can talk to him about his thoughts about this after the session if you want but he's got a product called RUMIFI, CASA. And this is a great candidate for this type of model. So it's a very specific product. It's based on open source tools and it would love to live in the cloud with all its checkout options and be able to get a site provisioned for a hotel at the click of a button with all those options. Another one who's doing exactly the same thing is called Indiviso. That's a company out of Hungary and they run a software that helps you do HR with video interviews and they also do single tenant SaaS where they provision an entire SaaS site for each customer. So they've got this flexibility as well. Another one who's doing this is CanU.be. There's a Spanish squiggly thingy on the end so it goes CanU, it's a cute name. And they provision sites for the Flemish government and the Flemish government comes and signs up for a website and they get a SaaS website but it's single tenant SaaS which allows CanU, the company to either do custom integrations and customizations themselves or hire somebody to do it for them. So that was the deployment and building part of the recipe but there's a really big part of the recipe that I haven't talked about and that is the go-to-market recipe. So this is what I only realized recently is probably holding Drupal SaaS back more than anything else is that this part's really hard and there weren't really tools until recently. So you need to be able to take money from customers and you need to be able to do it regularly every week, every month, every year and you need to not have to invoice them every time. They're swiping a credit card or giving a bank account number and if you think about a whole bunch of different SaaS business models you're going to run into all sorts of things like AWS who bills you at the end of the month for what you've used and you'll find other companies that bill you 50 bucks a month starting the day you signed up if you sign up on the 17th they'll bill you on the 17th next month, 50 bucks every time. There are different models called prepaid, postpaid, prorated, that's how much you use and you need to be able to support all of those to have a healthy variety of SaaS products represented. So you can do that with existing Drupal commerce tools which is why I said at the beginning, use Drupal commerce. You'll want to look at the commerce license and the commerce license billing suite so I'm putting the module names over here. What that allows you to do is what I put over here is put a license for usage on things like files, roles or different content. Those are Drupal concepts that you can then make people pay for or you can put a license on an add-on feature like the blog functionality or the ability to submit help desk tickets. So if you want an escalated SLA, an increased SLA you give them a license to submit Zendesk tickets. If they need 15 gigabytes of storage, that's a license and if they need to buy services from you as part of the customization for the flexibility that's also a license and those modules support all of those concepts in conjunction with the prepaid, postpaid and prorated billing models. Once you do that though, you'll find you need a payment solution, a payment solution like SagePay or Stripe that have vaults that keep credit cards safe, credit card numbers because you never want to store credit card numbers yourself and they give you a token that you store over time so that you can make recurring charges at the end of each week, at the end of each month, whenever. And there's a list, if you look at the list here, what I didn't put here is card on file. Okay, that's actually a module to commerce card on file. I should have put that, that's a mistake in the slide. Just make a mental note, start at the commerce card on file page and you'll see this list as compatible payment solutions. But that's not even enough and this is where the recipe starts to be complex if you were to have to build it yourself because credit cards often fail. What do you do with a customer when their credit card fails to charge? It's kind of like dating, you make a proposal to somebody and you either get a soft or a hard decline. A soft decline is like being pushed into the friend zone and a hard decline is get out of my face, perv. It's the same with credit cards and Dunning will handle the workflow for first emailing and contacting people, admonishing them to update their credit card to try again, we're gonna try again in a week, we're gonna try again in two weeks, oh, we're cutting you off and it manages all that workflow and there's a whole flow chart that takes care of all the possibilities and all of the error codes that can come back from credit cards. Commerce Dunning, that stands for delinquent user notification, Dunning. Then you also need to be able to invoice. If you had to write that yourself, that'd be a lot of work. Thank goodness there's Commerce Billy that generates PDF invoices that you can customize theme mail to people and they can download them from their purchase history. You need all that. Now at Commerce Guys, we also need a way to stimulate the market for our SaaS product, which is our platform.sh hosting and we created with the use of commerce discount, commerce coupon and commerce voucher modules, a cute little credit card system. I think I've even got one in my pocket here. They look like this and I hand them to people and when they put that code in, they get 30 euros off, $30, 25 euros off of our service so they can try it for a couple of months without having to pay and this is a market stimulation and I can do great things with that. If I've got five sales guys coming to a convention, I can give them a hundred of these cards each, make a note of the numbers and track the ROI on their sales effort at a conference one month, six months, one year down the road. If we decide to go to all the Drupal camps in Germany for a year, I can look back and say, oh, all of those vouchers I've put at Drupal camps, they generated me this much revenue, I spent that much on Drupal camps, easy decision to make whether I do it next year. So you need things like that and commerce provides them. So that was the very quick recipe. I hope I left enough time for Karen, but that was the recipe for commerce SaaS, so SaaS business in a box. It all exists, it's all on Drupal.org and the living, breathing prototype of it is the platform.sh hosting service that commerce guys built. However, that's still not enough for you to be successful with your SaaS products so Karen's gonna tell you why your dreams still have to be dashed a little further. And there's all of these things that now exist in Drupal and exist in this ecosystem to support this kind of work, like this is really possible and that's super exciting to see. So just kind of bringing it back to your business model and what you've chosen and the customer you've chosen to reach. There's some really, there's some good things about making sure that once you're starting to build these things out and do this, you know how to market your product and that's really four things. It's sell what you're really selling, build out a market analysis, master the dark art of pricing and understand the investment that you're really making here. So we're just, we'll go through them really quick. So sell what you're really selling, right? Are you selling table or are you selling a bike or are you selling your time? And as Robert showed, the ability to receive payments for and take payments for all of those things is quite possible in a system like this. So the ability to say, yes, you can buy a bucket of hours from us or you could buy a custom theme from us or you could buy, you know, you could get a license to this are all possibilities with this kind of system and that's in knowing what you're really selling and selling what you really want people to buy, not just what you think it should sound like is a really key element in selling a product like this. Do some market analysis. This is some very basic market analysis that we did in cartoons for Open Atrium and just to start to get our heads around who was in the different landscapes that Open Atrium was playing in. If we were going to start building intranets or collaboration tools, we wanted to know who else was collaborating out there, collaborating out there, how big those companies were, what they were focused on, what they cared about and where we fit in with that, with that in that landscape. And so, you know, while market analysis can sound like a really big, really heavy term and something that would cost a lot of money or something like that, it can easily be done in-house with some folks who say, what do we think this is gonna compete with and what are those things priced at and who are they serving and what needs are they not meeting? It's some really basic market analysis can actually take you a really long way in making sure that you're taking the right product to market. Mastering the dark art of pricing. You know, a lot of people will say, well, you know, I built this thing and you know, yeah, we put a ton of time into it, but that's kind of all water under the bridge. We wanna start charging for it. Everybody else in the market is charging $10 a month. I think we're gonna just charge $10 a month. And that can really run you into some problems really quickly. Understanding, you know, what does it actually cost you to provide it? What do others charge for something similar to this? That's one data point. Is your product providing more value or less value than the alternatives? If it's providing less value, that might be okay. If it's also a lot cheaper, if you're providing a lot more value and you are trying to get it to be competitive in the market, you might not be competing on price, right? What price can the market bear? How much are people really going to pay for this? And what's your goal? Is your goal to break even on this thing or support the next round of development on it or get really rich or quit your job? Really understanding your goals is the other data point here in all of the sort of dark art of pricing. We have explored business models before that we've built a prototype for, we've built an open source product for, and it hasn't been the right fit for the market and we decided not to take it to market because we knew that the market could bear something like $19 a month and we couldn't figure out a way to provide it for less than a couple hundred dollars a month. And if that's the case, if there's just a clear mismatch, way better to know that before you build out a whole beautiful SaaS offering on it and then have nobody clicking the button and putting their credit card in, right? So understanding the dark art of pricing and figuring out what you really should and need to charge for it is really important. And then understanding your investment and this is, you know, sorry to go Debbie down on you again. But it's important to note it and it's important to understand it so that when you do make this investment you feel great about it. So what will it cost to build the great open source tool or toolkit that you built? What will it cost to truly understand the customer you wanna serve to build a product that serves that customer, to find a mechanism for delivering that product to your customer like the one that Robert just went through, to then go out and find the customers to your product to get those discount cards into the hands of people so they go out and try it to take the product to market, to support the product in the market and then of course, because this is Drupal to keep contributing back to open source. So knowing what you're really selling, selling what you're really selling, building out a market analysis, mastering the dark art of pricing, understanding the investment, all key to marketing your product. And then one more thing, it's a little bit important that Robert's making me do it so that I'll get the question at the end of this session, which is do not ignore support. And this is, you know, I always say this when I talk about products, this is a lesson that a lot of us have learned, including our company about supporting the work that you're doing and being clear about the support that you provide, whether that is a total DIY on case tracker for a project in open source, whether that is something like Zendesk or desk.com or whether that's working with a partner to be your support provider or to help be able to provide ticket support and that kind of thing. This is something that can get you in pretty hot water pretty fast in an open source community, is anyone feeling like the product is not well supported. And sometimes that is, you know, there is an investment involved with that and there is work to be done on that. So you can't ignore support, you can decide exactly how much support you'll provide for free and how much you won't and be very clear and open about that with your customers, but you can't ignore it. Really, really important. So let's review. Here's what we've done. We know what a Drupal product is and what it isn't. We know that Drupal products offer an awesome opportunity but they're really challenging to take to market. We've seen, and we've seen one way to fully take a Drupal product to market all the way from choosing the business model to taking money from your customers all the way throughout to marketing support. So with that, we're gonna put really old pictures of me and Robert on the screen and happily take your questions from here on out. And if you have questions, it's probably best for the recording of the session if you can ask them into that microphone, but if that seems like too much work, just shout it out and I'll repeat the question into this microphone. So who wants to go first? How does the corporate culture change inside when you move from a services organization to a products organization? Do you want me to go at this? Because we're in the throes of exactly that change and it is a really good question. So Commerce Guys started out exactly as a services organization just building websites for customers. We also incidentally built Drupal Commerce but that was so that we could build Drupal Commerce websites for customers and that represented 100% of our revenue. And we decided along the way to build a product. We built first of all Commerce Kickstart which has a revenue model but it's not a software as a service revenue model so I won't go into it. It's based around partners. And then we subsequently built Platform.sh. So the corporate culture is, there are several things that are interesting. First of all, it is quite possible that it introduces tension between teams because there's a lot of strategic emphasis right now on Platform.sh but that doesn't mean the other stuff that's been earning 100% of our revenue for the entire history of the company is not important. It's terribly important to us but it's sometimes really hard in the excitement of every new achievement for Platform.sh to fully convey that to the other people who have been working really hard for the last four years to make a great services company and to not have them feel left out in the cold and I'll be very honest that that's not a problem we've fully solved. So beware. The other corporate culture problem that is possible to encounter is that you have a sales team. We have a sales team. That's already great. You have a sales team but do they know how to sell products rather than services? They can understand the value of a website build out and they can price it but have you actually trained them to do estimation and value proposition for a hosting Platform? So those are some of the challenges. Great question. Yes. So you talked about multi-tenant versus single-tenant, mostly single-tenant. What's to stop one from building a software service on Drupal using multi-tenant architecture? There's nothing to stop you from doing it. What are the downsides, the risks? I don't think there's necessarily a downside other than that if you tried to build Facebook on Drupal you'd fail. I don't see the application being suitable for that type of high concurrency with its current architecture. You lose some of the customizability too, right? And you lose a lot of the customizability. You have to make it so that whatever functionality you expose to one customer has to be exactly the same for all customers and that special advantage that I pointed out where you could club together a site that is the upstream product plus code that comes from partners or other sources, maybe even the customer themselves, that goes away altogether. That's the main thing and that's why I focused on the single-tenant rather than the multi-tenant. If, honestly, if I were building a multi-tenant SaaS, I would probably write 100% of the code from a framework like Symphony or La Ravel just so that I didn't have any code that's in there that's not doing what I wanted to and isn't written for a general case that I'll never encounter. Any more questions? What is that? Who's next? Over here. Ronald. Thank you. Thank you for breaking through the veil of modesty and allowing me to answer your question by saying that it is my dream to actually have a commerce guy's product that says business in a box which would provide you with a marketing website with a checkout that you would provide the options for that would, at the end of the checkout process, launch a, what's in the background, a platform.sh project but the customer would not go to the platform project which is for integrators and site builders but whether they would go to the finished site which you would provide as a business in a state that is ready to start solving their business problem from day one. However, in the background if you as a product owner needed to provide bespoke customization for that specific customer or provide a partner network you would have this drush make functionality that I described at your availability to do that in an organized and repeatable and maintainable way. It's my dream to do that. It'll be a bit market driven. The problem is as I'm making him do an extensive market study before he even goes. Yes. Yes, so, exactly. Any other questions? Have we run out of time? I think we'll both be up here if anybody wants to chat or has anything and can find both of us online. And oh, we're supposed to say do not forget to fill out your survey about the session. Thank you very much. I think we were also supposed to say thank you EXOV for sponsoring this room but we didn't put a slide in there. So thank you EXOV.