 For the patients with a few minute delay here, we have a few slide integration technical difficulties. I'm Andrew Hoppin, and we're going to talk today about OpenSAS, which is a concept that's been kicking around in this community since about 2009. But I feel like it's seeing a new dawn today in the Drupal community. And I'm going to go into why I'm personally so excited about it. I'm joined up here by some incredible thought leaders in the community. Chris AIDS from Aquia, Robert Douglas from Commerce Guys, and Josh Koenig from Pantheon. I'm very honored to be in their esteemed presence. So without further ado, I am going to kick it off and tell you why I'm so excited about this. So OpenSAS, I define as the best of open source combined with software as a service. And when I mean open source, I don't just mean open source and license in this context. I mean, open source in terms of the practical ability to support yourself with a code base without needing to go to any one particular company or without needing to pay anybody. If you have the technical skills, you can have a successful experience with it in production. And you can actually contribute to it. So to me, that's the definition of a true open source collaboratively built software project. Different than a company building a one off purpose built application and throwing the code up on GitHub. And the other key piece of this I think is the ability to deploy that application in a software as a service context. That means on a commercial cloud with support turnkey so that it just works. And the beauty of this is that when you have customers that don't want any technology burden, they can not have that and they can still benefit from the software. On the other hand, if you want to use the software without having any dependency on any company or any third party, you can do that as well. So it's really the best of both worlds, open source and software as a service. And we're gonna get into why I think Drupal is such a great platform to do this on. Just a little bit of background, way back when we went from managing stacks of servers in air conditioned rooms to running virtual servers in the cloud, that was great, great new efficiency. Then we went to being able to actually have Lamp in the cloud, took it up one major level which added a lot of efficiency for all of us. And now we're at the level where we can actually just focus on the application itself. We can actually just focus on creating the business value for the customer in the cloud. And all the other stuff is really commoditized and taken care of for us. So that's what's so awesome about SAS, obviously. But I think when you combine that with the truly open source collaboratively built software platform, you have something quite special. And the seminal example of this, of course, is WordPress, right? WordPress.com makes tens of millions of dollars not more for a company, automatic every year. Hosted, turnkey, it just works. You just focus on creating and sharing your content. But WordPress.org is truly open source. You can download the code base, never talk to automatic, never pay them a dime. And it also works and is really robust and you can contribute to making the WordPress platform better. So even though we're here at TripleCon, WordPress.com and .org I think are truly the seminal example of open SAS. However, Dries as far as I know coined the term open SAS back in 2009. So we certainly in the Drupal community deserve some credit for that as well. And the Africans were talking about it at conferences as far back as 2009. I came to this fairly recently. I was a former government CIO in the New York State Senate. And I was really frustrated. I really wanted to innovate in my institution. And yet I was always torn between getting to market fast with the new application that we needed to stand up, which implied software as a service. For example, we were looking at Salesforce for CRM. But the realization that I often needed to change my mind, sometimes on technical merits because the world's moving very fast and in a government institution, we're not always the most nimble and able to keep up. But also because sometimes my legal and technical and political requirements would be changed by stakeholders in ways that are out of my control. So I was really worried about having a dependency on a third party proprietary environment, even if it was quick and efficient to get up and running a software as a service. That led me to be biased towards open source. But at the time it was hard for me to get the same kind of efficiency and the same kind of support with open source solutions. So put them together, open SaaS. Very exciting, I think, particularly for public sector, where you have some of these unique requirements. So the value proposition for customers, pretty obvious, but no technology burden in software as a service. It just works. Fast time to launch. We're not, instead of building a custom Drupal site after writing an RFP and selecting a vendor, and maybe you get a product out the door a year after you started. If it's a really product that really meets your needs, you can just turn it on for all intents and purposes. Freedom to host anywhere. So cloud portable, if it's truly open, you ought to be able to host a software as a service in multiple places. No vendor lock-in inherent in that, of course, as well. Vendors ceasing to provide value to me, I want to be able to switch, take my application and my data with me to somewhere else. Unlimited seat licenses, typically, right? None of this, it's $50 a month per user, because that's the business model of the one company that provides it to you. And then, of course, rapid product innovation. I mean, the whole point of open, collaborative software development is versus open source and license, I think, is that we're aggregating the effort and the talent and the energy and the creativity of tens of thousands of people into making something that ideally can outpace even proprietary or software as a service by virtue of aggregating that effort across the global community. So that's on the customer value proposition side. For us as a product company, and I am part of an open SaaS product company now, the reason we want to do this is because we get higher profit margins. Software as a service, we can serve each additional customer with our open source base product more efficiently than we could by building custom one-off websites for them, and so we can get higher profit margins on that. We can even charge them less and be a better value for the customer while making more as a company. So that's obviously really attractive to us. Makes our business more scalable as software as a service. However, as I went through on the slide about going up the stack in terms of what we can commoditize and outsource on the cloud, we can commoditize all the way to the Drupal platform as a service layer today. So all that complexity, all that maintenance, all those security requirements that we used to have to handle on our own if we wanted to build the software as a service company, we can now outsource to companies such as these three that my friends here work for to my right. Similarly, we can defray the costs of R&D across an entire community if we play nicely in this community. If we build a Drupal-based product, which we've done, we ideally don't have to actually innovate that much ourselves because we're part of a community that's innovating on a global scale, and then we're just translating that into a form that a customer can get as software as a service which reduces our capital expenditure to keep our products innovative and out ahead of its proprietary competition to a tremendous degree. And why do we want to do this? Well, ultimately, it's kind of that, in our case, that we're impact junkies. We want to help more people. We started a company in order to make governments work better. We can only do so many of those if we're doing traditional website development and consulting, and we want to help thousands of governments. And we feel like if Boston figures out why something that works well and deploys it, we think Austin should be able to take advantage of that really quickly and really affordably and without having to reinvent that wheel or rebuy that wheel. And we think an open SaaS business model and service delivery model makes that possible. So just really quickly, and apparently Microsoft is being kind enough to update my software, let me speak here. Speaking of open SaaS, we're not. What we've done this with, there's really briefly is we found a use case that we think is really big and important, open data management. We wanted to make it easier to do that with Drupal. Huge market, so we built a Drupal-based distribution to do that called Decan, competes with two leading products in the world. One is the proprietary software as a service called Socrata. Another is a fantastic open source product called Ccan, but it's based on Python. And we built the Decan distribution to provide a new Drupal-based alternative to that. And why we think it's powerful is because it's got the software as a service ease of like Socrata, but it's got the open source goodness of Ccan, and we brought those two together. And because it's based on Drupal, because we can commoditize a lot of the hard things in terms of Drupal platform as a service hosting and support, we can actually bring this to market quite quickly and affordably for customers. So that's what we're doing. There's a lot of other companies out in the world trying to do this now with Drupal, a pig nose and interesting one in Switzerland doing this with a learning management system. And we think that Drupal is a phenomenal community and platform and culture to do this within. And a couple of reasons why. First of all, the distributions or distros and install profiles model is really powerful. It means that we can get together, not just at building something at the content management system layer and saying, we'll make this a great content management system every three or four years, Drupal-7, Drupal-8, what have you. But we can actually go up even a further layer and collaborate around that at scale effectively. We can say, at a product level, at an application that does something very specific for a very specific use case, we can actually aggregate that effort of hundreds or thousands or maybe even tens of thousands of engineers because the technical model for distros and the governance around that on Drupal.org really lends itself to that. So we built our lead maintainers on Decan, but we have contributions to it from engineers all over the world that never have to talk to us, never pay us a dime, but they're contributing to the project. Not all open source CMS projects had that. And similarly, the scale of the contributor community, Drupal is just so big that we can actually outpace much better resourced companies working on their proprietary products that do similar things because of the scale and our culture of not charging people for contrib modules and for themes in the Drupal community. So lots of focused web apps have use cases also that need content management systems. So for a long time, people didn't do open data with Drupal because they thought it's a special thing. It's a data store, it's APIs. And so they did it with other purpose-built applications like Ccan, which is all well and good, but a lot of the sites that launched with the Ccan platform as an open data store realized they really needed a content management system as part of that. They needed to manage user roles and permissions and content in the context of data and taxonomies and all these things that Drupal does so well. And so we think that having a CMS be the basis for products is a really good place to start because even if you're not thinking that it's content management that you wanna do, you need all that other stuff that Drupal has made so robust and really click together, admin, UI accessible in many, many cases. So the other thing is that there's so many people innovating at the platform as a service level. Again, most notably, I think these three companies on my right that we're gonna be able to stay out ahead of the curve, not only with our product, we think, but also in terms of the ability to have it delivered to a very large scale, delivered very securely and what have you. So we're just really grateful and fortunate to be doing this with Drupal for these reasons. It's gonna be a little small and hard to see so I'll invite you to check it out online later, but this is just a visual representation of all the things that we found we don't have to do because we're doing this with Drupal and because we're doing it in partnership with Drupal Platform as a Service hosting companies. We really are just focusing on the things that we know best which is how to provide business value around things that we really know intimately open data for government and everything else we're able to really outsource to partners because we know how to do this in the context of Drupal, legally, technologically and culturally. So with that, I'd like to turn it over to Chris Yates. Cool. Hey, I'm Chris from Acquia. I wanna build on the point in Andrew's last slide which is, you know, focus on what you know. And back in, I think 2012, I was talking with Barry Jasmine who is the principal architect of Acquia Cloud and he was talking about his vision that he had when we started building that product, I think back in 2009. And it was really that people could, you know, create their own businesses, their own SaaS based on these tools that we were providing to them. And he picked up something that he figured was like super niche, he said, well, you know, I could, you know, we can enable a company that service dentists office. They created websites for dentists and practices and I just and whatever. And that was like the most niche thing you could think was kind of a joke internally. And I actually expanded on that idea and, you know, presented that as an idea around the same topic to an AWS meetup that year. Talking about how, you know, Drupal is the ideal platform for building those types of services because it's incredibly malleable, it's incredibly, incredibly extensible. And then we've gotten to the point where we've been able to abstract so many of the layers that sit below it and are a burden to a company trying to build a product. So taking away the layers of network management and buying servers and managing their uptime and all of those types of things, you know, you can purchase as a subscription now. What's key to being able to build a business on top of that is one, having something great that you can go out and sell as a value proposition to your customers, being able to maintain that long term. So, you know, making it a turnkey service and being able to be really agile with how you actually deploy that. So being able to use APIs and really simple tools to create new sites and update masses of sites and network content between them. And drive new features so that you're increasing value year over year because that's what, you know, with SaaS you have to earn the customer's business every year. So it was kind of a, you know, a lark. We thought this would be an example. Hopefully it's inspirational. It's a little bit funny. We had this kind of concept which probably depends on, you know, whether you live in the States and, you know, grew up in a certain time period whether you understand what the good dentist versus bad dentist references are in these little slides that are probably like super fine print up there. But then last year it happened. So, you know, a company called Heartland Dental has a business serving dental practices, individual dentists and orthodontists. And they are building thousands of sites on Drupal and on, you know, past platforms and SaaS services that sit behind it. So they're using, you know, some of Aquaia's cloud services. But they're deluring that, you know, in a way that allows them to create things really quickly. So instead of having a technology bottleneck and a human bottleneck to be able to spin up a new site and sometimes taking weeks to get a single dental office on online, you know, they can just click a button and then start customizing that for the particular dentist really quickly. They have this, the ability to do updates both at the, you know, the feature and function layer. So what we would do with, you know, updating the distro but also at the content layer. So being able to say, you know, this office sells and does align and this office doesn't and being able to update, you know, certain products and product offerings and masks across sites as well. So it's letting them get to market a lot faster and increase their margins. So they're not, you know, they don't want to be a technology company. They want to be a company that provides a unique service and this is one of those services in the portfolio they offer. And I see this kind of breaking down into three categories of where companies can kind of enable this ecosystem. So to make more heartland dentals and Heartland is an example of a company that's actually created a business that's externally focused. They're going out, they're marketing this product. They're servicing this product. They're, you know, continuing to drive their innovation and their value but we have lots of customers and users in the Drupal community are doing this internally. So, you know, two of the largest farmers or the largest farm in the world is doing this internally. They have SaaS platforms to deliver campaign and product websites at the same speed and agility. You know, NBCUniversal is doing this internally with a distribution called Publisher 7 that they deploy out in Awkward's Cloud. So there are, you know, opportunities to engage at a couple of different levels for companies that want to be part of this ecosystem. So Awkward and Antion and Commerce Guys have built platform as a service, you know, as some of the foundational elements. So the ability to develop and deploy rapidly, be able to kind of abstract those lower layers of the stack we showed at the very beginning, not worry about servers and uptime and those types of things and push that on somebody else and some other systems. There's a great opportunity for companies that know a market, know a space to start building platforms. So take distros and actually start delivering them as true products and continuing to deliver additional value for their end customers. And then there's an opportunity to build things at the engagement layer, the top of the stack. So plugging in things like marketing automation and the expertise that surround that, you know, targeting and those types of things. So pure SaaS services that can complement the distro and the SaaS and the past that sits below it. And then the real key to being able to mechanize this whole thing is making sure that all of these things are available through APIs so that you can build, you know, custom tool sets and administrative portals, those types of things that are really suited to your specific workflow, whether you know, you have to send sites through an FDA regulation process or you have to send sites through, you know, a marketing review or whatever it is, being able to effectively build tools around the tools that you're using. It's a different sort of business though. So it is, you know, higher margin potentially, but it is a different type of business than pure services. So it's not enough just to build the distro. You know, it requires an ongoing commitment to continue to, you know, add features and functionality, you know, keep all everything that comprises that distribution and the business model up to date. And then, you know, go out and market and service it as well. So you have to deliver that in an ongoing basis. And like I said, there are, you know, opportunities for lots of different types of companies to be involved. Past providers, you know, SaaS providers, and then vertical experts to focus on what you know, whether it's, you know, dentists or it's NGOs or it's, what have you. So with that, over to. Thank you, Tristan. Hi, everybody. My name is Robert Douglas from Commerce Guys and a quick question. How many of you build and deliver sites for clients out of curiosity? Okay. How many of you would consider that you sell a product of some sort? Okay. Good. So back to the definition of SaaS. When you talk about software as a service, you're talking about software that you don't download and install but rather software that's delivered over the web. And there are a couple of observations in that. When you talk about Drupal, then that could either be a website that you build yourself and you maintain the website and people come and get whatever service that it is from the website. So it could be a single website and all your customers go to one website and that would be what we'd call a multi-tenant software as a service model. Or it could be that you provide them a website of their own and that's the software that they're getting delivered as a service and that would be what I'm going to refer to as a single tenant model of software as a service. So and I think the differentiation there is quite fundamental to any organized thinking on the topic so I bring it up right away. And it's also worth mentioning since we're inspecting software as a service that Commerce Guys, Aquia, Pantheon all had to go through the process of building a software as a service website when we launched our products. And we took massively different approaches. I've got tiny bits of insight into Pantheon and quite a bit of insight into Aquia and Commerce Guys. So it's a quite interesting space and there's a lot of variety and there are no clear rules. So I'd like to talk about one specific model that I think is particularly interesting to a really wide number of people in the room who raised your hands when you said that you build websites and deliver them to clients. And that's the single tenant model where your goal is to provide somebody with a website that's their very own website. And the reason I think that's particularly interesting for Drupal is because Drupal's strength lies in its ability to be customized. Everybody likes Drupal because it can fulfill any wish that you have. You just have to customize it the right way and it becomes what you want it to be. The limitation of a multi-tenant software as a service model where all your customers come to one website is that it makes it massively hard to provide that customization. Therefore you're missing out on the unique selling value of Drupal to begin with. So I'm gonna focus on the single tenant model. The single tenant model in its entirety is very abstractly and very naively represented on my slide. Now it's worth mentioning that I've been going around the world speaking at conferences, admonishing people to build Drupal-based products for quite a long time now. So I've probably spoken about how you should be productizing your Drupal distribution, concentrating your know-how, your domain of interest into a distribution and productizing it. But what I didn't realize until I actually moved to Commerce Guys and went through first the process of launching my own software as a service site and then seeing some of the stuff that my colleagues at Commerce Guys were working on is that there's a part that's missing in the thinking from that. Lots of people build distributions. How many of you built a distribution before? Install profile, distribution, right? It's a good way to encapsulate the things that you know and do over and over and over again. How many of you use distributions? Panthea, Panopoli, Kickstart, demo framework. There are lots of them and they're very useful. How many of you sell distributions to your customers? Wow, awesome, that's great. Do you have a direct sales model where they use a credit card to check out on the website? Raise your hand. Bingo, missing link. So in my previously naive and expanding view of software as a service, an actual software as a service business, at least a self-serve one, starts with a website and then you see that on the left hand side of the screen where it says myproduct.com and it has little credit card logos. That's where your customer goes to buy their software as a service product, okay? That's your website, that's a standalone website and that mirrors the model that these three companies have followed in their software as a service product and then what happens after that is magic. It goes, triggers some actions and creates hopefully based on a distribution or starting point, a website for your customer that has let's say a Drupal distribution in it and that comes from on the right hand side the product code repo. So that's where you're gonna wanna work on your product, do your product development, product maintenance and that's the source from which updates and upgrades flow from. But now remember we want to retain that flexibility and customizability that Drupal depends on. That's why I have little blue boxes on each one of those websites where it says customer one, customer two and customer three. Oh wow, you've made my next one's red. I apologize for making Robert's slides like awful. He turned all my Venn diagrams red. He did it. So to make that work, you actually need three things, okay? I'm gonna leave the Drupal distribution aspect to your imagination because you're probably experts on that. If you've ever built the same sort of website two or three times already, you're probably ready to go and make that distribution right now. Imagine that's in that code repository in the upper right hand corner where you do your product development. Now on the left hand side of the Venn diagram here is something called commerce licensing and I'm here to tell you that there are open source tools that handle the recurring billing, the usage-based billing, the metered billing, the prorated billing, the plan-based billing that you would want to do if you have a software as a service model. Now if you think about the different models out there, there are lots of them. Let's take a Flickr where it's like one size fits all. You pay 35 bucks a month and you get everything. Or let's take AWS, Amazon Web Services as another software as a service model. There you don't pay until you use anything and they've got 150 different products you can use at different sizes and they charge you for how much you use in the month and if you use it for five minutes, they charge you five minutes worth and if you don't use anything they don't charge you anything, et cetera, et cetera. Two completely diametric models all of which can be modeled with commerce license billing. And then finally at the bottom layer represented by the gentleman at this table you need a Drupal specific hosting platform that can do a number of things. So I'm gonna talk about that right now. The things that you want your Drupal specific hosting platform to do if you're going to build a software as a service model like I just demonstrated are you need to be able to launch a distribution, okay? It's no good if you have to check in the code for your distribution at the command line when you launch the site. You need to be able to actually build the site from the distribution to start with. Drush make files or dot profile files are the best methods for doing that because it relies on underlying tools that you already know like Drush. So look for that when you look for your hosting platform. Furthermore, you want to be able to separate the code that's coming from the upstream repository from the code that you're actually going to do the customization with. Why? Let's say you're doing restaurant sites, software as a service. Restaurant signs up, they get their website, they go in, they make their menu and put the map in there, contact details. The next thing they're going to want to do is they're going to want to theme their site. You're not going to want them messing around with the upstream code distribution because that's the part that you maintain. That's your product. If they get their hands on that, not only do you have no more IP that you have to release everything as the GPL and they can bring your server to its knees by stupidity. So you don't want that. So you want a way to segregate the code that they can edit and run in their repositories from the code that you provide and smush the two together in a way that's safe for everybody to run. And finally, you want it to be cheap enough to spin up a new site one at a time so that you've got a suitably low entry to the market for your customers so that you're not priced out of the market by your hosting company. So those are your evaluation points on choosing a hosting company. Now in terms of commerce license, I'm not going to go into this slide in detail. You can look it up at drupal.orgprojectcommercelicense.com, not .com, what a habit that is. .de. So the model of that is that you can basically put a license on anything. I could put a license on access to the website. I could put a license on downloading a file. I could put a license on a user role and then I can charge with the card on file, with the commerce license billing. I could charge any of the payment plans that you can imagine for your SaaS. Whether it's a package-based payment plan, whether it's a metered payment plan, whether you need to do prorating or not, that's the difference if you like bill everybody on the first of the month or bill everybody 30 days after they start. So like if I bill everybody on the first of the month and you start on the 15th of the month, what do they owe me, half a month? How do you figure that out? That software, which is available on that link can help you with all of that and you can make any business model you want. It's kind of like recurly only in drupal and you've got the software in your hands and you don't have to pay to use it. And then you sell licenses to those products. So right, there are a couple other fine details in running a software as a service. One of them is that you need to do invoicing. So anytime you do commerce of any kind, you need to do invoicing. So look at the Billy module, that's what commerce guys use. You also need to do what's called Dunning management. That's when a credit card goes delinquent, you need to start pestering the people that they need to pay you with either hard declines where the card was stolen and they changed the number or soft declines where they just didn't have enough balance or they're behind on their payments, but they've caught up so now they can pay you. All of that is in this world of commerce license billing and you can find lots of links online if you just follow the first one that I gave you. Can I have two more minutes? Yes. I wanna briefly branch out into how Drupal 8 is going to help with software as a service in Drupal. There are three major reasons Drupal 8's God send for these models. The first is configuration management. Configuration management is gonna give you upsell possibilities in terms of packaged features that you can just tick a box on your provisioning website and have the CMI configuration put into the customer's site in a way that activates a feature. You can put a license on that configuration with commerce license billing and when they don't pay for it, it goes away. With REST APIs in Drupal 8, you can actually monetize or you can do all sorts of things like you could monetize your APIs, you could build apps that help your customers manage their products. Just suffice to say that Drupal 8 is gonna have superior REST APIs and Twitter wouldn't have ever grown to what it is if it had just been a website. So stop thinking about building websites and build APIs first, build the website around that. That's my advice there. And finally, most importantly, Twig. Twig in Drupal 8 is a game changer for that separation of the code you maintain versus the code that you let your customers get their hands on. Now I was around when they built Drupal Gardens and if they had had Twig back then they would have done it totally differently because right now in Drupal Gardens as far as I know, you can't go in and edit any template files because they're in PHP. You'd hack all of the other customers with the PHP and bring the servers to its knees. But with Twig, you could actually let the customer go in and change the theme files like they really want to and not have to do browser-based theming and deploy it without bringing the server in any danger at all. So your software as a service model is gonna heavily depend on Twig for that restaurant that wants their own look and feel. You can just give them the Twig files. Let them do whatever they want. They can't break a thing. And with that, I'll hand it over to Josh. All right, rounding home. So I'm gonna speak to contextually why this matters for the universe. This is the software CMS market. This is website technology. None runs most of the internet. It's not being run by any WordPress, Drupal, or other content management system. Who here develops websites for a living is like a website developer, a PHP person? I asked that. Before you came to Drupal, how many of you who put your hands up had written your own content management system? In Java. None. None runs most of the internet. Like we don't have most of the world's developers coming to Drupal cons. Most of the world's developers are still banging it out, reinventing the wheel. And for open source to really achieve its destiny, which I believe Drupal's destiny is to run a double digit percentage of the internet. And I think in Toto, all open source content management systems should exceed 50%, perhaps even approaching 80% of websites. We're not gonna get there if we're building every website from scratch. Certainly not starting with blank slate and writing your own user forgot their password system, but also not if you're just installing Drupal, vanilla, and building it up from there. It's too much work. It takes too much time. And it requires people to make too many choices that they fundamentally don't really have the time or expertise to make. The role for us as experts is to marry our technical expertise with our domain knowledge that all these guys have talked about. And I have an analogy that I like to use when describing this. Inside of Drupal, we see our tools as this powerful building block system. It's like Legos. You can just lump things together, one piece on top of the other, and you build amazing and beautiful things. The problem is that for the uninitiated, for most of the universe, the experience of attempting to pick up and use Drupal is closer to this. It's a giant mess. You're stepping on things that hurt your feet, and it doesn't work very well. If Lego Incorporated sold only a giant plastic sack full of a bunch of Legos in the toy store, they would be out of business tomorrow because no one would choose that as their first-time experience. Now, after you have 10 Lego sets and you've got them all in the plastic bin and you don't have to play with, that's what you're doing. But that's not where you start. You start with something like this, right? There's a description of the product. It comes in a box. There's an original expectation that everything you need to construct the thing in the picture is in the box, and there are instructions on how to do so. There's even a label on the blocks that gives you an idea of who it's for. This is not for teenagers, it's for little kids, so I know if this is right for my audience. Being able to, this is the concept of productization, right, and it involves us as technical and domain expertise experts making decisions for other people. And it's very different than the consulting model where, by and large, you're looking, listening to what other people are desiring and figuring out whether it's possible to do. But I would really suggest that more of you probably have more expertise than you think about what your customers need. Like, if you serve a particular type of market, you know, the dentist market is a good one, or I know someone who's done this for lawyers, right? Once you've built the fifth lawyer website, you have more expertise on what lawyers need for websites than any lawyer, because you've seen across five different organizations what's worked, what hasn't, how they're working. And you can marry that domain expertise on their type of business with your technical expertise on how to build and deliver an amazing website. And for the sixth lawyer, suddenly there's not this long discovery process because you already have all the answers. And there might even be some cases of like, huh, I would've never thought of that, but you're so right, I totally need that feature, or I thought I needed this other feature, but you know what, it never came up. And that's what I mean by bringing together the expertise to make it happen. We need to figure out how to turn at a product level something that is purely a pile of Legos into something that comes in a box and people wanna pick up and use. And I believe this is possible because I got involved in Drupal by doing this. My experience was working on a presidential campaign, trying to take over the government, as I say, and having that fail, but taking the expertise that we use there in driving a very rapidly growing campaign and turning it into a general purpose product for nonprofits. This is before Drupal had installation profiles. This is before a lot of things existed. Very early days for Drupal, 2004, 2005. But you know, it was amazing to see what would happen. When you took Drupal, you made it so that on installation it had a bunch of content and configuration already in it that made it like a cause-based website, and you put up a website explaining what it was in that language to that audience, and you went out and talked to them and said, hey, I've got this great solution for you. And at the time, nonprofits were married to these terrible, proprietary SaaS monstrosities that were like leftover relics of the 90s that weren't being updated and they had all their data in there and they were just sort of squeezing them, honestly. It was a bad. And we went and then broke that open with open source and CivicSpace. And only later on did they realize that they actually had Drupal, and then they would try to hire a Drupal developer to extend their platform, and it was kind of fun. And at the time, we didn't have the automation technology necessary to deliver CivicSpace as a service. It was just a productized tarball that you have to download, kind of like how open Atrium was. But the future is now in terms of how we're doing this. And I mean, I'm building this stuff every day and it works, it totally works. And we can make it even better than it is now. So I would say if anybody is thinking about this or has dreams of doing this, start thinking about what your Lego box is and start thinking about who might be willing to pay, how much for it, how you would service it, whether you want that type of long-term commitment and start investing in the potential. Because we have all the pieces we need to put together open source, software as a service, open SaaS. Nobody? No. Open SaaS, and being able to deliver it. And that's what it's gonna take for us to get to to that broad reach of the market. And I'm terribly excited to be an enabling force in that equation, because I really do believe that the internet itself will get much, much better as we're able to drive none out of business. So thanks. That. That. Okay, so I wanna give one shout-out, one point of disambiguation, and then ask a question to each of y'all and then open it up. Shout-out is that we would never be able to do what we're doing today with our new data software as a service without the kinds of platform of service that these folks are investing and making. So we're very grateful as a very small company that we can do very big things thanks to that. Drupal platform as a service is just an amazing, amazing efficiency gaining thing for us. Disambiguation, I'm talking about Open SaaS as something where some customers of ours subscribe to our software as a service. It's turnkey for them, but others in the world never talk to us and never pay us and are essentially getting the same thing. It's just they're doing more work to self support and self rely. And that ability to go back and forth between a software as a service context or a self service context using the open source underlying distribution is really what's key in terms of our value proposition to our customers and the lack of vendor lock-in that we offer to in particular public sector customers where we're paying for this stuff with tax dollars in the first place. So that's what I mean by Open SaaS. And I think it's worth pointing out that I think what Robert is speaking about more with charging people with credit cards for a service that they sign up for and subscribe to online may not have that same dynamic. It makes a software as a service that's easy to build and maintain and affordable and powerful for the company because it's built on open source tools. And those open source tools are themselves affordable and robust because they're contributed to by a number of developers all around the world. But there's not necessarily the same context of the person paying you the credit card this month is then gonna go download the same code that they're getting in the service context and self support. So a subtle point, but I think it's really interesting that there's so much that we could talk about in the universe of Open SaaS and in the universe of how to do that well with Drupal. So that's my point of disambiguation, questions. And I'm gonna ask you to get a little commercial and competitive here and I can do that because I'm not in the Drupal platform of service business, but I'd like to ask each of you about your company's best product offering for people Drupal developers considering building software as a service based on Drupal and why it's awesome. You don't have to say bad things about others but why yours is particularly awesome. So Chris, your site factory products, do you mind just giving us a minute on why you think that's an awesome offering for software as a service in Open SaaS? Sure, site factory is a product that came out of our original Open SaaS in some ways which was Drupal Gardens. Drupal Gardens was a tool that was very much in the vein of what Robert was talking about where you go with your credit card, you sign up for a year and you build your individual website and it was a general purpose thing. What site factory has enabled us to do is to allow folks like Heartland and folks like Warner Music and other large enterprises to go take their specific distribution, not a general purpose one that's supposed to meet every conceivable use case even though it is quite malleable, everything from your dentist site to your insurance broker site to your soccer team's website can be built in a Drupal Garden sort of way. Site factory allows you to be much more specific in terms of the use cases you're going after because it allows you to plug your own distro into it and it gives you all of the tools to actually manage the updates across a really large network of sites. So out to potentially, in most of our customer implementations, thousands of sites, and the underlying technology runs, tens of thousands of sites in our wider SaaS product. And all these things intersect with some of the engagement layer services that we're also rolling out. So it's also important to note that it's great to have a platform to create and run the site, but there's a lot of added value that you can give to customers on top of that by, you know, through instrumentation or products like AcquiaLift that give you tools for adaptive personalization, user management, those types of things. Awesome. Robert, a new kid in the block, platform.sh. You have that right? That's right. Why is it awesome? It's awesome, particularly in this context because to build it, like I mentioned, we first built a SaaS site, you know, our platform.sh site with all the credit card taking details and the site launching details. And we coupled that with, you know, a system where you sign up for and it launches as a, you know, a platform as a service, it launches a cluster for you where you can develop a Drupal site. And it's only a slight twist on that story that makes what we've built actually a business in a box for somebody who wants to make a distribution-based software as a service business. So if you have a distribution that you want to launch as a software as a service, all those parts that you're not supposed to worry about, the payment taking, the invoicing, the dunning management, and of course the hosting can be provided by this business in a box because you'd use the same infrastructure that we use to take payments and manage the customer relationships. So you've got the monetization model built directly into it. And instead of launching a platform as a service cluster, you actually launch a website for your end customer, but it retains the platform as a service flexibility. So in the case of REST on site, they can hire an agency or their cousin to come in and actually work on the theme, maybe customize it a little bit. So it retains the best of both worlds. It retains the link to the upstream code repository where you're maintaining your distribution that they can't touch, but it gives them a space where they can add modules, add themes, add libraries to customize it the way that they want to. And they just see the customer just sees that they've got their own website. They can hire an agency, they come talk to us, they get access to repo, and then they can do that. And it's nicely encapsulated, nicely isolated. And you've got everything you need to build a business around your distribution in one place. Pantheon one to rule them all. One dashboard to rule them all, right. So what's good about our tech for this market is our infrastructure model is different and we don't need to launch servers or clusters to support new customers. We have a highly agile infrastructure that we've got other talks at DrupalCon on. But the important thing is that we're able to create partitioning and isolation between sites, between environments for sites. So if you want to have a staging and a development environment for a site and not just work in live, we encourage that. And this enables you to build highly efficient site network style architectures without having to deal with multi-site. It allows you to cleanly integrate changes that come from your upstream, as Robert Douglas explained, as well as changes that are specific to a site, whether those are the things that you're doing as an extra value-added service to a customer or whether you're enabling the customer to use the Pantheon dashboard or tool set or just get repository directly themselves. And I think that we have the ability to deliver stability for large site networks in a way that is somewhat unique because we're able to isolate and partition each site without creating a bunch of busy work for anyone to do. You can have one site get really big without having to worry about what's gonna happen to the other sites. You could have one site be attacked by Russian hackers without having to worry about what happens to the other sites. You could have one site decide that it wants to become very, very customized along a certain line without having to worry about how that will impact the other sites. And I think that flexibility and agility is key as we're in the next, say, three to five years as we are figuring out exactly what the right models are and what the right products are in the world of open SaaS. And to Andrew's point, we would make it, our system would make it relatively easy for you to do sort of the best of both worlds where you could have turnkey, getting it from company X, that's you, the site provider, this thing directly on Pantheon and you're kind of managing all of that and they're just getting the website at the end of the day or you could also say, but if you wanna do it yourself, here you can launch it on Pantheon and have a SaaS-ish experience, but you're in total control of the development of the site. Ability to offer hybrid models like that is something I think we bring to the table. Can we all agree, everybody at the table, that Drupal multi-site can die in burning hell? No, no, no, no, no, you cannot agree on that. John Pugh is moderating a discussion on the multi-site question. Oh, really, okay. The debate, the great multi-site debate. Yeah, yeah, so it's... All four of you should come. Okay, 1045. 1045 tomorrow, do we know what room it is? The 8A. 8A, Boughroom 8A. If you wanna see some developers throw down the merits and cons of multi-site. And other gloves really come off. Yeah, it's a Bough, it's like off, not off the record. So, we've got 10 minutes for questions, but while we get that queued up, please, please, please go to Austin2014.drupal.org slash schedule and say that we're awesome because that's the only reason we get to do this and if we're lucky, get to do it at a future Drupal con. Meantime, love to open up the floor to questions and John, feel free to ask a leading and provocative question. Thank you. What do you think about multi-site? I don't have no opinion on that. I'm an impartial moderator. So, I'm involved in the EGGER project and so something I'm very interested in is the possibility of open pass and the idea of how we all have these software tools like Chef and Puppet and et cetera to have our configuration and servers as actual software. The concept of open sourcing that is very appealing to me and I know everyone, a lot of people are doing this now and with independent repos and vagrant tools and all sorts of stuff like that. So, I guess I'm just curious how what your companies are thinking about that and how we might be able to kind of open up some of these things because so much of what you have is basically standard open configuration things like whether it's varnish or certain configurations. I feel like your business models are amazing and I have a ton of respect for you but the value is really coming from your secret sauce or whatever makes you unique. So, I feel like I'm just curious what if any thoughts or where you guys' companies might be going in terms of maybe releasing more or at least opening up how you can have a good standard, more standard or at least less chaotic suggested configuration for Drupal. So, I'll take my answer on that question. Yeah, so most of what we do is open source and we're actively trying to get less secret sauce. We look at secret sauce as it comes in two flavors where 99% of your secret sauce is actually like rotten vinegar and it's not so much the secret sauce that drives a business as it is the technical debt because you had to hack up some solution to get your stuff to work at a certain point in time. And then 1% of your secret sauce is actually something that you've figured out that's very unique and you've got a particular insight around and that's kind of what you're building your business on. And in our case, we've already pushed most of the stuff that lets us do our platform work upstream into system D and that's gonna be on every Ubuntu server and every Rails server. So, it's kind of cool that our code's gonna run on a lot of servers that don't even have anything to do with Drupal. So, at the core of all the stuff that we did low level that makes what we did possible, it's already open sourced and that's intentional on our part. Like we're actively looking to get more of our container solution built on that out of our custom thing and use something more commodity like an OpenShift or a Docker. We're not sure yet. But when we do that, it's less us throwing our stuff over the wall and more working with upstream because we wanna make sure really for us, the value is that we don't, not that it's nice to open source things, but I'm not a fan of companies that just throw code over the wall. Like really what you want is you wanna work with an upstream broader community so that you get something that's supported and that has value to us as a business too because then it means we can stop supporting things internally. Like any, all your poison secret sauce is work that you have to do every six months or every three months to keep going. And then beyond that, like the real value that we bring, it's all just orchestration and you've already cloned like 99% of what we do. So, and the truth is it's not like, we could, there's code that could be released but it's actually, you could just like use the product for an afternoon and figure it out. It's not really, it's not really, I don't feel like there's, and people have different opinions about the particulars of how they wanna do that. So I don't know how much value there is in saying we synchronize database by using my SQL dump and then loading it into the other database. Like that's what anyone would do. Like do I need to open source my gist? I don't know. So some of the stuff is, my answer is there's a little bit of stuff that we'll always keep to ourselves. There's a lot of stuff that we're actually trying to push out upstream as an intentional act. And then there's other stuff that kind of seems too obvious to figure out how or why we would open source it. You covered it perfect for me. Yeah, the only other thing I would add is that there are other aspects of what we're doing that we're also trying to push hard on getting back into various open source communities. So it might not be, the core of how we orchestrate servers and sites on servers and those types of things, but there's a lot of value that companies that are managing tools like this, whether it's SaaS or PASS, can contribute back to all the stuff that these things are built on top of. So whether it's contributing back to Tungsten or to StatsD or Graphite, trying to move other open source products forward at the same time, it's important. Yeah. Other questions? Come on, really? All right, let me ask you guys a question. Who in the audience actually wants to run a product-based business? Okay. Bravo. Who, like of those people who showed their hands, how many people are thinking that's like an automated subscription-based thing? Okay, interesting. Okay, yeah. I'm just curious like what people are thinking in terms of how they wanna be able to leverage this stuff because we're in the room for a reason. And I think that reason is that we're interested in exploring alternative ways of delivering service to people and making us and them happier at greater scale. So, I have... So interestingly enough, the question was what vertical to serve? Dries was asked that question on Reddit during an AMA Ask Me Anything. And he identified SAS as the highest margin, biggest opportunity model to go into, as opposed to customized hosting or digital agency. And he in particular thought that e-commerce and marketing tools were the hotspots and since that so completely conformed with my view of the world, then I stole his AMA as the beginning of my larger presentation, which you just saw the 10 minute version of. And I would just add one, there's a tendency when thinking about this to think, try to think too big. I think that actually going more niche, like having been a consumer of many marketing, marketing SAS tools over the past few years, I can tell you that most of them suck. And it's because they're trying to be all things to all people. And that I think there's an incredible opportunity as more and more marketing moves to the internet and people need to be smarter and smarter about it to say, I know not how to do all internet marketing, but rather I have a good idea of how to do internet marketing in a specific context for a certain audience, for a certain type of product. So if that's something where you feel like you have expertise, that's probably a solid goal. It's about audiences, isn't it? It's really about an audience. I would think of it, who do you know? Whose problems do you understand very well? And as long as they have a budget to address those problems, that's potentially a good vertical. And I would look for not the biggest market, but where you think your expertise is the deepest. You see people doing things like building LinkedIn for doctors and having great success. So what group of people do you know really well that you can build for? And what are they missing in specialized tools? That's a good way to do the analysis. Hi, I'm Sheldon Rampton. I work with Andrew, but since I see some of you guys here who I've encountered in the past who are really smart, I thought I'd like to ask some questions. Or one question, and if Andrew wants to answer it too, that's fine, but you guys are the ones that I'm... And it just occurs to me that the idea of selling software as a service is kind of probably the hottest new idea in terms of ways of productizing Drupal, but there have been a number of other efforts, for example, the Drupal App Store that people are trying to embed into distros and some others. And I know that... I remember hearing Robert talk a little bit about that and challenges with that at a Drupal camp once. And I'm wondering, are there lessons from other attempts to productize Drupal, both good and bad, that you think we should think about as we think about how to productize SAS and open SAS? So since you attended that session whenever long ago, thank you. What I've learned since then is that the missing element has always been payment models and the business model behind it. So nobody has actually taken the dive to... Well, very few people have taken the dive to actually charge money to access of an installation of a distribution online. For example, it seems really obvious, but I don't think that the tool set has supported it, so it's just been hard. And if you know how to build a Drupal distribution, you don't necessarily know how to make it an online product. That's why I'm really excited about the commerce license billing modules that you can get. Yeah, the other thing that we found is that building a pure SAS where you're trying to attract people to come to a website and then buy access to that site or access to that service with a credit card and not engage with them personally is really hard. It takes a lot of resources. So we've put a lot of resources behind it with Drupal Gardens over the years because that was the focus at the beginning was going out and engaging individuals in very small organizations. So I think where we've seen more success commercially is where we've been able to cultivate deeper relationships with a customer based around really strong expertise, whether it's companies like Andrews or it's companies like Heartland Dental, they already have a business plan in mind and they have a plan for attacking a deeper relationship with more of kind of an outside sales model. So people are interfacing with people, so we're not, dentists aren't going on Heartland Dental and swiping a credit card. That's part of a comprehensive service and that's gaining a lot of traction and these are the types of services that we can support now. And these are, when you look at, talk about finding a market, finding a vertical or a niche, those are the types of relationships you can create. You don't have to set yourself up for being the LinkedIn for doctors or something like that. One last question really quick. We're about out of time. I'm not sure if my question applies to everybody in the room. My product will be a custom compiled JavaScript based on inputs that you'll be able to unzip into a directory of a website hosted anywhere and it will be based on whatever data you put in. You'll get this interactive JavaScript product. Will the commerce guys, there'll be a free version, anybody can come and build this custom JavaScript and get their tar file or zip file out, but then there'll be a subscription where you can get more. It'll be a greater product. I have a recipe for you. Okay, cool. Commerce license, commerce license billing and commerce file. Okay, great. So your product will lend itself to that rather than popping up websites. It's not my product. They're modules on Drupal.org. Okay, thank you. All right, folks, thank you so much. Please again go to austin2014drupal.org slash schedule and say we're awesome. Thank you so much for your time. Thank you.