Katherine Druckman (11s):
Hey everyone. Welcome back to reality. 2.0, I am Katherine Druckman and Doc Searls is joining us along with our regular guest, Petros Koutoupis, and a new guest, Travis Carden, who I am lucky enough to occasionally get to work with and who maintains an open source project called Orca that is a testing tool for Drupal software. Before we get started, I'd like to remind everyone again, to go sign up for our weekly newsletter. You can sign up reality2cast.com. That is the number two and follow the newsletter link. We also just posted a link to buy some fun podcast related swag. So please visit the store link too if you are so inclined. And then I also wanted to give a shout out to our Patreon supporters.

Katherine Druckman (52s):
Thank you very much for your support. Now onto the, to the meat of the show. First, I should mention that I very rarely talk about the work I do. So this will be a fun opportunity to do that. And second, I should also mention that Travis is awesome. I was lucky enough to work with him on an amazing team, made up of some of the best minds working on the Drupal project. And somehow I got to work with them too, which was almost like maybe getting to fly the Millennium Falcon on the level of coolness for me personally. So anyway, Travis is one of those minds and we're going to talk to him today about all, all sorts of things related to open source projects, including testing, maintainership contribution, and mentorship. So stick around because it's going to be fun.

Katherine Druckman (1m 33s):
So Travis first, we would love for you to introduce yourself a bit.

Travis Carden (1m 38s):
I well, thank you for that very generous introduction for filling in the gaps. If there were any important ones, I work at Acquia, as you said, where I, where I have worked for six or seven years, I think at this point I was in the professional services organization for the first five or so. And then I moved into engineering. After that, I moved there for the express purpose of taking on the automated testing kind of initiative to standardize the testing practices and platform for all of our distributable packages at Acquia, meaning our Drupal modules and packages, packages, and at work.

Travis Carden (2m 35s):
Those are probably the most important things that I would want people to, to know about me on the strictly professional background level, on a more personal level, I am really passionate about mentorship and it excites me to work with other people and invest in them and in their careers. We're going to discuss open source in this podcast, and that has proved to be a really great vehicle and context for mentorship. And so I'm excited to discuss the way both maintainers and seasoned contributors can use their projects as a platform for helping other people and how newer and younger contributors can get into open source, not only as a way of giving back, but also as a way of growing professionally and learning and getting kind of built-in mentorship.

Travis Carden (3m 40s):
If you will, on the entirely not work personal front, I am a husband and a father of two girls, 11 and 12 years old right now. And they asked me if I was going to be on TV with this podcast. I, I told them probably not,

Katherine Druckman (4m 3s):
No we do not use the video because I would have put on makeup or something. I don't know.

Doc Searls (4m 10s):
Where are you in the world? On the, in the physical world?

Travis Carden (4m 13s):
I am in North Carolina in the United States where in North Carolina garner is a suburb just Southeast of Raleigh.

Doc Searls (4m 23s):
I lived in chapel Hill and Raleigh and Durham for many years. Yeah. Okay. So yeah, that would be kind of right between me and the Durham Drupal meetup. Cool,

Katherine Druckman (4m 36s):
Cool. So, so Travis, so the other thing that, that we, we mentioned earlier is just your experiences maintaining an open source project, but also just contributing to open source and mentoring other contributors within, within that project. And I wondered, I, you know, I think Petros and Doc may have a few more questions about that.

Doc Searls (5m 5s):
So I have a friend who used to work, actually works with, let us tour balls at a transmit or whatever the company was. And he said that all, all programmers are either Cowboys or engineers and he went into what those were all about. But I'm wondering whether in dealing with, I mean, in dealing in mentoring, you have to deal with psychology, you're dealing with human beings. Right. And so I'm wondering if you've got any insights about that or what you've learned about people in the process or categorizing them, or, you know, trying to make sense of them in different ways.

Travis Carden (5m 37s):
Yeah. There's so much that could be said on that subject. And it's, it's a subject that I really enjoy. I was really looking forward to talking to you about this when Catherine proposed my coming on the podcast as to the psychology of contribution and mentorship, I, that probably the first thing that anyone needs to know who is trying to solicit and coordinate contribution from other people is that everybody feels inadequate. Everybody has like imposter syndrome, right?

Travis Carden (6m 20s):
Like I've gotten inferior inferiority complex, but it's not a very good one. Even that was, that was a joke. It was hilarious. But yeah, so that's, that's one of the things that I've always run into fast is that even people who are excited about something will oftentimes feel incompetent to participate in it. So just creating and ethos, creating a, an environment that feels welcoming and encourages small contributions and mistakes, I think is really important.

Travis Carden (7m 13s):
I find that you can kind of cultivate a small number of contributors that you invest in very heavily and then empower them to multiply that effect by mentoring other people. I, I would be disingenuous, I think, to give the impression that I'm highly experienced or well accomplished in this area. I have a handful of projects that I maintain and others that I contribute to, but I'm not like an expert on these subjects so I can give my experience.

Travis Carden (7m 58s):
But

