[Step by Step] The B-Word

Brian: [00:00:36] Hello and welcome to Step by Step, a podcast by Future Commerce, presented by Shopware. I'm Brian.

Phillip: [00:00:41] And I'm Phillip, and this is Season 9 of Step by Step and this is Episode 3 of 5. You're jumping in just mid-way through. We're right on the hump day of Step by Step week. We have been climbing a hill, so to speak, to answer a big challenging question as we talk with industry veterans and experts and eCommerce builders who have created massive stores and created the world of eCommerce as we know it, and we're asking the big thorny question, "Is open source still viable for the modern business?" So far, the answer is yes. But I think the real question we need to answer is, "Yes. And how do you do it well?"

Brian: [00:01:20] Yes. Yes/and. I love it. I think part of that is being really thoughtful about how you get into an open source engagement. Open source is big, a.k.a open. Like you can do a lot with it. Maybe anything, although maybe not anything, but...

Phillip: [00:01:38] Anything, anything.

Brian: [00:01:39] Literally anything with it. And so how do you set yourself up for success when you enter into a project like this? Well, you need to plan and budget well. You need to make sure that you have guardrails going into this so that you can actually have a plan and don't get yourself into trouble, because I think that that's something that maybe open source picked up a little bit of a reputation early on where people were just like diving in without making smart plans, building something that was over or under architected or maybe was done in such a way that because they could do anything they did. What's the Jurassic Park line?

Phillip: [00:02:25] Your scientist was so preoccupied... That often that's really what it comes down to. I think  [00:02:31]there are a lot of decision criteria that go into not just selecting software, but selecting the strategy by which you build the software, which is, I think, just as important. [00:02:42] And that decision criteria sometimes come back to a lot of our biases in how we bring our full selves to work in our role. Believe it or not, people choose software today... This has come up on Future Commerce for the last year over and over again. We choose software today based on not just how it fits in our business or whether or not we're ready to purchase it, or even based on the price or even the infrastructure model. We base a lot of our decision making on our future career prospects and our prior experiences, and those things also inform how we build. They also inform who we build with.

Brian: [00:03:20] Absolutely. 

Phillip: [00:03:21] We tend to wind up choosing things that are quantifiable and the unknown becomes a really tough thing to get apples to apples with when you're working with a new product, a new vendor, a new delivery solution, or even maybe a new business model in the way that software is being built. If you're used to Waterfall, Agile seems really scary and all of these things contribute to, I think, the black box that is software buying. It makes it really scary. And that's where I think projects fall flat. When you mix too many unknowns with too many of your biases, you become inherently challenged. And we've seen a lot of projects in the open source space go sideways over the years, haven't we?

Brian: [00:04:04] Yeah, definitely. Especially if you have legacy software. You're coming into this and you have a lot of technical debt or you have legacy pieces that you can't migrate away from as a part of the initial project, you're going to have to account for those. And also you don't want to bring about too much change management at once. So there's a lot to think through. Yes, you need to make changes. Yes, you need to build something new. You also need to make sure you account for the parts of your business that you can't make changes to upfront. So there's a lot of planning that has to happen going into these things. And so, if you're migrating away from a legacy piece of software and you have complex requirements that might require you to think twice before reaching for the easy button SaaS solution, this podcast is for you.

Phillip: [00:04:57] Yeah, and I think we said this early on in this series, if you're trying to wrestle back control from the CMO, and we love us some CMOs. If you're going to write letters...

Brian: [00:05:08] A lot of CMOs listening to this podcast like, "Oh. Oh, wait. Hold up."

Phillip: [00:05:10] "Oh, I didn't know you guys felt this way. That's a little too punchy, Phillip and Brian." But, in reality, software development is really tough and it requires some skilled people and some really complex change management to get to where you're trying to go. And we all need to be rowing in the same direction in the organization. And so it's going to take a wealth of partners. It's going to take a lot of technology and a lot of planning to get there. And I can't think of anyone to help us kind of make sense of that, then somebody who's been doing it for over 20 years. Today we are being joined by Stephen Stark, who is the Founder and CEO over at ITG Commerce, who's going to help us figure out how you buy, build, plan, and budget well for open source. And he's going to teach it to us Step by Step. And today we are joined by Stephen Stark, the Founder and CEO of ITG Commerce, who's going to demystify how to plan well, the power of planning well when implementing open source. Welcome to the show, Stephen.

