 Okay. Hi guys. Thanks for coming at five o'clock to a session. Awesome of you. I'm Karen Borchard and this is my wonderful colleague Mike Potter and we are from Phase Two and we are two of the members of the Open Atrium product team as well as some additional things that we do at our jobs but that's that's how we are representing ourselves here today. This is a session called Open Source Products Unicorns or Game Changer. It is, I promise there will only be one or two pictures of a unicorn. So we're going to go ahead and get started and talk a little bit about that. So there's a lot of speculation and a lot of questions around open source and productization in open source. So at the business summit yesterday and pretty much every Drupalcon and Drupalcamp and business summit there are questions of can we create products in Drupal? Can we create open source products? Do products work in open source? And so there's a lot of questions about how do you build a product the open source way? How do you prevent competition when you can't protect the code? And how can you make products work when you're a services company? So these are the questions we hear all the time. And a lot of people ask us about it because we've had some experience in working on products and distributions of Drupal code like open publish and open public and open atrium. So the question often comes back, you know, is it even possible? Are we just kind of fooling ourselves into thinking that there that you could create an actual product in open source and take it to market successfully and build even potentially a successful products company in open source? So it is the question of today we're going to play a little game called Unicorn Reality or Game Changer and talk a little bit about some of the myths and some of the things that happen and that people think around open source and products and what the reality really is and how open source can actually be a game changer because we actually believe that open source is not only a place where it is possible to build products but a place that it can be even more beneficial or a game changer to create better products. And we're going to talk a little bit about use the context of open atrium which is a distribution that we built and launched and sent out into the world and have been working on for the past year or so. So a lot of our examples come from our experience there. And so why? I mean this is a good question. This is not because we are products pushers or that we are trying to change the way that everybody runs their Drupal companies. There are a million wonderful things about being a services company in Drupal. We know because we are part of a services company in Drupal but as businesses and business owners start to think about how do we diversify? How do we create more value? How do we push the code that we're building ahead? People start to think about products and we don't want there to be limits. So we're excited about the idea of what can happen with products in open source and that's why we're talking about it today. So there's three places that we're going to talk about. We're going to talk about product development which is actually building the thing. We're going to talk about go-to-market which is taking the product to the rest of the world and getting it out there and selling it. And we're going to talk about balancing services work and product work. And so we're going to look at a few myths, a few realities, and a few game changers in each one. Okay, ready? So myth, first myth. The only way to build an open source product is with a SaaS-hosted distribution. This is a myth that we hear a lot. People think, you know, if I can't build, if I can't create a hosted SaaS-spin it up distribution, it's not a product or it's not an open source product, it's not a Drupal product. And that is a unicorn. The reality is there are tons of business models around open source that can work. Modules hooked up to services like you see with a product like NodeSquirrel. Open source code packaged with services and integrations that the services and the integrations that are coupled together with the open source code create that product. Or even productized service offerings around open source code can be great examples of, you know, product companies or product-like companies that really take advantage of, you know, things like fixed pricing and really, really clear parameters around a product, but use open source code. So definitely, definitely not just if you have to build a distribution and have a SaaS version of it in order to have an open source product. And the game changer here is open source allows you to focus more on finding the right business model and less on protecting your IP. So when you're kind of free of the idea of worrying about how do I protect what I'm building? How do I protect all this code and make sure nobody steals it and nobody takes this idea? If you spend your time working on and thinking about your business model and how you're actually going to take it to market, you're spending your time better than worrying about, you know, okay, how do I, how do I make sure that nobody else builds, you know, the next best widget or the next best feature? So the hint on this one, we have a hint on all of these, is don't be afraid to change it. Don't be afraid to change the business model if the market changes or if the business model changes or if the product changes or if something's not working. So in building products, focusing on how you're going to get it to the world rather than how you protect its IP is really big. Okay, this one I'm passing over to our chief, our chief of all, all contribution on open atrium mic product. Okay, so is this on? It doesn't sound like it doesn't. Okay. Okay, so the unicorn myth here is that no one wants to work on somebody else's distribution or product or module and you know, part of that's maybe true sometimes, but the reality is, if you can focus on what you really want to do and focus on building with the best contributed modules, which is what we did in atrium, then you've got more contributors. You don't have to do it all yourself. The example of this is in open atrium, one of my development mantras really early on in the Drupal 7 project was proudly invented elsewhere, which I stole from Angie Webchik. She was talking about it in terms of Drupal 8 at the time about symphony and those things, but I applied that to open atrium. So, you know, the, the, what we did is we built open atrium on the Panopoly distribution and we let Panopoly from Pantheon do all of the layout control and all the WYSIWYG. You know, I didn't want to spend my personal development budget writing another WYSIWYG editor for Drupal. That problem's been solved. I wanted to focus my time on the actual collaboration pieces that are in open atrium. So, by building on the community, building on the best modules out there, we ended up with a much, much better product for a much, much smaller budget. So, if you're wanting to do a product and you've got a limited budget, you know, build on the best of what's out there and don't be afraid to contribute back, you know, help them fix bugs because those are going to help you in the long run. So, the game changer there is other people help you build a product in a really cool way and the hint is don't let your ego get in the way of your best product and I, I, you know, I practice this all the time. The more contribution I can get, the better, the happier I am, the happier I am. And the better the product. And the better the product. Right. Okay, so now, so outside of just developing it and building it, you actually have to get the thing to customers and you have to get the thing to market. So, we're going to talk about some myths around open source and products in the go-to market strategy. So, myth. So, we talk about this a lot. I think I say this at most every dribble con. There's a myth. You cannot sell open source code. The reality is you can, in fact, you just cannot prevent anyone else from doing so. That's actually a very common myth around, around open source licenses and it's something that people need to know. If you don't know it, it's a good, and helpful thing to know. The game changer is that in open source, you differentiate on what you know and how you deliver not on the thing that you built or the, or the IP that you own. So, that's actually a really big deal. And in fact, it makes for a better product and happier customers because again, what you're focusing on is how you deliver it, how you serve your customers, and how you, how you make it work for the market and less on the exact, exact perfect thing that you built. Next myth. If I'm going to have a product, I'm going to need a partner program. This is a myth that we hear. People think, oh, well, you know, these product companies, they always have these, you know, affiliate programs and partner programs. I'm going to, I'm definitely going to need that. I don't even know how to do that and I don't even know how we would do that. The reality is if you aren't both getting something out of the deal, you're not partners. So, the idea of taking something to market with a partner or a partner program really is all about creating mutually beneficial partnerships. But the game changer is that in open source, open source is built on the idea of collaboration and partnerships. So, finding what is beneficial to you and what is beneficial to me and how can we take this product forward into our customers this way can make for really, really powerful partnerships. A really good example of this, I, we're giving pantheon all kinds of love with monopoly and this, but great example of this is, you know, we had, we had a lot of people asking us early in our product days, you know, oh, well, is there a hosted version? There are two questions. Is there a hosted version? And is there anywhere I can just spin it up? Those were always the questions. I just want to try it out. I just want to spin it up. Well, we're not a hosting company. That's not what we do. It's not something that we, that we really offer our customers. So, for a long time, we kind of thought that the answer was no. And it actually sometimes stood in the way of us bringing customers onto products like open atrium and open public because people couldn't see it. They couldn't spin it up quickly and easily. So, they couldn't evaluate it. And it was a really big problem. We ended up having a really great partnership, a true partnership where there's mutual benefit with pantheon on this because they said, hey, we can do that. We can host distributions and we can get a really quick spin-up of these things. And we can do that all on our side. And it'll be great for us because we'll get more people coming to pantheon. And it'll be great for us at phase two because we don't have to provide that service, but we can say yes. And being able to say yes to customers is huge when you're building a product. So, now, when people say, is there a hosted version or can I spin it up and try it out, our answer is yes. And so, finding the true benefit to each is the hint here. But in open source, you can really do that because you're at a place like DrupalCon where you see all of these different partners. People want to help each other out. People want to be partners with one another. It's all just about finding the real true mutual benefit. Okay, this one's yours. So, the unicorn myth, I can't build a product because the community needs too much in the issue queue. Like, I'm going to spend all my time answering issues in the issue queue. If you're a module maintainer, you can relate to this. The reality is that your issue queue is actually your friend. Community members are your first customers and you should be treated as such. The kind of better you treat the people in your issue queue, the better they'll treat you. And our game changer is community members can become great allies, marketers, salespeople, contributors to your work. Listen to them, thank them all the time, and be a great community member on top of that. That's my background before coming to phase two. I was heavily involved in the community. I still am with features and things. It was really important for me to keep the community spirit to this. So, the example for this is I'm going to pick on David Snopik here who's in the front row. He was greatly involved in the alpha version in the issue queue, reporting bugs. He was really interested in the whole case tracker thing which we were telling people we weren't doing because we just didn't really have the budget. He's like, well, I need a case tracker so I'm going to write one. So, he wrote the work tracker module which eventually became part of our core distribution that you get as part of open atrium that does kind of the old case tracker issue tracking stuff. And he's been just a really valuable ally and community member and great to have somebody else who understands the stuff to toss ideas off of. And it's resulted for you as a community in a much, much better product with better functionality. And then it's not just this phase two thing. It's really shows that other people can get involved. We do value having other people involved. And so, we encourage that. And I think any product that has that model, it's what you put into it, the more you put into it, and the more you put into that community, the more your payback you get from that. All right. Now, a couple of last myths in unicorns around balancing products and services. This is a big one and I'm just not going to lie to you at all. This is really difficult. It's really, really hard to do. Everybody has trouble doing this. It's a known thing across open source and non open source alike. If you are running a services company and you make your living on services, it is difficult to add or to compliment that with products work. It just is. But I think and we think that there are some really great things, especially in open source that really help it. So myth. Myth is your product is a completely different offering or area of expertise than your services. So we have heard time and time again people say to us, oh, yeah, I really want to create a product. What we want to do is get all of our developers and all of our guys in a room. And what we're going to do is we're going to think up a really cool idea for a product and then we're going to build that product. And that is actually a really big red flag. The reality is products work best when they follow your core competencies as a company. So a lot of the work that we've done in building open atrium was in helping to understand how our clients collaborate and communicate with one another and share assets and information. Similarly, a lot of our work on open public, which is a distribution for the public sector, was built on building government websites. When you can have a product that actually follows your core competencies and is not a super separate thing from it, you are actually bringing so much more expertise and thought leadership and quality to the product and that's going to really show. Game changer. Services work is built in market research. This is true and this is the same hint as before. Listen to them and then thank them. If you are getting to figure out what you might want to build in a product by working with actual real customers, then your product is going to be more relevant and it's going to be a better quality. So if you are working with a client, you've built a little prototype of a product and they say, these are the 10 reasons that that thing sucks, just say thank you because that would have cost so much in market research for you to get. What real customers think of your product is the best thing that you could get. And then this is our last one, the myth. You need a dedicated team in venture capital to truly launch a product. A lot of people think this or wonder this. If I'm going to create this product or I'm going to create an offering out there, I have to wall off a whole team and dedicate a whole load of venture capital or outside money in order to make this happen and put them in a special room somewhere so that they can go off and do that and it won't disrupt our services company. The reality is products can and should be built with more of a product maturity model so that it allows you to say, let's take something from concept to a research and development phase to more of an operational phase to a true product with where there are milestones and thresholds and you make investments. That's actually how product investment works in the real world. It doesn't happen with just dumping a whole bunch of money into a product. It happens by investing in ideas and prototypes and seeing proof of concept. The game changer here is, Potter has a lot of experience and so he's going to tell you about it. You're a services company so try to find clients within your current services company that are willing to work with you on this. The going havesies with a client to fund your product gives you the great client feedback. You're actually using your product to solve a real problem. It makes the product a whole lot better and they're helping you with the funding. You still make that investment. The client's not paying all of it. You make an investment. You have the client understand what you're doing, understand that they're building a site on a maybe immature product but that they're going to help develop that and that they're putting money into this. This was actually a really key success factor for open atrium last year actually at around this time. As we were working on a project for an organization called AHRQ which is the Agency for Healthcare Quality and Research, Research and Quality. They needed a collaboration system. It's basically an internal internet and they really were interested in atrium. They really liked where it was going but this was last May the alpha had just come out. For example it didn't have event calendars and they really, really needed event calendars so they funded the event calendar development in open atrium. Ended up being a huge part of the product feature set. They were able to drive it so it exactly met their requirements and their functionality so it was the best of both worlds. If you're upfront with your clients, a lot of clients are willing to do this. They're picking open source. They're picking Drupal for reasons. They want to be open source contributors. Some of them will want their name out there. Some of them might not but they really are interested in getting involved in helping with this. Don't pretend or don't think that your clients can't help you with this when in fact they can. Right. When we say going havesies, what we mean is that sometimes you can have a client who will be willing just like AHRQ to fund a specific feature as it relates to the thing that they need or that they want built but you can also bring it into the product. You can also say to a client we will invest some time, some extra time beyond the budget of this project in order to build this in a more product way, in a more generic way or in a way that we can reuse and going half season contributing to both a client project with some additional investment can really boost your product development time and budget. Then you have the work of the project and the work that you've invested and you go together on it and it creates a great product for your client and a great product for your company. So takeaways, I'm just going to reiterate our few hints. Don't be afraid to change your business model. That's one of the beauties of open source is that you can really figure out what's working with your product, what's happening in the market and focus your time on that rather than on proprietary code. Find the true benefit to each partner when you're engaging in partnerships. Treat your community as your customers. Be upfront about product development with clients and finally don't let your ego get in the way of building and delivering your best product. I put that one last because I do think that it is an amazing opportunity in open source. It's what we all sort of ask each other to do in open source is to contribute and improve and continue to build things and that goes for products too. It doesn't stop at community contributed modules and things. So those are our takeaways, those are our myths debunked, some ways that we think it's a game changer. If you have questions, a lot of times people have questions or just want to talk through ideas around open source and products and productization, we would be really happy to help answer your questions. Oh yeah, maybe just jump up to the microphone if you've got a question. Yeah, it is on. So you guys have been really good about updates in open atrium since Drupal 7, but there was a period with atrium in Drupal 6 where that's not so great and open public and open publish both have known security issues on Drupal.org right now. There was a period with open publish for over a year where people were trying to get patches committed to get those updates made and there was no response from phase two whatsoever. So while open atrium is going well, how do you reconcile, and I know you guys work primarily in open atrium, but how do you reconcile as an organization the need to maintain those or transfer ownership of them, open it up to additional contributors versus just keeping ownership and letting those things go stale like that. Right. It's a great question. Super valid question. I'm going to start and then you can finish. Yeah. Okay, so one of the very truest answers to that is we've learned a lot, and we haven't always done it right and I don't think that any of us think otherwise. It's really, really challenging to figure out all of the best ways to do this. These are some of the lessons that we've learned. We focus a lot more time, energy, and investment on making sure that things are right on open atrium as one of our more active products right now because of those lessons that we've learned. I will also say that the part of how we figure out where to spend that time and energy because, again, it is limited as it is for all of us, is where we are using things the most. If we are using open public or open atrium over and over and over again to accomplish the work of our organization, we spend more time and we're able to spend more time really going through the community in the issue queue. Open publish is, to be really honest with you, a distribution that we don't really use very often in our projects. A lot of our projects don't call for it, and so it hasn't gotten as much maintenance and love, to be honest with you. We haven't always done it right. I'm not going to say otherwise, but that's why. That's how we've done it. To follow on that, just generally, first, it's what we came back to, like Karen said earlier, about making sure that your products fit with your core competencies. That if you aren't using your products, they're going to languish, and you need to be willing, essentially, to cut at some point and recognize that, hey, we're not really doing this, and maybe let's open it up to the community, which is what's basically happening with open publish right now, is we aren't using it, and so it's going to the community to maintain. Honestly, it does take some community people to stand up sometime, too. Anyone in here who's done modules, like I do features, and I'm always looking for people to help there, everyone's got limited time, and the number of people who actually contribute to Drupal is a very, very small percentage compared to the more people that use Drupal, and so it's sometimes very difficult to find people who want to step up and be maintainers. I think in all these things, when you put it out on Drupal.org, it's important to recognize that it's, phase two doesn't own these things. They are open source distributions, and we welcome contributions, but the reality is we also have limited money. We're a services company. We're going to get busy with client work at the same time, so there's always a balance. You know, my main thing is treat people as people. Sometimes in the SUQ, it kind of is like phase two owes people something for doing this. We're just community members, too. We're trying to do our jobs. We're trying to do the best thing. Karen says we learned from this. I think we're doing a better job with atrium two. I think we learned with atrium one. We were trying to kind of figure out, after we acquired that from development, see what is this thing, like a product, and what do we do with this, and how do you move that forward in V7 in some way? It took a while to struggle with that and talk to the community about what they wanted to do, too. No easy answers there. I just hope that we keep doing it better and that some of those things are more in the past. Certainly, if there's an issue in open public that's a security issue, that should be getting taken care of, because that is one we still do support. I have a question about the pricing model. You talked about open source products don't have to be software as a service. If you deliver your product to your client, they put it on their server, in many software licensing models, you're charging them on a per user basis. Once they have your code, you have no way to restrict what they're going to charge you, or what you're going to charge them rather. How do you deal with generating recurring revenue and selling the idea of recurring revenue when you're delivering an open source product that can't be licensed on any kind of usage basis? Right. From our perspective, it's a great question. From our perspective, we've never looked at or explored the idea of licensing if it's not in combination with some other kind of service. If it's not with a hosting subscription or if it's not with a subscription or we're not helping to maintain some integration or something like that, we're not going to just put the code on somebody else's service and then start charging a license fee for it. To us, that doesn't seem like a very viable model to just do that. In terms of creating recurring revenue, though, or creating opportunities for that, there are some ways to do that. A hosted version is certainly one. The idea of putting together a partnership where you say, we're going to integrate our open source code base with this paid service and we're going to offer these two things together as an integration and charge for that on a regular basis. That's a way that you can see some recurring revenue. The ability to start to create really specific service offerings and be able to create repeatable service offerings, even if it's not fully passive revenue, it does create recurring and easier to accomplish revenue. Revenue around training, that you perform the same training for a product over and over and over. Yeah, that's services. It's time. But once you've done it and you've built the curriculum and you've built the materials and you know how to do it, you can create that recurring revenue opportunity over and over. I think it's really hard to just create a straight up license on an open source base for the exact reasons that you said, but I think that there are some other ways to create recurring and potentially passive revenue there. Any other questions? All right. Thanks guys. Have a great afternoon. Have a good evening.