Doc Searls (7m 58s):
Yeah, it's interesting to me that you, you, you know, mentors can make mentors. That's an interesting angle on it. Cause you want people to, you want it to kind of roll forward Elsa to relieve you of work, right. I suppose,

Travis Carden (8m 13s):
Which is true at Aquia where a Drupal company and our CTO is the project founder and inventor, I suppose, Drupal Dries Buytaert. And it's very interesting to listen to him talk. He's discussed over the years a lot of these dynamics. Drupal began as in a story that I think is fantastic. When Dries was in, in university, I think he was rooming with some folks and he started Drupal as a bulletin board to share grocery lists with the folks in, in the rooms adjacent to him.

Travis Carden (9m 4s):
And then it just kind of grew in functionality incrementally until it became something that he decided the rest of the world could benefit from. And he talks about how early on it, it was such a small and maintainable thing in terms of a single maintainer that when he made API changes, breaking API changes to Drupal core, he would go out and just fix the modules that flux third-party or contributed modules that other people owned.

Travis Carden (9m 44s):
He would just go fix them himself to work with the updated API APIs. And obviously now Drupal is a massive international phenomenon. And I think last time I heard it was something like one in 20 websites on the internet is supposed to be powered by Drupal and he no longer fixes other people's modules. So that's, that's something that's been essential to the growth of Drupal is this kind of multiplication of effort.

Katherine Druckman (10m 20s):
You can't sustain an open-source project with a handful at the same handful of developers forever.

Travis Carden (10m 27s):
Right. That's a familiar

Petros Koutoupis (10m 28s):
Story though. You know, just a small project while you're in college, serves a small purpose and then just sort of evolves from that. You know, I, I think, I think we've heard that story many times in this industry, haven't we,

Doc Searls (10m 44s):
I, I think Linux journal went on Drupal in like 2003 or four, it was right after we wrote a piece about comparing blogging software with the back to the, when everything was blogging and, and, and I'm pretty sure that trees actually worked directly with us on that. You know, that it, so I'm wondering, so as it grew, I mean, there's so many things that don't, let me put it another way, you know, hanging out in Silicon Valley for a long time and not, I don't live there now, but functionally I'm still there is because everything is everywhere.

Doc Searls (11m 25s):
It seemed to me like every company has three stages of growth. There's new, there's hot and there's big and they are different, right. When you're new, you got this crew of people usually starts with one person or a few people and everybody's working very long hours and, you know, and, and it's all, it's all kind of crazy. And then hot is this other stage where you've got the next round of VC money. You hire a whole lot more people and marketing comes in and, and lawyers in and stuff like that, but it grows through that. And then when it gets to be big, it's very divisionalized. And my guess is that Acquia is, I remember when Dries started, Acquia was like, you know, he came to Boston and I was in Boston at the time.

Doc Searls (12m 7s):
And in fact, I introduced him at a talk he gave one time and it was a new thing. It was like, I'm going to start a company for this thing. And he moved to Boston for that. And now it's relatively gigantic and he's kind of stepped back and kind of stayed in his one role. So I'm wondering if, you know, is there a stage beyond where you are now where Drupal is now, where it just continuously matures is kind of in the big stage or, you know, or maybe just kind of grows horizontally and you add new maintainers and new, new ways of expanding sideways.

Travis Carden (12m 40s):
You're asking about the future of Drupal

Doc Searls (12m 43s):
To some degree. Yeah. And or it doesn't have to be about Drupal, but the, the, the, the growth path of companies like that that are built on open source started with one, one guy scratching an itch to, you know, you know, Linux was a hobby really. I mean, kind of a, just a little project for Linus, MySQL, very similar. These guys just want to do a different database, you know, and it went this way and, you know, and, you know, Dries had his grocery list, you know, and, and started to kind of in this little bloggy area, but it clearly was better suited than anything else that we saw for a publisher. You know, we were you know, a somewhat serious publisher, which meant we weren't gonna use WordPress.

Doc Searls (13m 27s):
We were gonna use something more serious. And there it was, and it was open source and that was helpful. But at that stage, you know, we were growing and so is, so was he, and so there was a, a kind of synergy there, but we were one of many, but I'm just sort of curious how, if you have any insights into how an already successful large open source operation grows

Travis Carden (13m 53s):
Well, here again, I should, by no means, be thought of as giving expert insight into this, but just colloquially my anecdotally, my observations about Drupal kind of run as follows. I tried Drupal for the first time when way back in the triple five days, which for people who have been in the Drupal community for long know that that was kind of prehistory up to like Drupal six is when things really kind of started getting going.

Travis Carden (14m 38s):
I think so I tried it before things really got the kind of traction and momentum needed to capture the average developer, I think, and then I I've seen it since then go through. I think those stages that you propose are a pretty good framework go from being new and not well understood. Probably not well marketed or represented part of the reason I said that I discovered it back in Drupal five. I didn't pick it up at that point.