Brian: [00:06:12] Welcome, Stephen.

Stephen Stark: [00:06:14] Hi, guys. Thanks for having me. A pleasure to be here.

Phillip: [00:06:16] Yeah, it's a pleasure to have you. Let's just get the myth busting out of the way up front. Is open source still relevant for the eCommerce industry? Some people would say, "Maybe." Some people would say, "No." What's your take at ITG?

Stephen Stark: [00:06:33] I think more than ever it is, absolutely. I think that the innovation that's coming out of the open source community is still alive and well. I think we've seen investments and platforms that are embracing that still very active and growing in new markets. So yeah, we're definitely big proponents of open source and have been throughout our eight years in business and proud to be a promoter of it. Absolutely.

Phillip: [00:06:59] Amazing. We're both products of the open source ecosystems. Right, Brian? 

Brian: [00:07:04] Oh yeah. 

Phillip: [00:07:04] I think a tremendous amount of trust is placed every day on the Internet, which is fundamentally an open platform and we continue to build on it today. Commerce wouldn't happen without open source. What is your perspective there at ITG? I know that you've built quite a business servicing prestigious companies, well known brands, commerce implementations of all sizes. What's your superpower? Is it planning well? Is it helping sort of guide folks through what is a very complicated and probably tumultuous time in their business to be implementing some sort of digital transformation?

Stephen Stark: [00:07:38] It is. We got our start many years ago really focused on integration, sort of knotty integrations of some commerce platforms with different ERP systems and CRMs, etc., before a lot of those things became commercial connectors. So we very much grew up as a very strong back end development company in that sense, dealing with those and matured over time to include other disciplines, business analysis, design, of course solution architecture, QA, and everything. But [00:08:15] at the core of any project, any engagement we start is good project management, good ownership. And and we have an extremely strong product ownership team. And one of the things we definitely focus on with them is expectations setting with the client from the beginning, getting to understand the personalities of the client, the various people who would be involved. And we find that setting those expectations of getting to know the people, that's where everything starts before we get into the the nuances of the technilogical decisions. And we tend to do that in a discovery phase, which we find to be very effective. But again, it's any project, whether it be software or something else, there's a big human component of it, and I think getting defined up front, getting the communications defined upfront is extremely important. So that's where we start. [00:09:19]

Brian: [00:09:19] I'm sure I'm about to quote somebody, but I don't know who when I say that 90% of a project is managing expectations. {laughter}

Phillip: [00:09:29] I heard that somewhere before. I'm not sure. I can't remember where.

Brian: [00:09:34] I love the managing expectations component, what you just talked about. And I wonder, so we're talking about open source eCommerce. And so when you have clients come to you for the first time, what are some of the things that you have to level set and expectations set, specifically around building on open source commerce and educate on really? Because that's part of expectations management.

Stephen Stark: [00:10:04] Well, I think it's looking at the possibilities that that brings on the positive side and measuring that against all the options that are out there. So with an open source product or platform there are a lot of vendors, there are a lot of extension vendors, there are a lot of options out there. So one of the reasons a client might choose an open source platform is because of that. And rather than being overwhelmed with those choices, we like to help guide them again through an initial phase and provide sort of best of breed options for them to extend the core platform they're working with. And we like to bring new products, cutting edge things to them as well, maybe that aren't even there from the sort of "main line extension vendors," let's say, and trial those things out or POC them right from the beginning to see if it's a good fit for their use case. Now, having said that, if you're going with a let's say a SaaS more closed source type of product, it is there, it's a checklist, it's a little bit more straightforward. And so we have to help our clients, of course not look at every option out there because then we'll just look at every option. We'll never get on with the project and they'll never have what they came to do. So it helps to have an experienced partner. Fortunately, we have quite deep experience within our team that can help our clients kind of, again, marry that optionality, all that exists out there, using things we've tried and are true to us and in other vendors and at the same time keep them sort of focused on their deliverable because they inevitably have one that they came to us with.

Phillip: [00:12:02] They have a success metric too.

Brian: [00:12:04] Yeah.

