This is a transcript. For the full video, see Lessons Learned: Contributing to Open Source Projects (Part 2) - Tag1 TeamTalk - #029.2.
Michael Meyers: [00:00:00] Hello, and welcome. Welcome to another edition of the Tag1 TeamTalks, the Tag1 Consulting podcast and blog. Today's topic is the Lessons Learned, Contributing to Open Source Projects. And we're going to talk to you looking back on 50 years of our collective experience, working on open source projects, what we've learned in the hopes that you can learn from our mistakes, capitalize on our successes.
Become an even more amazing developer by participating in open source communities. I'm Michael Meyers, the managing director at Tag1, and I'm joined today by three of our top engineering leaders. They're all well-known major contributors to open source projects.
Lucas Hedding is the maintainer of the Migrate subsystem, the author of the new Auto update module, and he reviews first-time contributor’s modules and approves them, and is a mentor of open source contributors.
Janez Urevc, is the Media [00:01:00] initiative owner really helped transform Drupal's handling of multimedia, the image upload process, and handling and has made many other contributions, including to the MongoDB module.
Doug Green has well over a thousand commits. He helped build and maintain the Coder module and was key to the early search subsystems within Drupal. This is part two. In part one, we talked about challenges and lessons learned as a new contributor. And in part two, we're going to talk about the benefits, why you should contribute, why you should encourage your teams to contribute and your clients as well.
So, basically everyone benefits. When you contribute, you benefit, your employers benefit, the open source project benefits. It's a win for everybody. So let's walk through these from the different perspectives, starting with the contributing from an individual standpoint. Janez. Why would you say individuals should participate or participate more in open source projects?
[00:02:12] Janez Urevc: I think the first reason or the main reason is that it is a great learning opportunity. It is very different to learn coding skills or engineering skills in a bigger community compared to doing it alone. Not locked into your office or wherever you may be. Because there will always be somebody that has more experience than you that has worked on more projects.
And when you contribute, you will get feedback from these people and they will point out where you might improve your contributions or I don't know - where you are, might not be following the best practices, how you could improve the visual quality of your code and all this at the end of the day makes you a better developer, a better engineer.
It's almost like attending university for free except your time. Of course.
Michael Meyers: [00:03:32] Doug. I've heard you say that. And it's like getting a master's degree or a free education.
Doug Green: [00:03:39] I use that analogy. I'm not sure that a lot of people I've heard - I've had some pushback on it, but the analogy I use is that it's like getting a college degree that I don't.
If I was getting a a post postgraduate degree, I'd write a paper or do some research, publish some new information which proves that I am worthy in the field and also expands upon the knowledge base of the field. And I kind of view my initial Drupal contributions like that, that. You know, I was an unknown quantity.
People didn't know me, although I had a lot of software development experience I put in a lot of free time writing. You know, the, the, a few of the things that you mentioned, but once I did all that, And built up a bit of a reputation. I kind of graduated and you know, by graduating, I then went out and I was very marketable and you know, I got a good job, a good paying job.
And I'll, I'll say that my contributions have changed since that initial work where I've built the reputation and graduated now the contributions are done almost entirely in the scope of my, my day job.
Michael Meyers: [00:05:06] Lucas, I know you work with a lot of first time contributors and mentor people that become more engaged in the project. What do you hear from them or, or what is your advice to these people that are, that are new or just getting started with open source.
Lucas Hedding: [00:05:25] So there's a program to the Drupal Association called Global Training Days.
And I think I've been involved in maybe close to a dozen of those plus Camps and DrupalCons and the consistent message is well. “Do you have a Drupal account?” and half the time they'll say, well, maybe. And then you have to help them get a Drupal account. And that's sort of like, to me, to me, like the first thing to do, because that's where you build your portfolio, your build your resume, your CV.
And if you, if you've got that account, even if it's just a dated account it can show that, Hey, I've been in the community for five years or six years and anything over a couple of three years. You, you, you switch from one side to another and then. As you look at their contributions, many of these people that come to these camps or these events have bought into this mentality, this false mentality that they're not good enough, that they can't contribute.
And when I consistently will tell them as you're coming at this from a perspective that no one that's experienced has because. We've worked with Drupal for so many years. We said 50 years among the four of us on this call, we look at him and say, Oh yeah, this, this, this, and this. And it just seems obvious to us, but the user experience benefits that they bring to the table.
It's, it's something that I can't bring. I cannot share that. And many of them have those perspectives that I will never have again. And just that they need to not discount. Plus they can do software development. They can, they can, they can contribute in some way they can do triaging of an issue queue like half the issues are like, Dead and just need to be closed out or Hey, how do we reproduce this?
And see if they can plug away at it and reproduce something, just do something it's going to be a benefit to the community of open source and in turn benefit yourself.
Michael Meyers: [00:07:47] Yeah. A huge learning opportunity. Do you build that portfolio of contributions? You mentioned that the D.o Handle, if we're hiring for a Drupal project we need a Drupal resource.
You know, that's the first thing we look for is your Drupal.org handle. And your contributions are Drupal and, and a lot of other technologies that your Github portfolio, if you don't have that, we're not even going to proceed beyond that point. You know, it's, that's a non-starter, that's an absolute critical must.
And we evaluate you in part because of cultural fits and, and you know, our conversations with you, but largely based on the quality of your code and your interactions and reputation within a community. And as someone who hires a lot of resources, people who contribute make a lot more money than people who don't. Doug, you mentioned how things have really changed for you over time.
You can command a significantly greater salary as a well-known contributor to an open source project. So there's a, there's a really great financial return on investment for people. You know, there's something in it for you. You're not just giving, you're getting tremendously.
Doug Green: [00:09:15] I have a story about that, which was - I was still relatively new in the Drupal community.
I’d done some search work, but I wasn't yet the core search maintainer. Hadn't quite gotten that commit yet. There I was working for one agency at the time. Another agency was building a new website. And knew the work that I had done and contacted me as the expert in search to do some work for them.
And at the time I think I was making $50 an hour. And they asked how much would I like to be paid for this two week engagement? And I said, a hundred dollars an hour. Which was crazy double what I was getting paid. And this was Lullabot was the contracting agency. And they said, how about we pay you 110?
Janez Urevc: [00:10:17] I have a similar story. Based on my contributions to MongoDB module, I was approached the same way to be part of a project where Mongo was being used. And I, the same as Doug I've been paid very well for that, that engagement, like almost exactly the same story.
Michael Meyers: [00:10:40] Another interesting thing that you guys just pointed out it's that people come to you as a company Tag1, the vast majority of our business is people coming to us because of our reputation, because of our major contributions to the platform and saying, we'd like you to help us with this. We want you to do that. You know, and as individuals we, we never post a job on, on a job board. We never advertise that we're looking for someone.
You know, when we have a need in a specific area, we'll look through, Github for people that are doing work in that area meaningfully, and we'll reach out to them and we'll recruit them and we'll try and get them to come on board. So gone are the days of like a traditional resume it's your code and the more well-known you are the more likely it is that people are going to come to you and offer you work.
And the other way around. What about other benefits? You know not just say the code. Are there other things that you guys have taken from or gotten from your participation in communities?
Janez Urevc: [00:11:57] Yeah, definitely. Being part of such a diverse and global community allowed me to learn a lot about different cultures, a lot about diversity, different worldviews, and you know by helping me understand these things, I could say that it also made me a better person. And through the years I developed many friendships that will, I'm pretty sure all last. Now, even if I move on into a totally different space, these friendships will, will stay for sure. For the lifetime which is the biggest reward one can get for sure.
Michael Meyers: [00:12:53] What about you Lucas?
Lucas Hedding: [00:12:55] Yeah, a lot of friendships some, and it's just really nice sometimes when I can get together with people at DrupalCon, Camps and things, but a lot of it just ends up being interactions in the issue queue.
I see a person's name over and over again, and three, three sentences. And a comment here, two sentences there, five paragraphs over there, you kind of get to know people and. And, and then when you actually see John or, or Sally or whoever the person happens to be, right. Oh, and you like, slap each other on the back and you fist bump for, well, maybe in today's world, we don't do any of that, but like virtually six feet away, a handclap.
And we, we start to chat and that's great. And, and, and some of the contributions you can do, aren't really coding at all. You mentioned the mentorship program. Drupal's probably, in my opinion, we've got the best mentorship program out there in open source and folks coming to us and asking us how we're doing it and studying our resources and modeling off of us.
And it's very relationship driven, very empowering. And that, that makes me feel good to be able to look around at people and say, Hey, I helped that person. And you know that person over there and over here. And they're doing even better than me, you know? Cause we're, we're standing on the shoulders of giants in a lot of ways.
How about you, Doug? I know
Doug Green: [00:14:38] you just know what Janez and Lucas were saying. I think. We have learned as developers how to communicate through issues queues, through conversations that are remote and built up a skill set here where I don't need to be in an, a physical office for a job. I know there's some debate in, in tech companies and specifically That, whether you have to be in the same room to be able to brainstorm better.
But I think that the open source model where we're a part of a worldwide development community, where we talk in issues queues, we talk in IRC, which is now Slack. It has allowed me to have a job where I work remotely, which is kind of the new norm in, in 2020. But I think that we built up these skillset over the last, over the time I've been here.
And that flexibility allows me to work from home to set my own hours to work multiple. You know, to switch back and forth between multiple contracts, if need be or different agencies, different clients is what I'm saying. And, and, and that flexibility that that gives, but what Janez started out saying is probably the biggest benefit to me.
You know we're talking a little bit here about what's the benefit for the employer and the job. The personal benefit is knowing all you people, working with all your people. And I always think it's really cool when I come on and I'm working with people in Europe and California and Vancouver and Canada, and South America got a guy in South Africa right now that I'm working with.
Yeah. And getting to know those people and culturally, every now and then we get on a zoom call like this, and we just talk about what it's like, where you are.
Michael Meyers: [00:16:50] It's pretty amazing. You know, I've had the opportunity to develop friendships with people. Like he said all over the world. It's, I think it's given me that
You mentioned, Janez, is it's made me a better person. I feel more connected to our planet in a way that. I didn't before participating in open source communities. And I think back and I started with Drupal over 16 years ago watching what Drupal has become and playing you know, even a small part in that has been so rewarding to see something that I've helped grow to be used by millions of websites many organizations doing wonderful things and that's.
That's really exciting. It's meaningful. You know, it drives a lot of value to me personally, about our work. So what about agencies from, from an agency perspective you know, why should agencies get more engaged or encourage their resources to get more engaged? I know it's an investment and you know, I don't think that agencies need to be altruistic.
You know, this doesn't need to be like a nonprofit donation. I think that there's a lot of sort of benefits you even be very self-interested and contribute meaningfully and, and help the project, but also really help your company. You know, you guys all work for many different agencies.
Lucas, what do you see as some of the biggest benefits for, for these organizations to get more engaged?
Lucas Hedding: [00:18:32] So I, I sort of fit in between a majority of my time. I work at these days with Tag1 that I, I work with a couple other agencies as well, like a lot of contractors, but I also have a small agency of my own that I sort of Moonlight with.
And I've got a couple of a handful of nationals here in Central America working with me. And one of the first things I do with any of these guys is getting them as they, as they get hired, is start contributing back to the project. And I've been blessed, lucky to have some of them work with some very large agencies and in the world.
And I, I want to attribute that primarily because of their contributions back to the community, we can look at our little small agency of, let's say six or seven people. And some of these folks will even work Drupal part-time, but we're at the very bottom of the first page or the very top of the second page of Drupal organizations that contribute back to Drupal.
And that, that allows that work then also we, we tag back to the agencies we're working with. So you know, pick your favorite agency or your, your, your local large agency in Europe or America. And we might've worked with them at some point. And those credits come back to your organization.
And so in turn, when you're marketing your yourself out to other clients to do, to build websites. They're able to show that you guys really know your stuff when it comes to you're not, you're not a no-name, you're not a yeah, they're, you're really able to to position yourself as your agency, as, as a, as a go getter and it doesn't take that much investment.
It really doesn't. That breeding a culture is, is the hardest part of it is just, Hey, make sure that whenever you're rolling there for that client, you roll that back as a patch to the project. That's probably the biggest thing. How would advise an agency is don't do that in a silo. Don't do that in an altar or some form.
Do that in the actual code, throw up a two K patch and it'll probably get committed someday.
Michael Meyers: [00:20:58] So just like individuals where as you become a more, you know, you contribute more and more and people come to you and hire you. The same thing happens in agencies that people seek you out because of your talent or are more likely to hire you. Because of your talent.
Lucas Hedding: [00:21:15] That's what I found to be true very much.
Michael Meyers: [00:21:19] So how about you, Doug?
Doug Green: [00:21:22] I can't speak from the business perspective. You know, I was going to throw the question back to you, Michael, from the business perspective, but from the developers perspective working on projects and the benefit to my customer is if I create a patch and I put it on D.o It's got a chance of being committed.
And once it's committed, I don't have to maintain a separate patch. You know, if I don't put it on D.o , I've basically forked the proc, you know the module or core or whatever, I'm patching our forked it. And it takes me a lot of effort to maintain it over time. Even with composer and composer patches where things can commit be applied automatically.
There's still a cost to maintaining that local patch. So if I can get it on D.o, and this might be a good enough place to mention. I've got a I'm, I'm not the best contributor or maintainer these days. You know, I was better when I was spending a lot of my personal time. But now that, like Lucas said you know, I'll spend a little extra effort to try to fix it on D.o. And get it on there, but usually I'm just starting the process. A lot of times I'll find bugs. I'll we'll find something that's wrong. We'll find find a bug , I'll be able to identify what it is and create the initial patch and, and then put it on D.o.
And then I use that patch in my project. That is generally the extent to that. That's where I kind of stop and I think of it kind of as Hansel and Gretel. That I'm leaving breadcrumbs out there and hopefully someone else in the Drupal community is picking it up because anytime I find a problem, I go and search I actually, I use Google to search, but I search for Drupal issues.
And if I find somebody else has something, then I can use that. So I'm frequently just starting the patch and putting it up there. And hopefully someone else in the community is picking it up and finishing it. And the short story I'd have related to that as I was at a DrupalCon once and at DrupalCon during the code sprints, we have they mentor new new Drupal developers and teach them the how to go to issue queues and frequently somebody will take up a patch and the issue.
And we do a live commit at DrupalCon. And I remember at one DrupalCon, they were doing a live commit up on the stage of a, of a patch that some new person had picked up and rerolled and got it committed into Drupal Core. And it happened to be something I had started, I dunno, five years ago.
Michael Meyers: [00:24:22] Wow. Yep.
From my standpoint. You know, one of the hardest things as someone who's run a company that uses Drupal to power their business or an agency is finding talent. That's you know, that that is our biggest challenge and finding really amazing talent is an unbelievable challenge.
And I really had the good fortune of working with folks like yourself because. The organizations that I've been a part of have made it, you know you know, a big part of what they do to contribute and support and [00:25:00] being engaged in the community. So from, from my standpoint, it's been a phenomenal way to attract not just talent, but amazing talent.
And then it's a snowball that rolls downhill talent begets talent. I remember, Doug. We were working together. I sold Now Public to Examiner. And you know, we needed to ramp up and hire a really large number of developers to rebuild The Examiner on Drupal. And you know, for folks who don't know, Examiner was the first top one hundred websites to run Drupal.
We grew it to a top 50 website. And I remember going out to the community and talking to people that Hey, it Doug Green works here. Janez works here. See Chx works here and they're like, holy bleep! When can I start? It was, it was I don't want to go so far as to say it was , crazy easy, but you know, people wanted to come work with you guys because they knew you from the community.
They knew how amazing you were. They wanted to learn from you or just be a part of a team with you. And so from an organizational perspective it really positions you. To put together a really awesome team. Janez what would your advice be to an agency
Janez Urevc: [00:26:23] To, to start contributing if they don't do it already?
But yeah, my, my, my opinion is, and just to note here, I'm not really a business person on a technical side, but I do believe that. If you decide a new base or business model on, on a piece of software, like Drupal and in our example, or that there are many agencies in the community. If you are contributing A: your developers, your members , your team will have more knowledge about a software, which means that they will serve your clients better, which in turn means that the clients will be happier and it will stay with you and probably pay better as well.
But also if, especially if you, if you, if you do that extra step and you contribute a little bit more, like you are a little bit more active in the community, at some point you will have some influence on the direction of the project. And if you base your business, on that software. That's always a good idea.
Like it's, if you don't have any influence then, and basically puts destiny of our business into somebody else's hands that's how I see it.
Michael Meyers: [00:27:49] Yeah. You, you just reminded me of something else that it's, you know it isn't just about code, right. You know, case studies, as an organization when we post a case study.
it helps people see the capabilities of these platforms. So it's, win-win we get to promote our business and the awesome things that we do, the community benefits, because we help promote what it can do and more organizations come in and use it. So you know, I'm, for the same reason, we sponsor events because we want to keep our organization top of mind.
You know, when you think Drupal, we want you to think Tag1 and remind you. You know that we're the experts that are helping drive this community forward.
Janez Urevc: [00:28:33] Yeah, I, I maybe didn't answer your question that directly. I think about the advice for, for the agencies. I think that the best advice is the one that Lucas gave already just build contributing culture into your company and that's.
The first and the most important step, because it really doesn't necessarily have to take extra [00:29:00] effort or serious extra effort. But when you have it built into your culture, it just as you work on projects for our clients, you will automatically start contributing.
Doug Green: [00:29:13] And you know, I don't think we've said this in the broadcast, but it's been brought up in our back talk that.
Have it built into your contracts that your clients accept that you contribute back. And I've only had one client where that was an issue and we hadn't negotiated and it still didn't end up perfect. But it, I don't want to work for a client that won't allow me to contribute back.
I don't want to do things in the dark.
Janez Urevc: [00:29:45] Yeah. And some clients don't want to be exposed. And there is totally fine, too, to agree that you won 't mention their names with when you publish patches. But if, if they are [00:30:00] not against that, it's totally fair that you do. So then also the clients will get a visibility.
Michael Meyers: [00:30:08] Totally. We have some you know, fortune 500 clients that want to remain confidential. But they understand the benefit and value of open-source. And so they've asked us, or we have agreements with them where we contribute these components that we build back to the community on their behalf, because they are going to get all of the benefits of that over time.
You know, many of the, the the benefits that we talked about for individuals and agencies also apply to clients you know, Doug, you were just talking about contracts and, and, and. Lucas, I know that you and I have talked about this and I really hope that we can do a Tag TeamTalk about this in the future.
But you have very specific views on, on companies and contracts and agencies and contracts. Can you give us a little insight on [00:31:00] that?
Lucas Hedding: [00:31:01] Sorry. Flipped out there. You were asking me, Michael. Yeah, I I don't know why he got into my craw, but probably five or six years ago. I started really looking closely at contracts that agencies would give me and I, my, my model is, I come in and I work and then I try to do a really good job for the client and, and the agency, but part of that is I want to be, have my hands unlocked so that I can contribute this code back to the.
The community. And as you look through the contracts that agencies have have written for, for contractors it's pretty, pretty awful. If you, if you want to be honest, it's pretty awful. It usually says all the codes belong to me or to my client. And I have to scratch my head and say, well, how can that possibly be true when we're dealing with [00:32:00] GNU GPL MIT, whatever some type of open source license.
How can you say all the code belongs to you? It's just not possible. And I've pushed back every single time and every single time one of these agencies is, Oh yeah. And it's like, the light bulb goes on and they struggle to figure out how do they word this? So that. Yes. Obviously, there are some things that do belong to the clients, obviously.
And so I've, I've gone to through so many different contract negotiations and it's like someone should have a standard contract that says open source, and then you have to define open source and what it means and, thankfully, Tag1 has been really, really, really great about this.
They, they were one of the two agencies that I've worked with that I didn't have to have them rewrite their contracts. I could work with And I think that now there's probably a half dozen or dozen agencies out there that do have some friendly language in their contracts now, but those were all written as one-offs.
If I went back to any of them they would probably have to, Oh yeah. You're that guy. So let's rewrite our contract for you. It'd be really great as a part of building this culture of contributing back. If we would include this concept of yeah. The business logic, the important stuff to your organization obviously is owned by you, but the fact that you just patched web forms so that it doesn't cache the session context, and you can't visit the page as an anonymous user without re you know, these problems that we face on a daily basis, and you don't want to rewrite web forms.
And you don't want to have just [00:34:00] let my hands. Not be contrary or again, I'm not going to lie, but maybe I have to lie and just sort of sneak it in and patch this thing anyways. Just open up the contract. Oh my goodness. Let me, let me do my job.
That's how I feel about it.
Michael Meyers: [00:34:19] Yeah, it's it can be challenging at times to convince companies to incorporate these aspects into their contracts and.
You know, there are a lot of controls that they can put in place. You know, as I mentioned, we work with some top fortune 500 companies. They're they make their business in many cases on proprietary software or applications. You know, they, they understand the benefit of open source, but they they have sort of like a control process that they put in place to review and approve what makes it out into the open source community.
And it, it takes some time and it can be a little frustrating to go through that, but. You know it sort of it gets them through that sort of corporate governance but also enables them to do this contribution. And you know, speaking of control I think that when I ran a business based on Drupal and with what I see with some of our clients, it gives you tremendous amount of control over your technology and technology platforms.
You know, we, we recently you know, we're working on an intranet for a top 50 fortune 500 and they really wanted it to run on Oracle. And so we were able to make that happen Drupal doesn't support Oracle, or it didn't very well and, and you know, we're going through that corporate governance process right now to be able to contribute that back.
You know, Janez you talked about your Mongo DB the same thing Examiner, needed to scale Drupal to top 50 website status, and did some of that through [00:36:00] incorporating MongoDB, if it wasn't an open source platform that they were using, they would have been screwed.
You know, their options would have been really limited as to how they could have achieved their goals. You know, they would have been locked into their technology. So having access to the code, being able to modify and extend it. You know, these are all well-known benefits of open source. So we've seen them firsthand we've seen how companies have really benefited in situations where they otherwise really would have had a hard time solving these problems if they could solve them at all.
So before we wrap up, you know any, any last words for companies as to what they should do or why they should get involved?
Doug Green: [00:36:47] Just I don't know if this is new, but to reiterate what we've talked about to two different contributions to your one is just fixing bugs or minor improvements, you know?
You know, to the project. And then there's the other, which are the MongoDB, you know Oracle when I was with Pfizer, they did you know, invested a lot in workflows. There's the bigger contributions and the smaller contributions. And it's really up to I, I know when I was with the companies that did the bigger contributions.
No, it took management, buy-in to, to do that, but they did it because they needed that product themselves. And a lot of times Drupal might do 80% of what you want to do. And matter of fact, not on a lot of projects, I mean, Drupal might only do 80, 90%, what do you want to do? And that extra 10%, it does take some development effort.
Doing that development effort in house means that your, [00:38:00] you only had to develop 10% of what your project needed because 90% was already there. And the cost of doing that is really contributing in it back. And when you contribute it back, then you get the rest of the community. Your company may be carrying the bulk of the effort there.
But eventually you'll get some buy-in and some improvement from the rest of the community. So I want to encourage both types of contributions. You know, my contribution as an individual developer tends to be, I've got to, I've got a job to do a project to do. I find bugs. I find small improvements that I can make and I'll spend the extra 10, 20, 30% of my client time to make that contributable back.
they get it over the hurdle, but then there's the other contributions which are agency level or corporate level where they have to make a decision that we're going to put one [00:39:00] full-time developer on this and contribute the whole thing back. And that's a major investment and there's I can't speak to that end as much as somebody like Michael can, but I've seen it happen.
And it seems to be a good thing.
Michael Meyers: [00:39:13] I think Pfizer is the gold standard from what I've seen. For how corporations can get engaged in open source and the benefits that they derive from it. There might be case studies on that topic out there, if not, we should talk to Mike Lamb about doing that, but they have achieved all of the benefits that we've talked about.
They've recruited an amazing team. You know, the control that they've had over their technology has enabled them to do. you know, everything they need on a rapid pace, they run thousands of websites on the platform and have had major improvements so it's I'd love to get them in and do that as a, as a future Tag TeamTalk, we'll reach out.
But I think that's all the time we have for today. I really want to thank all three of you for joining us. Doug , Janez, Lucas. Thank you. Really appreciate the time. Please make sure for our listeners that you check out part one, the challenges and lessons learned as a new contributor, because it leads into this and I think reinforces and helps you become a better developer.
The links that we mentioned today are going to be posted with the talk in the show notes and the description. If you like this talk please remember to upvote, subscribe and share it out to folks. Please check out our past tag team talks at Tag1.com/tagteamtalks. And as always, we really appreciate your feedback and input as well as topics suggestions.
So please read to reach out to us at tagteamtalks@tag1consulting.com. Again, a big thank you to our guests and everyone who tuned in today. Thank you for joining us. We'll see you soon.
Doug Green: [00:40:56] Thank you, Michael.
Lucas Hedding: [00:40:57] Thank you.
Michael Meyers: [00:40:59] Thank you guys. I really appreciate it. Sorry for running over again, but this was, this was awesome.
Janez Urevc: [00:41:05] It's totally fine. Cool.
Michael Meyers: [00:41:08] Take care.