Travis Carden (15m 19s):
I kind of went away and I use WordPress actually for awhile. And then I came back and found it again in the Drupal six version cycle. And I guess something flipped and I was ready for it, then not, not least of all. I think the, there had been some serious maturing in the software and the community. And so then it was kind of in the new phase. And then there was kind of a hot phase, I think, as you talk about during which there was a rapid influx of interest and contribution and press, and by boy that we were kind of in that phase for a number of years.

Travis Carden (16m 8s):
And then I kind of feel like when we got to Drupal eight, we started getting into the big phase where now there's a lot more discussion of enterprise deployment and more moving away from, or at least maybe I should say, adding to what previously was discussion mostly of how can I get X website to look good and do the basic things that I want and kind of a presupposition that it was going to be like the WordPress install kind of on your GoDaddy hosting or something.

Travis Carden (16m 58s):
You know, you spin it up with one of those. I can't even, can't even think of the names of them anymore, but one of those bits of software where you just tell them, give me WordPress, or give me Drupal or give me Joomla. And that was kind of the scale and style in the early days. And then getting into, as I say that big phase, then questions started the big questions that got a lot of discussions started being things like, how do we do a multi-stage like dev stage prod kind of workflow, and how do we, how do we scale for performance and scalability kinds of questions?

Travis Carden (17m 43s):
How do we work with a CDN, a content delivery network or scale to handle A thousand requests in a minute? You know, whatever other, other kinds of things that you're excited, but small audience isn't concerned with. And, and I'd say we're still in, I mean, is there something after big? I don't know, but,

Doc Searls (18m 13s):
Immense?

Katherine Druckman (18m 13s):
I don't, I don't know. I don't know if, are you allowed to talk about some of the sites you've worked on, is it top secret? But I'm always, I'm constantly kind of impressed by, by some of the companies and entities that are using Drupal. I find out, you know, some massive entity is using Drupal and I, you know, I'm still, I'm still impressed by that. It's still exciting for me because, you know, back in the day when Linux Journal first started, and even when I first started working on the Linux journal site, you know, it was in the fours by the way, it was like 4.6, I think. Yeah. Yeah. When I started, it was 4.6 and we moved, I was part of the migration up to five, which was, which went actually through 4.7 on the road and then stopped at five.

Katherine Druckman (18m 57s):
But yeah, so even still, to me, it's very exciting to see, to see, you know, where it's gone. And I mean, I know, you know, just some like kind of fun examples, like I know Godiva chocolate, and I find that very appealing because you know, who doesn't love good chocolate? Anyway, but I'm wondering if you could talk about some of the, like really massive, impressive sites that are, that are running Drupal that you know of. I bet you can think of more examples than I can.

Travis Carden (19m 25s):
Well, there are a few that I've worked on that I've found really exciting. The, the first one that comes to mind is NASDAQ, which well it's no, I can't. The specific entity is no longer NASDAQ. I think it was, well, I shouldn't talk about things I am not competent about, but some years ago, right around the time Drupal seven was becoming Drupal. Eight Aquia worked with NASDAQ to create a platform for their investor websites, all the companies that are on the NASDAQ stock exchange, who are, who are using NASDAQ in that sense, they have investor websites that are for the people who are investing in a given company.

Travis Carden (20m 30s):
It's kind of, kind of, I suppose,

Katherine Druckman (20m 33s):
Investor relations, I think is what it's called. I remember this because I, I wrote about it when it happened on Linux journal, because I saw Andrew post about it and it was big news, right?

Travis Carden (20m 42s):
Yeah. That's right. So yeah. Investor relations platform. Is this how we talked about it? You can tell been a while. Cause I can't even think of that, but there, there was, it was like a five ish thousand website platform, but at the time, so what we built was a Drupal application, really an installation profile, like what you're working on now, Catherine actually, so the NASDAQ investor relationship platform was a private distribution or installation profile more technically that powered some 5,000 investor relationship on sites.

Travis Carden (21m 26s):
And the scale of that is obvious. I don't know how many websites are on it now, but it was 4,000 something was, was what we started with my, one of my favorite things that I've ever done with Drupal is that I was for a period of time, the open source product maintainer for the white house petitions platform. That was a lot of fun. It was a huge project, huge national interest of course, and huge technical complexity as well.

Travis Carden (22m 9s):
And you

Doc Searls (22m 9s):
Had mentioned that one because that's very cool.

Travis Carden (22m 12s):
Yeah. Yeah, definitely. I, I'm trying to think of, of some of the others that have been really noteworthy. I know the department of defense had something on there. I, I don't know if all of these are still current, but Sony, BMG at least used to have every single one of their artists on, on Drupal. Not, not many, not many projects can claim both the white house and weird Al Yankovic at the same time, but yeah.

Doc Searls (22m 51s):
Oh, too funny. Yeah. So in short in summary, I suppose you drew, Paul has come a really, really long way since well, since doc and I, I guess, started with it way back in the dark ages

Travis Carden (23m 6s):
Where he brought it.