Phillip: [00:12:05] Which is like a delivered, shipped, final. Now we can get to growth, which is what I'm assuming most people are after, some sort of cost savings in 2022. We're also in profitability in cost saving mode now, not just grow, grow, grow.

Brian: [00:12:18] I think one of the key words that I heard there though, was focus. I think that's the beauty of sort of working with open source software. You have the ability to do so many things. [00:12:31] You have the ability to really serve your customers' needs, but you have to have a discipline and focus and vision that you can guide back to when you go build on an open source platform. [00:12:48]

Phillip: [00:12:48] I'm having flashbacks. I don't want to go down memory lane. It feels today like back maybe ten years ago you would adopt one piece of software and it was going to move the needle in your business. And it feels like today really it becomes sort of a a yak shaving exercise where to adopt one piece of software, you actually have to adopt three or four.

Brian: [00:13:07] Three? Ha. Ha.

Phillip: [00:13:08] You have to make a decision in a whole ecosystem for the next ten years. And that's where I guess the first real question here, Steve, is what are some of the common pitfalls when you're estimating those software investments for your clients? What are the things they get hung up on? And how do you sort of help streamline some of that to get them down to making the decisions that they need so that you can help them be successful?

Stephen Stark: [00:13:32] Certainly. Well, I think back to your previous point, one of those pitfalls can be are you adopting software now because of an adoption of software you made eight years ago? And so that can be a pitfall.  [00:13:47]At some point you need to deconstruct what you have and make sure that you are planning for the future and not bolting on to a good or bad decision from the past. [00:13:57] But I think the beauty of integrations and where things have gone certainly in the last several years, a lot of that becomes easier to change one part of your system without having to deconstruct everything. I think when we work with merchants and they're planning out their next program of work or they're looking at their roadmap, I think the things that we definitely encourage, especially if we're starting to estimate a project with them, is looking at the integration points of if they're replatforming their commerce platform or they're changing out in ERP, finding those integration points, finding the best solution, whether it be a custom integration or some commercial option to do that, those can be very difficult. And sometimes we find that merchants overlook that significantly. Specifically, if you're looking at an ERP to commerce platform integration, that's your business. I mean, it is the business. And so we like to start with the biggest pain points possible. All these things we're mentioning, they'll come out, and if there can be a good collaboration and an up front, you'll probably hear me use the word "discovery" more than a few times on the show, but to really flush out what the project is going to look like before the client makes significant investment. I run an agency. I work with marketing agencies. I have lawyers and accountants. I go to them and I say, "How much is this going to cost? When is it going to be done?" And that's what I expect. At the same time, I know I'm a bit hypocritical because I go to our clients and I want to work with them on fleshing out the best solution and know that if we just try to tell them how much it's going to cost and when it's going to be done right upfront, we're probably making a mistake. So I see it from both sides. We talk to clients sometimes and we say, "Hey, let's do a 4 to 6 week design phase. Let's get your principals in the workshop with our principals and flush this out." And they look at it and they say, "What? After X dollars and six weeks I'm going to have a document? What's that worth?" Well, what it's worth is what it's going to save you on the back end, typically. And I think that there is tremendous value in architecting as much as you can and in POC-ing what you can and making sure there's business alignment up to the CEO, whoever is authorizing, before you get deep into development. And that's the biggest pitfall we see is people wait, wait, wait, wait, wait, wait. And then rush into it.

Phillip: [00:17:18] Can I ask you for a definition, Steve? Is POC or proof of concept really just code for free work to win the deal?

Stephen Stark: [00:17:28] {laughter} Sometimes it feels like it. Yeah. I mean, I'm not going to... I don't want to talk about the margins of our discovery projects because it's not great. Yeah.

Phillip: [00:17:39] {laughter} That's what it feels like, right? It kind of comes down to I think a lot of times and this is where I think, especially in agency land, and I hate to be critical of it because Lord knows I'm a product of having helped build agencies in the past, but I think sometimes desperate times call for desperate measures, and some are thirstier than others. And I don't think that it's always the most highest qualified, most well rounded, most capable, most credentialed or academic team or the smartest strategist or the most brilliant people or even the cheapest project that wins. It's kind of who's hungriest for the deal. 

