 So as everybody's coming in, getting settled, you might notice that the title on the screen does not match what's in your program. I'll explain that. You're probably in the right room. But it's really your choice if you want to hear me talk about one topic or the other. If you're really married to the other topic and you don't want to hear about business models and Drupal products and open source and Drupal 8 and how that can accelerate your business models, then you should leave now really fast. Right. So we may as well begin. That's about time. Thank you for coming. My name is Robert Douglas. I'm the Director of Products for Commerce Guys. And when my CMO asked me for a session title and description for DrupalCon, I thought it would be really cool to talk about all the different ways that your business can do commerce that isn't necessarily having a product catalog and shipping things in the mail. That's still probably a really great idea. But in the meantime, I had a different idea. That's actually what I decided to force upon you today. So let me give you the spiel so you can evaluate whether you really want to be here or not. I have a vision for Drupal and for particularly agencies or the so-called Drupal shop who do sites how they could make a leap into a more product oriented business model. And I call that open source as a service or a hybrid SaaS. And I want to give you the recipe that I have in my mind for actually doing that type of hybrid SaaS. And I've got a couple of case studies along the way. And we're going to talk about Drupal 8. We're going to talk about recurring payments and hosting. So if you're not interested in any of that, I won't be offended if you leave right now. Otherwise, I'm going to start. So most of the Drupal people that I know, they wake up in the morning and what really makes them go, what really brought them to the project, what really made them stick to it is they have this deep and ferocious desire and need to contribute to the Drupal project. I mean, if you feel the energy of DrupalCon, if you saw Drees or WebChick on stage earlier today and the energy and enthusiasm they have for the open source community aspect of our project, then it's really easy to understand why people want to contribute. So with all the DrupalCamps and DrupalCons, the deep inner urge that people have that I know is to make this software that we all share and all build better and better and better and participate in that some way. But I've noticed that that gets really hard to do over time. So life happens, business happens, job happens, clients happen, and it's sometimes really hard to contribute. So I know at least the way in which I contribute to Drupal has shifted dramatically over the years. I used to write a lot of code, and now I don't. When I saw this, this is a chart from Drupal.org. This is about get contributions, contributions of code to Drupal.org over the years. This is like phase where it goes up until about 2011, I thought this thing could point, but maybe it can't, where it's steady growth and there's a huge spike when we change to get and there's a whole bunch of false positives, and then it still grows until mid-2012, and then kind of tapers off. It's like, hey, that looks just like me contributing code to Drupal.org, only mine's more like boom, like I totally stopped all at once. And I thought, yeah, that's just a metaphor for a person growing up in Drupal. You start off as a coder, and you contribute more and more, and you ramp up, and you get better and better, and maybe you make a switch to a manager or running a business or marketing business, designing a product, and all of a sudden it's really hard to find that time to sustain that level of contribution. Don't worry about this graph too much, part of reason why it goes down is because GitHub happened, and people started shifting their contributions to other places, but it was a nice metaphor for how hard it is to pay for contributing to Drupal. So take it from Bart. Open source is good for you, it's good for me, it's good for all of us, and to really embrace that and to keep that Drupal developer happy, the guy who's contributing, you really need a way to pay for it, and I want to call out Acquia at this point. They were in the room right before, they're probably all gone, so they don't appreciate the moment. Acquia, in case you don't know, employs all these people and a couple more full time to contribute to Drupal, all the time, that's all they do. They don't have business ROI, KPI, whatever, they just sit and they make Drupal core better, and that's awesome, but to do that, it's really hard, you have to be able to pay for that, and it goes beyond just raising a lot of money from venture capitalists, actually has a lot to do with your business model, and that's what I'm here to talk to you about, is your business model, but it's not just Drupal, there's a huge precedent in open source for companies making vast contributions to open source software. We wouldn't have the Linux kernel either if companies like IBM, Red Hat, Intel, Samsung, Google were not paying for massive contributions of software and time in engineering to open source projects. What is it that makes you get to be one of these companies? Obviously, we'd all like to be Google or Red Hat. The secret is that you have to build yourself a high margin business so that you can actually afford to contribute to Drupal, and I would like to share one of my visions for you, how you can use commerce, you can use Drupal to build yourself a high margin business so that you can make that Drupal contributor happy and be able to pay for them to have that half day, full day a week to do core, or maybe you can sponsor code sprints, or, I mean, there are lots of ways to contribute. It's not just about writing code, but it's also about sponsoring camps, hosting events, having people help out in the issue queue, but all of that, all of that takes time and time in business, it equals money. So you really can't afford to sustainably contribute to Drupal unless you build a high margin business. Before we go on, how many of you either work for or own a company that builds sites for other people? Okay, I call you Drupal agencies. How many of you work for or own a company that provides hosting of some sort? Okay, and then how many of you work for or own a company that builds a product that you sell to customers? Okay, so there's a little bit of overlap there. Good, but the vast clear majority is the agency crowd, so this is exactly perfectly rightly targeted for you, and I'm speaking to the people who go out and get customers, do projects, and then move on. So my vision of the internet, and you can compare this to yours, is that you open your laptop in the morning and money flies out. Okay, I just, I like that feeling, I like the coffee in the morning, but what I like more is opening the laptop and that's the feeling that I cherish more than anything when I open my laptop is just like being bombarded with dollar bills, and that, but if you think about it, that's actually what the internet should be doing. You should, you build the internet, right? You build websites for other people. The internet should be earning you money. If you build sites for people, by the way, your time earns you money. The internet isn't earning you anything. It's your hours of labor that are earning you money. And I like the internet to earn me money. So there was a Reddit AMA, so ask me anything. I don't know if you know Reddit, you probably do. In Europe, they've never heard of it. Dries did an AMA and asked me anything on the Drupal subreddit on Reddit, and somebody asked him, if I were to start a Drupal business today, what would be an appropriate business model for me to go in? And his answers were fascinating to me, and I've recorded them and they actually form the outline for part of the rest of my presentation. So Dries's business models that he identified were, well, you could start an agency. It's a really easy way to get into business in Drupal, so build sites for people. The gross margins tend to be 20 to 35% for the agencies that survive over time. It's not spectacular, margin-wise, but you know, you can grow it out and scale it up and eventually it can be fairly lucrative. You could go into specialized hosting. Dries thinks that there's still a lot of demand. It's worked for Acway. It's worked for Pantheon. Gross margins tend to be higher, 45, 65%. Or if you really want to go where the gravy is, you'd build a software as a service company, and that's where you start to see margins of 75% or up. And he in particular singled out e-commerce and marketing tools as the verticals within SaaS services that he finds rife with possibility. And I really agree with him. Because his thinking was so close to my own, I copied it here and attributed it to him, but it really, it's the way I see it, too. So this is a picture of me talking to a customer, especially if I have to build a website for them. I hate that. I never do that anymore. I stopped doing that 10 years ago. This is what I sound like when I'm talking to the customer, but really inside. That's what I feel like anytime that I'm building a website or a piece of software for our customer, and you know why? It's their idea. It's not my idea. It's their baby's dirty diapers, and I'm changing them, okay? I just, you might love it. You love your jobs, I know. But for me, building websites for other people is very frustrating work. So I always, when I was building the website, I always wanted to find ways to take part of that, to be able to use it next time. So I could save myself the pain of going through it again. And eventually, I always dreamed of turning that into a sort of a product that I could just sell to people so that I didn't have to actually build the website every time. Because, again, when I was doing that work, it wasn't that the internet was blowing money in my face when I opened the laptop. It was that I was punching my time card and getting paid by the hour. Whether you do fixed price projects or retainers or, no matter how you do your pricing, if you're delivering a project to a person, it's either, it's hourly in the end. You could do a P and L statement that breaks it down by hourly. And you can try and do it faster and cheaper on your side. But that's just like raising your hourly rate. And there's a fixed upper limit to how high that can go in terms of gross margin. So that's the agency model. Let's look at the specialized Drupal hosting model briefly. That's where Dries said the margins were between 45 and 65%. So this model's working out for quite a few companies these days. Acquia Cloud, Pantheon's got a great stand-down stairs. Commerce Platform, a product that my company is launching. I'm gonna give you a demo of that later. And some others that you, who's heard of Aberdeen Cloud, for example? I'm really curious. Not so many, it's more of a European thing, comes from Finland. There are probably 10 more of these companies. The biggest two are, of course, the top there. But a lot of people have moved into the specialized hosting. I actually think it's becoming somewhat of a crowded market. So out of Dries's business models, I don't find that the most attractive for a new company. And I know from Commerce Guy's effort that we spent two years and like a million euros building our platform. So it's not something you can do from scratch very easily if you're bootstrapping. And I also think that like the Drupalized specialized hosting, Drupal specialized hosting market is going to be more and more threatened by these guys who do generalized hosting really, really well. And at such a great scale and with such increasing sophistication and better and better tool sets that it's more and more suitable for anything you want to host. So I think that the Acquia's, Pantheon's and Commerce Guy's are going to have to move very quickly to stay ahead. And differentiated from these guys. So let's focus on the SAS business model, your Drupal business in the cloud. Because that's where Dries said the money is and that's what's really interesting for Commerce and Drupal products. So in case you didn't know what software as a service is, it's when you migrate your applications and you outsource everything to the web and sales and product development is outsourced to the web. And you achieve a state where you can run the entire company with a monkey. That's actually the point of software as a service. But you also need a second money, monkey, to look at the PowerPoints of the first monkey. So I totally slaughtered the Dilbert jokes. Sorry. You can look up online and laugh on your own time. But what was really important about software as a service is that you have to find a way as a website owner, as a product owner, to take money from people who are visiting your websites. And I've got the feeling and it's just my suspicion that most of the websites that Drupal people build don't actually demand payment online. Now how many of you are building or have built websites that demand payment online? Okay, it's less than half. How many of you run and own a website that demands a payment online in some form? Very few of you, right? That was my suspicion all along. And I think that generalizes beyond this room. I think we're really good at building content websites and marketing websites and some social aspect websites. But we have no clue how to actually get money from the people who visit our websites. So that's just, I learned that because I moved to commerce guys a couple of years ago and they started teaching me how you do e-commerce. I was never an e-commerce specialist and it's opened my eyes. But actually, if you want this to happen in the morning when you open up your laptop, you have to demand money from your website, right? You have to have people come to your website and swipe their credit card. How else are they going to pay for what they're taking from you, right? You're giving them a product, a service, something really valuable. How many of you use Salesforce? Salesforce? Really? So few. Okay. How many of you pay for Spotify? Okay, I'm doing a little better. How many of you pay for any monthly recurring service on the web at all? There you go. So you're all familiar with the value that you get from a website that provides you a monthly service. Why aren't you more familiar with building such websites? So what I learned when I went to commerce guys and when we built our own hosting platform and various things is that the actual essence of any product strategy, if you're going to build a software as a service product, you need a recurring usage-based or metered billing strategy. And Boyan, you have to talking about it? So I've invited one of my colleagues, Boyan, Savanovich, is going to come and take the microphone. And he's going to give you what is essentially a preview of his talk tomorrow, which we'll go into depth on this. But it's one of the salient, absolute crucial elements of building a SaaS software sort of product, and it's, yeah, take it Boyan. Okay, great. Let's see what Robert has prepared for us. Yeah, so in the previous year, we've been building a framework called Commerce License and on top of it, a framework for recurring billing called Commerce License Billing. And the idea is to be able to easily attack all of these digital use cases where you're not shipping a physical product, but instead you're charging for some kind of a service either once or multiple times in some kind of a recurring fashion. And the idea of Commerce License is to make it easier to charge for multiple kinds of services because by implementing various use cases, we learned that many of them, if not most of them, work in a similar way. So take a look at our support offering. It's called a TurboTicket. So you go to our TurboTicket page and you get fields for entering what's bothering you. You have a title and a body and you provide that information directly on the AutoCard form and then you enter a checkout. And what happens in the background is that we create a license object for you and when you complete checkout, when you give us the money, we call a special method on that license object and that method creates a Zendesk ticket for you transmitting the information that was attached to the license. So the license had information about your ticket. We created it on Zendesk and then we showed you the link. And afterwards we can list your licenses and we can show you the Zendesk tickets that you have opened. And that's only one of the things where this works. Look at our various subscriptions to services. So we have a ton of partners. We would like to sell you perhaps an account on Xector or PayPal or American Express. And they all work the same way. You check out this product and at the end of checkout we call a special license type per partner synchronization code that creates this remote account for you and then shows the details of that. And that license can have specific validity. It could be valid for a month or two or three. It could be a one time thing or it can be a multiple time thing. So and of course the main value in this is handling some kind of SaaS billing which is what we do for a commerce platform where you start to check out, you select the zone in which we'll create your little cloud. And when you finish, when you complete checkout, we create your platform. We attach information about your platform to your license. And based on that license, we continue to bill you every month. And we support many different ways of doing so. We support prepayment which means you pay upfront. We support post payment which is kind of like the way your mobile subscription works. You pay for the previous months. We have plans, we have usage that can be attached to a plan plus an overage fee where you pay for some kind of additional usage. For example, minutes that weren't included in your mobile plan and many other details. So those are just some of the use cases. So we have charging for a SaaS product. We have charging for support per incident. Or we have handling subscriptions or billing for a third party. And we can go further and further. We can charge for files, build any kind of a service like that, charge for premium content. So anything that's not shipable is handled by this framework. And if you're interested in learning more details about that, we have a session called the digital commerce ecosystem tomorrow at one o'clock. So come and see us. Thanks. Thank you, Brian. So there you have it. It's basically a recipe for how to take money from your website visitors for basically anything that you want to sell them. Whether it's access to a resource on your website or the ability to do something on your website or a remote resource like the Zendesk ticket example. I think tomorrow you might be showing an example where you're selling access to files on Amazon S3, for example. And so that's one of the fundamental recipes or building blocks for building a successful SaaS service. And I've long gone around the world basically talking to Drupal groups about building products and moving out of agency work and achieving higher margins. And I'd seen so little of it happening and I really had begun to wonder why. And what I realized when I came to Commerce Guys, it was because nobody was talking about the payment part. Nobody was talking about how to actually get the money from your website visitors and especially on a recurring monthly basis. So there are a couple other parts that I realized were missing and a couple other opportunities that I want to speak about. So how many of you have ever built a Drupal distribution of any kind? How many of you use Drupal distributions like Kickstart, Atrium? What's your favorite one? Panoply? Who uses Panoply? Yeah, really? Only one person uses Panoply? OK, check out Panoply. Great. Have you tried the demo framework distribution from Acquia, DF? You've got to go home and download the demo framework. How many of you used Kickstart, by the way? Wow. Good on you. You've got great taste as an audience. OK, so I see distributions as being the distilled concentrated know-how of a digital agency, basically, or a Drupal agency. How many of you have built sites two or three or more times for similar customers? OK. And do you use installation profiles or Drushmake files to launch any project, like to get you started to do the part that you do every time? Raise your hand, don't nod your head. Thanks. So, OK, good. Interesting. So maybe a little background because not as many hands went up as I thought. Drupal has this singular, very unique ability to package itself as a pre-built site that gets you 90% to 100% of the way towards a usable product in a specific vertical out of the box. There are tons of distributions. Open atrium is groupware and internet and collaboration. Kickstart, of course, is e-commerce. Push tape is for musicians. Drupal Rooms does hotel bookings. Red Hen does customer relationship management. Drupal Commerce is also an internet collaboration solution cameo as an e-learning. And it goes on and on and on. I've learned of two new distributions that I'd never heard of since I came to DrupalCon already. So a lot of people build distributions, but very few people actually build a business model around their distributions. There's even a restaurants distribution. And this is actually a great example. So imagine for the rest of my talk that we're going to talk about the example where you want to go out and get websites for all your local restaurants. You've noticed that none of their websites either exist or are very good. And you want to use this Drupal distribution as a starting point. So what do you want to do with this? You want people to, for little or no money, to be able to sign up and try it out. And then you want to be able to charge them a base monthly price for having the website and maybe a higher price for some more features like integration with menu systems that distribute the menus or an automated online reservation manager because there are different types of reservation managers that people like to use. But not every restaurant will be happy with one of your stock themes because they want an individual look. So you're going to have to customize it. So those are kind of the parameters. Two different plans, and you want to be able to customize the theme. So here's the overall recipe then for how you could do that and what that product looks like. So you've got your distribution, your restaurant site, and you've got this commerce licensing that Boyan talked about. That's going to handle the two different types of plans. That's going to handle the monthly billing aspect. And then we skipped one part. We didn't talk about how you're going to actually host that site. So the idea here is that you're going to launch an entire site based on a distribution for this restaurant. So that has to be hosted someplace. And this comes back to one of Dree's business models. I think for that, the recipe calls for a Drupal-targeted hosting that lets you easily launch sites from, say, a distribution or install profile at a very low cost can totally hide the complexity from the end user, the restaurant in this case, but still allows you to do something like go in and customize the theme. So there are two solutions to that, aside from finding a company that will sell you good hosting at the right price point. You need your customer-facing site, where they sign up for it, to be able to launch the restaurant site. So the workflow from the customer point of view, I'm a restaurant, I go to the website, I say, I want a restaurant site, it launches on your hosting, and then you've got to have somebody, whether it's the cousin of the owner of the restaurant or you as a digital agency or somebody they hire come in and customize that theme so it looks like what they want their restaurant to look like. And then the billing has to be there so that you collect your money every month. So that's the recipe of what it looks like to actually turn a Drupal distribution into a business model. And the software as a service happens in the center where all of those things intersect. Cool, this is, I'm gonna come back to the Scott and we're gonna do it towards the end. Scott here, Scott Hooker? Yeah, he's back there, great. Skip those two slides for a moment. Yeah, it's, Scott provided a case study that actually fits better to the talk I was supposed to give so we're gonna do that at the end. After we finish the arc of the current conversation. So I've just given you a recipe for taking a distribution, using commerce, using a hosting solution to turn it into a business model and now I wanna speak very briefly about how Drupal 8 is going to accelerate that and make it easier for you to achieve that type of business model. There are three ways that I can identify that Drupal 8 is a godsend for the business model that I just specified. The first one is CMI or configuration management. That's handy because if you have different configurations of your product, one that has a seating chart, one that has a daily menu, one that has a blog, one that has a Pinterest wall, image gallery wall, then you want to have a way to deploy these features or these add-ons to your websites but maybe these are exactly the things that you're putting licenses on. So maybe you charge your restaurants an extra price every month if they have an online seating plan, okay? Like where you can actually pick your table or if you can do a custom menu or for catering or whatever. These are add-ons that cost more and the license billing handles the part of the equation where you actually take money for that but the CMI, the configuration management in Drupal 8 where it is able to export the configuration for something that you've done into deployable files is going to be great for when you want to actually upsell one of your restaurants to having one of these features. You'll be able to transport these files onto their site and they'll have that feature without you having to go in and click around and build things. So to me, CMI is going to allow how many of you use features module in your daily practice? Right, I see CMI as being the better features module in the end. It tries to do less but it'll enable us to do more and that's in Drupal 8. The second area where Drupal 8 is going to really turbocharge the SaaS offering business for you is in the REST APIs that it enables. So an API is when it's gonna allow apps and other servers and other websites to talk to your customers' websites and interact with them. So Twitter got really big, really fast in part because it was an API-based service. You didn't just go to the website to tweet, you could do it from your phone and it could communicate with your phone, you got your alerts on the phone or you could build a integration with Facebook so that any tweet that you tweeted got posted to your Facebook wall or you could build a desktop application for your desktop computer to tweet deck to do all your tweeting in a more rich way than they could have done in the web browser. So giving Drupal the ability to easily specify REST APIs will give you ways to expose the business value of your sites, of your distributions to other applications and agents. You can even monetize those. The licenses that you sell and meter and bill for could actually be API calls, for example, why not? So I see the REST API integration in Drupal is being a great enabler for these softwares as service models as well. And finally, most importantly, Twig. This comes to the use case where you want to provide a custom theme for your restaurant. Twig is going to allow you to do some really amazing things, especially if you want to keep your hosting costs down, you're probably gonna wanna cram a lot of people into like a multi-site or one document route. But if you did that, you'd never let them edit the theme because they could hack all your other customers' sites because in Drupal 7, the theme runs in PHP and that's a powerful enough programming language that you could simply just hack the server. So you could never, on Aquia Gardens, for example, just let people upload or edit the actual theme template files. Twig takes that all out of the equation. Twig makes it safe for your customers to be able to edit the theme files and make the site look like they want to without posing a risk for the running software or security hazard for the other customers you have on there. So I see Twig as being essential in your distribution-based software as a service model to keeping the costs really low by being able to do a multi-tenant product. Plus you can define your own widget tags and that would give you like a drag and drop features like place your table choosing widget here. Possibly, maybe, and what you see is what you get editor. We'll have to see how that turns out, but Twig's gonna be a big one. Okay, so I've spoken, if I go back to that Venn diagram, I've spoken a little bit about Drupal distributions being the core distilled essence of your know-how that you're going to sell to the customer. We've spoken about the commerce license billing, which is your way to actually charge your customers for your software as a service product. I wanna speak very briefly now about the Drupal targeted hosting and I'm going to use Commerce Guy's hosting platform as an example because hey, this is a sponsored session and we get to do that stuff here. But in reality, you could actually use any hosting service that fulfills a few very important criteria. One, that you could launch sites on it using API calls. So you could just say, launch me a site from somebody's bought a restaurant site, launch me a site. Two, you're gonna wanna be able to build your site from a install profile or a Drushmake file because you wanna maintain your product in one repository but deploy it on the customer's site from that repository. So you don't wanna have to copy the files over, you want just a Drushmake or a profile file. And three, you wanna be able to give your customer the ability to get into that theme directory and theme file in a very organized way without being able to get into the rest of the code. So there are three pretty tight parameters and I'm gonna show you how the Commerce Guy's platform actually fulfills that. So really briefly, this is the overview of the interface I'm making a branch of my code. The way the Commerce platform works is that you take your master repository and that's an entire running website and you branch it. And a branch is not just the code but like the entire stack, the PHP, MySQL, the Redis, the Solar. And it branches it hierarchically so that I could make like a sprint branch and then underneath that I could make like feature one, feature two, feature three. And each one of those is a full working website with developers committing code to it. So that's what you just saw there. In the next screenshot, I'm gonna add some users. So this is where in my example, I would add my agency themeer or my cousin who knows how to do CSS or a shop that I've hired to come in to be able to work on my theme as a restaurant. So I'd enable them to come in. They can have different permissions on every branch that I'm working on and every branch is an entire website. So I could make a feature branch that's like my new theme, give one developer access to that, they go to town making it look good and then I'm gonna merge that backup stream into my live site when it's ready. And that allows you to have the restaurant site that has a unique look and feel. And finally for the hardcore command line people out there, I'm just going to show you what it looks like to edit a project make file to add some modules to it. So the website, remember, has to grab the installed profile of your product and deploy it onto the server. And you need to be able to add some custom features and stuff. And it's very easy to make that kind of product if you can build it all in a make file or project make file. And what I'm doing here in the video is that I'm pushing that make file to the server and all of a sudden, boom, I've got the C-tools modules which I just added on my server. And there it's built the entire environment new. So this is important for the recipe because this is how you put the theme that the the themeers are working on in your directory but all of the other software comes from your private repository. Then your restauranteer's cousin can actually safely go in and work on that theme without screwing up your site. So with that kind of recipe, I think you could build the type of product that I was mentioning. And if I were to wrap that all up, I call it hybrid SAS and it starts with a specialized distribution. You're building a site per client, not multi-tenant in that particular example. It's built on specialized hosting that supports some of those features like Drushmake, Profile Files, the separation of the code you want your customer to work on versus the code they're not supposed to touch. Pay for features, pay for usage, like you can pay to have the menu booking feature or you could make your customer pay for how many people book on the website or how many people visit the website. Monetized APIs and a theme layer that you can actually expose to the client. That's my recipe. We're gonna have some time for questions left over, I believe, if I look at my clock really quickly, then yes, we're good on time. So now I'm going to invite Scott Hooker up and he's going to give you one more example from commerce that at this point seems a little disjointed, disjunct, but it came from the other session description, which is something that you could be doing with commerce that's not necessarily selling, okay? Something, a use case for commerce that you hadn't necessarily thought of, so you get a little of the other session too. Scott Hooker. Hello, so I'm doing a session after this on how you can build a commerce mobile app built on PhoneGap, but what I've done with this site, and it's a bit of a kind of shameless plug, is basically nicked or stalled in order of the commerce code to produce a site that doesn't sell anything, but still uses the same sort of architecture of a cart and an order. And what this site does, I'm correcting saying gambling's illegal in Texas. Is that correct? Can you gamble? Nothing's illegal in Texas. Okay, well, okay, cool. So in the UK, gambling is totally legal, it's totally fine. And what this site does is tracks soccer bets and lets the user place the bet in the application or on the website. So it's using all of the commerce functionality. So in this instance, the products are the football fixtures. And when you add them to your basket, they become the line items. And here is the website view. So here we have the fixtures that I said are the products. The basket here is what I call a tracker and you add them and they become line items and then you can save them and they become orders. And it's quite a good use case where you can use commerce without selling anything. It's a really good data structure. So Scott, will you go back all of those commerce terms, line orders? Yes, yes, sure. Fix your products and explain what those are. Like in the commerce sense? Yeah, so in the commerce sense, products in commerce are the physical items or digital items as Borne explained earlier that you can sell. So be it a t-shirt or a digital product. And in this instance, they're just football fixtures. When you add a product to an order in commerce, they become a line item and that lets you persist the price. So if the price of the product changes, the historical order data still remains correct. And then when you check out your cart, in this instance, when you save your tracker, it becomes an order and that contains all of the line item data and the references to the customer profiles which would contain all of your customer order data and any shipping information and such and such. Cool, cool, thank you. So that was a great example of how you can do cool things with commerce that you might not have thought of. So that was nice tacked on at the end a little bit, but you got to see something else. We have plenty of time for questions. We have at least four commerce guys in the room. The question mic is there. So if you have a question, is this being recorded? I think the question mic is mostly so it's being recorded. I don't think this is actually being recorded. So forget the question mic. Is it recording? Okay, then use the question mic please. Let me turn it up in case anybody actually has a question. Could somebody test it for me? Tap it. Yes, sir, and what's your question? See, I knew. Is there any feature that would allow a customer's credit card to be held and then charge after they've purchased the service or charge if they do not go through the service and so that for their charge for cancellation? So I'm probably gonna have to have Boyan come up and talk about this a bit, but yes, this is a very important feature if you want to do something what we call post billing and we actually do this on our site when you sign up for our hosting platform. So most credit cards have a feature where you can either do an authorization with no value or they have like a convention if you like charge, is it $1 Boyan, what $1 that they don't, they don't even ring it through, right? They just use that as like the authorization that they're going to use for a charge that you're going to make later and then they can hold that for a specific amount of time. So what are the payment solutions that we know that do that really well? We use PayMill, Stripe and Braintree, both do that as well, right? So the piece of software you're looking for not at the payment solution level, not like at the Stripe, Braintree, PayMill solution level but at the Drupal commerce level is called commerce card on file and it's an integral part of the usage based in recurring billing because you don't want your customer to have to put their card in every time, right? Like, oh, the month's up, come and give us your credit card details again, that wouldn't ever work. So you need the card on file which stores a token from the payment solution and uses that token to authorize a charge at the end of the month. It's one of my distribution is in a kind of an appointment service and with appointments, one of the biggest concern is people making reservation and then canceling. And so I was trying to figure of an easy way through PayPal to set up a system where the card is on reservation, if they go through the service, they don't even have to pay anything on the website but in the event that they cancel and essentially leading to a loss for the person who would have booked the appointment otherwise. Right, you could, with a card on file and maybe with the license billing, you could do something like, you know, you could do the capture when they reserve and there's a $5 cancellation fee and $50 if they use the service. If you wanna hear a lot more about the possibilities, come to Boyan's session that goes deeply into this stack. When is it Boyan? He's looking it up. Yeah, tomorrow at one. Tomorrow at one. Okay, thank you. I wanted to mention, now that you remind me that there are two actually very important and very interesting elements to the recipe that I didn't go deeply into. One is that you have to be able to send your customer's invoices and that fills out that part and we use something called commerce billy, B-I-L-L-Y. And you also have to be able to chase people down when their cards don't work. That's called delinquent user notification or D-U-N and that's why, as a term it's called dunning, dunning management. So there's a commerce dunning module that will send out all of the notifications saying, excuse me sir, your card didn't go through. Can you check the details? We're gonna try again in a week and then we're gonna cut your service off and however you wanna configure it. It's very configurable and it fits all of the different workflow stages of soft declines versus hard declines. I lost my card so they gave me a new one with a different number. Therefore my service stopped working. That's a hard decline. Soft decline is I was over for the month but I've paid my bills so it should work now. So commerce dunning and commerce billy two important bits of the recipe. Other questions? Hey, can you talk about the development plan and the timeline for commerce for Trooper 8? No. Do I look like Dries? Sorry, what specifically do you want to know? I mean, I was wondering when will you guys start a development for Trooper 8? Oh, you mean commerce? Yeah, commerce. So we've kind of waited until there was a really stable API and maybe some, I thought you meant Drooper 8. Now I hear it, commerce 8. Commerce 2.0 is what we're calling it. We've waited until there's a stable API in Drooper 8 because we're really dependent on Drooper 8 so we've decided that commerce 2.0 is going to be Drooper 8 specific and we've been collecting all of the lessons learned from Drooper Commerce and we've got an amazing amount of literature and research and planning gone into what we want, commerce 2.0 to be, and we're actually in July having our kickoff sprint in Paris with all of our internal leadership and tech leadership to lay the foundation for commerce 2.0. We're not gonna make any guarantees about when anything's available but Drooper 8.0 isn't gonna be available tomorrow either so we feel like we've waited the right amount of time to start so that the APIs are no longer shifting underneath of us. Did that answer your question enough? It's very nebulous but we definitely, Yeah, that's when it all gets going. Yes, sir? Is there a use case where you would actually change the price of the service being offered or the product being offered based on demographic information? So not necessarily a promotional? On which kind of information? Demographic? Demographic. Or like how you get it? Right, yes. The user then you change the price based on that and they've been unnecessarily promotional type of adjustments. In Germany they have a haircut called the Kranz and that's if you're bald like this they only charge you five bucks instead of 10. So that would be kind of like a demographic based pricing alteration. And yes, no problem. I mean that's rules based, that's something that you could do with just the basic rules integration. In commerce, in Drupal commerce, all of the pricing happens, it goes through a pipeline of rules that you can set up. So you can say if you're in Texas, charge them twice as much. No problem. Did you have a particularly difficult use case? Okay. It's probably the most powerful pricing rules engine available for any open source e-commerce package. It's very powerful. You can literally do anything. Other questions? Yes ma'am. Step forward to the mic and record your voice for posterity. Can you speak a little bit more to the multi-tenant capabilities on platform? You had at one point you talked about it how you would adjust it for multi-tenant so they could adjust their own themes. And then at the end, you said something about that wasn't multi-tenant, so I'd like to clarify. Yeah, that was confusing. So let me just tell you how Drupal Gardens, who's familiar with Drupal Gardens from Acquia? Good. Drupal Gardens runs on what's called Drupal multi-site. That means one code base, many databases, okay? So you've got different URLs coming in and based on the host name, Drupal knows which database to use to get the data and the permissions and the content and all of that. So it looks like many, many different sites and it is many different sites, but if I change one character of code in the files, on the file system, it affects all of the sites, okay? And they're all physically on the same hard drive right next to each other, which means that if I were going to give one of those, let's say 100 customers access to the theme files in Drupal 7, they would essentially be executing a PHP code on a server that has 99 other customers on it, which can't happen unless you're really clever with Linux permission, but probably it's, no, it just can't happen. So the opposite end of that is to launch an entire different code base and database for every one of your customers and that doesn't intersect necessarily with commerce platform in any way, okay? I was just pointing out that my business example, my recipe assumes that you're launching one site for every customer and that they're separate sites. Okay, okay. They can still build off of one another and off of the master code or is that correct? Right, so the blueprint for the site comes from something called an install profile or a distribution and you launch that using a Drushmake or a .profile file and that's why I said you need a hosting company that can actually launch a site from a Drush file or a project file so that you've got this distribution that you're controlling, that's the blueprint for your site that upgrades everybody's site remotely because you change a feature there, it's like a new release and they all get the new release plus you need the local ability to work on something like the theme or maybe a custom module because that's actually Drupal's selling, you know, unique selling value is that it's so customizable so why would you make a Drupal product that you can't customize? So I hope that cleared it up a little. It was a little confusing in my presentation, I'd say. Right, okay, thanks. Anybody else? Four commerce guys in the room, three of them smarter than me. All right, well then thank you for coming, sorry, I switched the topic of the talk, thanks for staying anyway and I hope you liked it. Yeah, because I switched the levels there because there was nobody in here and we were getting feedback. Like I'd speak here and you'd go,