Doc Searls (23m 8s):
Yeah. It was all less. I don't even know what the version was. What would it have been in 2003 going to have a version number? It may have been four something at that point. Yeah. I'm not sure. I guess we did have was 4.6. Yeah. But what I do remember is that

Travis Carden (23m 27s):
I think we had

Doc Searls (23m 29s):
Question for Dries and I think he responded with, you're only, you're using, there's a whole bunch of critical responses. Like you should be doing this and this and this, so you okay. You know, but I think that was what Phil, you know, the guy who started the magazine was the, was our techie. I think it was just before you came, Catherine. It's actually, when,

Katherine Druckman (23m 46s):
When I started, so Linux journal was very much a, a print magazine and that was the focus and there was a website that was kind of frankly, an afterthought. It was some blogs and it didn't really share content at all. And so when I came on, one of the, the, the main things that I was involved in is moving it to a digital product and making it more of a, yeah. More of the thing, you know, the, the, the magazine digital magazine platform. And so that was a huge undertaking digital first, that's what they call it. Yeah, exactly. Digital first. And, and, you know, we grew the traffic tremendously from, from going to, starting with the Drupal five site, the traffic went way, way up, but even more so actually after I think about a year and a half later, maybe two years later when we moved to Drupal six, the traffic to shot up, because I think that, you know, this Drupal itself grew to the point where it was easier for me to make it into a very robust publication.

Katherine Druckman (24m 50s):
So, you know, we were basically, you know, I was standing on Travis's shoulders at that point, benefiting from all the great work that all the Drupal contributors were doing. That, that's the thing that I actually enjoy most about the kind of work that I get to do is I, I like to think that the work that I'm doing now is helping people who used to be in my position make a better online experience for their users, because I've already gone through that gauntlet. And, and now, you know, I may be able to give back a little bit to help people who are in that position.

Travis Carden (25m 27s):
And that kinda makes that actually transitions nicely into one of the things that I wanted to say about mentorship and open source. And that is that everything that you do in the open can be a, a gift if you will, of mentorship to people. You'll never know. When I got started with Drupal, I was not a backend developer to call me a developer at all, would have been generous. I think. So I began really as a, a site builder and a steamer, and back in the Drupal six days, there was a, my favorite starter theme.

Travis Carden (26m 10s):
And this is the base theme that I built my customer designs on top of called Zen

Katherine Druckman (26m 18s):
Linux journal was Zen. Drupal 6 Linux Journal was the Zen theme.

Travis Carden (26m 24s):
I love Zen and Zen was, was kind of my first real open source experience. The thing that really got me hooked if John Albin hears this, thank you. I remember the first I wanted to build a Zen sub theme. I opened up the code for the page template and the template file in the Zen itself had this dozens or hundred line comment at the top of the file that says things like this is the page template file contained in here is the outermost shell of the HTML, along with the body and the, the section containers, which incidentally, we followed X design pattern for doing our columns.

Travis Carden (27m 22s):
And then it listed to an A-list of part article that explained the, the Genesis and the theory behind this particular CSS column strategy. And then just went on with all of these kinds of, we made this decision because of X here's a link to an article that that explains how you can do it. And this one file in this open source project became like a mentorship experience for me that the maintainer couldn't have known was coming. And I don't, I don't even know how long it, the, those details have been in the code by the time that I read them.

Travis Carden (28m 3s):
And I'm sure he has, or they wasn't just John Alvin, of course, but I'm sure the contributors to that project, they could never have guessed how many people that they were kind of from a distance, helping them build their careers like they did mine. And so when I think about mentorship person to person, like one-on-one kind of, mentorship is incredible, and it's a huge thing that deserves discussion. But I kind of think about everything that I do with software as being a mentorship activity, writing the documentation for people who will use my software, writing inline code comments, the way that I structure and design my code code reviews that, that I do like code reviews are one of, one of the least appreciated forms of mentorship.

Travis Carden (29m 4s):
I feel like if, if you're working on a project that is big or significant enough that you have multiple contributors, I hope that you're reviewing each other's code because that's such a great context for knowledge transfer. And I've tried to use my code reviews kind of like to create an experience similar to what I had with the Zen theme framework, where if I find something in your code that I think has an opportunity for improvement, I'll comment on it. And then I'll say, here's why this should be X instead Of Y.

Travis Carden (29m 44s):
And here's a link to maybe API documentation or an article, or even a book or something that discusses the paradigm that a motive that would motivate me to do it this way, instead of the way that it's been done here. And I've, I've been in a software architect role and a team lead kind of role over a number of years. And I've been able to watch people who were on my teams grow over time. And a lot of that growth has just been as a result of those kinds of, by the way, kind of interactions, you know, like never a kind of let's sit down once a week and, and have a, let's have a mentorship today.

Travis Carden (30m 33s):
You know, like never anything that formal just transfer the knowledge you have whenever you bumped into people.