Stephen Stark: [00:18:23] Yeah.

Phillip: [00:18:24] That can really work for, when I say hungry that sounds kind of gross. It's really like who's going to work hard to forge the relationship up front and really prove that they understand the headspace that their client is in to try to solve the problem? I don't think an RFP is a surrogate for that. There is no way to really get apples to apples. It kind of comes down, Brian, to vibes. 

Brian: [00:18:47] Yeah. 

Phillip: [00:18:47] Do you want to go through something, a traumatic experience for the next ten months with this person? That's what it comes down to.

Brian: [00:18:53] Yeah. Yeah. Who do you want to be in a foxhole with? That's the ultimate question. Actually, I love that you sort of your discovery process that you talked about, it's back to what you said before. It's about managing expectations, like getting buy in, building trust, getting on the same page. It may or may not save the money, but at least they'll know up front here's what I have to do in order to get to where I want to go. And that allows for more trust when they are going there. And I love that. Usually an upfront process like that is typically run by a Waterfall shop. But I think you've described yourself as more of an Agile shop. What does it mean to be an Agile business when you are doing a lot of deep documentation and sort of expectation setting and building something where you do your work against the set of deliverables?

Stephen Stark: [00:20:13] Right, right. So I think that while it would be somewhat viewed as Waterfall, I think back to that human part of it first, just to kind of go back to the previous question for a second. I think if a merchant has the time and has maybe the budget, I think because of all the getting to know each other, are we going to work well together? All those things that wouldn't necessarily come out of an RFP process. I would advise them to do do discovery, have a bake off, do a discovery with a few agencies. Because I think that you're probably going to get free work out of it, to be honest. You're probably going to learn a lot in the process and you're definitely going to figure out how is that team going to be to work with. So I think before you go down a multiyear road with them, let's say. So I think that that's from a merchant's perspective, it may be annoying maybe to the agencies bidding, let's say. But from a merchants perspective, I think that can be very, very helpful.

Brian: [00:21:22] The one question I have around that is how much has to go into some of the planning upfront? Are there dangers in sort of over planning and maybe overcomplicating things? Do you see that that is also a danger or is it literally almost impossible to over plan it?

Stephen Stark: [00:21:49] I mean, it certainly can be. It can be possible. And we see that sometimes in requests for proposals. It's sort of evident that there's been a lot of documentation or a lot of things may be requested, "Do you have experience with X?" that is never going to come up in the project. And I think that feels a bit like a checklist is being ticked. It has to be ticked. Somebody has to sign off on it but maybe isn't going to contribute to the project and it's going to slow them getting to market. So I think there can be an element of overplanning in that sense. We see it, but I think that's why I would blend some of that with a collaborative start to a project with a partner. And you can do it 50/50 and get into it. I think certainly the bigger risk is that you don't plan enough, I think, or don't have a good understanding up front than it would be over planning. But in this industry and certainly in eCommerce where things change so fast, sometimes you've got to get on with it. And I think a modest upfront discovery is a good way to do it. In terms of how we operate, in terms of Waterfall, Agile, etc., we run our projects in an Agile fashion. That works best because in all of our situations, in most of our projects, actually, I would say pretty much all now that we've learned the hard way, our clients are directly involved on a day to day basis. So we'll have a product owner on our side, of course, who's the surrogate for the client and is their representative in a sense to the development team. But the client has to be, multiple members from the client need to be involved typically throughout to get what is ultimately to meet their vision. We tend to operate in that way. But throughout my career I've seen every different methodology and good and bad.

Phillip: [00:24:19] I'm sitting here sort of jealous. I wish I had worked for more Agile shops in my life because it feels like I could just answer every RFP with, "Yeah, it's all in scope. Eventually. On a long enough time horizon, everything's in scope." {laughter} But maybe AR feature that you have as must have at launch, maybe that one needs to be reprioritized. But everything else.

Brian: [00:24:52] You've said this many times, Phillip, it's MVP, not RFP these days.

Phillip: [00:24:57] Yeah, but I'm starting to hear a lot more about POC too. And I think that we were getting earlier and earlier in sort of how do we get our hands dirty into actually seeing and visualizing what it is that we're going to get and I have likened it to sort of like a wedding planner. A wedding planner typically understands the spaces in which you would plan the event. They understand the order in which the events are going to happen. They've seen way more weddings than you will ever have seen in your whole life. Hopefully. Hopefully you don't get married enough to where you have a really great understanding of how to plan a wedding. Maybe you do it twice, maybe three times, hopefully once. So you should partner up with someone who's really adept at understanding how this works. They have a vision. It's their job to help you have their vision, so that it's a collective vision. And that seems to be easier and easier today because software doesn't require the same sort of lift that it used to to help communicate that vision to a client. We have things like functional wireframes that didn't exist 20 years ago. So the way that we do things today, I think there's this big delta in the industry, especially those in open source too where we have visual mediums and tools to kind of communicate what it is you're going to get at the end of the day and so that we can all make sure that we're insured on the same page so that we can all accurately forecast and budget properly. And then you have this other type of a shop is just like, "Oh, it's, I don't know, strategy, vision. We'll get there eventually." And I think that sometimes the bar continues to be raised for what a prospective commerce client wants to see in the process of discovery or what it is they're getting at the end of the day. I think it's much more tangible today than it used to be. But actually, Steve, I'd love for your input there, because my perspective certainly is a few years removed from reality.

Stephen Stark: [00:26:58] No, I think it's very true. I think that if I go back 20 years when I started managing software development projects, that was very Waterfall then it was RUP, Rational Unified Process. And to a degree, I guess my heart's still is in that place to somewhat. But then there's Agile unified processes with just a slightly shifted version of that. And then you have Scrum on the other side. So I think that there's no real wrong or right way. I just think that given the ecosystem where it is now, the tools that exist, the ability to plug and play more than there certainly used to be, lends itself to more of an Agile approach. And I think that back to the original question about pitfalls of projects, the reason Agile came out and Scrum came out is because late changes in projects and back when it was much harder to shift gears when you're already in the transition phase. That still is very much true today. And I think that having client involvement continuously, and what we always try to emphasize is we're going to have kind of a rolling UAT, User Acceptance Testing, an iterative process, iterative development such that feedback comes earlier. Bad news earlier is much better than bad news later. So let's make sure we sort of contain everything as early as possible, make sure we're managing expectations throughout. And that ultimately tends to lead to the best results.

Brian: [00:30:06] I love this. Yeah, it actually plays really well into Phillip's wedding analogy, which, by the way, Phillip, I actually love that.

Phillip: [00:30:16] I don't know, it's overextended. I think I keep using it in the last couple of months.

Brian: [00:30:19] Have you? Maybe it might be the first time I've heard it.

Phillip: [00:30:22] If my wife is listening, I'm not planning another wedding. I'm just letting you know.

Brian: [00:30:25] Oftentimes we compare in the industry building a new eCommerce website or effort or whatever to a car. Do they want the Ferrari, the Lexus, or the Toyota? Or to making a cake or a pizza or to building a house, although that one's a little bit closer. But actually, I think wedding is maybe the closest because actually weddings are highly influenced by the culture of the couple that are getting married.

Phillip: [00:31:08] I love an overextended analogy. Keep going. This is great.

Brian: [00:31:11] So as you come to the planning and thinking about how to go accomplish this couple's goals, the brand's goals, how do you factor in the way that they interact with each other internally and then also with their vendors and their planner and with their goals in minds? How do you factor in the customer culture?

Stephen Stark: [00:31:41] I won't add any more to the analogy. I would just say that I love it and I will definitely be using this for sure. That's where it starts. It starts with the people involved or all parties there. Is everybody present at the beginning in the decision making process? Because Agile or not, there are certain things that have to be laid down upfront, and we've seen it many times where it's ten weeks into a project and then a new decision maker comes in. This is a little bit late. I think making sure that the internal users, people who are managing the product are involved from the beginning. And that usually means you've got to have the product people involved, you've got to have marketing, you've got to have obviously the technical team, and probably logistics as well, if that's in-house or 3PL or what have you. We recently won a deal and I went to the meeting, the kickoff meeting. There was the CEO, there was the Head of Marketing, the Head of Shipping Logistics, Head of IT, and I think Human Resources. And they were all in the meeting and I was so floored by that because usually we're having to ask who else is going to be involved, who else is going to be involved? And the project's going great because there's alignment from all parties at the beginning. And this is again, the wedding analogy is great because it's the cultures, the people involved that will be making the decisions.