Katherine Druckman (30m 40s):
Yeah. Well, I have to say I've learned a lot of my efficiency strategies from you, Travis. It's pretty great. Yeah. It's funny. Like, I, I think, you know, before I, I was hired, actually, I don't know, probably Adam Hoenich or somebody asked me as an interview question, something about code reviews and how I felt about it and my reaction, because I kind of inferred through, by what he was saying that some people don't like code review, don't like their code to be reviewed. And I remember putting that's the craziest thing I've ever heard. Why would you not want somebody better at this than you to review code? I was like, are you kidding? Yes, please, please review my code and tell me how to do it better because yeah, I just remember thinking that was so exciting because I had had so such limited opportunities for that before, but anyway, yes.

Katherine Druckman (31m 24s):
Review each other's code for sure. What can you tell us about how Orca came to be?

Travis Carden (31m 30s):
Orca has been around as a project slightly longer than I have been in engineering. The kind of idea of it, I think was percolating for quite a while. And as I said, I was brought into engineering specifically to make it a reality to execute on it and create the application and kind of shepherd the program from that technical perspective, it, it became something actually usable and only six months or something like that.

Travis Carden (32m 16s):
We, I had the good fortune of working closely with you and Nick on getting the lightning integration going very early on. And there was, there was working software there in that partnership, if you will, long before it really gained any traction or stability sufficient to really deploy fully. But after, after it did become the standard and not only the standard in terms of policy, but actually rolled out and then people actively, depending on it, it wasn't too long before we got approval to open source it.

Travis Carden (33m 6s):
And so I don't know if that was within the first year or something and for your listeners, that's when it really starts to matter entirely.

Katherine Druckman (33m 18s):
Yeah, that was my next question. So I guess I didn't realize how, how young a project it was when I came along. So that's interesting, but yeah. So, so tell us a little bit more about, I mean, I suppose the decision to open source, it is probably pretty obvious just because that's in sort of the company DNA, but so what is that process like? How, you know, how has the process of taking something that is internal and releasing it out in the wild

Travis Carden (33m 46s):
In principle? That can be very simple. It can be as little as just making your get hub or get lab repository or whatever version control platform you use can be as little as just making it public. In the case of Orca and many similar PHP packages, it involves publishing it on package just for composer based installation. And at Aquia, we have an official process that we go through to evaluate candidates for open sourcing to ensure that they abide by certain quality standards and that they don't include proprietary information or open other vulnerabilities for the company.

Travis Carden (34m 37s):
And then kind of, kind of comes down to have a good read me and go for it.

Katherine Druckman (34m 43s):
Right. Awesome. Well, it helps also. I'm sorry, go ahead.

Petros Koutoupis (34m 46s):
Oh, I was going to say in my experience, especially with companies that I've worked with and we're talking about right now, I'm with HPE and prior to that, well, Catherine, you know, said earlier, you know, Craig, like I was part of an acquisition at HP, but prior to that, IBM, our process was very, very, very legal, heavy. We had attorneys specializing in, in open source licensing and just doing their due diligence to make sure, like you mentioned, make sure that we are only putting out our code, our code that is also not cannot be seen like bits and pieces

Travis Carden (35m 38s):
As, as proprietary, but it was just like a very heavy legal process. And I don't know if that's the experience you've had as well at Aquia. The process has not been that heavy on the legal side. There are a small number of related Gates, but on the whole, as Catherine said, the, the Genesis of Aquia was as a Drupal based company and employees that really began in the Drupal community.

Travis Carden (36m 22s):
And so there's always been a very strong open source ethos. And aside from the lawyers and the folks whose job description involves more corporate mentality, I suppose, legal self protection kinds of interests amongst the developers and everyone in the product and engineering organizations to say nothing of professional services there, they already have a strong bent toward open-source contribution. In fact, that's one of the things that I think draws people to execution and delivery roles within Aqua.

Travis Carden (37m 4s):
I know it was for me.

Katherine Druckman (37m 10s):
Yeah. Well, I mean that's yeah. The aforementioned millennium, Falcon analogies, that's kind of, I mean, getting to be that involved in not only contributing to Drupal, but again, being mentored by, I mean the absolute top triple developers, it was D I mean, you know, sign me up, pinch me. Yeah. So I would also guess when you're, when you're taking a project and releasing it into the wild, as I said, really, it open-sourcing, it, it helps when you write really good code and not to, you know, I don't know, actually, I, I make no apology about plugging Travis, his skills again, Travis writes elegant code.

Katherine Druckman (37m 54s):
He writes really beautiful readable code, and he's quite passionate about code quality. So when your code is already really, really solid, I, I feel like it must be easier obviously to then go release it. Whereas I, I often wonder sometimes if, if there is a cleanup process, you know, when, when things are released, which I suspect you didn't really have to do

Travis Carden (38m 19s):
Well, I am, I am, as you say, I'm passionate about these things and very detail oriented. And so it may be the case that I was better prepared with my particular projects to open source that other people might be. But I think that when you know that there are going to be thousands of potential eyeballs on your work product that that tends to make you want to make it really high quality. I, I really enjoy that pressure, that motivation to do great work and to make it accessible, that I enjoy writing documentation that is adequate for someone to come into my project from the outside and be able to understand it and become an effective user or even a contributor.