Brian: [00:33:10] Don't forget the mother in law. {laughter}

Stephen Stark: [00:33:15] That usually who comes in late. Yeah, exactly. Yeah. So you've got to be prepared.

Phillip: [00:33:20] I think that's apropos. I'm glad to have helped sidetrack us a little bit, but I do think tying it back to these big, big events, let's talk a little bit about avoiding some other pitfalls. I think there's definitely an opportunity in a company to sort of run with MVP. I've heard it said that there's nothing so permanent as a temporary government program. I think that a lot of enterprises fall for the same sort of trap and a POC open source hypothesis proving project becomes a highly dependent, can't fail, always on channel and never gets readdressed.

Brian: [00:34:00] And then the spreadsheet becomes de facto for everything. {laughter}

Phillip: [00:34:04] {laughter} This is always the case. What are some ways that thinking about how you grow up and help teams sort of grow into new capabilities, is that a factor of sort of business maturity and how are you coaching that along open source or otherwise? Is it your job to help sort of coach them on how to take ownership and grow their team and their capability to be able to manage software at scale?

Stephen Stark: [00:34:26] Well, I think it's become part of the project. Maybe when we got started it was a purely technical endeavor and it definitely has changed over the years, I think. And some of the platforms that require good internal capabilities in order to operate them in some expertise and training, we provide that certainly as part of our delivery. We have to because unless... There's maybe two flavors of this, if somebody is migrating to a new platform, that's always going to be part usually of a project we do: the training, the transition, the onboarding for them and the operations side of it. And if it's something that is an existing system that maybe won't be there so much. But certainly when there are replatforming, it is for sure. Because we do a fair amount of marketplace related work. I see a lot of need for agencies to provide an operational side of an offering to complement the technical side. And that's needed as some of these things have exploded quite quickly. They can get the vendors, they can connect the vendors to their marketplace platform. But then there's a big operational side of it that may not be prepared for. So I think that seeing that in the industry as well, that's something that agencies like ours can provide.

Brian: [00:35:53] Yeah, that's really good. I was thinking about something that was said in a previous episode of this Step by Step season and the idea that open source has matured. You just talked about how it used to be that projects were just technical and now you're involving more and you're talking about change management. And in this previous episode, Sander from Shopware talked about how open source community is about more than just technical resources being involved and how there are more aspects of the organization that can contribute and be a part of the open source community. And so as you go in, what are some of the ways that you're kind of helping tear down some of those silos and helping again with education and expectation setting and drawing people into the world of open source and that community.

Stephen Stark: [00:37:05] You mean in terms of silos within organizations?

Brian: [00:37:09] Yeah, Silos within orgs. Yeah, because oftentimes it used to be and still is, from a title perspective, oftentimes one department has more ownership of a project like this than another does. But they have to work together in concert in order for this to be successful.

Stephen Stark: [00:37:31] Yeah. And I think that it is important to get right up front, and I think back to the original question of what could be a pitfall of a project is if that alignment isn't there and the company's too siloed. We find that a lot of times our main contact, let's say a sponsor in a company or a merchant, sometimes it's CTO, sometimes CIO, sometimes it's the Head of Marketing, sometimes it's an eCommerce director, based on the maturity and the size of the company, they're going to have variety of people who might have ownership. So an eCommerce director is probably the most, let's say you see that obviously more and more than you used to, but if a company is relatively new to eCommerce, you might have an old school CTO who you're dealing with or you might have the Director of Marketing and they don't have any technical in-house staff. So I think that helping these, we always start with roles and responsibilities and understanding the people involved up front, we find that that's key, such that there isn't finger pointing later and it may not be finger pointing at us it might be between them, which is going to be worse because don't have any control over that. It's important that that there is alignment from the beginning and we explain to them how they're going to have to operate the system such that they're not just focused on a software project, which has its own sort of nuances, but they're actually thinking about how they're going to operate after launch and getting their titles and their people in place to do that, because surprisingly, that isn't always as well thought out as it should be. They're making an investment and not preparing for operation. So yeah, it's definitely part of it. And sometimes that is business change, business transformational type of things. That's driven from the technology standpoint, but eCommerce is no longer, of course, just a technical aspect in any way. It's fundamental to their business. And for some businesses it is their business. So yeah, we have to address that as well.