Travis Carden (39m 25s):
So regardless of the complexity of what I'm releasing, there's going to be a certain amount of cleanup and preparation for putting it out there.

Katherine Druckman (39m 37s):
So if I am a company that is not Acquia or I'm any Drupal developer, and I want to start using Orca, how do I do that? I mean, obviously you go to the project page, which I will link to in the description of this podcast, but how, how hard is it going to be for somebody new to Orca to get set up with Orca?

Travis Carden (39m 58s):
Sure. Well, maybe I should preface my answer to that question by explaining who would want to use Orca. And the answer to that question is that anyone who has an interest in the ongoing functioning of Drupal adjacent software, including Drupal modules, themes, installation profiles, as well as composer packages or anything else that is meant to work within or alongside the functioning Drupal application, such people are the target users of Orca.

Travis Carden (40m 49s):
And the service that work provides for those people is that it creates a repeatable standard test scenario. The creates a fixture, which an automated testing terminology just means whatever has to be true in the universe for your tests to succeed. And so in the case of a, a Drupal module or other extension, you need to have a functioning Drupal site.

Travis Carden (41m 29s):
So Orca, which incidentally stands for official representative customer application. And it, it spins up not just any Drupal site or application, but it's intended to be kind of a codification of Acquia, his idea of what a standard or best practices Google out about the patient looks like. And so it, it spins that up creates an application that's, that's realistic in nature.

Travis Carden (42m 10s):
It actually reflects something that would go into production so that it can be testing in a real life or life-like situation. And then it performs various static code analysis tests and discovers and runs automated tests. And then it does this in a number of different permutations of scenarios, including multiple versions of Drupal core, including only the package under tests or all the packages that the company in question owns.

Travis Carden (42m 52s):
So having prefaced with that general high level explanation of what work it is, and the intended user would be someone who has modules to test, or who had that is modules that they own maintain or are responsible for, or that uses a relatively consistent set of modules that they want to ensure are going to keep working with one another now, and in the future, like maybe a professional services organization that almost always uses, you know, 10 or 15 of the same modules together.

Travis Carden (43m 32s):
So they want to know if they're going to break. And your direct question then was how would a company gets started and to get started with Orca. There are a few different ways to use it the most central way. The chief design goal or use case I should say is for using Orca to drive the automated tests on a CI or continuous integration platform or workflow. And Orca comes with Travis CTI integration templates and the like out of the box.

Travis Carden (44m 18s):
And for most of Acquia is internal users implementing. It has been a mere matter of having a Travis CGI account and copying in the example Travis got, yeah, we'll file that and making minor tweaks to it. Some of our internal products have done almost nothing, but copy the template file and change the name in it for an, for a company external to Acquia there's. There would be that that is copying the template files, getting them in place on Travis CI, or, or, you know, turning on your Travis CI integration.

Travis Carden (45m 3s):
And then you just need to make ORCA aware of the packages that you're going to be pulling in and testing, which is also a pretty simple matter of just specifying them in a YAML file and telling ORCA where to find it.

Katherine Druckman (45m 18s):
Does it work with, with other CI platforms? Like, can I use it with not Travis like Jenkins or something else?

Travis Carden (45m 28s):
Yeah. Orca can be, can be used in innumerable different contexts. I should explain that when we talk about work we're there, there may be three things that we have in mind. One would be the project or the program that we talked about at Acquia. Another would be the total integration, which involves Travis CI by default. The other is the Orca CLI or command line interface, right? The terminal application for which the Travis CI scripts and configurations are really just a thin interface.

Travis Carden (46m 17s):
Really. It's just a handful of scripts that contain the CLI commands kind of pre pre plugged in if you will, but the CLI can be used in any context. I like gets nomenclature. That is the version control system get talks. The documentation talks about the porcelain interface and the plumbing interface, the app, if humorous nomenclature, referring to the fact that a in a, in a person's bathroom, they have the interface that they want to interact with.

Travis Carden (47m 2s):
Like the same, for example, the porcelain and the average person. That's all they care about. But when the plumber comes, they want to get under the sink and work with the actual pipes and everything underneath the kind of polished outer facade and Orca is the same way. There's, there's the porcelain interface. That's all that most people care about or need to care about, which is just the Travis CGI thing. Configuration just pop that script in. And it goes, and that's all that most people want to know, but under the hood, there's the CLI command, which is very robust.

Travis Carden (47m 48s):
It can function and be made to function in pretty, pretty much any context where you have a, a Knicks shell like bash. So making it work on circle CI, or github actions, or just vanilla Jenkins or whatever you like is, would be a fairly straightforward thing. You could probably, even in many of those contexts, just pop the Travis CI scripts that are already part of Orca and plug them into whatever YAML file or whatever is the integration point for your CI system.

Katherine Druckman (48m 33s):
If we kind of zoom out a little bit and think more broadly beyond Orca, beyond Drupal, even. So I think a lot of people, I mean, I'm sure a lot of people listening are automated testing, continuous integration experts, but a lot aren't. And as we know, a lot of people don't write tests for, for their code. I'm wondering if you could talk to us a little bit about automated testing theory and, and first of all, why, why you should be writing tests because maybe it's not that obvious, you know, why is it worth putting in the time to write automated tests? Number one, and number two, what's the easiest way to get started? And the most, let's say, sustainable way to get started.

Petros Koutoupis (49m 17s):
I think that second question is probably the most important one, because many companies struggle with just kicking it off. I mean, you, you've got an idea. You, you know, you, you know, which tests you want run, it's just getting that implemented and into an existing framework. That's the struggle.

Travis Carden (49m 38s):
Yeah. Yeah. I would agree with that. And it has been not only my observation, but also my personal experience that, that first hurdle getting over that first hurdle from zero to anything non zero or using automated testing is a huge hurdle. And it's daunting for probably most people. So if I were to take your questions in the order that you asked them, Catherine, I would say that the reason to actually let's start with really simple, what is automated testing. And I would say that automated testing is simply the process of creating some sort of automation that exercises your software.

Travis Carden (50m 28s):
That is to say it runs your software and observes the outcome to ensure that it does what you expected to do in a given context. And there are a lot of different frameworks or platforms for this skipping past that we'd asked me, why would you want to do that? There are a few important reasons. The reason that I like to start with that most people don't talk about is that it helps your design and it helps it in a few different ways.

Travis Carden (51m 10s):
The first way is that if you have to make your software in a way that a robot could also use it, you're forced to design it with certain quality attributes that wouldn't come up. If you were just writing it for your primary use case. And as it happens, those attributes that make it more testable are also the attributes that increased quality, like helpful abstractions, cohesiveness of design, single responsibility principle for, for the nerds, the Liskov substitution principle that probably won't even talk about it.

Travis Carden (51m 55s):
But one must, one must use the name. If one's talking about automated testing and keeping out a little bit of all of those design principles of which there are many are our principles, which when followed improve the actual quality of your software, they make it more maintainable, easier to understand and writing for automated testing or with automated testing in mind, forces you to observe those patterns as well. So that's, that's the first reason is it just nudges you in the direction of better software design. And secondly, it forces you to think about the outcome of your software before you think about the mechanics.

Travis Carden (52m 42s):
If you begin by asking yourself, how am I going to verify that this works, it puts you in a different mindset. Then the programmer tends to be in when they begin most programmers. When you sit them in front of the keyboard, start immediately thinking about what design pattern am I going to use here, or what, what director or class structure, or even which language am I going to choose and start thinking about low level implementation details. And instead of thinking about what matters first, which is business outcomes, you know, we only have jobs doing this information type work or programming work that we enjoy so much because it brings business value to someone.

Travis Carden (53m 35s):
So if you start by asking those business questions, which is what's necessary to be able to test your outcomes, then that's going to get you thinking in a more productive way as someone who's actually bringing value to their employer and to the world. Now, once you're thinking in those terms, bringing value, then it becomes evident that you want your work to continue to bring value over time as the marketplace and the employers technical and other constraints change over time as technology evolves and people depend on new versions of the S that you're aiming at, or the server software that you're deploying on once, once you maintain more than one piece of software.

Travis Carden (54m 35s):
And probably before that, it's just too much to keep up with all the updates, the patches, the security fixes, and everything that go into the long, long list of pieces of software that Minneapolis station depends on. So you want a robot to be doing that. You, you want an automated process that can run on a regular basis without human intervention and can just try different permutations and then ping you on Slack or send you an email when something breaks.

Travis Carden (55m 15s):
And goodness for containers helps simplify a lot of the various software implementations and library revisions and so forth. It's just, if you're right, it becomes a huge headache. When, when, when you, when you try to think about all the variations and combinations of softwares and software versions that you have to work with.

Katherine Druckman (55m 39s):
So I wondered if maybe so based on my personal experience, and I, I guess I, I mentioned that I never talk about what I do, but I thought I should. I wanted to make sure to actually tell people that listen to this show, what I actually do in real life. So I mentioned, I used to work with Travis and, and I used to work on a Drupal distribution that Acquia maintains called Lightning. I think Travis mentioned it earlier. Now I actually work on a different Drupal 9 distribution. That is an opinionated Drupal 9 distribution called Aqua CMS for running low code sites on, on the Acquia hosting platform. It's, it's very cool. I mean, obviously because I help make it, but it's, I like to think of it as a more approachable Drupal.

Katherine Druckman (56m 23s):
I think people are a lot of, are a little bit intimidated by Drupal's learning curve, but, and I think this, this solves that a bit, but what I was going to say that, you know, in the, in the context of automated testing is absolutely essential to our development process, but at the same time it can, what, how would I put this? It can create bottlenecks. Like we recently struggled quite a bit with, I don't know, just developer experience in terms of, you know, just if you, I, I'm not gonna say overdo testing, but you need to structure your tests in such a way that you are not sabotaging your own efficiency, I guess is if, if that's, and I wondered if, if Travis could speak to that a little bit, because frankly I long conversation with Travis, this is how, what helped me solve this problem for our team.