Phillip: [00:40:10] Let's address sort of a thorny topic. And I'm curious your take on this, Steve, total cost of ownership. There is sometimes a question around the direct link between the cost of management of a platform, an ongoing sort of ownership and all the variables and inputs that are required to make a platform sort of operational and it's total enterprise value over the long term. And I think finding the right balance there sometimes the responsibility I think is a little bit undetermined whose responsibility is to help own the total cost of operation for total cost of ownership for a business. If you're a good partner, especially as a development partner, you would probably be thinking about how do we make this sustainable in the long term? Because we can certainly create something that would be unsustainable and require so much upkeep or so much maintenance or so much custom development work that would eclipse its total enterprise value down the line, to some degree. You would never want to. It's the reason why I bought a big house and now I have to flippin' clean the house. I never thought about buying a big house. I just want a big house. I have to upkeep a big house. That sucks. So if my realtor would have just, dang it, if she would have told me that would have been amazing. I thought about you got to mow this big freakin' yard, too. There's a lot of upkeep, and so I think sometimes just finding that right size for the organization, whose responsibility is that? Is that the software buyer's job? Is it the software vendor's job? Is it the partner who's helping sort of implement? Who at the end of the day helps provide that check and balance to make sure that you're building the right size for the right outcome?

Stephen Stark: [00:42:15] Of the three I guess it's not the software vendor's job, although it's certainly part of the sales pitch. Once the once the license is agreed to it becomes I think more the partner's job. Now sometimes we're obviously part of that selection and part of that. And I think when we are we try to evaluate with the client that TCO for sure. We're not always part of it. It depends on the situation and what part of the project lifecycle we're involved. I think that we're typically an extension of of a client we're working with. They view us that way. So in that sense, we view that very much as partially our responsibility to help guide them and help them with analysis of that. Because if the maintenance of this or the what have you associated with a platform decision down the road is going to be too expensive for them that's not going to be good for us either. So that is back to the sort of discovery or inception we like to do up front is usually part of it. And I think savvy clients are going to try to get a good idea of the running cost, both from an agency side, partnership side, in addition to the licensing before they start with a big project. They should because it's going to be part of the TCO. Absolutely.

Phillip: [00:44:12] Yeah I think that's a really honest answer. I think the safe answer is it's a shared responsibility. But in my experience, any responsibility that's shared is no one's responsibility.

Stephen Stark: [00:44:24] Right.

Phillip: [00:44:25] At the end of the day. And so it's like buyer beware. But I've seen a lot of buyers who didn't beware and they're sort of left at the end of the day with the Enterprise has to assume the ownership of it after the team that did the implementation has come and gone and now you're left there having to continue to build on a vision that wasn't necessarily the current team's mandate.

Stephen Stark: [00:44:54] And I think that we may be a little bit different in this regarding the majority of the builds we do. We provide long term support and so we are thinking about it from that angle as well, so that it won't be somebody else's problem necessarily. So we do try to to think about this as a long term partnership. So it's part of that evaluation. But yes, you're right. It's a shared responsibility in the end. That's ultimately the client's or the merchant's decision. But we try to guide them with that.

Phillip: [00:45:37] Can  ask one more sort of pointed question? I really appreciate your candor, by the way. This has been a great conversation. I think when making decisions like this, it's extremely nuanced. I think, every single software buyer's journey sort of has this well, it depends on your exact specific use case and scenario and budget and timeline and all of those things come to bear. But at the end of the day, don't people kind of come in with a horse in the race? You kind of know, the buyer kind of comes in with a predetermined idea of what it is they're looking to purchase. And what they're really looking for is confirmation that they already are kind of on the right track, that they're making the right decision. Would you say that's true or is it not true?

Stephen Stark: [00:46:23] I think the majority of times, the people that are in the decision making seat in a big sort of platform or software platform, software vendor decision, either from their past experience or from certain influences have a clear favorite. That's right. They don't always disclose it. But yes it can become obvious at some point that that's the case. So yeah, I mean, obviously we do better when we're on the right side of the buyers perception for sure, but yeah, I would say that that tends to be the case. And I think, most of the platforms we're discussing and most of the options that are out there are not brand new. So people have previous experience with them, even in their current role or previous role, and they're comfortable with certain solutions or they've been burned by certain situations. And so that definitely factors in. And that's where psychology and the human side of this is extremely important to understand that certainly when we're quoting on work and we're deciding on becoming a partner with somebody for sure.

Brian: [00:47:47] The wedding analogy still works.

Stephen Stark: [00:47:50] Yeah.

Brian: [00:47:53] I love it.

Phillip: [00:47:54] Well, let's get married, Steve. I feel like it... I really appreciate all of the time. I think that just in summation, just giving us one more beat back to the beginning here, open source, I think, definitely has a place in the modern business. It definitely is still part of the buyer's calculus. It sounds like there's more places to plug open source in today than just a shopping cart. There are so many places where open source could belong in your organization. I think we talked in the pre-show, and I'd love to come back to it real quick, it's really that sort of midmarket opportunity or that sort of growing mid-market, I should say, where we have this expanding bell curve of businesses that are undifferentiated in sort of the middle of the market whatever dollar amount GMV you decide to attribute to whatever mid-market is in your opinion. But there is that sort of race to differentiation in digital experience that I think we're all realizing. [00:49:06] It's not really the base platform features that provide that leg up. It's the stuff you do on top of it and that extensibility and customizability is the difference maker for most businesses trying to differentiate in eCommerce. [00:49:20] Giving you the final word, your thoughts on that and sort of the growing, is that a growing or shrinking opportunity for all of us looking to build eCommerce in the next ten years?

Stephen Stark: [00:49:32] I think it's very much a growing opportunity. And I think that looking back a bit, I think so much innovation has come out of that movement in that community, the open source community, that has complemented a lot of the platforms that are out there, open source or not now. I have a development team. We have close to 40 devs, they're passionate about open source, and they like to contribute to it. So definitely we see what motivates my own group of people that I work with on a daily basis is that, so we've definitely been down that road and we'll continue down that road for some time. I think from a client's perspective, look to innovation, and look to innovation from a broad community because that's where it has come from. I think that's where it will continue to come from, and I think it's that community model and all the partners agencies that exist out there that are contributing to that, that will provide the next breakthroughs. So there's no reason that's going to change. I see nothing in the economy that would change that model. And I think we're going to see that even more over the next couple of years. Yeah.

Phillip: [00:51:09] What a time to be alive. It's been a pleasure having you on. I'm excited. I feel like there are two ways to win, and it's like you can grow your piece of the pie or you can grow the whole pie and everyone's piece gets bigger. I think that's really what we've all been invested in over the last decade, and I don't see any stop to it now. In fact, there's more opportunities to contribute back to large ecosystems today than there has ever been. We see more corporate buy in than we've ever seen. We've seen more corporate investment in open source than we've ever seen. I feel like in many ways we're in our golden era and it's great. Open source still alive, Brian.

Brian: [00:51:50] I never said it was dead. {laughter} No, I'm with you. Let's go.

Phillip: [00:51:56] Yeah. Hey, it's been a pleasure. Thank you so much, Steve.

Stephen Stark: [00:51:59] Thank you, Brian. Thank you, Phillip. I enjoyed it. Thanks a lot.

Brian: [00:52:01] Thanks, Steve.

Phillip: [00:52:04] Thank you so much to Shopware for making this season of Step by Step possible. I am a firm believer that there is still benefit to building on open ground and that the future of commerce is open. Open commerce will power the future. Whether you are a small business or you're an enterprise, the underpinnings of much of our ecosystem depends on the contributions of people and communities that are powered by open source. So thank you so much to Shopware for making this season possible. You can find more episodes of this podcast and all Future Commerce properties, including five podcasts at FutureCommerce.fm. We have content coming about every day of the week. You can get it all at FutureCommerce.fm/Subscribe where we're going to be in your inbox twice a week telling you everything you need to know, giving you the insight that you need to be able to build the future. Thank you for listening to Future Commerce.

‍