Katherine Druckman (57m 17s):
And that's just, you know, in terms of breaking up jobs into different groups and, and, and, and testing in a way that is again, developer friendly and, and only, you know, running certain tests when you need to and not, you know, at other times. And I just kind of wondered if we could go into a little bit of that theory because it might help other people.

Travis Carden (57m 41s):
Sure. So automated tests are software. I think that that recognition is fundamental to thinking well about the question you are, the subject you raise here, when you consider that automated tests are themselves software, a number of insights arise. The first of which is that they are also subject to quality concerns. And it is very easy to write fragile tests in the same way that you can write fragile production code.

Travis Carden (58m 22s):
And as most people, when they first start to understand things, dive in with more enthusiasm than understanding people who are learning how to do automated testing can easily follow their excitement past their level of competence and into quagmires of over specified tests, over complicated tests, tests that depend on too much extraneous detail and therefore become costly to maintain costly, to execute some of the dynamics that you're referring to.

Travis Carden (59m 5s):
When you talk about a testing set up, being costly for a development team or having a negative effect on the developer experience includes such things as first of all, the difficulty of setting up your test framework. One of the importances of ACI set up in general and as Petrus mentions containers, as one way of solving for this kind of problem is that not every developer has to solve the problem on their own. I remember other teams that I've been on in the past, where you spend the first week with your, of your onboarding, just having someone more senior, sit down with you and help you set up your computer and install an amp stack and get your IDE going and XD bug plugged in and, and everything.

Travis Carden (1h 0m 7s):
And it it's a huge drain. And then you still have the, it works on my machine problem. There's maybe nothing more frustrating for a developer than to have something work beautifully on their own development environment, and then to commit it to the repo or push it up to a pre-prod environment and have it not do the same thing that it did for them locally. So that is one problem that on the one hand can be addressed by automation, but on the other hand can also cause a difficulty you have to, you have to get your developers used to a workflow that involves CD or CGI CD being continuous delivery.

Travis Carden (1h 0m 57s):
I think we already said that CIA has continuous integration. We didn't it. In other words, it's kind of a, a mindset and a discipline, and it just has to be learned a little bit possibly. Well, there are two, two other challenges that can arise that seemed to me to be in competition for the next most significant. The first one is the difficulty of maintaining working tests. As a system evolves over time, I talked about tests being fragile or brittle over specifying tests, other forms of creating tests that are just hard to maintain.

Travis Carden (1h 1m 48s):
If you, for example, let's take a common Drupal scenario, say you've got a test where you've got a config form. You need to navigate to a given URL and then log in as a given user and then interact with the form in some way, if your test is written in such a way that it depends on, let's say a CSS class being present or used in a, in a specific way on your front page in order to log in, then something that your theme or does could break one of your automated tests that has nothing whatsoever to do with that.

Travis Carden (1h 2m 31s):
Just because your tests needed you to log in before it could exercise the form. And now when that CSS class moves or goes away, your, your test that was depending on that suddenly starts breaking. And nobody knows why the reason would be because it was dependent on irrelevant or extraneous details and writing code. That's not subject to that kind of weakness in automated tests is a challenge. I won't go further into that, I think at the moment, but the, the other, or the next issue that stands out to me is the simple overhead of keeping tests working when you make changes to the system.

Travis Carden (1h 3m 25s):
I think anybody who's been working with automated testing in a team context, or even on their own, frankly, has probably had the experience of making a change in one part of the software and then having tech tests completely on the other side of the application break. And sometimes they break for good reasons because every time for me, every time for you kidding, I'm kidding. Sometimes it feels that way. You know, sometimes they break for good reasons because the change that you made actually broke business logic or, or application functionality, other times your tests break, just because they were fragile tests.

Travis Carden (1h 4m 10s):
And especially when you're getting started or Katherine, as you talk about getting an, a team started with these kinds of practices, when they're unfamiliar with them, that's, that's a real challenge to figure out just to, to navigate this new space.

Katherine Druckman (1h 4m 26s):
So, yeah, I think we've been, we've been going awhile now. It's probably about time to wrap it up. Doc, do you have any final thoughts?

Doc Searls (1h 4m 33s):
I think this is really good stuff. And thank you a lot for being on here. This is a, it's a good show.

Travis Carden (1h 4m 40s):
Pleasure. Thank you for having me

Katherine Druckman (1h 4m 43s):
Really helpful to a lot of open source developers out there and people who are interested in contributing. So if you've made it this far, thank you so much for joining us. Thank you to Petros and thank you to Travis for, for being here. And, you know, if you have any questions about any of this, please feel free to reach out to us through the podcast and, you know, we can forward your questions along to, well, frankly, anyone relevant, what are we? We're info@reality2cast.com. You can reach us there.